1.はじめに
2025年2月13日、つまり1年余り前のことですが、欧州(EU)でTLPT(脅威ベースのペネトレーションテスト)の規制技術基準(RTS、Regulatory Technical Standard)が発効しました。末尾では、テレビニュースなどでも良くおみかけする、フォンデアライエン欧州委員会委員長の名において施行が宣言されています。
日本のペネトレーションテスト市場では、TLPTとはなにか、同じようにブルーチームが検知や対応を行うRedTeam Exercise(レッドチーム演習)と違いがあるのかという点について、専門家の間でも意見の一致を見ず、お客様にとってもとても分かりづらい用語混乱の状況が続いています。
日本と遠く離れたEUの事とは言え、「この要件を満たすものがTLPTであり、満たさないものはTLPTとして（欧州当局は）認めない」という基準を公的機関が発出したことは、注目に値します。
私個人は、多くの日本企業にとってこの基準を意識したTLPTを実施することが良いとは考えていませんし、そもそもEU当局がTLPTプロジェクト自体に人を送り込んで監督することが前提となっているこの基準をそのまま踏襲することは不可能です。しかしながら、その内容を把握し、どのような考え方が読み取れるかを考察しておくことには意味があるでしょう。
そのような背景から、今回は私がこのRTS基準からポイントだと思う点をピックアップして解説したいと思います。
【注】本稿は、RedTeam Exercise や TLPT について、一通りの予備知識がある読者を想定した記載となっています。表明される意見等は筆者個人のものであり、所属元である株式会社ラックの見解を示すものではありません。また、基準に込められている考え方の読み取り等は、推測を含みます。基準引用における日本語訳はすべて、Geminiによる翻訳を参考にしています。
2.EU TLPT技術規制基準のポイント6選
ポイント1：対象システムは自分で選べない
TLPTの対象は組織全体であり、CIF(Critical or Important Functions)、つまりその組織を支える最重要システムを全て候補に含み(AnnexII 項番1および2)、「ここが狙われたら痛い、ここが狙われるのではないか」というところを、脅威インテリジェンスを元にして選定していくことが必要だという考え方が読み取れます。
つまり、テストを受ける側が「この範囲だけを対象にTLPTをしてください」と依頼することは、そもそも欧州基準のTLPTでは自己矛盾的だということになります。
通常の日本の組織でTLPTを行おうという時には、そこまで杓子定規に考える必要はないと思いますが、TLPTとは本来「組織」に対する脅威に導かれて行うテストであり、（攻撃者はどこを狙うかわからないのに）対象システムを、ましてや対象サーバを勝手に限定することはTLPT的ではない、という考え方は参考になるでしょう。
ポイント2：稼働中本番システムが大前提
「対象を選ぶのは脅威（攻撃者）である」という考え方を取った時点で自明な事ではありますが、対象は「実際に稼働中の」「本番環境」ということが前提であり、例えば冒頭の採択理由列挙箇所の項番(11)には、下記のような記載があります。
「(TLPTは)重要な機能が稼働中の本番環境でテストするものであるため、TLPTには固有のリスク要素が伴い、サービス拒否インシデント、予期しないシステムクラッシュ、重要な稼働中本番システムへの損傷、またはデータの紛失、修正、もしくは開示を引き起こす可能性がある。」
もちろん、「したがってこれらのリスクの適正管理をしながら進めなければならない」という趣旨の文章が続いています。しかしリスク適正管理はリスクをゼロにできることを意味しませんので、ある意味では、最悪そういうことが起き得るのがTLPTだと明確にし、かつそのリスクを理由に本番環境を避けて検証環境等を対象とすることは許されないとの考え方が読み取れます。
このことは、そのような事態に備えてレッドチームプロバイダが専門職賠償責任保険(professional liability insurance)に加入していることが求められていることからも分かります。
日本ではまだ、このような保険の実例は少ないと推定されますが、「検証環境等ではなく、稼働中の本番システムへの実施」が本来の姿であるとの認識は必要であると考えています。これは、TLPTで見つかる類の脆弱性や、それを突かれた際の検知・組織対応が、本番環境と検証環境では異なるからです。また、後述するTLPTのブルーチームへの秘密性ということに関しても、TLPTの一環で通常あまり発生しないと想定される検証環境への攻撃が発生すれば、「これはテストだな」と勘づかれて、秘密性を損なってしまうでしょう。
ポイント3：ブルーチームには、実施を悟られてはならない
この点は、本基準では非常に徹底しており、検知・対応にあたるブルーチームの要員等に、TLPTを行う企画の存在自体を知られてはならないことが複数個所で強調されています。
そもそも、「ブルーチーム」の用語の定義（第一条項目3）において、「・・・(略)情報システムを防御しており、かつ TLPT を認識していない者を意味する」と書かれています。
「どうもこれは何かのテストだぞ」と勘づいた人が出てしまったら、その瞬間からその要員はブルーチームの定義から外れるということです。
しかしこれは、考えてみると難しい要求です。実際、検知内容の分析等から勘付く人が出たら具体的にどうすれば良いのでしょうか。第11条項番9 によると、そのような時には、「コントロールチームは、テスターと協議の上、秘密性を確保しつつTLPTを継続することを可能にする措置を提案し」なければならないとされています。ここで、コントロールチームとは、外部ベンダではなく、テストを受ける金融機関自体の推進チームです。
コントロールチームへの経営関与要件、つまり各種例外的調整も行えるような十分な権限・地位(seniority)をもち、経営理事会へのアクセス権を持つ要員の入ったチームとすることが求められている（採択理由列挙箇所 項番10）ことと併せて考えると、「（何かのテストが行われているのではないかということを）本来の申告フローで上司等にエスカレーションを行わない」などの指示をし、その後の対応では実務や判断の中心にならないようにしてもらう、というところでしょうか。
いずれにせよ、そのような場合であっても、可能な限り最大限、秘密性を維持し続けることが求められています。
蛇足ですが、ブルーチームは、テストについて最後まで秘匿されるにも関わらず、テスト終了後10週間以内にブルーチームとしての情報をまとめた報告書の作成を行うことが求められています。秘匿されるということは、事前に明示的な工数の確保等はできていないでしょうから、様々なシステムの運用部隊や外部監視ベンダ等を含む混成チームであるブルーチームにとって、なかなか大変な作業になるでしょう。
さて、秘密性は、次に紹介するleg-up(レッグアップ)の取り入れの観点からもテストを受ける機関にとって、高い成熟度が求められる難しい要求だと感じます。leg-upとは何かを含めて、次のポイントで考察します。
ポイント4：leg-up処理が規定され、推奨されている
leg-up処理とは、「レッドチーム側の攻撃が行き詰った場合、また時間制約やリソース制約によってそうせざるを得ない場合に、攻撃パスを継続できるようにコントロールチームからテスターに提供される支援または情報」（第一条 項番12）を意味します。具体的には、例えば外部から侵入できない場合に、侵入できた場合を想定した攻撃行動の続きを実施するために、内部端末へのリモートアクセスとアカウントを提供するなどのことが該当するでしょう。
これ自体は、当社がペネトレーションサービスの開始当初から大事にしている非常に重要な考え方です。キルチェーン全体を通じた防御・検知・対応のテストをすることが大切だという考え方が読み取れます。
この考え方は、TLPTのみならずペネトレーションテスト全般について重要であり、広まってほしいと思います。
一方で、ポイント３であげた「秘密性」との両立については、簡単ではありません。
上記の例で言うと、「仮に侵入できたら」という前提への leg-up を提供する事は、具体的にはアカウントや接続経路を提供することを意味するでしょう。
それを、ブルーチームへの秘密性を阻害せず準備・設定せよということです。システムの運用を行うチームと、システムの異常対応・分析等のみを行うチームとが完全に職責分離された状態でもなければ、あまり現実的ではない事がおおいように思います。
日本の組織で現実的に実施可能な形を考えるとき、「leg-upの使用によって検証範囲を最大限とし、秘密性は犠牲にする」か、「秘密性を最優先と考えて、leg-upの大々的利用は断念する」か、二者択一となる事が多いのが現実ではないでしょうか。少なくとも、どちらを重視するのかは明確にしておく必要があると思います。（現状では、多くの企業に前者がおすすめであることは、前回記事ブルーチーム演習の考え方 - ラック・セキュリティごった煮ブログに述べたとおりです。）
ポイント5：TIとRTの兼務の禁止
脅威インテリジェンスチーム(TI)と、レッドチーム(RT)には独立性が求められています。同一の会社であることの禁止までは明記されていないようですが、同一会社の場合にはレポートラインが別であることは要件とされています（第7条項目1-e項）。
ある会社の特定の単一部門がTLPTサービスとして両方を提供していたら、それは欧州基準ではNGの可能性が高いということです。
脅威インテリジェンスも定義が曖昧な言葉ですが、本基準では、脅威インテリジェンスレポートに含む内容として、OSINT等の技術的偵察情報だけではなく、地政学的環境、経済的環境の分析などもレポートに含めることが求められています。
確かに、それらを含めるとサイバーセキュリティを超えた少し別の専門性が求められるように思います。
TLPTもそうですが、脅威インテリジェンスについても定義や考え方が様々であるため、実際にTLPTを実施しようとする際には、どのような脅威インテリジェンスを求めているかを明確にし、ベンダの脅威インテリジェンスの解釈と一致しているかどうかを事前に確認することが必要でしょう。
また、脅威インテリジェンスを元に、シナリオを提案（３シナリオの提案・実施が義務付けられており、それぞれ機密性侵害・可用性侵害・完全性侵害を主とする）するのは脅威インテリジェンスチームの役割であり、レッドチームはその実現性等について相談を受けるものの、シナリオ策定は脅威インテリジェンスチームの役割とされています。
挿入コラム：猫も杓子もインテリジェンス
さて、ここで少し脱線して、「脅威インテリジェンスの利用」は、何のために必要で、どんな「偽TLPT」を排除したいということが背景にあるのか考えてみます。
日本では、よく「自社固有の脅威インテリジェンス」ということが言われることがありますが、個人的には疑問を感じています。自社固有なのはシステムの方であって、例えば「金融業界で実際に被害がでた手口情報」や、「日本の金融業界をターゲットにした実績のあるサイバー攻撃グループ」という脅威インテリジェンスは業界共通であるはずです。またEU基準では、地政学的環境分析が明示的に求められていますが、かといって「我が国の地政学的環境」を個々のTLPTプロジェクトで分析することが効率的とは思えません。
この点について、例えば、金融庁ディスカッションペーパー「国際動向を踏まえた金融機関における実効性のあるTLPTに関する考察(金融庁金融情報センター 北原幸彦氏 2025年7月)」(https://www.fsa.go.jp/frtc/seika/discussion/2025/DP2025-2.pdf)では、インテリジェンスを「脅威インテリジェンス」（手口や想定される攻撃者像）と「ターゲティング」（どこからどう攻撃されるか）に分ける、CBEST英国規格などで採用されている考え方を紹介した上で、脅威インテリジェンスについては「個社単位ではそれほどの違いは考えにくい」とし、むしろ業界単位等で優先脅威シナリオを打ち立てることが有効である可能性を示唆しておられます。
これに対し、ターゲティングは、基本的に「攻撃者が攻撃対象アタックサーフェスを選定」することにはじまり、間違いなく個社それぞれ独自分析が必要です。
その意味では、OSINTによる技術的偵察および狙われそうなアタックサーフェスの確認が、脅威インテリジェンスフェーズで最も重視されるべきということになります。
さて、EU基準の脅威インテリジェンスレポートでは、技術的な範囲のものとして、「入手できた従業員のユーザ名およびパスワード」、「類似ドメイン」、「ダークウェブで販売されている情報のレポート」などが求められています。これらの部分はまさにOSINTの実施を想定していると考えられ、更に「職員のユーザ名とパスワード程度はほぼ必ず漏れているものだ、そこまで侵入されている前提で厳しいテストをしなさい」というメッセージを出しているのだなと、私は感じています。
ポイント6：安易にTLPTを実施すべきではない
EU基準が話題を呼んだ理由のひとつは、「3年に1度の実施が義務化されたということ」、そして、その義務を負う金融機関の条件が定量的に（売上規模等）に示されたということです。
しかし一方で、「TLPTの複雑さとそれに関連するリスクを考慮すると、実施はそれが正当化される金融機関に限定されるべきである。（採択理由第３項）」とも書かれています。具体的には、「ICTリスクプロファイルと成熟度」等に照らして、たとえ定量的な（売上規模などの）対象条件を満たしていても、対象とするかどうかは個別判断すると書かれています。
つまり、実施を義務化する一方で、十分に成熟した組織でなければ、TLPTの実施をするべきではないとも言っているのです。
この記載における「成熟度」とは具体的になんでしょうか。第二条 項番1.(b)(viii)を見ると、それが「ICTセキュリティ検知および軽減措置の成熟度」であることが分かり、下記のような例示があげられています。
・ICT関連のイベントをリアルタイムで検知する能力（の成熟度）
・検知イベントを分析する能力（の成熟度）
・検知イベントに対しタイムリーかつ効果的な方法で対応する能力（の成熟度）
また、ポイント３やポイント４に記載したような成熟度も、併せて必要でしょう。
義務化ばかりが強調されている印象ですが、これらの運用が成熟していない組織では、TLPTは実施できないということを明示している点も、義務化と同じだけ注目すべきだと思います。
3.おわりに
如何でしたでしょうか。ほかにも「リプレイ」や「パープルチーミング」（実施後に、あらためてミニ技術検証等を含んでブルーチームとレッドチーム共同で振り返りを行うこと）、テスト期間に関する要件など、まだまだ紹介すればきりがないのですが、今回はここまでとしたいと思います。
これに準拠したTLPTを、と考えるのは、多くの組織にとって現段階ではコスト効率的ではないように私は考えていますが、そうであってもところどころに散りばめられた考え方自体は参考になるのではないでしょうか。
EU基準は、EU当局側がテストマネージャを輩出して実施するものであることからも分かる通り、監査の色彩が非常に強いと感じます。自主的取り組みとしてのTLPT実施においては、何を主目的として、何にはこだわり、何はお任せでよいかをある程度明確にした上で内容を詰めていくことが、求めるサービスを提供してもらえるためにお客様側で必要な事だと思います。
