-
タグ
タグ
- セキュリティ
- 人材開発・教育
- システム開発
- アプリ開発
- モバイルアプリ
- DX
- AI
- サイバー攻撃
- サイバー犯罪
- 標的型攻撃
- 脆弱性
- 働き方改革
- 企業市民活動
- 攻撃者グループ
- JSOC
- JSOC INSIGHT
- サイバー救急センター
- サイバー救急センターレポート
- LAC Security Insight
- セキュリティ診断レポート
- サイバー・グリッド・ジャパン
- CYBER GRID JOURNAL
- CYBER GRID VIEW
- ラックセキュリティアカデミー
- すごうで
- ランサムウェア
- ゼロトラスト
- ASM
- EDR
- SASE
- デジタルアイデンティティ
- インシデントレスポンス
- 情シス向け
- 対談
- CIS Controls
- Tech Crawling
- クラウド
- クラウドインテグレーション
- データベース
- アジャイル開発
- DevSecOps
- OWASP
- CTF
- FalconNest
- セキュリティ診断
- IoT
- EC
- サプライチェーンリスク
- スレットインテリジェンス
- テレワーク
- リモートデスクトップ
- アーキテクト
- プラス・セキュリティ人材
- 障がい者採用
- 官民学・業界連携
- カスタマーストーリー
- 白浜シンポジウム
- CODE BLUE
- 情報モラル
- クラブ活動
- 初心者向け
- 趣味
- カルチャー
- 子育て、生活
- 広報・マーケティング
- コーポレート
- ライター紹介
- IR
ラックに寄せられるご相談の中に、ITシステムに疑似攻撃を仕掛けてサイバー攻撃に対する弱点を発見する「ペネトレーションテスト」の要望が、実戦演習型のテストである「TLPT」の要望として扱われたり、その逆であったりということも少なくありません。
TLPTやRedTeam演習、ペネトレーションテスト、さらに脆弱性スキャンを含むセキュリティ診断には、それぞれ目的やテストの内容に差異があるとされますが、明確に区分されるわけではなくオーバーラップする部分も大いにあります。
ここでは、TLPTを軸に他のテストの内容と比較しながら、TLPTの目的から導かれる実施のポイントをお伝えします。
TLPTの特徴をおさらい
TLPTは、「脅威ベースのペネトレーションテスト」の英語表記、Threat-based(またはThreat-Led) Penetration Testingの頭文字を取ったものです。TLPTには、「(現実の脅威に基づいている)脅威ベースであること」、「レジリエンス向上を目的としていること」という大きな特徴があります。どこから由来していて、それが何を意味していると考えられるか、考察してみたいと思います。
「脅威ベース」とはどういうことか
TLPTは、脅威ベースのペネトレーションテストですが、では逆に脅威と無関係なペネトレーションテストというものはあるでしょうか。そういうものは実際にはありません。セキュリティに関連するテストは、かならず何らかの脅威があるからこそ実施されています。なんの脅威に対して行っているのかという脅威シナリオを強く意識して実施する場合と、すでに慣習化しているためにそれほど強く意識しない場合があるだけの話です。
ではなぜ、ことさらに「脅威ベースの」ペネトレーションテストの実施が叫ばれたのでしょうか。TLPTは、2018年にG7のサイバーエキスパートグループによる「脅威ベースのペネトレーションテストに関するG7の基礎的要素※」が公表されて以来、取り組みが本格化しました。それなら、「脅威ベース」の脅威とはG7の構成国から見た敵性国家を背景としたサイバー攻撃の脅威が念頭にあると考えられます。それは、直接的な破壊目的のものだけではなく、経済制裁等の効果を薄めかねない金銭目的のサイバー攻撃の脅威なども含むでしょう。
※ 「脅威ベースのペネトレーションテスト」及び「サードパーティのサイバーリスクマネジメント」に関するG7の基礎的要素の公表について:金融庁 (fsa.go.jp)
国家との関係が取り沙汰されるサイバー攻撃グループが取る攻撃手法を脅威として念頭におく場合、慣習としてよく行われている外部公開サーバに対する脆弱性調査等だけではかみ合わなくなってきます。そうした攻撃グループは、遠隔操作マルウェアを利用して、標的とする組織の内部に直接潜伏する手法を主軸としているからです。
G7会議の本年の議長国は日本です。上記文書の公表から4年が経ちますが、国際情勢を鑑みれば、サイバー攻撃対策がますます重要な議題として取り上げられる可能性は高いでしょう。攻撃側の戦略や攻撃手法、手順にあたるTTPsを意識することが、なおさら求められると思います。
「レジリエンス向上が目的」とはどういうことか
TLPTの目的は組織のレジリエンス向上です。これは、上記の「脅威ベースのペネトレーションテストに関するG7の基礎的要素」や、金融庁の発行する文書である「金融機関等におけるTLPT実施にあたっての手引書」にも明記されています。攻撃者に入られないための防御壁を「事前対策」とすれば、レジリエンスとは、簡単に言えば「事後対策の全体の質」と言ってよいでしょう。事後対策とは、脅威の検知およびそれ以後の人・組織・技術的対応内容およびそれらの対応を決定するプロセスであり、プロセスの成熟度や再現性、スピード等を含めたクオリティが全体の質にあたります。
先述のような、敵性国家が背景にある可能性がある洗練されたサイバー攻撃を想定する場合、事前対策だけでサイバー攻撃を完全にシャットアウトすることはほぼ不可能と言えます。むしろ、検知能力や検知してからの迅速な対応が命運を分けるため、レジリエンス向上が叫ばれています。
TLPTでは、疑似攻撃を行う攻撃側と、攻撃を迎え撃って検知および対応を行う防御側による実戦形式の演習として実施します。攻撃側をRedTeam、防御側をBlueTeamと呼びますが、TLPTの目的は、「BlueTeamにとって良い演習であること」、「BlueTeamの対応能力が向上すること」が第一だと言い換えることができるでしょう。この点が、基本的に脆弱性等の技術的改善点をより多く見つけることを目的とする脆弱性調査やペネトレーションテストとは、明確に異なります。TLPTについて考えるとき、このことを忘れてはならないと思います。
良いTLPTを実施するための工夫とは
TLPTの目的はレジリエンス向上にあります。つまり、BlueTeamにとって良い演習となるかどうかに力点が置かれるべきです。TLPTのご相談をいただく際に、「BlueTeamといっても、当社のCSIRTは小規模で、きちんと動けるか不安がある」というものや、「シナリオの決め方が分からない」という声を聞きます。本節では、良いTLPTを実施するための工夫は何かを考えてみたいと思います。
BlueTeamが適切に動けるのかという不安について
BlueTeamが適切に動けるか分からないので、TLPTなどの取り組みを通じて現状を把握し、レジリエンス向上を目指すのです。ほぼ間違いなく適切に対応できる状態ならば、そもそもTLPTを実施する必要はありません。なので、適切に動けるか不安に感じる必要など、そもそもありません。それでも攻撃レベルとの落差などが心配な場合、ラックでは下記のようなご提案が可能です。
BlueTeam防御シナリオ概要を準備した上での実施
攻撃概要の設計段階で、お客様監視設備、チーム構成等からそれぞれの攻撃フェーズにおける、防御・対応の概要を検討しておきます。これにより、防御・対応の概要がどんなもので、どのようなポイントがあるかを可視化できます。
これを元に、例えばBlueTeamに対する防御シナリオの概要をインプットするブリーフィングを行っておくことなどで、「概ねどのような対応をすればよいかを理解した状態」で演習を行えます。また、演習の全体調整を担うWhiteTeamと連携し、攻撃のペースをコントロールすることなども可能です。
一般的には、BlueTeamの要員に対してテストを実施する旨を事前に告知しない、完全な抜き打ち実施が理想とされていますが、私たちはそれにこだわる必要はないと考えています。レジリエンス向上が目的なのですから、それに最も資する形態をとればよいのです。
監視機構の確認とその後の対応の机上確認による実施
そもそも、CSIRT等BlueTeamの対応のトリガーとなる攻撃検知のアラートがちゃんとあがるのか、という心配の声も聞きます。
確かに、肝心のアラート等が上がらない場合はBlueTeamの初動がスタートしないことから演習とならず、結果としてレジリエンス向上にも寄与しないということになりかねません。
この場合、監視機構の確認から始めてみるのはいかがでしょうか。疑似攻撃に対して、監視機構から検知アラートがあがるかどうか、アラートがあがったことでどのような対応を行うことが想定されるか、対応するインシデントレスポンス手順書等の記載の粒度は適切かなど、検知確認と机上シミュレーションを行うだけでも、十分にレジリエンス向上に寄与していると考えられます。これをTLPTと呼ぶことには議論があると思いますが、目的であるレジリエンス向上に立ち返ったときに最もよいやり方こそ、本来「TLPT」の本質だと私たちは考えています。
どんなシナリオを実施したらよいか分からない
「攻撃シナリオ」と呼ばれるものは、攻撃の起点および攻撃目標のセットです。例えば、最近被害が多発しているランサムウェアを考えるとき、「社内端末の感染を想定した際、その背後にいる攻撃者が」「データ暗号化により、身代金を入手しようとしている」という想定が、攻撃シナリオとなるでしょう。こうした攻撃シナリオの立て方には、どのような注意点があるかを解説します。
実際に起きている事故を参考にする
良いシナリオの第一条件は、実際に起きている事故等を踏まえてシナリオを検討することだと言えます。注意深くセキュリティ事故情報や、セキュリティベンダのレポート等を観察していれば、どのような事故が起きているかはある程度わかります。しかし、セキュリティの専業業者ではないお客様側で、戦略や攻撃手法といったTTPsのレイヤーで具体的な攻撃シナリオの見当がつかないということは、ある意味で当然のことだと思います。TLPTが想定する、国家レベルのサイバー攻撃となれば、なおさらです。そもそも、「この事故は国家が背景にあるサイバー攻撃グループによるものである」という判断(アトリビューション)自体が、簡単ではありません。
プロにお任せいただければよい領域だとも考えられますが、一つの方法は、事故種別の統計等を活用することです。例えば、当社サイバー救急センターにて対応したセキュリティ事故の種別は、下記のようになっています。
こうしたデータを参考に、シナリオの大枠を決めるのも、一つの方法だと思います。ラックのTLPTでは、3大脅威ともいえるマルウェア、サーバ不正侵入、内部犯行について実施のプレシナリオを用意しています。
多層防御の全体を試験する
現代のサイバーセキュリティ環境は、単層の防御で攻撃を守りきれるほど甘いものではなくなってきています。二つ目の留意点は、攻撃シナリオ、あるいはその進め方を多層防御の全体を試験できるように設計するということです。
例えば、外部に公開するサーバにセキュリティパッチを迅速に適用する体制ができていても、攻撃コードがそれよりも早く作成され、標的とされれば侵害される可能性があります。セキュリティパッチが提供される前に攻撃コードが公開されてしまうことがあります。これを「ゼロデイ脆弱性」と呼びますが、最近では珍しくなくなってきています。マルウェア感染ならば、「アンチウイルスソフトが検知してくれるはずだ、それに不審なメールは開かない」というものがありますが、それが完全でないことはもはや説明を必要としないでしょう。こうした可能性がある以上、第二の防御線、第三の防御線が必要であり、「多層防御」という言葉が生まれました。
レジリエンス向上というTLPTの目的に立ち返るとき、第一防御線の検証だけで終わりにすることは有効ではないでしょう。いまこの瞬間に、第一防御線がプロジェクト期間や条件等の制約内で破れないからといって、今後数年間そうであり続ける保証は全くありません。結果の安定性に問題があるためです。進め方やシナリオを工夫し、多層防御を複層的に検証できるようにし、様々な形の検知に対応できるようにすべきでしょう。
他のセキュリティテストとの比較
これまで、TLPTの成り立ちから、その背景や目的をあらためて確認し、その目的であるレジリエンス向上につながる実施方式のコツを紹介しました。最後に、各サービスとの切り分け・すみ分けについて触れたいと思います。これらは、それぞれ共通部分を持つものであり、明確な差異の定義が確立している訳でもありません。ニュアンスとして、それぞれの重視する要素を読み取っていただくことで参考になれば幸いです。
ペネトレーションテストとTLPTの違い
ペネトレーションテストは、基本的に技術的なセキュリティ上の問題点を検出することを目的としています。これに対し、TLPTはテストを実施する中で検出された問題点は報告するものの、その目的は実際に検知・対応の流れを実施、確認することにより、組織のレジリエンスを向上することにあります。
RedTeam演習とTLPTの違い
RedTeam演習とTLPTには、明確な違いがありません。どちらも、技術的問題点の検出およびレジリエンス向上の両方を行います。
ただし、RedTeam演習と言った時には、協働してBlueTeamのレジリエンス向上を引き出すというよりは、RedTeamとBlueTeamの対戦という側面が重視されます。サービスメニューとしてRedTeam演習とTLPTを比較する際は、価格の観点などからTLPTが最上位とされることも少なくありません。本来、より防御・検知および対応に自信のある組織がRedTeam演習に臨むもので、「BlueTeamが完全にうまく動けるか分からないな」という組織こそ、より丁寧にレジリエンス向上を達成できるシナリオ、進め方等をプロジェクト内で設計できるTLPTの実施をおすすめします。
おわりに
昨今の情勢を顧みると、地政学的緊張は高まる一方です。今後、他国とも情報連携を進めてサイバー攻撃に対抗するといったレベルにまで話が進んでいけば、サイバー攻撃を受けたときに迅速に対応できるだけでなく、さらにそれを観察でき、分析でき、結果をIOCデータ等の形で抽出・提供できるということが、脅威情報などの情報連携をする組織に参加する必須要件となってくるのではないでしょうか。
「レジリエンス向上」は、技術的対策のみで防げることを目指す従来の「安全神話」的な立場から見れば、「完全には防げない」ことを認めたパラダイムシフトと言えます。今後の展開を考えると、それはやはり最初の一歩にすぎず、変化が起きるのはこれからであるように思います。
タグ
- セキュリティ
- 人材開発・教育
- システム開発
- アプリ開発
- モバイルアプリ
- DX
- AI
- サイバー攻撃
- サイバー犯罪
- 標的型攻撃
- 脆弱性
- 働き方改革
- 企業市民活動
- 攻撃者グループ
- JSOC
- もっと見る +
- JSOC INSIGHT
- サイバー救急センター
- サイバー救急センターレポート
- LAC Security Insight
- セキュリティ診断レポート
- サイバー・グリッド・ジャパン
- CYBER GRID JOURNAL
- CYBER GRID VIEW
- ラックセキュリティアカデミー
- すごうで
- ランサムウェア
- ゼロトラスト
- ASM
- EDR
- SASE
- デジタルアイデンティティ
- インシデントレスポンス
- 情シス向け
- 対談
- CIS Controls
- Tech Crawling
- クラウド
- クラウドインテグレーション
- データベース
- アジャイル開発
- DevSecOps
- OWASP
- CTF
- FalconNest
- セキュリティ診断
- IoT
- EC
- サプライチェーンリスク
- スレットインテリジェンス
- テレワーク
- リモートデスクトップ
- アーキテクト
- プラス・セキュリティ人材
- 障がい者採用
- 官民学・業界連携
- カスタマーストーリー
- 白浜シンポジウム
- CODE BLUE
- 情報モラル
- クラブ活動
- 初心者向け
- 趣味
- カルチャー
- 子育て、生活
- 広報・マーケティング
- コーポレート
- ライター紹介
- IR