継続的な情報収集により脆弱性を正しく理解し、適時判断するのが危機対応のポイント――Armoris 取締役専務 CTO 鎌田敬介氏：ITmedia エグゼクティブセミナーリポート（1/2 ページ）

危機対応にはベストプラクティスは存在しない。国内外の企業で実際に起きたサイバー危機対応事例をベースに、組織的な対応としてどのようなポイントが課題となりやすいのか、平常時にはどのような備えが必要なのだろうか。

[山下竜大，ITmedia]

　アイティメディアが主催するライブ配信セミナー「ITmedia エグゼクティブセキュリティセミナー 2022 春」の基調講演に、Armoris（アルモリス）取締役専務 CTOで、一般社団法人金融ISAC 専務理事兼CTO、および『サイバーセキュリティマネジメント入門（出版社：きんざい）』の著者である鎌田敬介氏が登場。「実事例から学ぶ、サイバー起因の危機事象発生時における組織的対応のポイント」をテーマに講演した。

Armoris（アルモリス）取締役専務 CTO、一般社団法人金融ISAC 専務理事兼CTO、『サイバーセキュリティマネジメント入門（出版社：きんざい）』の著者 鎌田敬介氏

危機対応は100％の対応ではなく被害を最小限に食い止める活動

　そもそも危機対応とは何か。鎌田氏は、「危機対応とは、組織や関係者に致命傷をもたらしかねない事象が発生したときに、100％の対応を目指すのではなく、被害を最小限に食い止める活動です。このとき重要視されるのは、渉外や広報の観点です。技術的な対応だけでなく、レピテーションリスク（会社に対する評価）に対し、対外的な情報提供やアナウンス、いわゆるパブリックリレーションズの観点も重要なポイントです」と話す。

　サイバー攻撃に対し、企業や組織としてのレスポンスが必要なときに何をすべきかは「ISO22320: 社会セキュリティ −危機管理− 危機対応に関する要求事項」に規定されている。ISO22320は、サイバー攻撃やインシデント、脆弱性など、さまざまな観点でも役に立つ、組織的に考えるべきポイントをまとめたもの。想定外を含むあらゆる場面を含むため、特定の被災に直面したときの事業継続手段（BCP）とは異なり、非定型の対応を想定している。

　ISO22320における危機対応の3つのプロセスは、以下の通り。

（1）指揮・統制（または調整）

　危機対応の準備活動として、権限や要員、組織、立ち上げプロセス、リーダー、文書、人的要因などがある。

（2）活動情報

　全体像を認識し、情報提供の適時性、正確性、使いやすさ、包括性、客観性など、品質管理が求められる。

（3）連携・協力

国や自治体、公共機関の活用や協力、他の組織、関係者と協力したり、専門家の相互派遣、組織間連携、情報共有したりすることが規定されている。

　この3つのプロセスのコアとなる活動は、観察、情報収集、評価、計画、意思決定、実行、フィードバックのループを繰り返すこと。これにより、危機対応が可能になる。レジリンス協会では、ISO22320の内容をどの程度考慮できているかを簡易に可視化することを目的とした「ISSO22320簡易版チェックリスト（※1）」を公開している。

　鎌田氏は、「サイバー起因の危機事象は、インシデント、脆弱性がテーマとなります。インシデントは、サイバー攻撃による個人情報漏えいの発覚、ランサムウエア実行犯の声明、サービスや業務の停止などです。一方、脆弱性は、一般的な脆弱性情報の公開の他にも、未知の脆弱性による大規模攻撃（ゼロデイ）や、自社の独自アプリの脆弱性の発見などがあります」と話している。

（※1）ISSO22320簡易版チェックリスト

ここ10年でも非常に注目度の高かったLog4jの脆弱性

　世界中で大騒ぎになり、日本では12月10日の朝から話題になり始めたLog4jの脆弱性は、ここ10年で話題になった脆弱性の中でも非常に注目度の高いものだった。Log4jは、設定によりきめ細かなログ保存をすることができるJavaのロギングユーティリティーである。今回見つかったのは、遠隔の第三者が細工をした文字列で、任意の行動を実行できる深刻度の高い脆弱性で、通称「Log4shell」と呼ばれる。

　鎌田氏は、「Log4shellは、遠隔コード実行（Remote Code Execution）が可能な脆弱性で致命的なものです。攻撃手法が改良されていったことも特徴の1つで、継続的な情報収集が必要になります。これに伴い、Log4jが何度もアップデートされています。脅威度を判定するCVSSの基本値は10.0で、最も高いと評価されていますが、CVSSは、本来は基本値だけでなく、現状値、環境値の3つのパラメータで判断することが重要です。Log4shellも同じように、基本値が高いから危ないという感覚では過剰な対応となってしまう可能性のある脆弱性の1つです」と話す。

　Log4shellの基本的な攻撃の流れの例としては、以下の通り。（GovCERT.chが公開する攻撃フロー図に基づく）

（1）攻撃者がHTTPリクエストヘッダにJNDI lookupとして攻撃コードを仕込む

（2）JNDIの文字列がlog4jに渡されログに記録される

（3）Log4jによりJNDI lookupが実行され、evil.xa にLDAPプロトコルでクエリを発信

（4）Ldapサーバが悪意のあるjavaクラスを含む応答を返す

（5）Javaがクラスを実行する

　「Log4jが生成するログの中に攻撃コードを含む外部からの入力文字列が組み込まれますが、log4jが動いているから必ず危ないわけではありません。外部からの文字列がHTTPヘッダに含まれ、log4jが処理して、アプリケーションがログとして保存することが必要です。そのためアプリケーションの仕様により、外部から入ってきた文字列を保存しない仕様になっていれば攻撃は成立しにくくなっています」（鎌田氏）。

　この図の攻撃フローの想定においてLog4shellの対策例は、以下の通り。