【更新情報】当初 2021年2月12日に掲載されたこの記事は、PICERLやサイバーセキュリティの枠組み、そして劇的に変化している脅威の状況の現状を反映させるため、更新されました。
絶えず変化し続けるデジタル脅威の情勢において、サイバーセキュリティ防御体制を強化し、インシデントに効果的に対応しようとする組織にとって、 のインシデント対応（IR）計画 を理解し、実施することは極めて重要です。 その手法の一つがPICERLです。これは、組織が導入することで、現在のセキュリティインシデントへの対応能力を高め、将来発生しうるインシデントに対する防御体制を強化できるサイバーセキュリティフレームワークです。
データ漏洩、ランサムウェア攻撃、その他のサイバー攻撃など、サイバーセキュリティインシデントへの対応は、組織の日常的な業務運営に深刻な支障をきたす可能性があります。
効果的なインシデント対応がなければ、セキュリティインシデントは社会の信頼を損ない、ブランド価値を低下させ、売上高に大きな打撃を与える可能性があります。
このブログ記事では、PICERLに関するあらゆる側面について解説します。その起源の簡単な歴史を紹介し、PICERLを他の一般的なサイバーセキュリティモデルと比較するとともに、PICERLやその他の セキュリティフレームワーク のようなプロセスを組織内で成功裏に導入するための、インシデント管理に関する実務的な知見を提供します。
サイバーセキュリティにおけるPICERLとは何でしょうか？
PICERLとは、 の6段階からなるインシデント対応プロセスです。P：（検知）、 repare（修復）、 I：（特定）、 C：（封じ込め）、 E：（根絶）、 R：（復旧）、 L：（教訓）。
と、セキュリティ研究および教育を提供するために 1989 年に設立された民間組織であるSANS（）によって開発されたPICERLモデルは、インシデント対応における業界標準となっています。 PICERLは、セキュリティインシデントへの対応において、体系的かつ包括的なアプローチを提供するため、多くの人々から効果的なフレームワークであると見なされています。
PICERLに従うことで、組織はインシデントに万全の準備を整える（準備）、インシデントを迅速に特定する（特定）、さらなる被害を防ぐために脅威を封じ込める（封じ込め）、システムから脅威を根絶する（根絶）、インシデントから復旧して通常の運用に戻す（復旧）、そしてインシデントから教訓を得て将来の対応を改善する（教訓）ことが可能になります。
PICERLの手順についてさらに詳しく確認するとともに、インシデントの影響を最小限に抑え、組織全体のセキュリティ態勢を強化するために、今日から実践できる具体的なポイントについてもご紹介いたします。
手順 1. 準備する
事前の準備を行うことで、適切なチームから適切な人材が関与し、各自の役割を理解し、インシデントが発生した際に何をすべきかを把握できるようになります。
準備段階では、 のインシデント対応チームのメンバー が、組織がバックアップや災害復旧（DR）の手順を練習するのと同様に、実際に演習を行えるような計画を策定する必要があります。
IR計画については、弱点を解消するため、定期的にリハーサルを行う必要があります。 模擬IR訓練を行うことで、チームメンバーは実際のインシデントというプレッシャー下でも確実に実行できる自信がつきます。
[関連記事：AI対人間：SecOpsが次の戦場になる（あるいはならない）理由]
模擬訓練に参加するIRチームは、次のような質問に答えられるようにしておく必要があります：
- 広報（PR）チームへの連絡は誰が担当するのでしょうか？
- 法務部門への連絡は誰が担当するのでしょうか？
- 財務部門への連絡は誰が担当するのでしょうか？
- 法執行機関や規制当局には、どのような場合に通知する必要があるのでしょうか？
準備段階では、適切な道具が揃っているかどうかも確認します。 もしそうでない場合、それらを調達し、チームメンバーへの研修を行うために必要な資金は確保されていますか？ インシデント対応計画が策定された後は、経営陣がその計画および計画の実施に必要な予算について検討・承認を行うことが重要です。
ステップ 2。 特定する
インシデントが発生したと判断したら、特定フェーズでは、次のような質問に答えることで、優先順位の付け始めを行います：
- それはいつから始まり、どのようにして起きたのでしょうか？
- 侵入経路はどこだったのでしょうか？
- これは、 のパッチが適用されていない脆弱性（）だったのでしょうか？
- 誰がそれを見つけたのでしょうか。また、どうやって見つけたのでしょうか。
- その範囲は分かっていますか？ それは1人か2人の個人や資産に限られているのでしょうか、それとも広範囲に及んでいるのでしょうか？
- 今後も取引を続けていただけますか？
- 私たちがどのような措置を講じても、当社の事業分野の1つに影響を及ぼすことになるのでしょうか？
多くの場合、侵害された認証情報が侵入の入り口となります。 そこから事態はエスカレートし、悪意のある攻撃者は、お客様の環境内のあらゆる機会を悪用してきます。
[関連記事：脆弱性スキャンの基本と、それが現代のサイバーセキュリティにおいてなぜ不可欠なのかについて詳しく解説しています]
Taniumは、エンドポイントに関する深い知見を活用して、脅威を徹底的に調査します
脅威の特定精度を高めるため、各組織では を活用し、 を通じて、対応プロセスの策定や検証にゲーミフィケーションを取り入れ始めています。 例えば、「 」というフィッシングメール（ ）を発見したチームや、チェックリストの計画を最も迅速かつ明確に実行したチームに対して、賞を授与することができます。 ゲーミフィケーションは、特にセキュリティ分野の初心者にとって役立ちます。
ステップ 3。 含む
インシデントが宣言された後、封じ込めとは、望ましくない事態の拡大を防ぐための計画を実行することです。 封じ込め手法については、2つの主流な考え方があり、それぞれに長所と短所があります：
短期的な封じ込め戦略 は、侵害されたシステム、資産、またはアプリケーションがセキュリティツール以外とは通信できないようにするための隔離コマンドを発行する、という単純なものでも構いません。 これには、恒久的な解決策が策定されるまでの間、さらなる被害を防ぐために、影響を受けたシステムの隔離、悪意のあるトラフィックの遮断、または侵害されたアカウントの無効化といった迅速な措置が含まれます。
短期的な封じ込め戦略を策定することは、セキュリティインシデントによる当面の影響を最小限に抑える上で極めて重要なステップです。 これにより、インシデント管理の初期段階において、事業運営を維持し、業務への支障を最小限に抑えることができます。
による長期的な対策は、全社的に実施された修正措置ですが、本インシデントの根本原因に対する完全な是正とは言い難いと考えられます。 インシデント対応における長期的な封じ込め戦略は、セキュリティ侵害に対して持続可能な解決策を提供することを目的としており、脅威を一時的に抑制するだけでなく、再発を防ぐことも保証します。 これには、システムのアップグレード、 パッチ管理、ネットワークのセグメンテーション、あるいは高度なセキュリティプロトコルの導入などが含まれる場合があります。
例えば、インシデントに関連する、パッチが適用されていない脆弱性はありますか？ その場合は、当該ソフトウェア（アプリケーションまたはオペレーティングシステム）のパッチ適用スケジュールを前倒しすることが、長期的な封じ込め戦略の一環として盛り込まれるべきです。
封じ込めプロセスにおいて盛り込むべきもう一つの重要な課題は、どのユーザーがどのシステムに対して管理者権限を持っているかを再検討することです。例えば、次のようなものです：
- のActive Directoryと比較して、貴社の攻撃対象領域はどの程度でしょうか？
- 多要素認証は有効にされていますか？
データのバックアップおよび復旧システムと連携した長期的な対策策を講じておくことは、データが適切に複製され、インシデント発生前の状態に容易に復旧できる可能性を高めるのに役立ちますので、お勧めです。
ステップ 4。 根絶する
さて、あなたは現在、その侵害の原因を――いわゆる「根こそぎ」に――取り除こうとしているわけですね。 それはどういう意味ですか？ つまり、例えば、マルウェアを発見した場合、特定できたすべてのインスタンスを安全に削除することができるということです。 必要に応じて、システムのセキュリティ強化とパッチ適用を行ってくださいました。 強化できないシステムを再イメージ化しました。 侵害に関連する痕跡を確実に特定できるよう、脅威インテリジェンスを更新しました。
インシデント対応プロセスが進むにつれ、対応の範囲が変わる可能性があります。 たとえば、ランサムウェア攻撃を受けた後などには、最後の正常なバックアップからシステムの再イメージ化や復元が必要となるシステムが多数ある場合があります。 また、攻撃に関連する痕跡をすべて特定できなかった場合や、侵入に悪用された脆弱性に対処していない場合は、再び攻撃を受ける可能性があります。
根絶の鍵は、徹底することにあります。 この究極の問いは、あなたが「それ」――それが何であれ――をすべて見つけられたかどうか、ということです。 専門的な知識を持つパートナーや第三者が、復旧作業を支援してくれることがよくあります。
ステップ 5。 復元
根絶から回復へと移行することは、手術から目覚めるようなものです。 すでに被害は生じてしまいました。これからは、回復に注力する時です。
インシデント対応の観点から、今こそ自分自身に率直に向き合い、次の問いに答えるべき時です：
- 影響を受けたシステムは、いつ本番環境に戻すことができますか？
- パッチを適用し、セキュリティ強化を行い、テストは行いましたか？
- 社内の レッドチーム（ ）を利用して、攻撃者と同じ手法を用いてこれらのシステムに対する模擬攻撃を実行したことはありますか？
復旧とは、影響を受けたシステムやプロセスを、侵害前の機能状態にどれほど迅速に復元できるかによって測定されます。 復旧とは、インシデント発生後に監視の範囲をどのように変更するかを明確にすることでもあります。 侵害の原因となった活動について、どのくらいの期間監視を行うか（例えば、 30 日、3か月、または6か月など）を決定し、具体的にどのような点を確認するかを明確にしてください。
ここでも、レッドチームのテストや封じ込め作業中に収集された証拠品が役立ちます。 復旧フェーズの終了時には、「脆弱性に対処しました。これがその証拠です」と自信を持って言えるようにしたいものです。
セキュリティ専門家の間では、平均修復時間（MTTR）の短縮 や、、つまり、問題の特定、封じ込め、根絶の各段階を完了するまでに要する時間を短縮する動きが強く見られます。 IR計画が成熟し、各チームがIR計画の実践に熟達するにつれて、MTTRおよび 、つまり検知までの平均時間（MTTD） は減少するはずです。 これらの指標を長期的に追跡することで、PICERLフレームワークが御社にとって効果的なインシデント対応モデルであるかどうかを把握するのに役立ちます。
ステップ 6。 得られた教訓
このステップでは、インシデント対応チームの全メンバーに加え、情報セキュリティ、コンプライアンス、法務、広報などの関連部門の担当者も参加する事後検討会から始めるべきです。 ここでは、その事案について学んだことを振り返り、記録することができます。例えば、次のような内容です：
- IR計画のうち、どの部分がうまくいきましたか？ 何がうまくいかなかったのでしょうか？
- 人手不足の箇所はありましたか？ リソース一覧に載っていない第三者や社内のチームに連絡する必要があったのでしょうか？
- 今回の出来事を踏まえて、私たちの業務の進め方を変える必要があるでしょうか？
- 私たちは、手持ちのツールを効果的に活用できていたのでしょうか？ それらは正しく設定されていましたか？
- チーム間のコミュニケーションはいかがでしたか？ もっと改善できるでしょうか？
- 今回の情報漏洩には、 のようなソーシャルエンジニアリング攻撃 や、不適切なデータ取り扱いなど、従業員に起因する要因はありましたか？ これは研修で解決できるでしょうか？
- その脆弱性の悪用は、特定の事業部門に限られたものでしたか、それとも組織全体に広く見られたものでしたか？
- 別の運用体制やプロセスを用いて、この脆弱性に対処することは可能でしょうか？
インシデント対応計画（IR計画）の柔軟性が高ければ高いほど、実際にインシデントが発生した際に得られる教訓も多くなります。 そして、学んだことはすべて、準備段階に反映させ、さらに磨きをかけて改善していくべきです。
[関連記事：Taniumが、進化し続けるサイバー脅威やデータ漏洩から組織を守る 7 の方法]
PICERLはNISTとは異なりますか？
PICERLおよび （NIST ）のサイバーセキュリティ・フレームワークは、インシデント対応において広く採用されている手法ですが、その構造や重点が異なります。
[Read also: Operationalizing the NIST Cybersecurity Framework 2.0 with Tanium]
PICERLでは、6つのフェーズを用いたセキュリティインシデント管理のための段階的なアプローチを提供しています。 これに対し、NISTは、組織がサイバーセキュリティリスクを管理できるよう支援することを目的として、5つの中核機能（特定、保護、検知、対応、復旧）を軸に構成された、より広範で柔軟性の高い一連のガイドラインです。
PICERLはインシデント対応のための詳細なプレイブックであるのに対し、NISTフレームワークは、 におけるサイバーセキュリティリスク管理全般に関する、より包括的なガイドです。。 しかし、NISTのフレームワークは、一般的に規範的なものではないと見なされており、高レベルのサイバーセキュリティ成果の分類体系と、それらの成果を達成するためのリソースへのリンクを提供するに留まっています。
これは、御社のインシデント対応計画にとってどのような意味を持つのでしょうか？ 組織では通常、サイバーセキュリティリスクを効果的に管理するため、NISTフレームワークというより広い文脈の中で、インシデント対応にPICERLを活用しています。
PICERLは、インシデント対応モデルとして最良のものなのでしょうか？
PICERLは、インシデント対応に対して詳細かつ体系的なアプローチを提供しており、大規模な組織や、より複雑なIT環境を持つ組織にとって有益です。 しかし、PICERLフレームワークには、入念な準備が必要であることや、インシデントの特定や封じ込めが複雑化する可能性があること、また全スタッフが適切な研修を受けるよう確保することなど、課題も存在します。
こうした課題は、PICERLのようなアジャイルなプロセスを採用したフレームワークに比べ、より柔軟なアプローチを提供するように設計された新たなインシデント対応モデルの登場への道を開きました。また、組織が効果的なインシデント対応を行うために必要な戦略を再考しなければならないという点において、重要な転換点を示しています。
その一例として、SOAR（ Security Orchestration、 Automation、および Response）というモデルが挙げられます。 SOARは対応の自動化に重点を置いており、即時の対応を要するインシデントに対処するためのリソースが限られている組織にとって、特に有用です。
同様に、 DAIR、あるいは Dynamic Approach to Incident Response も、PICERLのように順次実行する必要のない「ウェイポイント」や「マイルストーン」を用いてインシデント対応に取り組むことを重視しているため、人気が高まっています。 DAIRモデルでは、段階的なアプローチに従うのではなく、成果と、その成果を達成するのに役立つ活動に焦点を当てるよう導いてくれます。
サイバー脅威は混沌とした性質を持つため、ますます巧妙化する攻撃に迅速に対処するためには、最新のインシデント対応計画とそれを支えるツールが、限られた予算と のサイバー人材不足という状況下でも、迅速に方向転換し、脅威を是正できる能力を備えている必要があります。
今日のセキュリティインシデントには決まったパターンがないのですから、インシデント対応計画に決まったルールがある必要はあるでしょうか？
インシデント対応フレームワークの選び方
この記事では、PICERLがインシデント対応のための詳細なロードマップを提供することで、セキュリティモデルの分野において従来からどのように際立った存在であったかについて学びました。 しかし、どのインシデント対応モデルにも、それぞれ長所と課題があります。
結局のところ、貴組織が遵守するインシデント対応計画は、貴組織の業界特有のサイバーセキュリティ上の課題に合わせて策定されなければなりません。 IR計画が効果を発揮するためには、利用可能なリソース、ツール、人材を効率的に活用するとともに、実際の状況において実行可能であり、新たな脅威が出現した際にも対応できるよう適応性を持たせる必要があります。
インシデント対応計画を継続的に改善・進化させていくことは、サイバーセキュリティの分野で常に先手を打つために不可欠です。 PICERLであれ、DAIRであれ、あるいは貴組織のニーズに合わせて独自に構築された他のモデルであれ、重要なのは、現在のセキュリティ上のニーズに対応し、将来のサイバー脅威に自信を持って立ち向かえる体制を整える計画を策定することです。
Taniumは、「 Tanium Incident Response」を通じて、あらゆるフレームワークに対応した比類のないサイバーセキュリティサポートを提供しています。このソリューションは、ばらばらの単体ツールの代わりに統合されたソリューションを提供し、組織が脆弱性を迅速に特定、管理、および是正することを可能にします。
Taniumは、お客様が現在ご利用中のSIEMおよびEDRツールの機能を強化し、脅威の検知やインシデント対応の取り組みを、ユーザーの生産性への影響を最小限に抑え、サイバーレジリエンスを強化する予防的な防御策へと変革します。
リアルタイムの可視性と包括的なエンドポイントデータを活用し、 、Tanium Automate、といった、コーディングの専門知識をほとんど、あるいは全く必要とせずに複雑なタスクを大規模に自動化するために開発された当社の最先端テクノロジーを活用することで、規模やスキルレベルを問わず、あらゆるチームがより効果的かつ生産的、そして効率的になることができます。
