インシデント後のレビューの進め方

dotshock | shutterstock.com

あなたの企業がサイバー犯罪者に攻撃される可能性があるとしましょう。しかし攻撃が遅れて発見されたものの、無事にかわされて、ビジネスへの大きな影響がなかったとします。その後、いつもどおり業務を続け、その件を忘れてしまうのは逆効果です。なぜなら、攻撃者はあなたのシステムを侵害し、防御措置を回避する方法を見つけたからです。

だからこそ、この時点でインシデント後のレビューが不可欠です。これは構造化されたプロセスであり、企業は以下を分析します。

• うまくいったこと、
• うまくいかなかったこと、そして
• 今後のパフォーマンスをどのように改善できるか。

これは一見簡単に思えますが、堅牢なインシデント後レビュー戦略を開発するために注意すべき重要な事項があります。それが何であるかは、さまざまなセキュリティ専門家との対話の中で明らかにしました。

1. 迅速に対応する

分析に関してだけでなく、セキュリティインシデントではタイミングが非常に重要です。インシデント後のレビューを実施するまで数週間または数か月が経過するのを待つと、重要な要素が忘れられるリスクが高まり、セキュリティ意思決定者とそのチームは攻撃の完全な概要を把握できなくなる可能性があります。

IT コンサルティング企業 Protiviti の執行役員デイビッド・テイラー氏は、できるだけ早く対応することをお勧めします。「インシデント直後のレビューにより、すべての詳細がまだ新鮮であることが保証され、さらに緊急性の感覚も伝わります」。チーフアドバイザーによると、レビューの参加者はこの方法で、イベントの正確なタイムラインを作成することもできるということです。

このタイムラインをどのように構成すべきかは、ヘザー・クローソン・ハウギャン氏が知っています。データ保護に特化した法律事務所CM Lawの共同創設者兼エグゼクティブパートナーです。「まず最初に、何が起こったか、最初の問題の兆候から対処まで、正確に記録することが重要です。」

これにより、すべての関係者が、どこで遅延またはエラーが発生したのか、そしてどこで発生しなかったのかを理解することができます。「基本的には、インシデントを理解できる「ストーリー」に形作り、そこから適切な教訓を引き出すことです」と法務専門家は説明しています。

2. 根本原因分析を実施する

インシデント後のレビューの必須要素は、根本原因分析（ルートコーズアナリシス）です。少なくとも、将来のインシデントを防ぎたいのであれば。

IT サービスプロバイダー Presidio のフィールド CISO であるマイケル・ブラウン氏もこの考え方に同意しています。「インシデントの根本原因を特定することは必須です。チームは、技術的な脆弱性、人的エラー、プロセスまたは技術的なギャップかどうかを判断する必要があります。これによってのみ、症状の治療だけでなく、原因に対応できることが保証されます。」

3. ギャップを特定する

インシデント後のレビューには、確立されたプロセス（例：インシデント対応計画）に関するセキュリティチームのパフォーマンスを評価することも含まれるべきです。Protiviti のマネージャーであるテイラー氏によると、チームの能力を段階的に向上させるためには不可欠です。「革新的な最適化に関する貴重な情報を提供し、トレーニングのギャップを特定し、対応段階の非効率を排除することができます。」

フィールド CISO のブラウン氏が明かしているように、Presidio はこの点で模範を示しています。「インシデント後のレビューの一環として、検出、対応時間、コミュニケーション、調整、プロセス遵守など、さまざまな分野でインシデント対応チームのパフォーマンスを評価しています。」

4. ビジネスへの影響を分析する

セキュリティインシデントの影響を完全に理解することは、定量的および定性的分析の両方を含むべき多層的な問題です。セキュリティ意思決定者のブラウン氏によると、前者は例えば、財務損失、失われた市場シェア、または失われた顧客契約などの側面を含むべきです。

後者は、次のような問題に対処すべきです。

• ビジネス継続性は永続的に影響を受けたのでしょうか？
• 主務官庁に時間内に通知されたのでしょうか？
• 評判上の損害は生じたのでしょうか？

5. 背景を把握する

インシデント後分析の別の重要な要素は、セキュリティインシデントの背景です。これをキャプチャすることは、インシデント用のタイムラインを設定する際に重要です。すべての関係者が学べるものです。

「事後レビューでは、決定が下された背景が多すぎてスキップされることがあります」とセキュリティ研究者のエイリーン・レバレット氏は批判し、次のように付け加えます。「インシデントがどのように発展したかを文書化してください。結果だけではなく。インシデントは時間とともに発展し、これを扱うチームは事前にすべての事実にアクセスできることはめったにありません。」

新しい発見 – 例えば攻撃の入口、その範囲、または攻撃者が使用したツールに関するもの – はチームの調査目標を変更する可能性があると、レバレット氏は言います。「封じ込め努力として始まったものは、すぐに広範な復旧プロジェクトになる可能性があります。変更がいつ、なぜ行われたかを追跡する場合にのみ、後で講じられた措置を理解することができます。」

6. 部門間で協力する

インシデント後のレビューを主導することは、CISO の責任です。または他のセキュリティまたは IT リーダーシップ。ただし、潜在的に洞察を提供する可能性がある他の部門の人員を関与させることをお勧めします。例えば、セキュリティ専門家のレバレット氏は、ガバナンス、法務、リスク管理の同僚でインシデント後チームを拡張することを推奨しています。「これらは、インシデントの根本原因をより広い、より広い政策ギャップと関連付けることができるかもしれません。」

レバレット氏の意見によると、財務部門と人事部門を含めることも賢明です。また、インシデントの種類と重大度に応じて、取締役会メンバーも含めることができます。後者は戦略的な優先順位付けを示し、技術的な知見をガバナンス レベルでのリスク議論と結び付けるのに役立つと、この専門家は確信しています。

「重要なのは、すべての関係者が立場や役割に関係なく、同等の発言権を持つことです」と Protiviti のテイラー氏は付け加えています。これはセキュリティインシデントをより深く理解するだけでなく、協力的な環境も確立します。

7. 責任追及を避ける

インシデント後のレビューの枠組みでは、「犯人探し」を行うことはおそらく生産的ではありません。したがって、IT 弁護士のハウギャン氏も、学習と最適化に焦点を当てることをお勧めします。「責任追及は前に進むことはありません。イベントの実際の進行を明かし、意思決定プロセスを理解し、エラーに寄与したすべての要因を特定することが重要です。このアプローチは、ツール、トレーニング、およびポリシーに関連する将来の戦略的な決定を支援することができます。」

レバレット氏も責任追及の文化には反対しています。「特定の個人が正しい決定を下したかどうかは関係ありません。むしろ、『与えられた状況下で、チームは適切な決定を下す能力があったのか？』や『より良いドキュメンテーション、異なるツール、またはより多くの予算がより速く、より良い結果をもたらしたのか？』といった質問に答える必要があります。」

8. 行動を起こす

インシデント後のレビューで得られたすべての知見は、その後何も起こらなければ相対的に無用です。つまり、知見に続いて具体的なアクションが必要ということです。

これを最善の方法で実装するために、法務専門家のハウギャン氏は、最適化が必要な場所、それがいつ起こるべきか、誰がそれに対して責任があるかを詳細に文書化することをお勧めします。「これらの改善には、ソフトウェア更新、ポリシーの変更、または新しいトレーニングイニシアチブが含まれる可能性があります。関係なく、この事後処理により、インシデント後のレビューが本当に有用になります。そうしないと、実行可能な推奨事項が失われます。全体は学問的な演習以上のものではありません」と、データ保護専門家は述べています。(fm)