脅威ベースのペネトレーションテストとは、自社を狙う可能性の高い攻撃者の手口を分析し、その戦術をそのまま再現して、組織の防御力と検知力、対応力を確かめるテストです。英語のThreat-Led Penetration Testingを略し、TLPTとも呼ばれます。脆弱性診断が「弱点がどこにあるか」を洗い出すのに対して、こちらが答えるのは「実際に攻撃を受けたとき、自社は気づいて止められるのか」という問いになります。
診断やテストを重ねても、監視やインシデント対応が本番で機能するかどうかは、攻撃を受けるまで分かりません。この空白を埋める手法がTLPTです。ただし本番環境に予告なく疑似攻撃を仕掛けるため、通常のテストより費用も期間も社内調整の手間もかかります。
この記事では、通常のペネトレーションテストとの違い、実施体制と5つのフェーズ、費用と期間の相場、そして金融庁が実施経験のある銀行への調査で明らかにした3つのつまずきとその回避策を解説します。いずれも、自社がTLPTに着手すべき段階にあるかどうかを見極める材料になりますので、ぜひ参考にしてください。
脅威ベースのペネトレーションテストとは何か
脅威ベースのペネトレーションテストは、自組織が現実に狙われる可能性の高い攻撃者を想定し、その攻撃者が使う戦術や手順をなぞって疑似攻撃を仕掛ける検証手法です。一般的なテストが「侵入できる弱点があるか」を確かめるのに対し、こちらは「実際の攻撃者に同じことをされたとき、自社はどこまで持ちこたえられるか」を問います。シナリオの作り方、評価する範囲、そして公的な定義が置く条件の3点に、通常のテストとの差が表れます。
実在する攻撃者の手口を起点にするという考え方
出発点になるのが脅威インテリジェンスです。脅威インテリジェンスとは、攻撃者の目的や標的、使用する手法などを収集し分析した情報を指します。公開情報やダークウェブ上の情報、業界内で共有される攻撃事例などから、自社や自社の業界を狙う可能性のある集団を特定し、その集団が過去に使った侵入経路や道具立てを洗い出していきます。
この情報をもとに攻撃シナリオを作るため、テストの内容は組織ごとに変わります。同じ業種であっても、扱う情報や外部委託の状況が違えば、想定する攻撃者も攻撃経路も別のものになるでしょう。
評価の対象はシステムだけでなく人とプロセスにも及ぶ
もうひとつの特徴が、評価範囲の広さです。
攻撃者はシステムの穴だけを狙うわけではありません。従業員をだますメール、外部委託先の管理の緩さ、退職者アカウントの放置など、組織の運用上の隙も等しく狙ってきます。
そのため脅威ベースのペネトレーションテストでは、攻撃を検知する監視部門と、検知後に動くインシデント対応の体制が評価対象に入ります。防御側の担当者を指してブルーチームと呼び、その対応の速さと適切さがテスト結果の中心を占めます。
公的な定義から読み取れる4つの条件
G7サイバー・エキスパート・グループは2018年10月、脅威ベースのペネトレーションテストに関する文書を公表しました。金融庁の仮訳では、金融機関のコントロール下において、実在の攻撃者の戦術、テクニック、手順をまねることにより、金融機関のサイバーレジリエンスを侵害しようとする攻撃の試行と定義されています。サイバーレジリエンスとは、サイバー攻撃への耐性と、被害からの回復力を指す言葉です。定義はさらに、特定の脅威情報にもとづき攻撃を試行するものであり、予備知識と業務への影響を最小限に抑えつつ、金融機関の職員、プロセス、テクノロジーに焦点を当てるものと続きます（※1）。
文言は金融分野を前提としていますが、考え方そのものは業種を問いません。ここから読み取れる条件は4つです。
- 特定の脅威情報にもとづくこと
- 実在の攻撃者を模倣すること
- 組織の管理下で安全に行うこと
- 人とプロセスとシステムの3つを対象にすること
この4点は、G7文書の定義文から読み取れる要素を整理したものであり、規格化された適合基準ではありません。ただし、いずれかが欠けている場合、名称は同じでも中身は通常のペネトレーションテストに近づきます。また、EUのTIBER-EUのように、これに加えて独自の要件を課す枠組みもあります。
※1 参考：金融庁│「脅威ベースのペネトレーションテストに関するG7の基礎的要素（仮訳）」
脆弱性診断や通常のペネトレーションテストとの違い
3つの手法は目的も対象も異なります。違いを取り違えたまま発注すると、期待していた検証が行われないまま報告書だけが残ってしまうでしょう。ただし実務でより迷うのは、目的の違いそのものより、3つのうちどれを先に実施するかという順番です。
3つの手法を目的と対象範囲で比べる
なお、期間や実施環境は条件によって幅があります。脅威ベースのペネトレーションテストの期間は、シナリオ数や当局の関与の有無で大きく変わります。範囲を絞った実施では1〜2カ月で終わる例がある一方、当局主導の枠組みでは準備を含めて1年近くを要した例も報告されています。（※2）
| 比較項目 | 脆弱性診断 | ペネトレーションテスト | 脅威ベースのペネトレーションテスト |
|---|---|---|---|
| 主な目的 | 弱点を網羅的に洗い出す | 特定の目標を達成できるか実証する | 組織の防御力と検知力、対応力を評価する |
| 起点 | 既知の脆弱性パターンや規格 | 想定した攻撃シナリオ | 自社を狙う攻撃者の脅威情報 |
| 対象範囲 | 個別のシステムやネットワーク | システム全体と侵入経路 | システムに加えて監視体制と対応体制 |
| 実施環境 | 検証環境でも可能 | 目的により選択 | 原則として本番環境 |
| 防御側への通知 | 該当しない | 多くの場合共有する | 原則として予告しない |
| 期間の目安 | 1週間から4週間程度 | 1週間から数カ月 | 3週間から1年程度 |
とくに差が出るのが、防御側への通知の扱いです。脅威ベースのペネトレーションテストでは、防御側に予告しないことが原則とされています。実施日時を知っている担当者の対応は、平常時の検知力とは別のものになってしまうからです。
優劣ではなく積み上げる順番がある
脅威ベースのペネトレーションテストが上位互換というわけではありません。既知の脆弱性が放置されたままでは、攻撃側を担うレッドチームが最短の穴から侵入して終わってしまい、検知力や対応力を測る段階まで進めないからです。
どこから着手すべきかは、自社の対策がどこまで回っているかで決まります。脆弱性診断で基本的な弱点をつぶし、必要に応じてペネトレーションテストで侵入経路を実証し、そのうえで組織の対応力を確かめる。これが基本の順序です。それぞれの手法の詳細は、脆弱性診断とペネトレーションテストの違いを扱った記事、および実施の流れを解説した記事もあわせてご覧ください。
※2 参考：金融庁│「諸外国の『脅威ベースのペネトレーションテスト（TLPT）』に関する報告書」
いま国内で注目される理由と2024年以降の制度動向
侵入を完全に防ぐ前提が崩れたことが、この手法が広がった背景にあります。標的を絞って長期間潜伏する攻撃に対しては、境界での防御だけでは足りず、侵入された後に気づいて封じ込める力が問われるようになりました。国内では2018年の調査報告書に始まり、2024年のガイドラインで実施時の留意点が明文化されています。海外はさらに先を行き、法規制に組み込む段階へ入りました。
出発点は2018年の調査報告書とFISCの手引書
国内での検討は2018年に動き出しました。金融庁は同年5月、諸外国の実施状況をまとめた調査報告書を公表しています。この報告書には、英国の財務省と中央銀行、金融行為規制機構が2014年に導入したCBEST、欧州中央銀行のTIBER-EU、香港金融管理局のiCASTといった当局主導の枠組みが記載されています（※3）。同年10月には、G7サイバー・エキスパート・グループの文書が公表されました。
2019年9月には金融情報システムセンターが実施の手引書を刊行し、手順が具体化しています。ただし、この段階では実施は各金融機関の任意でした。
2024年10月の金融庁ガイドラインで示された6つの留意点
状況が変わったのが2024年10月4日です。金融庁は金融分野におけるサイバーセキュリティに関するガイドラインを公表し、脅威ベースのペネトレーションテストを対応が望ましい事項として位置づけたうえで、実施時の留意点を示しました（※4）。
同ガイドラインは2025年7月4日に一部改正されていますが、これは内閣サイバーセキュリティセンターが国家サイバー統括室へ改組されたことに伴う技術的な修正であり、脅威ベースのペネトレーションテストに関する記載に変更はありません。
| 示された留意点 | 実務上の意味 |
|---|---|
| 必要な経験と技術を持つ業者を選定する | テスターの資格や経歴の確認を含むバックグラウンドチェックを行う |
| 実際の攻撃者が行う水準の技術を用いる | 脅威インテリジェンスを踏まえた技術水準が前提になる |
| 深刻だが現実に起こりうる脅威シナリオを計画に含める | サービス提供に影響を及ぼしうる事象を想定する |
| 防御側の担当者による対応能力を評価する | 防御、検知、報告、封じ込めまでを評価対象とする |
| 本番環境で、防御側に予告せず実施する | 検証環境や予告ありの実施では要件を満たさない |
| 判明した課題を経営陣に報告し、改善活動を行う | 報告して終わりにせず、改善までを要件に含める |
このガイドラインは一律のチェックリストではありません。基本的な対応事項と対応が望ましい事項のいずれについても一律の対応を求めるものではなく、自らの事業環境やリスクの許容度を踏まえたリスクベース・アプローチを採ることが求められると明記されています（※4）。
地域金融機関への実証事業が進んでいる
金融庁は2025年6月に公表した分析レポートのなかで、地域金融機関に対する実証事業を進めていることを明らかにしました。いくつかの金融機関に実際にテストを行い、判明した脆弱性のうちよく見られるものを地域金融機関に還元していく取り組みです（※5）。
金融以外の業種でも、重要インフラを担う企業や大規模なサプライチェーンを持つ企業が、同じ考え方を自主的な検証として取り入れています。
EUではDORAにより実施が求められる段階に入った
EUのデジタル・オペレーショナル・レジリエンス法は2023年1月16日に発効し、2025年1月17日から適用が始まりました。
適用後は、所管当局が指定した金融機関が、少なくとも3年に1度、重要な機能を対象とした脅威ベースのペネトレーションテストを本番環境で実施する義務を負います。当局は対象となる金融機関の指定とテスト範囲の検証を担い、要件どおり実施されたことを確認する証明書を発行します（※6）。
これに合わせて欧州中央銀行は2025年2月、TIBER-EUの枠組みを改訂しました。改訂により成果物の提出期限が明確になり、攻撃側と防御側が協調して学びを深めるパープルチーミングが必須となっています。テスト全体を統括する役割の呼称も、ホワイトチームからコントロールチームへ変わりました（※7）。国内の解説記事の多くは改訂前の用語を使っているため、海外の資料と読み比べる際は注意してください。
※3 参考：金融庁│「諸外国の『脅威ベースのペネトレーションテスト（TLPT）』に関する報告書」
※4 参考：金融庁│「金融分野におけるサイバーセキュリティに関するガイドライン」
※5 参考：金融庁│「金融分野におけるITレジリエンスに関する分析レポートの概要」
※6 参考：European Central Bank│「Adopting TIBER-EU will help fulfil DORA requirements」
※7 参考：European Central Bank│「TIBER-EU Framework updated to align with DORA」
実施体制と5つのフェーズ
テストは、攻撃側と防御側、そして両者を統括する管理役という3つの役割で進みます。全体は計画から報告まで5つのフェーズに分かれ、攻撃シナリオの設計はその2番目にあたる工程です。社内調整の量は、この体制とフェーズの組み方で決まります。
レッドチーム、ブルーチーム、ホワイトチームの役割
レッドチームが攻撃側で、多くの場合は外部の専門会社が担います。ブルーチームは防御側にあたり、監視部門やインシデント対応チームが該当します。ホワイトチームはテスト全体を統括する管理役で、社内の限られたメンバーで構成する形が一般的です。
ホワイトチームの役割は調整だけではありません。テスト中に発生したアラートが疑似攻撃によるものか本物の攻撃かを切り分ける判断も担います。この切り分けができないと、本物の侵入を見逃すおそれがあるからです。
計画から報告までの5フェーズ
進め方は、計画立案とスコープ定義、脅威分析とシナリオ作成、テストツールの開発と準備、テストの実施、評価と報告の5段階に分かれます（※2）。
計画立案では、守るべき重要な業務と情報資産を特定し、範囲と制約条件を決めます。準備の段階で欠かせないのが、テスト中にリスクが表面化した場合の中止基準とエスカレーション経路について、関係者間で合意しておくことです。本番環境に疑似攻撃を仕掛ける以上、この合意がないまま実施へ進むことはできません。
攻撃シナリオの例
シナリオは単一の手法ではなく、複数の手口をつないだ形で設計します。たとえば、公開情報から従業員を特定してなりすましメールを送り、端末を感染させ、権限を昇格させながら内部を横移動し、目的の情報にたどり着くまでを一連の流れとして組み立てていきます。
外部委託先を経由する経路や、内部関係者が加担する想定を含めることもあります。金融庁の調査報告書には、現金自動預払機の仕組みや国際送金システム、IP電話や監視カメラといった、通常のテストでは対象になりにくい資産が範囲に入った例も記載されています（※2）。
※2 参考：金融庁│「諸外国の『脅威ベースのペネトレーションテスト（TLPT）』に関する報告書」
費用と期間、実施頻度の目安
国内では、数百万円から数千万円という水準が一般的とされます。ただし、これを裏づける公表統計はなく、対象範囲やシナリオ数で金額は大きく動きます。数字の根拠として比較的確かなのは、金融庁が海外の実施状況を調べた際のデータです。同じ調査には、実施頻度の考え方や金額を左右する要素についても記載があります。
海外調査で示された費用と期間
同報告書には、平均的な水準として、英国で9万から12万ポンド、米国で10万から13万米ドル、香港で50万から110万香港ドルという数字が示されています。期間は英国で4カ月から5カ月、米国で4カ月程度、香港で3週間から2カ月程度でした。
ただし、これは2017年11月27日から2018年1月30日にかけて行われた調査によるもので、公表からすでに8年以上が経過しています。報告書自身も、目的やスコープ、シナリオ数、実施方法、成果物などの条件によって決まるため一概に比較できないと注記しています。
ここでの期間はテストの実施期間だけでなく、計画から報告完了までを指します。また香港の数字には、脅威インテリジェンスの収集と分析を行わず汎用的なシナリオで実施した例や、範囲を限定した例が含まれています（※2）。
脆弱性診断と比べて高額になるのは、脅威情報の収集と分析、シナリオ設計、報告書作成といった工程が加わるためです。準備期間を含めると、数カ月単位の計画が必要になります。
頻度は年1回を軸に変更のタイミングで見直す
実施頻度に決まった基準はありません。同報告書によれば、米国の大手金融機関は年1回の頻度で実施し、大規模なインフラ変更があった場合には頻度を上げています。英国では、非公式ながら当局が主要な金融機関に対し、少なくとも2年に1度の実施を推奨していたそうです（※2）。
年1回を軸としつつ、システムの大規模な刷新や組織改編、新たな攻撃手法の出現といった変化を実施の判断材料にするのが現実的でしょう。なおEU域内では、DORA第26条により、指定された金融機関は少なくとも3年に1度の実施を義務づけられています。所管当局は、金融機関のリスクプロファイルなどを踏まえ、必要な場合に頻度の引き上げまたは引き下げを求めることができます（※6）。EU域内で事業を行う金融機関は、この基準を前提に計画を立てる必要があります。
費用を左右する3つの要素
金額に効くのは、対象範囲の広さ、シナリオの本数、そして脅威情報の収集をどこまで委託するかの3点です。範囲を重要な業務に絞り、シナリオを優先度の高いものから着手すれば、初回の負担は抑えられます。
脅威情報の収集と疑似攻撃の実施は、別の会社に分けて依頼することもできます。自社に脅威情報を扱う体制があるなら、収集と分析を内製し、攻撃の実施だけを委託する形も選択肢に入るでしょう。
※2 参考：金融庁│「諸外国の『脅威ベースのペネトレーションテスト（TLPT）』に関する報告書」
※6 参考：European Central Bank│「TIBER-EU Framework updated to align with DORA」
実施しても成果につながらない3つのパターンと回避策
費用と期間をかけたにもかかわらず、得られる知見が乏しいまま終わる例があります。金融庁は、実施経験のある銀行から事例を集めて分析し、よく見られる課題と好事例を2025年6月の分析レポートで公表しました（※4）。課題は、脅威情報の作り方、防御側への通知、経営層への報告という3つに分かれます。同レポートが示す6つの推奨方針も、この3点と重なる内容です。
脅威インテリジェンスが一般論のまま止まる
もっとも多いのが、テストの前提となる脅威情報の分析が、一般的な脅威動向の紹介にとどまり、自社固有の脅威が反映されていないケースです。逆に好事例とされたのは、一般的な脅威情報だけでなく自社固有の脅威情報を導き出し、それを踏まえてシナリオを設定していた例でした（※4）。
一般論で作られたシナリオは、業界の平均的な攻撃像をなぞるだけになります。テストは成立しても、自社の事業構造や委託関係に固有の弱点には触れないまま終わってしまうでしょう。
回避するには、発注時に脅威情報の出所と分析の粒度を確認します。自社の公開ドメインや従業員の公開情報がどこまで調べられるのか。外部委託先や海外拠点まで調査範囲に含まれるのか。シナリオの根拠として提示される攻撃事例が、自社の業種や規模と重なるのか。この3点は、契約前の打ち合わせで具体的に詰めておきたいところです。
社内から提供できる材料もあります。過去に発生したヒヤリハット、監視で頻繁に上がるアラートの傾向、業務上どうしても残っている例外的な運用などです。こうした情報をホワイトチームが把握し、どこまでレッドチームに渡すかを決めておくと、シナリオの精度が上がります。
ブルーチームに事前予告してしまう
2つ目は、防御側の担当者にテストの実施を事前に伝えてしまい、対応を正しく評価できていないケースです。好事例では、防御側に予告せず実施することで対応を適切に評価していたと記載されています（※4）。金融庁のガイドラインでも、本番環境を利用し防御側に予告せず実施することが留意点に含まれています（※3）。
予告してしまう背景には、事故を避けたいという判断があります。ただし、予告した時点で測れるのは手順の有無までで、日常の検知力までは測れません。
事故を避けるなら、予告する範囲を絞ります。分析レポートは、不測の事態に備えて事前に通知しておいたほうがよい関係者として、経営層、情報システム部門の責任者、広報部門の責任者を示しました（※4）。この3者に限る趣旨ではなく、自社の体制に応じて範囲を検討することになります。
あわせて、テスト中にホワイトチームが担う対応も決めておきます。疑似攻撃によるアラートと本物の攻撃の切り分け、関係者からの照会への対応、一度成功した攻撃の再実行を省略するといった進行上の判断が、その中身にあたります（※4）。
重要なリスクが経営層まで届かない
3つ目は、テスト結果のうち重要なリスクが経営陣に適切に報告されていないケースです。好事例では、結果にもとづき重要なリスクを経営陣に報告していた例が示されました（※4）。ガイドラインでも、判明した課題を経営陣に報告し改善活動を行うことが留意点に含まれています（※3）。
報告が止まる原因は、報告書の技術的な密度にあります。侵入経路と使用された技術が詳細に記述された文書は、そのままでは経営判断の材料になりません。誰がどの形式で経営層に上げるかが決まっていないと、担当部門の中で完結してしまいます。
対策は、発注段階で報告の形式を要件に含めることです。技術的な詳細をまとめた報告書とは別に、想定される事業影響と対応の優先順位を示した経営層向けの資料を成果物に含めるよう求めます。報告会を開き、対策に関する質疑の場を設けられるかも確認しておきましょう。
分析レポートは、経営陣が主導して実施を決定し推進すること、テスト後に判明したリスクへ対応するための追加的な資源投入や施策の推進を支える姿勢を持つことを、重要な点として挙げています（※4）。報告の設計は、テスト後の改善が動くかどうかを左右します。
金融庁が示した6つの推奨方針を実務の確認項目に置き換える
分析レポートには、実施にあたっての推奨方針が6つ示されています。社内で確認すべき項目に置き換えると、次の6点になります（※4）。
| 推奨方針 | 示された内容 | 実務での確認項目 |
|---|---|---|
| テスト目的の認識合わせ | 制限を設けずリスクを可視化したうえで、検知力と対応力を評価する | 今回の主目的がリスクの可視化か対応力の評価かを、関係者間で言語化できているか |
| スコープの設定とテスト内容 | 特定システムに絞らず組織全体を対象とし、人やプロセスの弱点も本番環境で確認する | メール対応や物理的な侵入への対応が範囲に含まれているか |
| 経営層の関与 | 経営陣が主導して実施を決定し、テスト後の資源投入も支える | 実施の決裁と、改善策の予算確保がひとつの流れになっているか |
| 関係者との連携と通知 | 防御側には非通知とし、経営層や情報システム部門と広報部門の責任者には事前通知する | 通知する相手と通知しない相手のリストが文書化されているか |
| ホワイトチームの対応 | アラートの切り分け、照会対応、効率的な進行の判断を担う | ホワイトチームの人選と、テスト期間中の稼働時間を確保できているか |
| 共同利用システムへのテスト | 複数組織で共同利用する重要なシステムも対象に含めるよう調整する | 共同利用しているシステムの管理主体と、事前に調整する経路があるか |
この6項目のうち複数に答えられない状態で発注すると、先に挙げた3つのパターンのいずれかに近づきます。準備段階で埋めておくべき部分です。
※3 参考：金融庁│「金融分野におけるサイバーセキュリティに関するガイドライン」
※4 参考：金融庁│「金融分野におけるITレジリエンスに関する分析レポートの概要」
着手前に確認したい前提条件とテスト事業者の選び方
自社が実施すべき段階にあるかどうかは、3つの前提で判断できます。前提が欠けている場合には、順を追って積み上げていく道があります。そして前提が揃ったあと、テストの成否を分けるのが委託先の選定です。
テストが機能するための3つの前提
1つ目は、既知の脆弱性への対応が回っていることです。脆弱性診断の結果が未対応のまま積み上がっている状態では、レッドチームがその穴から侵入して終わってしまいます。
2つ目は、ログを取得し、アラートを見る体制があることです。検知力を評価する以上、検知する仕組みが存在しないと結果は出ません。
3つ目は、インシデント発生時の対応手順が文書化され、連絡経路が決まっていることです。対応力の評価は、対応する手順があってはじめて成り立ちます。
前提を満たしていない場合の進め方
3つの前提が揃っていない段階では、順を追って積み上げます。まず脆弱性診断で既知の弱点をつぶし、次に範囲を絞ったペネトレーションテストで侵入経路の実証を行います。
そのうえで、攻撃側と防御側が手の内を共有しながら検知の精度を高めるパープルチーム演習を挟む方法もあります。欧州の枠組みでは、この協調的な進め方が必須とされました。検知の仕組みを整えてから、予告なしのテストに進む順番です。
テストを委託する事業者を見極める視点
テストの質は担当する技術者の力量に左右されます。金融庁のガイドラインが業者選定にあたってテスターの資格や経歴の確認を求めているのも、本番環境に踏み込む作業だからです（※3）。
近年は、脅威情報の要約やシナリオ案の作成といった工程に生成AIを使う動きもあります。ただし、AIによる自動的な診断や攻撃の再現には、誤った判定や本番環境への予期しない影響を招くリスクが伴います。攻撃者の意図を読み、業務への影響を見きわめながら手を止める判断は、経験を積んだ技術者でなければ行えません。補助として使う工程と、人が担うべき工程は分けて考える必要があります。
委託先の確認項目は次の5点です。
| 確認項目 | 確認の観点 |
|---|---|
| テスターの経歴確認 | バックグラウンドチェックの手順が社内で定められているか |
| 脅威情報の出所 | どの情報源から、どの範囲まで収集するかを説明できるか |
| 中止基準と連絡経路 | テスト中断の判断基準とエスカレーション先を書面で合意できるか |
| 報告会と質疑の場 | 報告書の提出だけでなく、対策の相談まで対応できるか |
| 報告後の支援範囲 | 判明した課題の改善までどこまで伴走できるか |
ユービーセキュアでは、脅威分析とリスク評価の資格を持つコンサルタントが、手動によるペネトレーションテストを実施しています。蓄積した脅威シナリオから、対象の環境と資産に応じたシナリオを提案する形をとっており、脅威分析まで自社で終えている場合の実施のみの支援にも対応が可能です。
※3 参考：金融庁│「金融分野におけるサイバーセキュリティに関するガイドライン」
まとめ：脅威ベースのペネトレーションテストは事前設計が重要
脅威ベースのペネトレーションテストは、実在する攻撃者の手口を再現し、システムだけでなく監視と対応の体制まで含めて検証する手法です。脆弱性診断やペネトレーションテストの代わりではなく、それらで基礎を固めた先に位置づけられます。
国内では数百万円から数千万円という水準が語られるものの、公表された統計はなく、範囲とシナリオ数で金額は大きく動きます。そして金融庁の調査が示したとおり、実施したこと自体は成果を保証しません。脅威情報が一般論で止まる、防御側に予告してしまう、重要なリスクが経営層に届かない。この3つのつまずきは、いずれも発注前の設計で避けられます。
次の一歩は業種によって変わります。金融機関であれば、ガイドライン上で自社がどの位置づけに当たるかの確認から始まります。それ以外の業種なら、守るべき重要な業務の特定が出発点です。いずれの場合も、前提となる3つの条件を点検し、条件が揃っているなら目的と範囲を言語化する作業に進めます。判断に迷うようなら、現在の対策状況を踏まえた相談から始めてみてください。
この記事を監修した人
成田 大輝
CEO
株式会社ウェヌシスのCEOとして、情シス向けのオンライン研修事業やオウンドメディアの発信を手がけている。 また、株式会社映せばのCIOとして、ベンチャー企業の情報整備やシステム開発、情報セキュリティ対策まで幅広く携わっている。
-1.png)
