「海の向こうの“セキュリティ”」第198回公開

今月分が公開されました。

韓国の「ボイスフィッシング」被害、犯罪発生件数減少のカギになった4つの要因
https://internet.watch.impress.co.jp/docs/column/security/1483691.html

「海の向こうの“セキュリティ”」第197回公開

今月分が公開されました。

インシデント報告義務の厳格化など、EUのサイバーセキュリティ法「NIS2」最終版では何が変わった?
https://internet.watch.impress.co.jp/docs/column/security/1477038.html

「海の向こうの“セキュリティ”」第196回公開

今月分が公開されました。

EUが提言する外国からの情報操作・干渉とサイバーセキュリティの関係のあり方
https://internet.watch.impress.co.jp/docs/column/security/1469875.html

「海の向こうの“セキュリティ”」第195回公開

今月分が公開されました。

米CISAが公開、「選挙インフラ」に関する風説に惑わされないための“信頼できる情報”
https://internet.watch.impress.co.jp/docs/column/security/1461235.html

「海の向こうの“セキュリティ”」第194回公開

今月分が公開されました。

CISAが米連邦政府機関を対象に発行、脆弱性検知の改善などを義務付ける「拘束力のある運用指令」の中身
https://internet.watch.impress.co.jp/docs/column/security/1452812.html

「海の向こうの“セキュリティ”」第193回公開

今月分が公開されました。連載開始から丸16年、今回で17年目に入りました。

ソフトウェアサプライチェーンをセキュア化するためのガイダンス、推奨事項を要チェック
https://internet.watch.impress.co.jp/docs/column/security/1444853.html

「海の向こうの“セキュリティ”」第192回公開

今月分が公開されました。

情報の共有範囲を指定する「TLP」、新バージョン2.0ではどう変わった?
https://internet.watch.impress.co.jp/docs/column/security/1438180.html


[2022-09-15 15:05 追記]
JPCERT/CC の皆さんの翻訳による、TLP 2.0 の定義と利用ガイドライン日本語版がリリースされました。
https://www.first.org/tlp/docs/v2/tlp-v2_ja.pdf

「海の向こうの“セキュリティ”」第191回公開

今月分が公開されました。

脆弱性対応を「攻撃可能性」の観点で優先順位付けした場合はどうなる?
https://internet.watch.impress.co.jp/docs/column/security/1429318.html

「海の向こうの“セキュリティ”」第190回公開

今月分が公開されました。

FBI長官が語る、ロシアや中国など国家関与型サイバー攻撃の脅威動向
https://internet.watch.impress.co.jp/docs/column/security/1422627.html

「海の向こうの“セキュリティ”」第189回公開

今月分が公開されました。

MSPを狙うサイバー攻撃の世界的な増加、各国のサイバーセキュリティ当局が提案する推奨事項とは?
https://internet.watch.impress.co.jp/docs/column/security/1414563.html

「海の向こうの“セキュリティ”」第188回公開

今月分が公開されました。

EUの「協調的脆弱性開示」の実態、そこから見る先行事例としての日本の取り組み
https://internet.watch.impress.co.jp/docs/column/security/1408080.html

libevent 2.1.12 で LibreSSL 3.5.2 を使うためのパッチ

libevent 2.1.12 では LibreSSL 対応のコードが含まれていますが、LibreSSL 3.5.2 では OpenSSL との互換性が改善されているため、逆に以下のようなパッチが必要に。

--- ./openssl-compat.h.ORG      2020-07-05 21:01:34.000000000 +0900
+++ ./openssl-compat.h  2022-04-24 18:01:14.297526107 +0900
@@ -40,7 +40,7 @@
 #endif /* (OPENSSL_VERSION_NUMBER < 0x10100000L) || \
        (defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER < 0x20700000L) */

-#if defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER >= 0x20700000L
+#if defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER >= 0x20700000L && LIBRESSL_VERSION_NUMBER < 0x30500000L
 #define BIO_get_init(b) (b)->init
 #endif

MIT Kerberos5 1.19.3 で LibreSSL 3.5.2 を使うためにパッチは不要

LibreSSL 3.5.2 は OpenSSL との互換性が改善されたこともあり、MIT Kerberos5 1.19.3 ではパッチを適用せずにそのまま使用可能。

「海の向こうの“セキュリティ”」第187回公開

今月分が公開されました。SIM3 の新バージョンなどを紹介しています。

ナショナルCSIRTの能力を改善するための「CSIRT成熟度フレームワーク」、新バージョンで更新された内容は？
https://internet.watch.impress.co.jp/docs/column/security/1400650.html

MIT Kerberos5 1.19.3 で LibreSSL 3.4.2 を使うためのパッチ

MIT Kerberos5 1.19.3 で LibreSSL 3.4.2 を使うためには以下のパッチをあてれば良さそう。

diff -ru ../krb5-1.19.3.ORG/src/plugins/preauth/pkinit/pkinit_crypto_openssl.c ./src/plugins/preauth/pkinit/pkinit_crypto_openssl.c
--- ../krb5-1.19.3.ORG/src/plugins/preauth/pkinit/pkinit_crypto_openssl.c	2022-03-11 15:54:31.000000000 +0900
+++ ./src/plugins/preauth/pkinit/pkinit_crypto_openssl.c	2022-03-15 19:01:13.708955462 +0900
@@ -185,7 +185,7 @@
     (*_x509_pp) = PKCS7_cert_from_signer_info(_p7,_si)
 #endif

-#if OPENSSL_VERSION_NUMBER < 0x10100000L
+#if (OPENSSL_VERSION_NUMBER < 0x10100000L) || defined(LIBRESSL_VERSION_NUMBER)

 /* 1.1 standardizes constructor and destructor names, renaming
  * EVP_MD_CTX_{create,destroy} and deprecating ASN1_STRING_data. */

「海の向こうの“セキュリティ”」第186回公開

今月分が公開されました。

OSSのセキュリティリスクにはどう向き合う？ 「Log4Shell」脆弱性から学ぶ取り組み
https://internet.watch.impress.co.jp/docs/column/security/1393776.html

「海の向こうの“セキュリティ”」第185回公開

今月分が公開されました。

米CISAが公開、悪用された脆弱性をまとめた「カタログ」から見えた対策の実態
https://internet.watch.impress.co.jp/docs/column/security/1385527.html

「海の向こうの“セキュリティ”」第184回公開

今月分が公開されました。

リモートワークに伴う「燃え尽き症候群」のセキュリティリスクとは
労働者のセキュリティに関する意識調査 ほか
https://internet.watch.impress.co.jp/docs/column/security/1379243.html

「ENISA Threat Landscape 2021」における推奨事項の参考訳

「ENISA Threat Landscape 2021」を紹介する記事

「海の向こうの“セキュリティ”」第183回
コロナ禍で増えた偽情報や「悪意のない脅威」への対応として気を付けたいこと
https://internet.watch.impress.co.jp/docs/column/security/1372358.html

もご参照ください。

欧州ネットワーク情報セキュリティ機関（ENISA：The European Union Agency for Cybersecurity）が、2020年4月から2021年7月までのサイバーセキュリティの脅威状況をまとめた年次報告書「ENISA Threat Landscape 2021」において、対象期間中に顕著だった脅威として挙げた9つのうち、以下の8つについて対処のための推奨事項などが紹介されています。

• ランサムウェア（Ransomware）
• マルウェア（Malware）
• クリプトジャッキング（Cryptojacking）
• 電子メール関連の脅威（E-mail related threats）
• データに対する脅威（Threats against data）
• 可用性と完全性に対する脅威（Threats against availability and integrity）
• 偽情報 - 誤報（Disinformation - misinformation）
• 悪意のない脅威（Non-malicious threats）

ENISAによる推奨事項は、今回の報告書の執筆に多くの方が関与しているためと思われますが、表現形式（文体）が揃っていませんし、対象者の異なる項目が整理されないまま混在しているため、全体像を把握しづらいと感じる方も少なくないでしょう。それでも、様々な専門家らによる見方や「ある考え方」を列挙したものとして十分に参考になるところがあるはずです。とにかく、あくまで参考資料の1つとして使うべきものであり、何らかの標準規格や義務となるものではないことにご注意ください。

以下は各脅威に対する「RECOMMENDATIONS」を翻訳したものです。あくまで参考訳にすぎませんので正確を期する場合は必ず原文を確認してください。

ランサムウェア

• セキュアで冗長性のあるバックアップ戦略の実施。
• IDとアクセス管理の実施と監査（最小特権と職務分離）。
• ユーザ（特権ユーザを含む）のトレーニングと意識向上。
• 開発環境と本番環境の分離。
• インシデントに関する当局や業界との情報共有。
• 既知のランサムウェアサイトへのアクセスの制限。
• 権限を付与されたデバイス、ユーザ、およびプロセスに対して、IDおよび認証情報（credentials）を発行、管理、検証、無効化および監査を行うべきである。
• 最小権限と職務分離の原則を取り入れた、アクセス許可と権限付与を管理すべきである。
• 開発環境と本番環境の分離。※訳註：上記項目と重複しているので誤記と思われる。
• ランサムウェア対応・復旧計画を定期的にテストし、進化するランサムウェアの脅威に関して、リスクと対応の想定とプロセスが最新であることを確認すべきである。
• 既知のランサムウェアサイトへのアクセスをブロックするセキュリティ製品またはサービスの使用。
• CISAが開発したITおよびICS（industrial control system、産業用制御システム）ネットワークを対象としたツールであるRRA（Ransomware Readiness Assessment）を実行し、様々なレベルのランサムウェアの脅威への備えに対するセキュリティを評価する。
• 攻撃や攻撃の試みを当局に報告し、その拡散を抑制する。
• システムの監視による感染の早期確認。
• 最近のランサムウェアの動向、開発状況、防止策の提案を常に把握する。

マルウェア

• 電子メール、ネットワーク、Web、アプリケーションシステムを含む、全ての適用可能なプラットフォーム（サーバー、ネットワークインフラ、パーソナルコンピュータ、モバイルデバイスなど）の入出力チャネルに対してマルウェア検知を実施。
• SSL/TLSトラフィックを検査し、Webサイト、電子メール通信、モバイルアプリで送受信される内容をファイアウォールで復号できるようにする。
• マルウェアの検知機能（インテリジェンスによるスレットハンティング）とセキュリティインシデント管理の間のインターフェースを確立し、効率的な対応能力を確立する。
• マルウェア情報の共有やマルウェアの緩和のためにマルウェア解析に使えるツールを使用する（MISPなど）。
• 感染発生時に従うべきプロセスを定めたセキュリティポリシーを策定する。
• 様々なセキュリティツールの機能を理解し、新しいセキュリティソリューションを開発する。ギャップを特定し、多層防御の原則を適用する。
• 悪意のある電子メールに対するメールフィルタリング（またはスパムフィルタリング）を使って実行可能な添付ファイルを削除する。
• アンチウイルスのテスト結果を定期的に監視する。
• コンテナインフラにパッチ管理を使用する。
• SIEM（Security Incident and Event Management）ソリューションを使ったログ監視を活用する。具体的なログのソースとしては、アンチウイルスの警告、EDR（Endpoint Detection and Response）、プロキシサーバーのログ、WindowsのEventおよびSysmonログ、IDS（Intrusion Detection System）のログなどが挙げられる。
• PowerShell機能へのアクセスを無効化または削減。

クリプトジャッキング

• ユーザのデバイスのバッテリー使用量を監視し、CPU使用量が不審な急増を見せている場合は、ファイルベースのマイナーの存在をスキャンする。
• 一般的なクリプトマイニングのプロトコルのWebフィルタリング、および広く使われているクリプトマイニングのIPプールのIPアドレスとドメインのブラックリスト化を実施する。
• ネットワークの異常を監視し、マイニングプロトコルをブロックする。
• アンチウイルスプログラムやクリプトマイニングをブロックするブラウザのプラグインを使ったエンドポイント保護を導入する。
• 定期的にセキュリティ監査を実施し、ネットワークの異常を検知する。
• 新たに生まれる脅威や脆弱性から保護するために、強固な脆弱性およびパッチの管理を実施する。
• よく知られているエクスプロイトに対するパッチ適用や修正を行なう。
• ホワイトリストを使って、未知の実行ファイルのエンドポイントでの実行を防止する。
• 許可リストを使って、既知の実行ファイルのみエンドポイントでの実行を許可する。
• 一般的なクリプトマイニングの実行ファイルを監視およびブロックする。
• ユーザのクリプトジャッキングに対する意識を高めるために投資する。セキュアなブラウジング行動については特に。
• セキュリティ意識向上トレーニングの中で、クリプトマイニングについて議論する。

電子メール関連の脅威

• 疑わしいリンクや添付ファイルの見分け方と報告の仕方について定期的にユーザトレーニングを実施する。
• 電子メールゲートウェイにスパムフィルターを導入し、シグネチャとルールを常に更新する。可能な限り、フィルター（アンチスパム、アンチマルウェア、ポリシーベースのフィルタリング）の自動メンテナンス機能を備えたセキュアな電子メールゲートウェイを使用する。
• 従業員の受信箱にルアーが届く頻度や可能性を減らすために、電子メールゲートウェイにセキュリティコントロールを導入する。
• いかなるセキュリティ侵害の影響も抑えられるように、知っておくべき（need-to-know）アクセスポリシーを導入する。
• サイバーセキュリティの脅威に関する敵対者の戦術や技術についてMITRE ATT&CKフレームワークを参考にする。
• 組織外から送信された電子メールは受信前に自動的にマーク付けされるように。
• アカウントに多要素認証（MFA）を導入する。
• 疑わしい悪意のあるドメインの存続期間とその所有者を確認する。存続期間が1年以内の場合は詐欺の可能性がある。
• 可能な限り、機械学習技術を用いてリアルタイムでフィッシングサイトを識別するセキュリティソリューションを適用する。
• メールクライアントにおいて、コードの自動実行、マクロ、画像データのレンダリング、メールリンクのプリロードを無効化して（クライアントを）頻繁に更新する。
• スパムメールを減らすための標準規格のいずれかを導入する。
• 可能な限り、重要な金融取引または機密情報のやりとりには、デジタル署名または暗号化を用いたセキュアな電子メール通信を導入する。
• 可能な限り、ネットワークレベルで受信メールおよび送信メールの両方に対して不正や異常の検知を実施する。
• 電子メールの送信元に絶対の自信を持てない場合は、ランダムなリンクをクリックしたり、添付ファイルをダウンロードしたりしない。
• 閲覧するWebサイト、特に細心の注意を要するWebサイト（銀行のWebサイトなど）の場合は、ドメイン名にタイプミスがないか確認する。脅威主体は通常、正規のドメインに似た偽のドメインを登録し、ターゲットを「フィッシングする（釣る）」ために使用する。HTTPS接続を期待するだけでは十分ではない。
• 全てのオンラインサービスに強力且つ固有のパスワードを使用する。様々なサービスで同じパスワードを使い回すことは、深刻なセキュリティ問題であり、常に避けるべきである。全てのオンラインサービスに強力且つ固有の認証情報を使用することで、アカウントが乗っ取られる可能性のあるリスクを、影響を受けるサービスのみに限定することができる。パスワード管理ソフトウェアを使用すれば、一連のパスワード全体の管理が容易になる。
• 攻撃者が悪用できないように、問い合わせや登録、購読、フィードバックの入力フォームが自分たちのWebサイト上でどのように機能するかを確認し、必要に応じて検証ルールを追加する。
• 不要な添付ファイル、悪意のある内容を含む電子メール、スパム、不要なネットワークトラフィックを検出するコンテンツフィルタリングを導入する。
• 知らない送信者からの電子メールやSMSメッセージに含まれる新しいリンクには反応しないようにし、且つ、何よりも、そのようなリンクをたどる際に認証情報を入力してはいけない。

データに対する脅威

• サイバーセキュリティ意識向上計画を策定および維持する。ソーシャル・エンジニアリングやフィッシング・キャンペーンを特定するためのトレーニングやシミュレーション・シナリオを従業員に提供する。
• 知る必要がある人にだけ知らせる（need-to-know）原則の下、ユーザのアクセス権を制限する。従業員以外の者のアクセス権を無効化する。
• インシデント対応チームを設置・維持し、且つインシデント対応計画を頻繁に評価する。
• 機密性の高い情報/個人情報を発見・分類し、転送中および保存中のそのようなデータを暗号化する手段を講じる。つまり、データ損失防止機能を導入する。
• 検知、警告ツール、およびデータ侵害の抑制と対応の能力に関する投資を増やす。
• 強力なパスワード（パスワード管理）と多要素認証（MFA）の使用を強制する強力なポリシーを策定・維持する。
• オンプレミスおよびオフプレミスのリソースの両方に対するセキュリティを提供するために、最小権限方式を採用したモデルを検討する（例：ゼロトラスト）。
• ガバナンス、リスク管理、およびコンプライアンスチームと連携するためのポリシーと計画に投資し、且つそれらを策定する。
• データをセキュアなIT資産にのみ保存する。
• 担当者を定期的に教育・訓練する。
• 脆弱性スキャン、マルウェアスキャン、データ損失防止（DLP）ツールなど、データ漏洩の可能性を回避するためのテクノロジーツールを使用する。データとポータブルシステムとデバイスの暗号化、およびセキュアゲートウェイを導入する。
• データ侵害が発生した場合、事業継続計画（BCP）が重要となる。この計画では、保存されているデータの種類、その場所、データセキュリティと復旧対策を実施する際に発生する可能性のある法的責任の概要を示している。BCPには効果的なインシデント対応が含まれており、このようなインシデントによる損害について対処・管理・是正することを目的としている。
• セキュリティ計画を強化するために企業内で「スレットハンティング」を実施する。スレットハンティングはセキュリティオペレーションセンター（SOC）チームの熟練したメンバーによって行われ、積極的に（先を見越して）脆弱性を特定し、侵害を防止する。
• 速度ベース（velocity-based）のルールのようなポリシーは、特にペイメントカード取引におけるID詐欺を軽減するために使用できる。有効な取引のマシンデータは最適なポリシー定義のための十分な情報を提供することができる。
• シングルサインオン（SSO）の認証手段が利用可能な場合、ユーザは同じデジタル認証情報のセットで複数のアプリケーションにアクセスすることができる。SSOを使用することで、ユーザアカウントおよび保存された認証情報の数を最小限にすることが強く推奨される。
• 電子メールで送られてきたURLやランダムにアクセスしたURLは、そのIPアドレス、そのIPに結びついたASN、ドメインの所有者、およびこのドメインと他のドメインとの関連性に基づいて、それ以上の手順を踏む前に、まずチェックすべきである。
• クラウドサービスを採用している組織は、強力なクラウドセキュリティオペレーションを行うべきであり、顧客の個人情報を保護するために、オンプレミスのストレージ、プライベートクラウドのストレージ、パブリッククラウドのストレージを同時に使用するアーキテクチャを選ぶべきである。
• ハッキングを防ぐため、機密データにはTLS 1.3（ephemeral（一時的な）鍵を使用）などの強力で最新の暗号化方式を使用する。
• 全てのID文書およびそのコピー（物理的またはデジタルなもの）を無権限アクセスから適切に保護する。
• ID情報は未承諾の受信者に開示すべきでなく、電話、電子メール、または対面での要求に答えるべきではない。
• 不要な添付ファイル、悪意のあるコンテンツを含むメール、スパム、不要なネットワークトラフィックを排除するためにコンテンツフィルタリングを導入・使用する。
• データ損失防止（DLP）ソリューションを使用する。

可用性と完全性に対する脅威

• サービス妨害対応計画は、レジリエンスが優先される組織にとって不可欠なものであり、システムのチェックリスト、対応チーム、効率的なコミュニケーションとエスカレーション手順を統合すべきである。
• セキュリティプロセスは、システムおよびネットワークの進化とライフサイクルに追従し、適応する継続的な活動であるべきである。
• 緩和の取り組みを拡大・強化するためには関連組織間の連携と調整が重要である。
• オンプレミス型ソリューション、DDoSスクラビングサービス、またはハイブリッド型ソリューションを使用したDDoS防御を導入する。
• ネットワークファイアウォールとWebアプリケーションファイアウォールの両方を使用する。前者は、コンテンツデリバリネットワーク (CDN)、ロードバランサー、拡張可能なリソースなど、ピーク時のトラフィックを軽減するアプローチと組み合わせることができる。後者は、DDoSがインジェクションまたはXSSに基づいている場合に特に有効である。
• マルウェアの感染を抑制するためにアンチウイルスソリューションを使用する。
• ネットワークベースの侵入検知システムを使用する。
• パッチを速やかに適用する。多くの従業員が個人所有のマシンを業務に使用している場合は特に。組織は、システムアップデートの優先度を高くし、リモートでユーザに配信すべきである。
• トラフィックプロファイリングとトラフィックフィルタリングは、DDoS攻撃の指標となる異常なトラフィックパターンの兆候を早期に警告するのに役立つかもしれない。
• 異常なトラフィックフローを検知してトラフィックをネットワーク外にリダイレクトするDDoS軽減サービスに加え、受信トラフィック量を制限するレートリミッターを使用する。
• WebベースのAPIを保護し、関連する脆弱性を監視する。
• DNSを要塞化する、またはマネージドDNSサービスも検討する。キャッシュポイズニングや同様のエクスプロイトはDNSSECの使用によって防ぐことができるが、DNSSECの仕様をサポートするマネージドDNSベンダを使用するとなお良い。
• 複数のプラットフォームにわたる検知、調査、および対応能力を組み合わせたマルチレイヤーのソリューションを検討する。
• 進化する脅威環境にセキュリティ態勢を適応させるプロアクティブなアプローチに基づいて、脅威インテリジェンスプログラムを構築する。
• 能力開発と備えを強化するためにスタッフのトレーニングとサイバーセキュリティ演習を利用する。

Webベースの攻撃に対する緩和策として挙げられているのは以下の通り

• 悪意のあるリクエストを識別してフィルタリングするためにWebアプリケーションファイアウォール（WAF）を設置する。新たに発見された脆弱性からシステムを保護するために、WAFは常に更新されていなければならない。
• インジェクションベースの攻撃から守るためにコードベースを強化する（例：入力サニタイズ、パラメータ化されたステートメント）。
• ゼロデイ攻撃を避けるためにソフトウェアを速やかに更新する。
• Webサーバを適切に設定・堅牢化し、インターネットに公開されている全てのサーバに定期的にパッチを適用する。
• 攻撃ツール、脆弱性スキャナ、侵入テストサービスを使って、セキュリティ強化の効果を継続的に検証する。
• ログを有効にし、そのログを検査する。

偽情報 - 誤報

緩和策には技術的な領域と非技術的な領域がある。一方では、トレーニングや意識向上、ファクトチェックやデバンキング（debunking、偽りを暴く行為）、規制、そしてコミュニケーションを対象とした、手作業や人力によるアプローチが緩和策となる。その一方で、ソーシャルネットワークを通じた誤報/偽情報の拡散を抑制するための技術的な解決策も重要である。また、誤報/偽情報攻撃の影響をさらに抑えるためには全ての当事者の協力が重要である。

一般的に、誤報や偽情報のキャンペーンを緩和するためには以下のようなアプローチが考えられる。

• トレーニングと意識向上: 偽情報攻撃に対処し、また更にあらゆる電子メールやレポートを評価するために従業員に備えさせるプロセスである。これに関連して、ワクチンのようなアプローチに従うプレバンキング（prebunking）は、少量の誤報/偽情報にユーザをさらすことで、後に誤報/偽情報に対処できるように備えさせることを目的としている。また、ゲーミフィケーションに着目し、ソーシャルメディアのフィードをシミュレーションすることで、ユーザに本物のニュースとフェイクニュースの見分け方を教えるアプローチもある。例えば、オンラインゲーム「Go Viral!」はCOVID-19にまつわる一般的な誤報をプレバンク（prebunk）することを目的としている。
• 誤報/偽情報の識別: 偽コンテンツを識別したり、コンテンツに適切にアクセスしたりするためのガイドラインが登場している。例えば、出典、著者、相互参照、引用データ、日付を調べることが挙げられている。
• ファクトチェックと偽りのストーリーのデバンキング（Debunking False Stories）: 誤報や偽情報の影響を減らすために非営利団体と政府機関の両方によって多くの取り組みが行われている。これらの関係者は誤った情報やフェイクニュースを掲載した出版物やコンテンツをデバンキングすることを目的としている。COVID-19にまつわるインフォデミック（infodemic、根拠のない不確かな情報が伝染病のように広まって現実社会に悪影響を及ぼす現象）を阻止するために多くの取り組みが行われてきている。
• 規制: 新たな規制（提案中のECデジタルサービス法など）や、ソーシャルネットワークを含むフェイクニュースを拡散するサイトを処罰する動きが進められている。GDPR（General Data Protection Regulation、一般データ保護規則）の文脈では、ターゲット広告を可能にする情報へのアクセスを制限することが可能である。したがって、GDPRは、フェイクニュースを広めるためのツールでもあるオンラインターゲット広告による個人データの処理を規制することで誤報対策に役立つことができる。つまり、GDPRは、オンラインターゲット広告を規制することで、間接的に、より広いやり方で誤報の制限にも貢献できるかもしれないのである。偽情報に関する実施規範（Code of Practice）は、産業界の支援を受けて偽情報と戦うための自主規制基準を提供している。EUは先日「ハイブリッドな脅威への対抗に関する2016年の共同枠組み（Joint Framework）とハイブリッドな脅威に対処するためのレジリエンスの向上と能力の強化に関する2018年の共同コミュニケーション（Joint Communication）の実施」に関する第5回進捗報告書（Fifth Progress Report）を発表した。報告書では、自由で公正な選挙を守る必要性、戦略的コミュニケーションの役割とハイブリッド脅威に対抗するための卓越した研究拠点（centre of excellence）、各国間の協力の重要性、急進化や過激主義に対するレジリエンスについて述べられている。
• 戦略的で透明性のあるコミュニケーション: 事実に基づいたものであり、政治的なコミュニケーションとは別のものである。
• 技術的な対抗策
  • 検索エンジンのアルゴリズムの書き換え
    • ソーシャルネットワークの検知と緩和:
      1. 偽アカウント（重複した情報や冗長な情報を投稿するアカウントなど）の停止
      2. 偽ニュースをフィルタリングしてフラグを立てる仕組み
      3. 自動活動（ボットなど）の削減
      4. オンライン・アプローチに基づくフェイクニュース検出のための人工知能ツールおよびプラットフォーム
      5. 大規模な偽情報の拡散を特定するためのデータサイエンス/ビッグデータの可視化
      6. 一般市民を対象としたファクトチェッカーを搭載したモバイルアプリおよびチャットボット
      7. 一般市民を対象としたウェブブラウザの拡張機能
      8. デジタルメディア情報リテラシーのプラットフォームおよびツール
  • 広告による啓発活動
  • 信憑性評価、疑わしい行動に対するフラグ立て
  • デジタル電子透かし（ビジュアルコンテンツへのタグ付け）
  • センチメントトラッキング（sentiment tracking）とダークウェブモニタリングを中心とした保護戦略の策定

悪意のない脅威

• 従来のセキュリティに物理的な保護と災害復旧を加えた、セキュリティに対する全体的なアプローチを採用しなければならない。
• クラウドサービスだけでなく、悪意のない脅威を考慮したリスク管理プロセスを採用すること。
• 適切な資産管理とともにシャドーIT（特にシャドーIoT）を回避すること。
• エラーや設定ミスをタイムリーに発見するための継続的な監視とテスト。
• 組織的ポリシー: 基本的なサイバー対策が不十分なことが多い一方で、攻撃はより巧妙になり、サプライチェーンや人的要因への依存度が高まっている。後者の場合、AI（例：ディープフェイク）を利用した攻撃がヒューマンエラーを引き起こす可能性があり、完全に技術的な方法で防ぐことは非常に困難である。したがって、ヒューマンエラーを軽減するためには、強固な組織的ポリシーが必要となる。
• データとセキュリティに対するガバナンスベースのアプローチを採用し、データを徹底的に検討し、それに従うことができるようにすること。
• 脆弱性に対処するためのパッチ管理計画: 適切な計画とは、全てにパッチを当てることを要求するのではなく、必要なものにパッチを当てることを意味し、最終的には、例えば、リスク管理プロセスから得られる優先順位を使用すること。
• パッチ管理のより広い定義を採用するなら、アップデートを受け取る組織だけでなく、アップデートを推進する組織（ソフトウェアおよびハードウェアの製造者など）にも言及すべきである。IoTの脆弱性は何年も前から存在しているケースが多く、誰が実際にパッチを発行すべきかを理解するのは困難である。
• アップデートはセキュアな方法で配信されるべきである（例：Tesla Model Xのコード署名の欠如）。
• パッチ管理ではサプライチェーンのリスクを考慮しなければならない。
• あらゆるタイプのユーザに対するトレーニングと意識向上。適切なトレーニングを受けた開発者は、最新の言語やフレームワークを活用して、より多くのセキュリティ保証を与えながら、製品に多くのセキュリティおよび安全対策を導入することができる。これは、メモリの安全性に関する問題のような長年の課題を抱えていないセキュアなIoTデバイスを開発するためにも極めて重要である。管理者は、デフォルトでセキュリティが確保されているソリューションを利用して、自らの活動におけるセキュリティ（およびコンプライアンス）の側面についてトレーニングを受けるべきである。最後に、エンドユーザが、例えばインシデントの初期兆候を認識し、適切な瞬間に適切な選択ができるようになるためにはトレーニングと啓発が不可欠である。
• 自然現象に対してより強固な物理的インフラのエンジニアリング、および予期せぬ出来事や（何らかの）不足に際しても事業継続を保証するユーティリティの適切な管理。
• 全てのものが悪意のあるものであり、信頼できないものであると考える、ゼロトラストのセキュリティアプローチ。このアプローチでは、場所や所有者による暗黙的な資産の信頼から、「アイデンティティは新たな境界線である」とのモットーに従って認証と認可が明示的に与えられる動的なアプローチへと移行する。
• サイバーセキュリティと物理的セキュリティを統合しなければならないとの、経営者レベルの意識の向上。物理的な攻撃が増加しているにもかかわらず、企業のリーダーは自分たちの会社が物理的な脅威のターゲットになる可能性があることを信じようとしない。
• 復旧計画とバックアップはシステムのレジリエンス（回復力）を高めるための基本である。
• 物理的な侵害は攻撃を助長する可能性がある。例えば、物理的なアクセスコントロールの脆弱性、追尾者（tailgater）、無人デバイスは敵対者が攻撃を実行する際に役立つ可能性がある。
• 内部設備（暖房、換気、空調）のエラーや誤作動は、火災、湿度、不安定な電源供給などによりITインフラにダメージを与える可能性がある。
• 気候変動はシステムの可用性と耐障害性に新たな課題をもたらしている。洪水、火災、地震の発生率は増加しており、全てのインフラに与える影響は指数関数的に大きくなっている。リスク評価、災害復旧技術、人材育成が不可欠である。

「海の向こうの“セキュリティ”」第183回公開

今月分が公開されました。

コロナ禍で増えた偽情報や「悪意のない脅威」への対応として気を付けたいこと
ENISAが年次報告書「ENISA Threat Landscape 2021」を公開
https://internet.watch.impress.co.jp/docs/column/security/1372358.html