目次 |
原文のブログはこちらからご覧いただけます。
次のような状況を想像してください。脅威アクターによるネットワークの侵害を受け、あなたの組織はインシデント対応（IR, Incident Response）計画を迅速に実施しました。そして今、長い 1 日と短い夜、さらに週末もない日々を経て、組織のチームは疲弊しています。組織はまさに、修復と対応の最終段階を終える準備を整え、前に進もうとしています。
IR 計画のこの段階をどのように実施するかは、計画全体を成功させる上で極めて重要です。
インシデント対応における過ちは、特に持続的標的型攻撃（APT）に対処している場合には、脅威アクターがもたらす被害を悪化させ、攻撃を実施するための余分な時間を相手に与えてしまう可能性があります。
このシリーズの第 1 部では、インシデント対応における「大罪」として、攻撃に対する計画の準備段階でネットワーク防御担当者が犯す過ちについて解説しました。また第 2 部では、組織の環境で攻撃が進行中であることが判明し、まさにその状況にある中で犯されるインシデント対応の過ちを見てきました。
シリーズ最終回となる今回は、攻撃からの修復と復旧の段階での過ちについて解説します。組織が避けるべきこれらの「大罪」は、合計 100 年分を超える IR 経験を持つ BlackBerry のインシデント対応チームの知見に基づいています。
インシデント対応における第 10 の大罪：不完全な修復と復旧
何よりも重要なのは、対応時の封じ込め、根絶、修復の各段階を迅速かつ一挙に行うことです。これには、すべての感染システムを取り除き、影響を受けたすべてのアカウントをリセットし、重要なサーバーを新しく構築して復元することが含まれます。可能であれば、脅威アクターがこの時点で対策を講じることがないように、この段階の間は企業ネットワーク全体をインターネットから切り離すことを推奨します。
このとき、ネットワーク防御担当者が良かれと思って各システムを 1 台ずつ、長い時間をかけてオフラインにしようとすることがよくあります。これでは、組織が何らかの介入を試みていると攻撃者に知らせることになります。その場合、攻撃者は「クリーンアップ」のための対策を積極的に講じ、その上で休止状態に入ります（多くの場合、数か月）。この結果、インシデント対応担当者が攻撃者のインプラント（システムに密かに埋め込まれるマルウェア）をすべて特定することが事実上困難にもなります。インシデント対応のこの段階を迅速かつ一挙に行わないことは、やはり間違いなのです。
インシデント対応時のサービスアカウントの扱い
修復段階での重大な過ちは、サービスアカウントをこの段階の対象外とすることです。一部の企業では、ハードコードされたアプリケーションパスワードなどの扱いが難しいという理由から、こうした対応が見られます。脅威アクターは、これらのアカウントがしばしばリセットの対象外となるため、悪用の機会となり得ることを把握しています。
これらのサービスアカウントは通常、ビジネスに不可欠で収益を生み出すアプリケーションに影響を与えるため、攻撃を受けた後であっても、アカウントのリセットにはしばしば大きな抵抗が伴います。しかし、サービスアカウントは管理者権限を持っていることが多く、脅威アクターにとって価値の大きい標的の 1 つであるため、これらをリセットしないのは危険です。 また、多くのサービスアカウントはかなり過剰な権限を付与されています（このテーマに関するアドバイスについては、弊社のブログをご覧ください）。
もう 1 つの重要なポイントは、「バックアップ」の管理者アカウントの存在を忘れないことです。これらのアカウントも高い権限を付与されていますが、まれにしか使用されないため、パスワードが変更されることはめったにありません。
攻撃の把握状況にもよりますが、ゴールデンチケットが生成された疑いがある場合には、Kerberos のビルトインアカウントであるキー配布サービス（KRBTGT）のパスワードを 2 回リセットすることが推奨されます。ゴールデンチケット攻撃が成功すると、脅威アクターが組織の Active Directory（AD）ドメインへのアクセス権を得ることになります。なお、各リセットの間には AD 通信の問題を避けるために必要な待機時間があるため、このリセット作業はアドバイスを得た上で実施してください。
サイバー攻撃後の再構築 vs. 復元
弊社の経験では、通常、インシデント対応チームが現場で復旧作業を行うことはありません。チームの焦点は必要な手順のリストを作成することであり、これらの手順はシステムを担当する管理者によって計画され、実施されます。
これらの手順の実施時にも、企業が重大な過ちを犯している状況が散見されます。たとえば、古いスナップショットから復元することや、バックドアを手動で削除しようとすることがこれに該当します。解決策として最適なのは、各種のシステムをまとめて再構築することです。これにはより多くの時間と労力がかかりますが、リスクが軽減され、環境の安全が再び確保されたという確信が得られます。
一部のケースでは、バックアップから安全に復元を行えることもあります。このためには、インシデントの開始時期を正確に把握できているという強い確証を得た上で、攻撃者が実施したすべての活動を十分に可視化できている必要があります。これらを満たしている場合、一定の信頼性の下で侵害前の時点からの復元を行えます（ただし、再発防止のためにすべての脆弱性を修復する必要があることも忘れないでください）。
しかし、未知の感染要素がある場合、たとえば初めて侵入が発生した場合や、一部のサーバーを再構築していない状態で負荷分散が行われた場合などには、このオプションは危険であることがわかっています。このような場合、古いスナップショットがまだ感染している可能性があります。
影響を受けたサーバーごとに最適な対応策を決定する上では、再構築が必要なのか、あるいはバックアップからの復元で十分なのかを判断するために、IR チームと協議することを推奨します。バックアップがインシデントの発生前に行われていたかどうかを確実に判定する必要があるためです。
システムの再構築が必要となる場合は、ハードドライブを完全に消去するのが最善の方法です。これは、ランダムなバイト列またはゼロで全体を上書きしてから、信頼できる「ゴールデンイメージ」からイメージを再インストールすることを意味します。
ただし、ごく一部のケースでは、イメージを再インストールしても問題が解決しない場合があることに注意してください。たとえば、「Equation Group」と呼ばれる APT アクターは、10 種類を超える一般的な HDD ブランドのハードドライブのファームウェアプログラムを書き換えることで、ゴールデンイメージによる再インストールを切り抜けていました。
インシデント対応における第 11 の大罪：「事態は収束した」という思い込み
持続的標的型攻撃（APT）への対処で対応担当者が犯しがちな過ちは、実際にはそうでないうちから攻撃を完全に修復できたと思い込むことです。多くの点で、攻撃者を環境から排除することは始まりに過ぎません。セキュリティ担当者は、インシデントで得た経験を活かし、継続的な監視を実施・改善する方法や、プロアクティブな脅威ハンティングを実施する方法、さらには環境内でセキュリティチームの可視性を高める方法についても検討する必要があります。
こうすることで、APT の「P」、つまり「Persistent（持続的）」な側面から組織を保護できます。政府の支援を受けたグループは、標的と見なした企業を継続的に攻撃します。こうしたグループは、短期間の休止状態に入るようなしぐさを見せながら、突如として被害者の防御体制に別の弱点を見出し、そこに狙いを移すことがよくあります。
多くの場合、高度なグループは最も手軽な手法から始め、標的のネットワークの侵害に成功するまでその手口を変化させます。環境に侵入した後には、しばしば脆弱性スキャンの結果やレポートなどのセキュリティ情報を探し出し、組織の弱点を突こうとします。
たとえば、弊社が最近扱ったランサムウェアの事例において、以前から環境に存在していた無関係な APT アクターの動きを偶然妨げたと思われたことがあります。その APT アクターは、外部からアクセス可能な複数のアプリケーションに含まれる既知の脆弱性に関する事前知識を利用して、環境に迅速かつ容易に再侵入していました。
かつての環境はランサムウェア攻撃によって破壊されていたため、以前の攻撃の痕跡を得ることは困難でした。幸い、この事例は早い段階で捕捉できており、また修復計画には、人間が操作する攻撃によるシステムの再侵害を予防するための手順がすでに含まれていました。しかし、APT の存在が明らかになったことで、対応方針を素早く切り替え、アプリケーションの脆弱性を修復した上でアクセスを完全に排除し、さらに各種のマシンを（再び）再構築できる修復計画を迅速に策定する必要がありました。
重要なのは、APT アクターが組織に対する直接攻撃に成功しなかった場合、その標的がパートナーやサービスプロバイダに移り、異なる角度からの攻撃が行われる可能性があるということです。組織に対する最初の APT 攻撃は、多くの場合、組織が標的になっているという初期兆候に過ぎません。それが最後の攻撃になる可能性は低いため、この時点から警戒を強め、防御体制を強化する必要があります。多くの場合、「持続性」は国家的な脅威アクターと金銭目的の犯罪者を分ける主要な差別化要因となります。
インシデント対応における第 12 の大罪：得られた教訓を顧みない
「得られた教訓」の評価と実行には時間がかかるため、これらの活動は技術職や管理職を含むあらゆるレベルのチームで省略されがちです。困難で手間のかかるインシデントを経た後では、チームは疲れ切っているのです。また、多くの組織は、自分たちが間違っていたかもしれない事柄にこだわるのはやめ、できるだけ早く「通常業務」に戻りたいと考えています。
しかし、どうすればよかったのかを分析することは、組織のセキュリティ体制を改善するための重要な機会となります。こうした分析は、どのような計画や職務が欠けていたのかや、組織がどの領域に追加の防御策や外部ベンダーのサポートを検討すべきかを理解するのに役立ちます。
「得られた教訓」に関する活動を重視して実践しない限り、教訓そのものを実際に得ることはできません。APT に起因するセキュリティインシデントは、多大な時間をかけてそれらに取り組んでいるコンサルティング組織以外ではあまり目にすることがないため、この傾向が特に顕著です。しかし、このような攻撃を学ぶことで得られるインテリジェンスは、無駄にするにはあまりに貴重です。
以下に示すリソースは、「得られた教訓」に関する取り組みを実施するのに役立つでしょう。
- Mind Genius：https://www.mindgenius.com/5-easy-steps-to-the-perfect-lessons-learned-session/
- PMI：https://www.pmi.org/learning/library/lessons-learned-next-level-communicating-7991
インシデント対応における第 13 の大罪：痕跡情報を共有しない
復旧段階で犯されがちな最後の「大罪」は、サイバー攻撃の修復後に組織の経験と貴重な脅威インテリジェンスを共有しないことです。ただし、インシデントそのものが完全に解決するまでは、インテリジェンスを外部に共有すべきではありません。
場合によっては、ベンダー/クライアントとの守秘義務契約（NDA）やその他の法的制約により、侵入の痕跡（IOC）の共有が制限されることがあります。この場合は痕跡情報を外部に共有することが難しくなるため、痕跡情報をどの程度匿名化できるかを検討するか、あるいは YARA、SIGMA、または Suricata ルールを作成しましょう。これら 3 つの形式は、悪意のあるファイル、SIEM データ、またはネットワークトラフィックを識別するための一連の複雑な検知ルールを提供します。少なくとも、インテリジェンスの使用に関するキュレーションと運用化を社内で実施すれば、組織の実戦力が強化できます。
このキュレーションでは、インテリジェンスの品質保証を行い、侵入の痕跡にクライアント関連のデータ、誤検知、または個人情報が含まれていないこと、およびすべてのインテリジェンスが可能な限り高い信頼性を持っていることを確認します。
また、運用化とは、組織が導入しているツールや慣行に応じて、一連のインテリジェンスを可能な限り最善の方法で使用することを意味します。たとえば、痕跡情報のデータストリームを SIEM ソリューションに統合したり、APT の行動を捕捉できるよう、組織の EDR 向けに特定のルールを記述したりすることが挙げられます。
すべては組織のニーズ次第ですが、一般的には、脅威インテリジェンスは既存のツールや手順を改善するものであるべきです。
また、業界や部門内で信頼できる仲間のグループに属し（もしまだ存在しない場合は結成し）、組織のインテリジェンスを共有することを検討しましょう。私たちは時にビジネスで競い合ってはいますが、全員が同じ敵からの攻撃にさらされています。そうした中で行動を共にして互いに学び合うことで、全員が安全性を高めることができます。
以下に示すプラットフォームは、痕跡情報を共有するのに役立つオープンソースツールです。
- MISP：https://www.misp-project.org/
- Crits：http://crits.github.io/
- Alienvault 社 OTX：https://otx.alienvault.com/
まとめ：復旧時のインシデント対応における過ち
復旧に関して各種のインシデントに共通するのは、ほとんどの組織が、業務を再開できた時点でインシデントが収束したと考えていることです。弊社はインシデント対応者としての立場から、企業がパスワードリセットの必要性を軽視している状況や、侵害の全貌を明らかにしないまま、信頼を置くソースからシステムを復元しようとしている状況を何度も目にしてきました。こうした失敗はしばしば、わずか数か月後に別の侵害が発生することにつながります。
継続的な運用を確保することは、たしかにセキュリティチームが目指すところです。しかし私たちは、インシデント後の活動がインシデントそのものへの対処と同様に重要であることを理解する必要があります。
サイバーセキュリティインシデントは、文字どおりのいたちごっこの状態に陥りがちです。そのため、追う側としての戦略性を高めておくことが何よりも重要です。
おわりに：「罪」の報い
BlackBerry のインシデント対応チームは、このシリーズでチームの集合知を共有してきました。3 部ともネガティブな側面に焦点を当てることが多くなりましたが、これはやむを得ないことです。私たちの誰もが犯しがちなインシデント対応時の過ちは、重大な結果を引き起こす可能性があるのです。
しかし、逆もまた真なりです。今回解説した「大罪」を避けることで、対応と修復が成功する見込みは大幅に高まります。そうなれば、自身の努力が報われたという実感が得られ、夜もよく眠れるようになるでしょう。
同僚や交流のあるネットワーク防御担当者に、このシリーズをぜひ共有してください。できるだけ多くの組織がこれらの洞察から恩恵を得られるよう、支援の手を差し伸べましょう。
また、組織でインシデント対応リテーナーが用意できていることを確認しましょう。攻撃前にこのような備えをしておくことで、必要なときに支援を求め、時間を節約しながら次の行動の指示を仰ぐことができます。
.png)
