昨年末、JPNIC（一般社団法人日本ネットワークインフォメーションセンター）主催で開催された「InternetWeek 2018」にて、「丸ごとわかるペネトレーションテストの今」と題して、ペネトレーションテストに関して講演を行ってきました。
今回の講演では、自身（自社）の理解についてペネトレーションテスト提供者の方々と認識を合わせた上で、講演や資料を通じて広く情報をお伝えできる機会をいただき感謝しております。
ペネトレーションテストは、テスト対象の企業/組織に応じて様々なサイバー攻撃手法を講じて、システムなどへの侵入を試みることでセキュリティレベルを評価する取り組みで、2018年5月には金融庁から「諸外国の『脅威ベースのペネトレーションテスト（TLPT）』に関する報告書」が公表されたこともあり、金融業界を中心に関心が高まっています。
このペネトレーションテストという考え方は、以前から存在し、同名のサービスも多数存在しているのですが、サイバー攻撃で悪用される手法の巧妙化に合わせて、「Red Team Operation」や「脅威ベースのペネトレーションテスト（TLPT）」など、求められるアプローチが変化しつつあります。そのため、旧知の解釈のみで取り組むのではなく、「何を評価すべきなのか」、「その評価に必要なアプローチは何か」を理解して取り組む必要があります。
そのような背景を受けて今回講演をさせていただきましたので、用語やその解釈について事例を交えながらのご紹介となりました。本記事では、講演中や講演後の質問で特に注目いただいた「脆弱性診断（セキュリティ診断）とペネトレーションテストの違い」、「脅威ベースのペネトレーションテスト（TLPT）」についてご紹介します。
|
セキュリティ診断 |
ペネトレーションテスト |
|
|
目的 |
脆弱性を網羅的に洗い出すこと |
攻撃者の目的が達成されてしまうかを確認するために、必要な脆弱性を発見・評価・検証すること |
|
アプローチ |
ベースラインアプローチ |
リスクベースアプローチ |
|
方式 |
Web、ネットワークなど、システムを構成する要素をセキュリティ規格などに照らし、安全性を確認 |
サイバー攻撃を模して、攻撃目標が達成できるかを試行 |
|
報告内容 |
個別の脆弱性リスト |
攻撃シナリオと検証結果 |
具体的には、セキュリティ診断では対象システムの脆弱性を網羅的に洗い出すことを目的として、情報セキュリティの規格や基準と照らして評価を実施するため、サーバの侵害要因とはならないがセキュリティ上望ましくない点（例えば、Webページのキャッシュコントロールなどシステム利用者（ユーザ）を保護するための項目など）についても評価します。
一方、ペネトレーションテストでは、攻撃目標を達成できるかを確認することを目的としているため、攻撃者にとって狙い目となるセキュリティ上の欠陥が無いかを評価します。そのため、前述した例のような侵害要因とならない観点は含まれません。
このように、それぞれの実施目的に応じて、異なるアプローチをとることから、実施目的に応じた使い分けや組み合わせが必要となります。
昨今日本の金融業界を中心に盛り上がりを見せているのが、TLPT（Threat-Led Penetration Test）：脅威ベースのペネトレーションテストという考え方です。
TLPTは、サイバー攻撃の脅威をもたらす攻撃者の行動（攻撃者がどのようなテクニックを使って攻撃するかのアクティビティ）と、対象とする環境（企業やシステム、所属する人員）を踏まえ、実現し得る攻撃シナリオを構成し、ペネトレーションテストを実施するというアプローチです。
（「金融庁 平成29事務年度 金融行政方針について」などでは、「テスト対象企業ごとに脅威の分析を行い、個別にカスタマイズしたシナリオに基づく実践的な侵入テスト」と触れられています。）
TLPTは、以下のキーワードを押さえていただくと読み解きやすくなります。
TLPTで想定している脅威は、攻撃者がモチベーションを持つ点と捉えると理解しやすくなります。
敵対的意図：
攻撃者に動機があるか、攻撃対象は情報資産などを持つか
機会：
攻撃ポイントがあるか（攻撃者から見て攻撃できる対象があるか）
能力：
攻撃に必要な能力を攻撃者が持っているか（攻撃技術・テクニックの進歩、脆弱性によるシステムの危殆化など）
TLPTには、ペネトレーションテストの実施に際し、脅威を想定することに加え、Red Team OperationやPurple Teamingなどに関連する考え方も紹介されています。その中でも特徴的なものが以下です。
Continuous Operation（継続的な実施）
攻撃側（Red Team）が継続的に新しい攻撃テクニックを試行し、防御側（Blue Team）の技術・プロセス面で弱い部分を常に探し続けること。自社内にRedTeamを持つ企業であれば実現可能な考え方であると思いますが、セキュリティベンダーからサービス提供を受ける場合は実現が難しいと考えられます。
サイバー攻撃シミュレーションツール（Breach and Attack Simulation Tool 、Cyber Attack Simulation Tool）などを用いれば比較的実施はしやすくなりますが、ツールを使いこなすために、攻撃内容を理解し、実行する能力が必要となるため、これもまた実現が難しい要因の１つです。
Iterative Collaboration（反復的なコラボレーション）
テスト終了後に攻撃側・防御側が議論し合い、課題の改善を行っていく（Purple Teaming）ことでPDCAのサイクルを回すこと。これにより、組織全体としてのセキュリティを強化することに繋がります。
Real Threat Based Scenarios（現実の脅威に基づくシナリオ）
実際の脅威動向を踏まえて、攻撃シナリオを組み立てること。先にご紹介した”脅威”にも通ずる考え方ですが、具体的な攻撃者、攻撃内容として、TTPs（Tactics, Techniques and Procedures）を想定し、攻撃シナリオを組み立てて実施をするという考え方です。
そのため、目的や想定する脅威に応じて、セキュリティ監視チーム（SOC）やCSIRTなどの対応を含めることや、実施時間帯や対象を制限せずに実施することもあります。
これらの内容は、網羅するというよりも、ペネトレーションテストの「テスト効果を高める」、「実施目的を達成する」ために、組み合わせて取り組みます。そのため、弊社のようなサービスを提供するセキュリティ企業側から見ると、お客様毎にカスタマイズするコンサルティングサービス、もしくはそれぞれの会社でサービス名を設定していることが多いため、様々な用語で表現されています。
（ちなみに弊社では、サイバー演習やサイバーアタックシミュレーションもしくはレッドチームオペレーションとして提供しています。）
ペネトレーションテストの目的は「実際の攻撃テクニックを用いて、対象企業/組織に応じて設定する目標（ゴール）を達成可能か検証」することです。
そのため、まずは自社にとっての”脅威”を想定するところから始めます。自社が持つ資産（情報など）は何か？などの整理は良いですが、攻撃能力など脅威を構成する他の要素の調査や分析は難しいと思われますので、その段階でペネトレーションテストを提供しているセキュリティベンダーに相談して、一緒に計画を練るのはいかがでしょうか。
弊社にご相談いただく中では、大きな情報セキュリティインシデントとして報道されるようなマルウェア感染をきっかけとした情報漏えい事件をモデルにしたいというご相談が多いですが、攻撃者が狙うのは、OA環境だけではないため、何が重要であるかにより弊社からWebからのテストなど別のアプローチをご提案させていただく場合もございます。
また、自分たちはどれくらい狙われるか分からないと言った場合には、どの程度の方がマルウェアに感染してしまう可能性があるかを確認するためにメール訓練のような形で計画させていただくこともございます。
このような形で、その企業に応じた様々なペネトレーションテスト計画となりますので、計画段階からご相談いただくことで、より効果的なテストを実行可能になります。
本記事を通じて、「やってみたい！」「やってみた！」という企業が増えると筆者としては幸いですが、ペネトレーションテストは実施するだけでなく、実施後に対策を進めることで、組織としてのセキュリティレベル向上に繋げるための取り組みであることも忘れずに取り組んでいただけると幸いです。