ペネトレーションテストのシナリオ作成方法｜実践的な攻撃パターンの設計術

ペネトレーションテストを実施したいが、どのようなシナリオを作ればいいのか分からないという悩みを抱えている担当者の方は多いのではないでしょうか。実は、ペネトレーションテストの成否を左右するのは、実施前のシナリオ設計です。自社の業務実態やビジネスリスクを正しく反映させたシナリオを作成することで、本当に対処すべき脅威を発見できます。この記事では、中小企業のIT担当者向けに、実践的なペネトレーションテストのシナリオ作成方法を詳しく解説します。

ペネトレーションテストのシナリオとは何か

ペネトレーションテストのシナリオとは、攻撃者がどのような経路でシステムに侵入し、どのような情報を狙うのかを想定した攻撃手順の設計図です。このシナリオがなければ、テストは場当たり的なものになってしまい、本当に危険な脆弱性を見逃す可能性が高くなります。

シナリオの定義と役割

ペネトレーションテストのシナリオは、実際の攻撃者の行動パターンを模倣した、段階的な攻撃計画のことを指します。IPA(情報処理推進機構)が公開している「ペネトレーションテスト実施ガイドライン」によると、シナリオには以下の要素を含める必要があります。

• 攻撃起点：外部ネットワークからか、内部ネットワークからか
• 攻撃対象：Webアプリケーション、データベース、従業員端末など
• 攻撃目的：情報窃取、システム破壊、権限昇格など
• 攻撃手法：SQLインジェクション、フィッシング、総当たり攻撃など
• 制約条件：テスト実施時間帯、業務への影響範囲

シナリオの役割は、テストの目的を明確にし、限られた時間と予算の中で最大の効果を得ることです。2023年のセキュリティ診断に関する調査では、シナリオ設計に十分な時間をかけた企業は、そうでない企業に比べて重大な脆弱性の発見率が約2.3倍高いという結果が出ています。

脆弱性診断との違い

ペネトレーションテストと脆弱性診断は、よく混同されますが、明確な違いがあります。脆弱性診断は、システムに存在する弱点を網羅的に洗い出す作業です。一方、ペネトレーションテストは、発見した脆弱性を実際に悪用して侵入を試みる、より実践的な検証です。

NIST SP800-115(米国国立標準技術研究所のガイドライン)では、以下のように定義されています。

• 脆弱性診断：システムの弱点を特定し、リスト化する(診断範囲：広い)
• ペネトレーションテスト：特定の攻撃シナリオに基づき、実際の侵入を試みる(診断範囲：深い)

例えば、脆弱性診断では「このWebアプリケーションにはSQLインジェクションの脆弱性がある可能性がある」と指摘します。一方、ペネトレーションテストでは、その脆弱性を実際に突いて「顧客データベースにアクセスし、個人情報1000件を取得できた」というところまで検証します。

シナリオ設計の重要性

適切なシナリオ設計がなされていないと、以下のような問題が発生します。

• 重要な資産を守れない：本当に守るべき情報がテスト対象から漏れてしまう
• 業務に支障が出る：過剰なテストで本番システムがダウンしてしまう
• コストの無駄：優先度の低い箇所に予算と時間を使ってしまう
• 対策が後手に回る：実際の攻撃パターンを反映していないため、現実的な脅威に対処できない

実際に、ある製造業の企業では、シナリオ設計が不十分なまま外部ベンダーにペネトレーションテストを依頼した結果、本来守るべき生産管理システムがテスト範囲から外れており、後日実際の攻撃を受けて生産が3日間停止する事態となりました。シナリオ設計の段階で業務の重要度を正しく伝えていれば防げた事例です。

効果的なシナリオを作る3ステップ

ペネトレーションテストのシナリオを作成する際には、段階的なアプローチが有効です。ここでは、中小企業でも実践できる3つのステップを紹介します。

ステップ1：資産と脅威の洗い出し

まず最初に行うべきは、自社が守るべき情報資産の特定です。すべてのシステムを同じレベルで守ることは現実的ではないため、優先順位をつける必要があります。

具体的には、以下の項目を洗い出しましょう。

• 守るべき情報：顧客個人情報、取引先データ、設計図面、財務情報など
• 重要なシステム：基幹システム、Webサイト、メールサーバー、ファイルサーバーなど
• 想定される脅威：外部からのサイバー攻撃、内部不正、取引先経由の侵入など

洗い出しには、情報セキュリティ委員会のメンバーだけでなく、各部署の責任者も参加させることが重要です。例えば、営業部門にとっては顧客データベースが最重要ですが、製造部門にとっては生産管理システムの方が優先度が高い場合があります。

ある医療機器メーカーでは、当初Webサイトを重点的にテストする予定でしたが、ヒアリングの結果、患者データを扱う院内システムへのアクセス権限管理の方が重要と判明し、シナリオを大幅に見直した事例があります。

ステップ2：攻撃経路の想定

次に、攻撃者がどのようなルートで侵入してくるかを想定します。IPAの調査によると、中小企業への攻撃は以下の経路が多いとされています。

1. メール経由：フィッシングメールや添付ファイルのマルウェア(全体の45%)
2. Webアプリケーション経由：SQLインジェクションやクロスサイトスクリプティング(30%)
3. VPN・リモートアクセス経由：認証情報の窃取や脆弱性の悪用(15%)
4. 取引先経由：サプライチェーン攻撃(10%)

各経路について、以下の観点でシナリオを具体化します。

• 初期侵入：どこから最初にアクセスするか
• 権限昇格：一般ユーザー権限から管理者権限をどう取得するか
• 横展開：侵入した端末から他のシステムにどう広がるか
• 目的達成：最終的にどの情報にアクセスするか

例えば、「取引先を装ったメールで経理部員の端末に侵入→ファイルサーバーの認証情報を窃取→財務データをダウンロード」という一連の流れをシナリオ化します。

ステップ3：テスト範囲の決定

最後に、時間と予算の制約を考慮してテスト範囲を決定します。すべての経路を検証することが理想ですが、現実的には優先順位をつける必要があります。

テスト範囲を決定する際の判断基準は以下です。

また、テスト実施時間帯も重要です。業務時間中にテストを行うと、万が一システムに負荷がかかった場合に業務に支障が出る可能性があります。多くの企業では、深夜や休日にテストを実施し、翌営業日までに復旧できる体制を整えています。

よくある失敗パターン

シナリオ設計でよくある失敗パターンを知っておくことで、同じ過ちを避けることができます。

失敗例1：過剰なテスト範囲

ある小売業では、すべてのシステムを対象にした結果、予算が大幅に超過し、最も重要なECサイトのテストが不十分になってしまいました。限られた予算では、重点的にテストすべき箇所を絞り込むことが重要です。

失敗例2：業務への配慮不足

製造業の事例では、本番稼働中の生産管理システムに対して負荷テストを実施した結果、システムがダウンし、工場が半日停止する事態となりました。テスト環境を別途用意するか、影響範囲を事前に十分検討すべきでした。

失敗例3：シナリオが抽象的すぎる

「外部からの攻撃に耐えられるか確認する」といった曖昧なシナリオでは、ベンダーも何をテストすればいいか分かりません。「インターネット経由でWebアプリケーションの脆弱性を悪用し、データベースへのアクセスを試みる」といった具体的な記述が必要です。

中小企業で使える4つの基本シナリオ

ここでは、中小企業で実際によく使われる4つの基本的な攻撃シナリオを紹介します。これらをベースに、自社の状況に合わせてカスタマイズしてください。

外部攻撃シナリオ

インターネット経由でのWebアプリケーションへの攻撃を想定したシナリオです。最も一般的で、優先度も高いテストです。

シナリオの流れ：

1. 公開されているWebサイトの情報収集(使用技術、サーバー情報の特定)
2. 既知の脆弱性スキャン(SQLインジェクション、クロスサイトスクリプティングなど)
3. 脆弱性の悪用を試行(管理画面への不正ログイン、データベースへのアクセス)
4. 取得可能な情報の確認(個人情報、取引データなど)

**テスト対象：**企業Webサイト、ECサイト、顧客向けポータル、問い合わせフォーム

**実施のポイント：**IPAが公開している「安全なウェブサイトの作り方」で指摘されている主要な脆弱性11項目を中心に検証します。特に、顧客情報を扱うシステムでは、個人情報保護法の観点からも重点的なテストが推奨されます。

内部脅威シナリオ

従業員による不正アクセスや、従業員端末の乗っ取りを想定したシナリオです。IPAの「組織における内部不正防止ガイドライン」によると、情報漏えいの約6割は内部要因によるものとされています。

シナリオの流れ：

1. 一般従業員のアカウントでログイン(権限レベル：低)
2. アクセス可能な情報の範囲を確認
3. 権限昇格の試行(管理者権限の窃取、システム設定の変更)
4. 本来アクセスできないはずの機密情報へのアクセス試行

**テスト対象：**ファイルサーバー、社内ポータル、人事システム、会計システム

**実施のポイント：**アクセス権限管理が適切に設定されているか、職務分掌が守られているかを確認します。例えば、営業部員が人事情報にアクセスできてしまう、退職者のアカウントが削除されていないといった問題を発見できます。

メール攻撃シナリオ

標的型攻撃メールやフィッシングメールを想定したシナリオです。実際の攻撃の約45%がメール経由であることから、非常に重要度の高いテストです。

シナリオの流れ：

1. 取引先や顧客を装ったメールを従業員に送信(事前に許可を取った上で実施)
2. メールのリンクをクリックするか、添付ファイルを開くかを確認
3. フィッシングサイトで認証情報が入力されるかテスト
4. 従業員の反応と、セキュリティ教育の効果を検証

**テスト対象：**メールフィルタリングシステム、エンドポイント保護、従業員のセキュリティ意識

**実施のポイント：**このシナリオは技術的な対策だけでなく、従業員のセキュリティ意識を測る目的もあります。テスト後は、クリックしてしまった従業員に対して追加の教育を行うなど、改善活動につなげることが重要です。実際に、ある企業ではこのテストを年2回実施することで、フィッシングメールへのクリック率を初回の32%から半年後には8%まで低減させた事例があります。

物理侵入シナリオ

オフィスへの物理的な侵入を想定したシナリオです。サイバー攻撃だけでなく、物理的なセキュリティも重要です。

シナリオの流れ：

1. 部外者が受付を突破できるか確認(入館管理の検証)
2. 無人のデスクから端末や資料を持ち出せるか確認
3. サーバールームへのアクセス可否を検証
4. USBメモリなどの外部記録媒体を端末に接続できるか確認

**テスト対象：**入退室管理システム、監視カメラ、デスクの施錠状況、サーバールームのアクセス制御

**実施のポイント：**このシナリオは、必ず警備会社や施設管理部門と連携して実施してください。無断で行うと、警察沙汰になる可能性があります。ある企業では、清掃業者を装った侵入テストを実施した結果、警備員が不審者と判断し、警察に通報されてしまった事例があります。事前の調整が不可欠です。

シナリオ作成時の注意点とベンダー選定

最後に、シナリオを実際に実施する際の注意点と、外部ベンダーに依頼する場合のポイントを解説します。

業務への影響を最小化する

ペネトレーションテストは、実際の攻撃を模倣するため、システムに負荷がかかったり、一時的に利用できなくなる可能性があります。業務への影響を最小限に抑えるため、以下の対策を講じましょう。

• テスト実施時間帯の工夫：深夜や休日に実施し、営業時間を避ける
• 段階的な実施：いきなり本番環境で実施せず、テスト環境で事前検証
• ロールバック計画：万が一システムに問題が発生した場合の復旧手順を準備
• 関係部署への事前通知：テスト実施日時を全社に周知し、異常検知時の混乱を防ぐ

特に、業務システムが24時間稼働している企業では、メンテナンス時間帯を利用するなど、慎重なスケジューリングが必要です。

経営層への説明ポイント

ペネトレーションテストの実施には、経営層の承認が必要です。予算や業務への影響を理解してもらうため、以下の観点で説明すると効果的です。

投資対効果を示す：

• リスク低減効果：個人情報漏えい時の損害賠償(1件あたり平均5万円)を防げる
• ブランド価値の保護：セキュリティ事故による信用失墜を回避
• 法令遵守：個人情報保護法や業界ガイドラインへの対応

例えば、「顧客データベースに1万件の個人情報があり、漏えいした場合の損害賠償は約5億円。ペネトレーションテストに200万円投資することで、このリスクを大幅に低減できます」といった具体的な数字で説明すると、経営層も理解しやすくなります。

また、「取引先から情報セキュリティ対策の証明を求められる場合が増えており、ペネトレーションテストの実施はビジネス上の競争力にもつながる」という観点も有効です。

ベンダー依頼時の確認事項

外部のセキュリティベンダーにペネトレーションテストを依頼する場合、以下の項目を必ず確認してください。

提案書のチェック項目：

• シナリオの具体性：「外部攻撃を想定」ではなく「Webアプリケーションの脆弱性を悪用してデータベースへのアクセスを試みる」といった具体的な記述があるか
• テスト範囲の明確化：どのシステム・ネットワークが対象か、IPアドレスやURLが明記されているか
• 実施時間帯の調整：業務への影響を考慮したスケジュール提案があるか
• 緊急時の連絡体制：問題発生時の連絡先と対応手順が明記されているか
• 報告書の内容：技術的な詳細だけでなく、経営層向けのサマリーも含まれているか
• 費用の内訳：診断費用、報告書作成費用、改善提案費用が分かれているか

ベンダーの実績確認：

• 同業他社での実施事例があるか
• 情報処理安全確保支援士などの有資格者が担当するか
• ISMS認証(ISO/IEC 27001)を取得しているか

信頼できるベンダーかどうかを判断するために、複数社から見積もりを取り、比較検討することをおすすめします。極端に安い見積もりは、テスト範囲が限定的だったり、経験の浅いエンジニアが担当する可能性があるため注意が必要です。

テスト後の改善計画

ペネトレーションテストは実施して終わりではなく、発見された脆弱性を修正し、セキュリティレベルを向上させることが最終目的です。テスト後は以下の流れで改善を進めましょう。

1. 報告書の読み解き：発見された脆弱性を重要度別に分類
2. 対応優先順位の決定：影響度と緊急度のマトリクスで整理
3. 改善計画の策定：担当者、期限、予算を明確にした改善ロードマップ作成
4. 対策の実施：パッチ適用、設定変更、従業員教育など
5. 再テストの実施：修正が適切に行われたか検証(通常3-6か月後)

ある製造業では、ペネトレーションテストで20件の脆弱性が発見されましたが、そのうち重大度「高」の5件を最優先で修正し、1か月後に再テストを実施して改善を確認しました。残りの15件についても、3か月以内にすべて対応を完了させた事例があります。

また、テスト結果は社内のセキュリティ教育にも活用できます。「実際に自社のシステムでこのような脆弱性が見つかった」という具体例を示すことで、従業員のセキュリティ意識が大幅に向上します。

まとめ

この記事では、ペネトレーションテストのシナリオ作成方法について解説しました。重要なポイントは以下の3つです。

• 自社のビジネスリスクに合ったシナリオ設計：守るべき情報資産を明確にし、実際の脅威を反映させたシナリオを作成することで、効果的なテストが実現できます。
• 段階的なアプローチ：資産の洗い出し→攻撃経路の想定→テスト範囲の決定という3ステップで、無理のないシナリオを作成しましょう。中小企業では、まず外部攻撃シナリオから始めて、段階的に範囲を広げる方法が現実的です。
• テスト後の改善活動：ペネトレーションテストは実施して終わりではなく、発見された脆弱性を修正し、継続的にセキュリティレベルを向上させることが最も重要です。

次のステップとしては、まず自社の情報資産を洗い出し、どのシナリオが最も優先度が高いかを検討することをおすすめします。社内だけで判断が難しい場合は、信頼できるセキュリティベンダーに相談し、自社に最適なシナリオ設計のアドバイスを受けることも有効な方法です。ペネトレーションテストを通じて、組織全体のセキュリティ意識を高め、安全なビジネス環境を構築していきましょう。