ラック・セキュリティごった煮ブログ

セキュリティエンジニアがエンジニアの方に向けて、 セキュリティやIT技術に関する情報を発信していくアカウントです。

株式会社ラックのセキュリティエンジニアが、 エンジニアの方向けにセキュリティやIT技術に関する情報を発信するブログです。(編集:株式会社ラック・デジタルペンテスト部)
/ セキュリティブログ / セキュリティエンジニア /
当ウェブサイトをご利用の際には、こちらの「サイトのご利用条件」をご確認ください。

デジタルペンテスト部提供サービス:ペネトレーションテスト

ブルーチーム演習の考え方

まえがき

こんにちは、ディオゲネスです。今回は、ペネトレーションテストの中でも、レッドチームテストやブルーチーム演習、パープルチーミング、TLPTなどなど、色々な名称で呼ばれる「ブルーチーム評価・演習を含むタイプのペネトレーションテスト」について考えてみたいと思います。

(本稿では、ややこしいのでそれらを総称してTLPTと呼びます)

こういったテストと単なるペネトレーションテストの違いは、ブルーチームが参画することにあります。レッドチームが「サイバー攻撃を(疑似的に)行うチーム」を指すのに対して、ブルーチームとは「サイバー攻撃への対応を行うチーム」を指します。ごく簡単に言えば、攻撃と守備と言えます。

脆弱性を見つけるだけであれば、ブルーチームに関わる監視設備や、攻撃を検知した際の対応等は、すべて凍結してもらうほうが簡単ですし、何より正確な結果が出ます。事実、多くの診断系メニューではIDS/IPS、アンチウイルスソフト監視ソフト等は疑似攻撃元に対して監視等除外設定をすることが実施の前提とされています。

それでは何のために、わざわざ検出効率を下げてまでブルーチームを巻き込み、手の込んだテストを実施する必要があるのでしょうか?

それは勿論、ブルーチームの能力、すなわち組織のレジリエンスを向上することです。ではブルーチームの能力とか、組織のレジリエンスと呼ばれるものは具体的に何でしょうか。またなぜ、いまそれを改善する事が重要なのでしょうか?

本稿ではそれらの疑問に答えた後、ブルーチームの能力改善が引き出される実施様式とするには、どのような注意点があるかについて書きたいと思います。

 

 

TLPT系サービスが求められる背景

(1)ブルーチーム能力とは何か

ブルーチームの能力とは、サイバー攻撃が行われた際、特にサイバー攻撃が成功して侵入された際に、その事実を検知し、迅速に影響判断し、初期対応により影響を封じ込め、根絶するという一連のインシデントレスポンスを円滑に行う能力を指しています。

能力というと、人間のスキルをイメージするかもしれませんが、例えばどのような監視機器が入っていて機器検知能力がどれほどであるかも、ブルーチーム能力に含まれます。
また日本語としての「ブルーチーム能力」には、再発防止策の策定やそれを組織に徹底する統制力なども含まれそうですが、ブルーチームを含むペネトレーションテストの文脈でそこまでをスコープに含めることは稀であり、通常検知から初動対応完了までの能力を指します。

(2)ブルーチーム能力向上が何故重要なのか

言い古されたことですが、サイバー攻撃は高度化しています。ゼロデイ脆弱性を狙われるかもしれませんし、サプライチェーンを通じて納品された部品に最初からマルウェアが埋め込まれているかもしれません。
国家の支援を受けているとされるサイバー攻撃グループについては、一民間企業等が対峙して抑え込むことが難しくなっているというのが、サイバーセキュリティ版「不都合な真実」でしょう。

このため、「一次侵入は許しても、止めてはならない機能は維持しつつも被害を拡大させることなく脅威を迅速に検知して封じ込めるという組織能力」の重要性が相対的に増しています。このことが、ブルーチームを巻き込んだ各種ペネトレーションテストが求められる背景となっています。

レジリエンス向上に向けたTLPT実施のポイント

誤解されていることがありますが、TLPT型サービスなどのブルーチーム評価を含むペネトレーションテストは、ペネトレーションテストの上位メニューであるという訳ではなく、技術的脆弱性の検出においてはむしろ性能が低下します。
監視機構やアンチウイルス機構に、疑似攻撃という調査を邪魔され、場合によってはブルーチームの対応によって接続を切断されるなどのことが起こる訳ですから、当然のことです。技術的脆弱性の検出または確認が目的なのであれば、診断やペネトレーションテストを実施すべきです。

現在は、目的についてどっちつかずのまま、なんとなく「TLPT型サービスをやりたい」というお声も多いのですが、上記のような事情にも関わらずそういったタイプのテストを実施する場合には、もっと明確にブルーチーム能力改善目的を主役に据えるべき、少なくともその比重をあげるべきだと私は感じています。

その上で、レジリエンス向上、ブルーチームの能力向上のためにはどのような注意点があるかを見ていきたいと思います。

(1)ポイント1:適切なシナリオ選定

前述のとおり、誤解ではあるのですが、「ペネトレーションテストの上位版」というイメージでとらえられているTLPT等サービスを実施しようというようなお客様は、既に通常の診断なりペネトレーションテストを複数回実施していることが殆どです。つまり技術的脆弱性は既に大体潰されている状態にあります。

この状態で、たとえば典型的な悪例である「外部から単一のWebシステムを攻撃するのみ」のシナリオを採用したら、何がおこるでしょうか。
まず、侵入は発生しません。検知は発生しますが、本格的対応もまた発生しません。「ブロックされたとのログだから放っておいた」という対応となるのみです。

本当の攻撃者なら、例えば当該ウェブサイトの運用を支援している業者側にウイルスを送り込み、そこから管理経路を悪用する、などの事に何か月もかけられるかもしれませんが、テスターはそうはいきません。そもそも犯罪になってしまいます。

では、どのようなシナリオを策定すればいいでしょうか?
「一次侵入」自体を起点としてしまうことが、現実的な解決策です。例えば、ゼロデイ脆弱性の悪用によってフロントサーバなりVPN機器なりが侵害された、OAネットワーク内でマルウェア感染が発生した、サプライチェーン上運用委託等を行っているベンダ側が乗っ取られた、などのことを前提として組み込む方法があります。そうすると、ブルーチームの出番がないということはほぼあり得ない状況を作り出すことができます。
何かが検知された時点で、調査・駆除の必要性が生じている事態だからです。
加えて、外部公開システムに対する検知・対応というのは、相場が決まっていて、あまり差がでません。具体的シナリオのおすすめというのは、簡単に状況や環境を踏まえず言えるものではありませんが、敢えてあげるならば、多くの組織にとって実施すべきシナリオは、「OA環境におけるマルウェア感染の発生」だと思います。

実施すべき対応にも、攻撃種別によってバリエーションが広く、またどこで攻撃が発生するかも完全な特定はできない形となるため、良いバランスのトレーニングとなることが期待できます。また、ランサムウェアの猛威を引き合いにだすまでもなく、実際に明日起きてもおかしくないインシデント種別であることも理由です。

(2)ポイント2:適切な情報開示量

ホワイトボックステストと、ブラックボックステストという言葉があります。

例えば通常のペネトレーションテストでは、疑似攻撃を行うテスタが対象システムの構成や仕様、過去に指摘された脆弱性等について知識をもった状態でテストを行うことを、ホワイトボックステスト、なんの前提知識も持たずに標的情報だけ与えられて疑似攻撃を試みることをブラックボックステストと呼びます。

テスタ(レッドチーム)に対するホワイトボックス/ブラックボックス方式の優劣にも流儀や論争があると思いますが、TLPT型サービスの場合、同じようにブルーチームに対して情報を沢山開示した上で実施するのが良いのか、開示しないで、場合によって抜き打ちで実施するのが良いのかという選択肢があり得ます。

これについては、「こうすれば良い」という単純な答えはありません。しかし考え方は簡単です。自組織では、どちらのやり方が目的である「レジリエンスの向上」に繋がるかを判断すれば良いということになります。

より具体的には、既に運用が確立している成熟したブルーチームであり、かつ良いインシデント対応のポイントがチーム内で理解されているなどの場合には、抜き打ち実施(ブラックボックス型実施)などが効果的だし、まだまだ形を整えただけというレベルのブルーチームの場合には、積極的に情報を開示しながらある程度ガイドし、育成の機会と捉えて導いていくことが必要になります。

あなたの組織はどちらに該当するでしょうか。

失礼かもしれませんが、私はまだまだ後者のやり方が適した組織が殆どではないかと考えています。

その根拠は、TLPTを要望されるようなトップ層の企業様であっても、実際に評価を行ってみると、かなり基礎的なセキュリティ監視の設備面等でブルーチームの認識と実態がそもそも乖離しているということが少なくないからです。

そこで、ポイント③では、より多くの組織にベターであると思われる、ホワイトボックス型実施の注意点を記載します。

(3)ポイント3:適切な事前ルール提示

ブルーチームに対してある程度の説明、予告をした上でのホワイトボックス型実施が多くの組織に推奨できる旨記載しましたが、勿論デメリットもあります。

 

例えば、

・「テストだと分かってたからそこまでやらなくていいと思った、本番ならやった」

・「テストだから遮断したら脆弱性検出性能に対して迷惑をかけると思った」

と事後にコメントされてしまうようなこともあるのですが、こうなってしまうと良い演習ができたとはいえないでしょう。

この、「テストだから思考」を封じ込めて、良い演習とするためにはどのような工夫が求められるでしょうか。

情報を開示する代わりに、適切なルール化が必要です。

つまり、「テストであることを対応の判断理由に用いない」などを決めておくことです。ではそうすると、場合によって外部の公的機関への通報などまでやるのか、ということになります。あるいは、情報が漏れたと考えられる場合の対外発表はどうでしょうか。発表文の準備まではやるべきでしょうか。

これらのことについて、良いバランスのルールを明確に決めておくべきです。

 

あとがき

高校時代を思い出してください。テスト問題を先生が生徒に事前に見せたら、それは不正行為です。しかしこの辺がポイントである、この辺がテストに出るよ、と伝えて重要なポイントを予告することは、むしろ有効な育成方法です。

自分たちのサービスを教育指導に例えるとは甚だ傲慢ではありますが、ブルーチームの能力向上を目的としている以上、この不遜な比喩にも含蓄はあります。
テストを受けると言うのはあまり楽しい経験ではありませんが、テスト直前期は貴重な勉強機会でもあった筈です。しかしある程度、「こういう範囲でテストをする」という情報があるからこそ、勉強が進みます。
「来週全国総合学力テストがありますよ」と言われても、あわてて勉強をした人は少ないのではないでしょうか。

つまり、実施シナリオを踏まえて予想されるポイントや対応評価基準を予め示し、既存の手順書やルール等との事前対照を行ってもらうなど、ブルーチームの要員による思考や想像を促すことが、学習効果を高める上では重要です。

世の中のTLPTと呼称されるサービスの中には、評価ポイントや基準を事前に示さず、また明確なルール決めも行わずに「こういうところが気になりました」という後付けコメントだけで済ませている、偽TLPT系サービスも少なくないように感じます。
本当にそれで、目的であるレジリエンス向上につながったでしょうか。

私はCSIRT立ち上げが流行っていたころ、執筆記事の中で「名ばかりCSIRT」という言葉を作って、その後しばらく色々な記事で使われプチ流行しました。
これになぞらえて言えば、今回は、「名ばかりTLPTに気を付けろ」ということになるでしょうか。
本稿で述べたような、本当のTLPT系サービスを実施するのならば、ペネトレーションテストと同じような価格帯でできる筈は無いし、受ける方のお客様組織にとっても、調整の労はその比ではない筈です。

サービスの目的と意味を考え直すきっかけになればと願っています。