インシデントの対応と復旧を管理する

学習の目的

この単元を完了すると、次のことができるようになります。

• インシデントへの対応方法について説明する。
  
• 組織がインシデントから復旧する際の各自の役割について説明する。
  

インシデントに対応する

組織を保護するためにリスクを検出し、アーキテクチャの実効性を監視する方法がわかりました。次は、実際にインシデントが発生したときに、インシデントへの対応とインシデントからの復旧における各自の役割について説明します。サイバーセキュリティアーキテクチャをどれほど慎重に実装したとしても、悪意のある各攻撃を阻止する特効薬にはなりません。いつかはインシデントが発生し、サイバーセキュリティのインシデントへの対応においてサイバーセキュリティアーキテクトが重要な役割を果たすことになります。

サイバーインシデントとは、システムのセキュリティポリシーに対する違反で、機密性、整合性、可用性に影響を及ぼすもの、あるいはシステムへの不正なアクセスあるいはその試みのことです。サイバー犯罪者もビジネスと同様イノベーションにしのぎを削っており、ビジネスでのサイバースペースの利用が拡大するにつれ、犯罪者が侵害に成功した場合の潜在的な報酬も増大しています。現在では、アーキテクチャシステムの確固たる設計、標準コントロール、定期的な脆弱性テストやセキュリティ評価のすべてが、攻撃を成功させるリスクを軽減する対策として効果を上げています。それでも攻撃が起こってしまった場合、サイバーセキュリティアーキテクトはどのような役割を果たすのでしょうか?

サイバーセキュリティアーキテクトは、その役割の一環として、サイバーセキュリティインシデント対応チームが迅速かつ効率的に対処するための情報をすぐさま確認できるように組織に準備しておきます。インシデント対応チームは、インシデントへの対応アプローチを体系化し、損害を最小限に抑え、復旧に要する時間やコストを軽減する方法で、セキュリティ侵害の余波に対処します。その際、システムの連動関係を理解し、攻撃や環境全体への影響を追跡するために、ネットワークのダイアグラム、システムアーキテクチャ、レイアウトなど、IT インフラストラクチャに関する情報にアクセスする必要があります。  

さらに、設計してデプロイするアーキテクチャは、設計を始める時点からインシデント対応を念頭に置き、インシデントへの対応時間と修復時間をいかに短縮するかを検討し、環境全体のすべてのエンドポイントを可視化するものでなければなりません。たとえば、進行中の侵害を特定するためのロギングなど、検出コントロールを配置します。ビジネスができるだけ早く通常業務に戻れるように、バックアップなどの是正措置をアーキテクチャ設計に必ず組み込みます。こうした要素を早い段階から考慮していれば、実際にインシデントが生じたときに、インシデント対応チームがその攻撃で「誰が」「いつ」「どこで」「何を」「どのように」行ったのかをすぐさま把握することができます。また、アーキテクチャに精通するコーチとして状況を説明すれば、インシデント対応チームが必要なだけの技術的な知識や経験を踏まえて、インシデント関連のデータを分析することができます。 

最後に、アーキテクチャの設計時に、組織全体で、あるいは業界のパートナー組織とリアルタイムのネットワーク防御データを自動的に交換できる設計を取り入れる必要のある場合があります。この結果、情報共有が可能になり、集合体として防御が強化されます。

組織がサイバーインシデントから復旧できるようにする

インシデントの根本原因を修復し、影響を受けたシステムにパッチを適用して強化したうえでオンラインに戻すときも、サイバーセキュリティアーキテクトは復旧に向けて極めて重要な役割を果たします。根本原因分析では、問題を確実に修復し、再発を防ぐ目的で、質問をしたり、その経路をたどったりして、攻撃の発端となった脅威ベクトルを特定します。サイバーセキュリティアーキテクトの役目は、アーキテクチャを設計するごく初期の段階から対応と復旧についてあらかじめ検討しておくことです。攻撃に直面しても事業運営を継続するレジリエントな IT インフラストラクチャを開発して実装するにはどうすればよいのでしょうか?

サイバーセキュリティアーキテクチャを設計してデプロイするときは、サイバーインシデントへの速やかな対応と復旧を可能にするアーキテクチャを構築するにはどうすればよいかを初めから検討しておく必要があります。アーキテクチャを計画してテストするときは、自然災害、犯罪行為、妨害行為などの評価やシナリオを使用して、アーキテクチャ、事業継続、その他の対応計画をテストできます。また、攻撃を仕掛けた敵対者を正しく特定する適切なデータを収集しているかどうかも検討します。 

さらに、インシデント対応チーム、事業継続チーム、災害復旧チームがシステムの通常運用への復旧に取り組む際、こうしたチームに技術面のサポートを行うことがあります。事業継続チームは、予期せぬインシデントによってクリティカルなシステムがオフラインになった場合に、事業運営や中枢機能に深刻な影響が及ばないようにします。災害復旧チームの目的は深刻な惨事の影響から組織を守ることで、混乱後にミッションクリティカルな機能の維持または早急な再開に取り組みます。将来の攻撃に備えてセキュリティを強化し、問題の根本原因の再発を防ぐためにシステムアーキテクチャへの変更を提案することも、サイバーセキュリティアーキテクトの役割である場合があります。さらに、上記のチームと協力して、セキュリティインシデントをシミュレーションし、対応時の活動を練習してテストする予行演習を実施して、インシデントや災害に備えます。 

ここでは、アルバート・アインシュタインの「今日ある問題は、その問題が生じたときと同じレベルの思考では解決できない」という名言を心に留めておきます。

サイバーセキュリティアーキテクトは常に、組織を将来のセキュリティ状態に移行させる方法を考えています。システム設計の最初の段階から積極的にこうした移行方法を模索し、インシデントの後にも振り返って同じことを行えば、組織の IT 環境のセキュリティを確保できます。 

習得度チェック

では、これまでに学んだ内容を復習しておきましょう。次の習得度チェックは簡単な自己診断テストで、採点対象ではありません。左側の説明を右側の対応するカテゴリにドラッグしてください。全項目を結び付けたら、[送信] をクリックして習得度をチェックします。もう一度挑戦する場合は、[再開] をクリックしてください。

まとめ

このモジュールでは、ビジネスニーズとセキュリティの脅威を特定する方法と、組織を保護する目的で多層化セキュリティ機能を配備するサイバーセキュリティアーキテクチャを設計して実装する方法について学習しました。また、脆弱性評価やシステムセキュリティ評価でリスクを検出して組織を保護する方法や、実装したアーキテクチャの実効性を監視する方法の詳細も学びました。最後に、サイバーセキュリティアーキテクチャの設計のごく初期の段階からインシデント対応と復旧について事前に計画しておくことの重要性と、インシデント対応担当者がアーキテクチャや侵害されたおそれのある地点を把握できるようにサポートする各自の役割についても習得しました。 

「サイバーセキュリティアーキテクチャ」モジュールで確認した情報と共に、サイバーセキュリティアーキテクトになるためには何が必要なのかについて理解が深まったものと思います。Trailhead のサイバーセキュリティの学習ハブにアクセスすると、サイバーセキュリティリスクアーキテクチャ分野や他の分野の職務に就くために必要な、需要の高いサイバーセキュリティのスキルの詳細や、実務でセキュリティに携わる人々の詳細を知ることができます。 

リソース

• 外部リンク: Deloitte: Cyber Incident Response (サイバーインシデント対応)
  
• 外部リンク: NIST: Computer Security Incident Handling Guide (コンピューターセキュリティインシデントの処理ガイド)
  
• 外部リンク: Center for Internet Security (CIS): Incident Response and Management (インシデントの対応と管理)
  
• Trailhead: サイバーセキュリティの学習ハブ