SOMPO CYBER SECURITY
脅威アクターによるサイバー攻撃が日々発生しており、デジタル環境を利用するあらゆる組織・企業が潜在的なターゲットとなっています。
クラウドサービスを始めとするIT技術の発達・普及、また経済活動におけるサプライチェーンの拡大が、サイバー攻撃者や犯罪組織に格好の機会を与えています。
このような環境下で、組織がインシデント対応(レスポンス)のための体制を確立し、サイバー攻撃に備えることは必須の課題となっています。
この記事では、インシデント対応の重要性について説明した後、必要な準備、具体的な対応フロー、そして組織のサイバー・レジリエンスを向上させるためのさらなる改善策について紹介します。
記事に関するご意見・お問い合わせはこちらへお寄せください。
(SOMPOホールディングス、損害保険ジャパンなどグループ各社へのお問い合わせはご遠慮下さい)
セキュリティ・インシデントは、サイバーセキュリティが目標とする情報の機密性、完全性、可用性を侵害する事象です。
米国標準技術研究所(NIST)は、セキュリティ・インシデントを次のように定義しています。
この定義は、アメリカ国防総省が防衛企業に対し義務付けし、また我が国の防衛省も参照しているセキュリティ基準NIST SP800-171でも利用されています。
An occurrence that actually or imminently jeopardizes, without lawful authority, the confidentiality, integrity, or availability of information or an information system; or constitutes a violation or imminent threat of violation of law, security policies, security procedures, or acceptable use policies.
(法的権限なしに、情報または情報システムの機密性、完全性、または可用性を実際の危険あるいは差し迫った危険にさらす事象。または法律、セキュリティポリシー、セキュリティ手順、許可ポリシーへの違反、あるいは違反のおそれからなる事象。)
つまり、我々が普段利用している情報システムやそのシステムが取り扱う情報、あるいはセキュリティポリシーやサイバーセキュリティ関連法規を脅かす事象全般を指すといえます。
セキュリティ・インシデントの厳密な定義は出典によって様々であり、また抽象的でイメージが掴みにくいものもあります。
「では具体的にどのようなパターンがあるのか」ということを明示するため、本項ではニュース等で目にする機会の多い事例を参考に、いくつかの種類を紹介します。
このように列挙するだけでも、セキュリティ・インシデントがとても身近に潜むリスクであることがわかります。
なおセキュリティ・インシデントの定義には、いわゆるサイバー攻撃やインサイダー攻撃(内部犯による)に加えて、事故や災害等による情報の毀損等も含まれます。
インシデント対応フローとその確立に焦点を置く本記事では、外部・内部の攻撃者によって生起するセキュリティ・インシデントに対象を絞って説明を進めていきます。
サイバーセキュリティ・リスクは、企業・組織がマネジメントすべき重要課題です。
冒頭に記載したとおり、IT・デジタル環境とサプライチェーンの広がりに伴い、サイバーセキュリティリスク、つまりセキュリティ・インシデントの発生によるリスクの発生確率や影響も増大を続けています。
インシデント対応は、速やかに事態を収束させ、また被害を最小化するための極めて重要なプロセスです。
インシデント対応を行うための体制整備や計画が欠如していた場合、いざセキュリティ・インシデントが発生した場合に適切に対応できないのみならず、インシデントに起因する損害や信用の低下を招きかねません。
インシデント対応の重要性を簡単にまとめると次のとおりです。
セキュリティ・インシデントの兆候を検知したとき、速やかに対応できるかどうかで、その後の結果が大きく変わります。
例えばエンドポイント製品やEDRが不審な活動やマルウェアの存在を検知したとしても、この事象をスピード感をもって処理できない場合、攻撃者がさらに組織の環境を侵害する猶予を与えてしまいます。
今日のランサムウェア、例えばLockBitやロールシャッハ等は、高速な暗号化アルゴリズムの利用や断続的暗号化により、従来と比して高速な暗号化能力を行使します。
BlackByteランサムウェアのように、組織のシステム侵入から短期間で暗号化を行う戦術を運用するグループもあるため、初動対応の重要性は高まっています。
セキュリティ・インシデント発生時に、組織内のコミュニケーション、またステークホルダーや顧客等とのコミュニケーションを適切に処理することは重要です。
重大なセキュリティ・インシデントが発生した場合、影響はセキュリティ部署や情報システム部署を超えて波及します。
サイバー攻撃の手段は日々変化・進化しており、いかなる組織であっても攻撃を100%阻止するのは至難の業です。
攻撃者に侵入された状況を想定し体制を整備することで、被害を受けた後の見直しや改善につなげることができます。
インシデント・レスポンス・サイクルは、セキュリティ・インシデント後の改善や、教育、訓練演習を通じた組織のサイバーレジリエンス向上を目的の1つとしています。
サイバー攻撃の被害を被ったものの、その時のログや行動記録がなければ見直しもできず、改善点を挙げていくことも困難です。
インシデントの発生から適切な知見を吸収・反映できない組織は、将来的に同じような攻撃に遭う可能性が高いといえます。
適切なインシデント対応ができない場合、様々な問題が発生します。
|
経済産業省「サイバーセキュリティ経営ガイドライン3.0」(外部リンク)では、「インシデント発生時の緊急対応体制の整備」を怠った場合のシナリオとして、以下の4項目をあげています。
海外拠点を持つ企業や海外との取引を行う企業については、インシデント発生時や個人情報漏洩時の迅速な報告を義務付けるGDPR等も遵守する必要があります。
GDPRに違反した場合の罰則金は莫大であり、組織運営に直結するリスクとなります。
地震や火災に備えた防災計画や避難訓練を、多くの組織・企業が実践しています。
「うちは大丈夫だろう」、「その場で何とかなる」という風に、セキュリティ・インシデントに対する計画や訓練を行わないということは、組織としてサイバーセキュリティ・リスクへの備えを放棄しているととらえられる可能性があります。
セキュリティ・インシデント対応を行うためには、組織としての事前準備が必要です。
この章の目的は、セキュリティ・インシデントに適切に対応するための体制を確立することです。インシデント対応に必要な基盤を整備し、攻撃や不正に対する準備、検知、速やかな対応を実現します。
この項では、国内外で利用されているガイドラインを参考に、事前準備事項について紹介します。
各準備事項におけるよくある失敗例についても掲載しています。
ポリシー(Policy)は、組織におけるセキュリティ・ガバナンス、運用等に関する原則・ルールを規定するものです。
ポリシーは、セキュリティに関する役割分担や権限、責任分界点が明確化されている必要があります。
また、技術的な要件(ログの取得、モニタリング、システム要件)や手続き等を含めて、ポリシーに沿った運用が行われているかを適切な方法で常に点検しなければいけません。
よくある失敗例:
|
CSIRTはインシデント対応体制を統括する組織です。CSIRTの形態は、その組織や企業の構造によって様々ですが、デジタル化の進んだ現在は、セキュリティ・インシデントに対し組織全体で取り組むために、このようなチーム編成が重要となります。
CSIRTの役割はインシデント対応に留まらず、平時の情報収集やセキュリティ対策向上施策等も実施しているケースが一般的です。
多くの組織・企業が、組織の名を冠したCSIRT的なチームを立ち上げ、窓口として機能させるとともに、協議会やFIRSTといったCSIRTコミュニティでの情報共有に取り組んでいます。
CSIRTは組織を統括するチームですから、法務、人事、広報、IT等必要な部門が漏れなく代表者を選出している必要があります。
なお、製品に係るセキュリティ・インシデントを対象とするPSIRTも存在します。
よくある失敗例:
|
セキュリティ・インシデント発生時は、組織内・組織外・ステークホルダー・顧客との迅速・適切なコミュニケーションが事態収束のカギとなります。
サイバー攻撃や、不正アクセス被害、ランサムウェアによるシステム障害が発生した場合、初動対応の際の多数の連絡通報が発生します。
このようなコミュニケーションに際し、然るべき部署が最も効果のある発信を行うために、あらかじめ連絡先・通報先を含めた計画を定めておくことを推奨します。
その際、法執行機関やセキュリティ当局、個人情報当局に対する連絡タイミングについても確認します。
よくある失敗例:
|
セキュリティ・インシデント対応の根幹となる対応計画は、事前に準備しておく必要があります。
インシデントの態様は、シチュエーションによって様々です。
一般的には、大まかなセキュリティ・インシデントの種別(マルウェア感染、ランサムウェア感染、情報漏洩)と、組織へのインパクト(一部業務停止、国内事業に影響、グローバル事業に影響等)に応じた分類を作成し、各パターンごとの行動を定めておくことが推奨されています。
対応計画の策定にあたっては、経営層と、インシデント対応の中核となるCSIRTとの意思統一が図られており、対応中も円滑にコミュニケーション(報告、指示等)がとれるよう配慮することが重要です。
実際に重大インシデントが発生した場合、そのセキュリティ・インシデントがどの程度のインパクトを持つのか判断に迷う場合があります。重大度のレベルに応じて、責任者が部門責任者なのか、現地法人なのか、グローバル本部なのか等、態勢が変化します。
精確かつ迅速にセキュリティ・インシデントのレベルを判断する(インシデント・トリアージ)にあたって、CISが公開するCIS Controls(外部リンク)では以下の情報を判断材料として用いることを例示しています。
前項「CSIRTと組織化」で挙げたように、セキュリティ・インシデント発生時の連絡先も計画に含め、定期的に見直し・更新を行います。
インシデント・レスポンスに必要なあらゆる専門技術(フォレンジック等)を自組織で賄うということは稀ですので、事態発生時の支援ベンダーや調査会社等も支援リストに含めておきます。
近年増大しているランサムウェア被害でよく聞かれるのが、いざ対応しようと思ったもののすべてのPCが暗号化されてしまい作業ができないという事象です。
インシデント対応には、計画を実現するためのツールが必要です。
非常に範囲が広いため全ては挙げませんが、ガイドライン等では必要なツールとして以下を挙げています。
※ 組織がどの程度セキュリティ業務を内製しているかによって、必要なセキュリティツールは変わります。
インシデント対応において、訓練は「さらなる向上策」ではなく、「事前準備」に含まれます。
対応計画は、訓練を行わなければ実効力のあるものとなりません。訓練なしに、チームは機能しません。
組織は、定期的にシナリオベースの訓練を行い、要領どおりに行動できているか、要領に不備はないか等を点検します。
訓練においては、現実味のあるシナリオを策定することが望ましいでしょう。
訓練の意味:
よくある失敗例:
|
ここまでで、インシデント対応に必要な組織体制と事前準備が完了しました。
次章では、実際にセキュリティ・インシデントが発生した場合の対応フローを紹介します。
セキュリティ・インシデント対応フローを全体図で示すと次のようなものとなります。
ここでは、SANSが公開しているガイドライン(外部リンク)を参考に、具体的なフェーズごとの概要を紹介します。
様々なログやアラートを分析し、インシデントかどうかを判断するフェーズです。
セキュリティ・インシデントの前触れとなるイベントは様々であり、このような兆候を、誤検知や過検知に惑わされずに的確に察知することがセキュリティ部門の重要な職務です。
セキュリティ・インシデントの兆候:
攻撃者がターゲットを定めてから、実際に攻撃活動を開始するまでの潜伏期間は様々です。
最近のランサムウェアのように、侵入後素早く攻撃を行う攻撃者もいれば、情報窃取を目的とするAPTのように、長期間対象ネットワーク内に潜伏したり、ソフトウェア・サプライチェーンを狙う等して長期にわたり持続性を確立する脅威アクターもいます。
いずれにせよ、侵害発生から検知までの潜伏期間が長引けば長引くほど、被害影響は増大します。
速やかな検知と特定が、初動対応のカギとなります。
よくある失敗例:
|
このフェーズでは、セキュリティ・インシデントによって発生した影響を最小限に抑え、さらなる被害を防止します。
影響を局限するだけでなく、後の根絶や復旧フェーズに備えるために、攻撃の証拠を保全しておくことが重要です。手順を踏まずに侵害システムを消去したり、システムを初期化した場合、攻撃の全貌を解明する手掛かりが失われてしまいます。
よくある失敗例:
|
侵害されたシステムやネットワークにおける駆除活動を行うフェーズです。フェーズ②封じ込めと併せて実行されることもあります。
適切な手順を踏むことで、攻撃者の潜伏や、インシデント対応活動自体のかく乱を防止することが重要です。
サイバー攻撃を阻止するための防護策の改善もこのフェーズで行われます。
よくある失敗例:
|
復旧フェーズにおいては、侵害を受けたシステムを通常の体制に復帰させます。
インシデントがもたらした被害や影響を特定し、全貌を解明することは、インシデント・レスポンスにおける重要目的です。
攻撃者の痕跡を調査し、明らかにしなければ、侵害されたシステムやネットワークを復旧することができません。
また、この過程で行われる調査・分析は、その後の教訓収集フェーズにとっても重要となります。
よくある失敗例:
|
セキュリティ・インシデント対応を振り返り、組織のセキュリティ向上を行うフェーズです。
SANSガイドラインでは、インシデント対応における最重要フェーズとされています。
「何がおこったのか? どうすれば発生を防げたのか?」を明らかにし、体制の改善・強化につなげることは、インシデントの再発防止にもっとも効果のある活動です。
インシデント対応の総括として、一連の発生事象や対応を文書化することが非常に有効です。
ドキュメントとしてまとめることにより、インシデントから得られた教訓を活用することができ、また当局や外部への報告といった業務にも利用することができます。
組織はセキュリティ・インシデント全体の振り返り(デブリーフィング)を、2週間以内に実施することが望ましいとされます。
よくある失敗例:
|
インシデント対応は、体制確立と計画策定で終わりではありません。実際のインシデント対応を通じた改善点の発見等、サイクルとして常に運用していくプロセスが必要です。
ここでは、CISのガイドラインを参考に、組織の対応能力をさらに向上させるための方策として、脅威インテリジェンスと脅威ハンティングを紹介します。
脅威インテリジェンスおよび脅威ハンティングを活用することで、組織は受け身(リアクティブ)ではなくプロアクティブにセキュリティ対策をとることができます。
脅威インテリジェンスとは、攻撃者や脅威に関する情報を先行的に収集し、インテリジェンスサイクルを通じて処理することで、組織の対策に役立てるプロセスです。
図 FBI資料を参考に当社作成
脅威、すなわちサイバー攻撃に関するインテリジェンスを基盤とすることで、組織にとって真に必要なセキュリティ対策を定め、防護すべき重要領域に的を絞った投資をするといった判断が可能となります。
脅威インテリジェンスプラットフォームは、当社のCognyteを含め様々な製品・サービスが展開されています。
しかし、この概念は元々組織の情報処理・活用プロセスを指すものであり、インテリジェンスを活かす組織的基盤が整備されていることが前提となります。
脅威ハンティングは、脅威情報や攻撃者のTTP、IoCといった情報を活かし、組織のシステムやネットワークに潜伏している攻撃の兆候を予防的に探索し検知するプロセスです。
セキュリティシステムを回避しつつ高度な手法を用いて行動するサイバー攻撃者の動きをつかむために、脅威情報やログ、データを活用します。
脅威ハンティングの実践においては、EDR等のツールや、マネージドサービスによる提供も行われています。
組織がインシデント対応(レスポンス)のための体制を確立し、サイバー攻撃に備えることは必須の課題です。
インシデント対応フローの主要フェーズである「特定→封じ込め→根絶→復旧→教訓収集」は、組織によってはMSSに委託しているケースもありますが、組織体制の整備や、外部との対応、セキュリティ・インシデントを通じた教訓の活用といった部分は、組織自ら取り組まなければならない部分です。
ビジネスや事業を推進するために、サイバー攻撃に備え、レジリエンスのある組織を作りましょう。
記事に関するご意見・お問い合わせはこちらへお寄せください。
(SOMPOホールディングス、損害保険ジャパンなどグループ各社へのお問い合わせはご遠慮下さい)