脅威ベースのペネトレーションテスト「TLPT」超入門

イエラエセキュリティの顧問を務める川口洋が、イエラエセキュリティを支える多彩なメンバーと共に、サイバーセキュリティやサイバーリスクの今を語り合う座談会シリーズ、第17回をお送りします。

川口洋氏は、株式会社川口設計 代表取締役として、情報セキュリティEXPO、Interop、各都道府県警のサイバーテロ対策協議会などで講演、安全なITネットワークの実現を目指してセキュリティ演習なども提供しています。

イエラエセキュリティ主催にて川口洋座談会 特別版「TLPTとは何だ？」を2020年10月2日（金）に開催しました。本ウェビナーは、業務システムに関わる従業員、サイバー攻撃への対応チーム（CSIRT）を対象に参加者を募集し、当日は多くの視聴者の方々ご参加頂きました。
イエラエセキュリティからは顧問、川口洋がモデレーターとなり、イエラエセキュリティ　オフェンシブセキュリティ部　部長のルスラン・サイフィエフが登場。

そしてNRIセキュアテクノロジーズより大塚 淳平様（DXセキュリティ事業二部　上級セキュリティコンサルタント）と佐藤 裕作様（NRIセキュアテクノロジーズ　DXセキュリティ事業一部　セキュリティコンサルタント）にお集まり頂きました。「TLPT」と「ペネトレーションテスト」との違い、「脅威」とは何か等、丁寧に解説して頂きました。

本記事の収録動画を公開中

イエラエセキュリティ川口洋座談会

「TLPT」とは「脅威ベース」のペネトレーションテスト

川口洋（以下、川口）：今日はTLPTについて、ペネトレーションテストの違い等々について話していきます。私、モデレーターを務めさせて頂きます川口洋と申します。続きまして皆さん、自己紹介お願いします。

ルスラン・サイフィエフ（以下、ルスラン）：イエラエセキュリティのルスラン・サイフィエフと申します。主にペネトレーションテスト、レッドチームテストを担当しています。10月1日に「オフェンシブセキュリティ部」と「ディフェンシブセキュリティ部」が作られまして、「オフェンシブセキュリティ部」にペネトレーションテスト課とアプリケーションセキュリティ課が存在しています。私はペネトレーションテスト課に所属しています。

大塚淳平（以下、大塚）：NRIセキュアテクノロジーズの大塚と申します。普段はTLPTの支援ですとか、ペネトレーションテストを実行しております。よろしくお願いします。所属の「DXセキュリティ事業二部」の“DX”は、デジタルトランスフォーメーションの意味です。システムに関わるセキュリティ全般ということで、皆様のデジタル化を支えるという意味を込めた名前になっています。

佐藤裕作（以下、佐藤）：NRIセキュアテクノロジーズの佐藤と申します。私もTLPTやペネトレーションテストをメインでやらせて頂いています。その他、WebアプリケーションやAPIのセキュリティも専門としています。よろしくお願いします。　

川口：今日はいろんなお立場の方にご視聴、ご参加いただいておりますので、よろしくお願いします。ではまず最初に、「TLPTとは何か」という説明を、大塚さん、お願いいたします。

大塚：はい。近年、金融機関を狙ったサイバー攻撃というのは非常に多くなっています。皆さん、ニュースなどでご存じかと思います。そのうちここに挙げた3件「バングラデシュ中央銀行の不正送金事件」「Banco de Chile銀行の不正送金事件」「Cosmos Bankのシステムに不正アクセス」などに特徴的なんですが、非常に被害金額が大きいんです。

銀行さんから直接お金が送られたという信じられないような事件が起きました。これらの企業はセキュリティ対策を昔からしっかりやっていたと言われていたんですけど、何故やられてしまったのか。これまではシステム単体でのセキュリティチェックや対策で十分だったのが、業務プロセスに注目するというところが出来ていなかった。これをきちんと見るためには、従来のアプローチだけでは難しいということになり、「TLPT」というキーワードが出てくるようになりました。

「TLPT」とは何かというと、Threat Led Penetration Test=脅威ベースのペネトレーションテスト、つまり「自社が晒されている脅威を想定して行うペネトレーションテスト」ということになります。「脅威」というのは、教科書的には「敵対する意図」×「機会」×「能力」の組み合わせだと言われています。それぞれを噛み砕いてみると「どのような攻撃者が狙ってくるのか？　攻撃者の狙いは何か？」×「攻撃するポイントはどこか？」×「どんな攻撃手段を使ってくるのか？」ということになります。それと組み合わせてペネトレーションテストをする、ということになります。

具体例を挙げてみます。「敵対する意図」としては、お金を稼ぎたい、産業スパイのようなことをしたいということが動機として考えられます。そうしますと、狙う対象としては、顧客が多い金融資産を持っている組織、ということになります。「機会」としては、社内ネットワークがあげられます。これは近年どの組織も社内ネットワークに重要な情報を持っていて、例外ではありません。また関連企業と作業委託や業務連携をしていて、メールでやりとりする商習慣がある場合、これも攻撃者から見ると「機会」となります。そして「能力」でどんなことをしてくるのかというと、関連企業に成りすましてメール攻撃を行って端末を乗っ取る、乗っ取った端末から認証基盤を攻撃しましょう、といったことになります。そこから重要情報を取得し、それを売りさばくことで本来の目的「金銭を得る」を達成するわけです。

このうち「脅威」だけ想定して、「こんな事件が起こっているけれども自分たちは大丈夫か？」と考えてテストに臨んでしまうのがよくあるケースですが、ペネトレーションテストをする上では、得られた情報を元に自分たちの環境に照らし合わせて、どこが攻撃されそうか考えるのが重要です。先ほどの例で言いますと、メールを送ることで社内を攻撃してくる攻撃者がいた場合、「メールを開く人は居るから、うちの会社にも該当する攻撃だね」と考えて、「メールを開いて感染した人がいた場合、どこまで影響を受けてしまうか考えましょう」というのが、脅威を踏まえたペネトレーションテストになります。

「脅威」を「ゼロである」と見誤らない為に

川口：この「脅威ベースの」という言葉が出てきた時に「えっ、これまでも脅威ベースでやってたんじゃないの？」って思ったんですが、そこはどうなんですか？

大塚：従来からの「ペネトレーションテスト」というのは、例えば自社の基盤にあなた方の端末繋いでみるということはやっていたのですが、今どんな攻撃が流行っているのか、実際どんな手段が使われるのか、というのを組み合わせるのがペネトレーションテストということになります。

川口：質問を頂きました。5ページに「脅威は3つの要素の掛け算」と書いてありますが、そのどれかがゼロなら、無くなるということなんでしょうか、とのことです。

大塚：はい、本当にゼロならゼロになるかもしれませんが、実際には「非常に確率が低い」ということになるのではないかと思います。

ルスラン：スナップショットとしてはゼロかもしれないけれど、時間が経つと変わるということはありますよね。例えば「機会」では、会社が作られたばかりで資産が無い、ということが考えられます。「能力」についても、ゼロデイの脆弱性が出てしまうと一発でシステムが乗っ取られてしまうということがありますよね。

川口：続いて質問が来ています。「ゼロだと誤って認識しないようにする為にはどうしたらいいのか」ということですが、どうですか？

大塚：実際に調査をする時に、どこまで信頼がおける調査を実施するかですよね。自分たちの環境はリスク無いよねと判断せず、「やられるんだぞ」という可能性を持って評価をするのが大事なのかなと思います。

ルスラン：SOCがあって検知されてしまう可能性が高いとか、入られてしまっても最終的な狙いまではたどり付けない等の、リスクを考えた上で判断すればいいと思います。

川口：「脅威ベースのペネトレーションテスト」はまだまだ馴染みが無いのかなと思いますが、評価項目というのはどういうものなんですか？

大塚：システムの安全性だけではなく、会社が攻撃を受けた時にそのシステム自体が安全か、セキュリティーの対策ソリューションを入れている場合は攻撃がちゃんと検知できるのか、また検知した後に被害が大きくならないうちに押さえ込めるか。こういう所が、評価対象になります。

川口：今までは「脆弱かどうか」だけを気にしていた気がしますが、ちょっと変わってきていますね。

ルスラン：そうなんですよね。その脆弱性が“使えるか”どうか把握できていなかったんです。使ったとしても、最終的なゴールにどこまで行けるのかというのを検証しておく必要があります。脆弱性があったとしても、SOCがもの凄く検知してしまう場合は、使おうとしても使えないということになります。

脆弱性診断は「ベストプラクティス」との差分で評価

川口：脆弱性診断する時に「SOCの監視オフにしておいてください」ということはあると思うんですが、ペネトレーションテストでは「通常通りのセキュリティの運用のままやってください」と言わないといけないですね。

佐藤：いわゆる「セキュリティ診断」「脆弱性診断」という取り組みは、システムに対してある程度網羅性を持って脆弱性を洗い出したいという意図がありますので、そういう意味では、SOCのオペレーションでカバーされてしまったりすると、システム自体のセキュリティが正しく評価出来ないので、「オフにしておいてください」ということがあるんです。一方で「ペネトレーションテスト」や「TLPT」は、その部分も含めての総合的な評価となります。どこまで通常通りに対応してもらうかは、事前にしっかり決めておく必要がありますが。

川口：脆弱性診断とペネトレーションテストを比較する表に「観点」という項目があって、ここに「脆弱性診断＝ベースライン」、「ペネトレーションテスト＝リスクベース」と書いてありますね。リスクベースというのは理解できたのですが、この、ベースラインというのはどういう意味でしょうか。

大塚：「ベースライン」というのは、何らかの規格のことを表しています。例えば「OWASP」とか、「セキュリティ対策ガイドライン」等があって、それに照らし合わせて、対応できているのかどうか。チェックリストをチェックしていくイメージになりますね。

佐藤：ベストプラクティスと照らし合わせて、差分を見ていくというやり方ですよね。一方でペネトレーションテストはもう少しダイナミックにやるというか。実際に問題が発生するのかどうか、成功してしまうのかということにフォーカスしています。

「ホワイトチーム」の活躍がTLPTプロジェクトの鍵

川口：「TLPT」では、「脅威分析を踏まえた」というところがポイントになっているわけですね。この「脅威分析」というのは、プロセスの中では誰がやる事になってるんでしょうか。

大塚：脅威分析は「レッドチーム」と呼ばれる人たちが行います。TLPTの実施時には、経営者・プロジェクトチーム・ホワイトチーム・ブルーチームがテストを受ける対象者と考えられますが、レッドチームが攻撃者側として活動します。このレッドチームが、「今、脅威はどんなものがあるんだろう」「この対象の会社であればここを攻撃すべき」というのを考えて、作戦を立てて攻撃するわけです。

川口：「ホワイトチーム」「レッドチーム」「ブルーチーム」と、この3つの機能が必要になってくるということですね。よく出てくるキーワードで大事だなと思いつつ、まだまだ世の中に言葉が浸透していないところですね。

大塚：「レッド」や「ブルー」は昔から使われていましたよね。「レッドチーム」は攻撃側、「ブルーチーム」は防御側です。ブルーにはCSIRTの方々やSOCなど、何か起きた時に対応する人たちが該当します。最近は、ここに「ホワイト」を加えた形になっています。

ホワイトチームはテストの計画を立てて、関係者間調整や、テスト中に「どこまでやっていいよ」「何かあったら相談してね」ということをコントロールするチームです。TLPTを実施する背景には「システムの重要な部分を見たい」「重要な業務オペレーションをチェックしたい」という要望がありますが、そこをテストしたことでシステムが止まったり壊れたりすると業務に影響が出てしまいます。なるべくテストによる影響は抑えたい、でもなるべくテストできるところまでやりたい、というバランスを調整をするチームでもあります。

川口：ホワイトチーム、めちゃくちゃ重要なチームですね。

大塚：従来のぺネトレーションテストでしたら「テスト実施可能な会社に委託して終わり」だったと思うんですが、TLPTではホワイトチームにも重要な役割があるため、一緒にプロジェクトを進められる会社を選ぶことが重要だと思います。

川口：ここがTLPTの肝な気がしますね。テストを受けてレポート貰って終わり、ではなくて、関係者の連携こそがTLPTやる上で超重要だよ、と今すごく思えてきました。

ここで、今日、「何故、イエラエセキュリティとNRIさんが一緒に並んでセミナーをやっているのか？」というところが視聴者さんの気になるところだと思うんですけど、我々の役割分担というところをご説明頂けますか？

大塚：ぺネレーションテストというのは、より高度な内容をクリティカルなシステムでテストしたいという目的がありますので、それをより良く提供いくために、私たちの強みを生かして組んでいけないか、というお話をさせて頂いています。

TLPTのホワイトチームとして活動するためには、レッドチームやブルーチームの事情が分かっていた方が取組みやすくなります。弊社には、レッドチーム、ブルーチームそれぞれをサービス提供するチームやありますし、セキュリティ施策を支援するコンサルチームもありますので、それらのノウハウを活かしたご支援ができます。
TLPTの工程全般を支援したサービス提供実績もありますので、それらを活かすのはもちろんですが、更に攻撃力の高いレッドチームを作るためにイエラエさんと協力してサービス提供していきたいと考えています。
TLPTの対応に慣れてらっしゃるお客様であれば、ホワイトチームはご自身で実施するとして頂ければと思うのですが、慣れないうちはどうしていいのか分からないと思うので、ホワイトチームを含めた全行程を支援を受けていただいて、その中でスキトラもさせて頂くと良いと考えています。

川口：最初にこの話を聞いた時に「その役割分担ははまるよな」と思いました。ホワイトチームの位置を考えると、そのような支援は重要なのかなと思いますね。

“ポテンヒット”を出さない為の、リスクベース評価

川口：沢山質問が来ておりますので、ここからは順次拾っていきたいと思います。「ペネトレーションテストは、見つけた脆弱性を攻撃された時に対応できるかどうかという、総合的な訓練に近いイメージですが、それで合ってますでしょうか」

佐藤：そうですね、「総合的な訓練」という表現は間違っていませんが、事前の脅威分析でどこに力点を置いてどういう攻撃者を想定してやるのかということをより明確にするところがTLPTの特徴ですね。

川口：視聴者からの質問「TLPTは脅威分析を踏まえることで、行き当たりばったりではなく効率的に実施できるのでしょうか」。

佐藤：「効率的」という言葉をどう捉えるかというところもありますが、脅威分析によって攻撃者の想定が出来ているので、実際に直面し得る脅威に対応したテストになる、といった点では効率的と言っていいと思います。また効率性を上げていく、テストの密度を上げていくという意味では、脅威分析シナリオ構築の部分が非常に大事で、どういう攻撃が起きるのかというのを社内の環境や保有しているシステムと照らして決めていくのが、効率的に進めるための前段階として重要なポイントになると思います。

川口：視聴者からの質問「リスクベースの三つの軸のうち、敵対する意図というのは、主に評価対象は人ということでしょうか？　組織そのものの特質上（業種や知名度等）回避しようがないものもあると思いますが、敵対する意図の部分の評価方法について教えてください」

大塚：はい、ご質問にある通り、脅威のうちには回避できないものがあります。例えば歴史上の何か出来事があった時、例えばデモの発生というのは挙げられます。また日本の会社は一律に狙おう、オリンピックスポンサーを全部狙おう等ですね。

評価方法は、自分の会社が持っている資産や業務上の性質、ブランドを整理しておいて、そういうものを狙う攻撃者グループがいるかどうか、調査していくことになります。それと照らし合わせて「こういう攻撃者がウチを狙ってきそうだ」と評価していくような形になります。

ルスラン：内部犯罪者も考えられると思います。内部犯の場合は、システムが対策されているか、といったシナリオも考えていくことになりますね。

川口：視聴者からの質問「TLPTではソーシャルエンジニアリングなどの攻撃のテストも実施するんですか？」

佐藤：そうですね、そういう攻撃者を想定するのであればそこもテストに含めていきます。サイバーの世界のソーシャルエンジニアリングだけでなく、そこで得られた成果をもとに物理的な侵入まで試行する等、テストのスコープには広がりがあると思うんですが、そこも計画段階でどこまでスコープとするのかをネゴっておくというやり方です。国内ですと物理侵入を想定されるケースはまだまだ少ないんですが、今後そういったテストが日本でも一般的になっていく可能性というのはあるのかなと思います。

川口：海外ですと物理的なものも含めてぺネトレーションテストしてたらお客様の行き違いに巻き込まれて逮捕されたというような事例があったと思いますので、そこは慎重にやらないと大変なところですよね。

次の質問です。「TLPTで、システム・人・対応プロセスが同列に扱われている理由は何故でしょうか」

佐藤：いわゆる脆弱性診断はシステムにフォーカスした取り組みで、「防御」の観点を確認する意味合いが強いものですが、例え防御をすり抜けてしまっても「検知」したり、検知後に正しく「対応」できるのか等、深さのあるテストをやる場合には、その対応している「人」のスキルや、事前に定めている「対応プロセス」がどうなっているかということが重要になってくる。そういう意味合いですね。

大塚：例えば「セキュリティ検知が出たが、レベルがそんなに高くないとして対応無しとしていた。しかし攻撃の際にそれが大きなキッカケとして利用され、攻撃が成功してしまった」といったことが、TLPT実施することで分かるので、そういった場合に「対応プロセス」を見直しましょう、ということになります。

川口：視聴者からの質問「『敵対する意図』への追加の質問です。お答え頂いた内容からするとサプライチェーン的なリスクも含まれると思いますが、関係会社まで評価するのでしょうか」。最近世の中で起きている事件て、一社のシステムだけでなく他社と組み合わせてサービスを提供している中で起こっていますよね。自社のみで完結しないものに対するリスクをどう評価するのか。これがテストに含まれるかどうか、含まれるのであればどう評価するのか、お伺いしたいです。

大塚：ザックリとお答えすると「含めるべき」ということにはなるんですけれども、やっぱり限界はあるのかと思います。まずは重要な機能に注目して、そこにサプライチェーン的なリスクがありそうなのかどうなのか整理していって、どこまで確認するのかを決める。それはスコープや目的次第で変わってきますので、都度調整することになってくるかと思います。

川口：「スコープをどのようにしますか」ということを詰めていかないと、見たいものが見れてない、ってことになっちゃうわけですね。

大塚：そうですね。例えばシステム開発を外部に委託していて委託先から納品されたシステムが安全であるかを確認することはよく実施されているかと思うのですが、OA関連の物品を購入している会社からのリスクすら考えるのかなどが検討する点としてイメージしやすいのかと思います。

川口：スコープを広げすぎると大変ということですね。TLPTを受ける側はどのようなアクション、準備をしてTLPTに臨めばいいのか、というところを教えていただけますか。脆弱性診断なら「テスト用のサイト用意しておいてください。何時から何時までにこれでお願いします」と言ったら、あとは診断ベンダーさんがやってくれるもんだと思うんですけど、TLPTは自社で準備することを用意することが違ってくると思うんです。

大塚：はい、今、日本だと金融情報システムセンター（FISC）の出している手引書を参考にするのが良いのではないかと思います。それに従うと、計画フェーズに「プロバイダー選定」とあり、ここでレッドチームの委託先を選定したり、スコープ設定をする等があります。ここをホワイトチームとして活動頂いてからお願いする、といった流れにして頂ければと思います。ただ現実的には、計画を発足させる段階で我々にご相談頂ければ、うまく調整できるんじゃないかなと思いますね。

川口：この全体イメージと、フェーズの理解は大事ですね。あと「どの程度の期間を見ればいいですか」という質問がありました。フォーカスする内容によるとは思うんですが、一般的な、何らかの目安になる時間軸の目安としては、いかがでしょう。

大塚：私が対応するケースで多かったのは、このフェーズ1「計画」から4「評価及び改善計画策定と実施」まで、全体で3〜4ヶ月程度ですね。

佐藤：最長で半年位かかったこともありますね。計画段階から実施段階に差し掛かって来た時に、少しお客様側の事情に変化が起きてしまって実施タイミングを後ろにずらさざるを得なかった、だとか、そういうこともありました。またフェーズ4のフォローアップの段階で、少し長めに支援させていただいたことで長くなったこともあります。

ルスラン：フェーズ3「ペネトレーションテスト実施」については、これも対象やスコープによって変わってはきますが、長くても2ヶ月ですね。攻撃のシミュレートや、調査にも時間が必要ですので、できれば長い期間を頂いた方がいいですね。どうしても期間を減らしたいという場合、「この攻撃は出来てしまった、という想定で進める」と条件を設定することがあります。

川口：2ヶ月もテストしてくれるんですね。そうなると、相談してから契約に至るまでの時間のリードタイムを考えると、やりたい時期の半年位前に話が出ていないと、準備しきれないですね。

佐藤：そうですね。サクッとやるようなものではないですね。腰を据えて計画していく必要があるので、早め早めにご相談頂ければそれだけご要望のスケジュールに合った提供の仕方もできるかと思います。

川口：次の質問です。「外資系コンサルティング会社との差別化はどのようなものがあるか気になります」。

大塚：これは鋭い質問ですね。大手金融機関はTLPTの実施が1〜2巡程度してらっしゃるかとは思うんですが、その中で外資系コンサルティング会社の良い所・悪い所を耳にすることが多いんです。そこで、その中でも失敗例について整理しています。それらのお声を反映して、ペネトレーションテストの計画から改善まで、きっちりとフォロー、ケアするというところが、差別化…になっていると嬉しいなと思っております。
また、弊社ではCBESTなどが提唱された頃からTLPTに近しいコンセプトのサービスを提供していて、それらのノウハウもあることから、昨年にFISCから発行された「金融機関等におけるTLPT実施にあたっての手引書」の検討部会に委員として参加させていただいており、日本企業にあった形での進め方のアドバイスをさせていただけると考えています。

川口：視聴者からの質問「近年では自社サイトに脆弱性診断する企業が増えてきましたが、ペネトレーションテスト、TLPTについては理解が薄いように思います。普段診断業務されている皆様から見た温度感や、どのように普及させていくべきかのアドバイスについてお聞かせ下さい」

佐藤：個別のシステムの脆弱性診断を行なっていると、ポテンヒットというものがどうしても生まれてしまいます。最近ですとスマートフォンアプリのバックエンドにAPIがあって、ブラウザアプリからも同じAPIを別の方法で利用できたり、そのAPIが別のシステムとも連携していたり、等ですね。システムの関係自体も複雑化していますので、そこで今まで通りのテストをやっているだけですとどうしても「システム間の連携に不備がありました」だとか「スマホアプリのユースケースにだけ穴がありました」ということが出てきてしまいます。

そこでやはりリスクベースの評価というのは非常に大事だと思っておりまして、「結果として攻撃者はこんなこと出来てしまいますよ」というストレートな答えを出していくのは必要なことです。その辺をしっかり説明して、社内で合意を取っていくということになるのではないかと思います。

川口：「TLPTの結果報告書にはどのような内容が含まれているのか、目次例等でご紹介いただければ幸いです」とのことです。こちらは後日、資料をご提供時で構いませんが、チラ見せできるサンプルはありますか？

大塚：はい、サンプル報告書、目次等ご用意出来ると思います。

川口：「TLPTに向いている業種、TLPTをやって良かったという事例があったら教えてください」ということですが、ルスランさん何かお話頂けるケースはありますか？

ルスラン：そうですね、侵入テストをした会社さんからはよく感謝されます。侵入が出来て、監視不足ということが把握できますので、レッドとブルー、両方の側面を持つ「パープルチーム」としてSOC側との擦り合わせをして、どの部分をもっと見ておけばいいか相談することもします。

TLPTはレッドチームテスト等よりも体制をきっちり調整していくという所に差があります。そういうチェックが必要なければレッドチームやペネトレーションテストでも良いかもしれませんが、大企業などでは部門間調整も重要なファクターですので、その場合はTLPTがオススメですね。

佐藤：冒頭にあった脅威の大きさの見積もり方の話の中で「敵対する意図」というのはコントロールすることが難しい部分です。ですので、「敵対する意図」が大きいと思われるような業態、金融機関やミッションクリティカルなシステムを取り扱っているお客様には、TLPTが適していると思います。

ルスラン：TLPTをやらなくてもいいという会社は存在しないと個人的には思っています。総合的な評価をすることが出来ますので、是非どなたでも、やって欲しいと思います。

川口：元々TLPTという言葉は金融機関から出てきたように思いますし、インフラ企業さんも向いていそうですね。

さてここまで1時間、あっという間に経ってしまいました。聞いてらっしゃる皆さんはそれぞれの所属や組織規模、業務によって、それぞれ気になる点は違うと思います。その時は是非、周囲の営業さんを捕まえてお話聞いて頂けると良いかなと思います。本日は有難うございました。

本記事の収録動画を公開中

イエラエセキュリティ川口洋座談会