脆弱性診断士スキルマッププロジェクトはじめに本ドキュメントの目的コンピュータシステムに対して実施するセキュリティテストの1つとして「脆弱性診断」がよく知られています。「脆弱性診断」は脆弱性診断士スキルマッププロジェクトでも紹介しているような脆弱性を発見するためのセキュリティテストの手法です。一方で最近は「ペネトレーションテスト」を採用する組織や、ペネトレーションテストサービスを提供する事業者(テストベンダー)が増えてきました。現状では「ペネトレーションテスト」という名称に共通認識がなく、テストベンダーによっては「脆弱性診断」のことを「ペネトレーションテスト」と呼んでいることもあり、テストを採用する組織が目的に合ったサービスを見分けることが難しくなっています。本ドキュメントは「ペネトレーションテスト」の位置づけを明確にし、セキュリティテストを活用する組織が実施目的に合うサービスを選択できることを目的としています。Testing)」とは、明確な意図を持った攻撃者にその目的が達成されてしまうかを検証するためのセキュリティテストの一種です。ペネトレーションテストではその組織が持つすべてのシステム、もしくは指定されたシステム全体を対象として、実際の攻撃者が使用しているツールや脆弱性、ソーシャルエンジニアリングなどを利用して一定期間内に目的を達成できるかどうかの調査を行います。Directoryなどのシステムへの攻撃を行い管理者権限を奪ったりすることもあります。ペネトレーションテストはいわゆる脆弱性診断のようなWebアプリケーション単体やプラットフォーム単体のテストではなく、また網羅的に脆弱性の調査を行うわけではありません。)のスキルマップと学習の指針となるシラバス、脆弱性診断を行うためのガイドライン、Webアプリケーションを安全に構築するために必要な要件定義書などを整備しています。セキュリティ機能の不足を「網羅的に洗い出す」ことを目的とし、システムに内在するリスクをすべて洗い出します。脆弱性を洗い出すため、ガイドライン等に従って定型的なテストケースに基づいた作業を行います。脆弱性の有無を確認するために必要最低限の通信にとどめ、実際に被害が発生してしまうような調査を意図的に行うことはありません。ペネトレーションテスト実際の攻撃者が使用しているツールや脆弱性の利用、ソーシャルエンジニアリングなど様々な手法を用いて一定期間内で目的を達成できるかの調査を行います。網羅的に脆弱性の調査を行うわけではありません。ソーシャルエンジニアリングや物理面での調査などを実施するかどうかはテストベンダーによって異なり、実施手法は顧客と相談の上で決定します。システムを調査対象とし、指定されたWebアプリケーションやIPアドレスごとに作業をします。一般的に、調査対象と関連するシステムであっても、調査対象に指定されていないWebアプリケーションやIPアドレスに対しては、診断を行いません。ペネトレーションテストシステム、人、組織、ルールを調査対象とし、その組織が持つすべてのシステム、もしくは指定されたシステム全体に対して作業をします。された脆弱性やセキュリティ機能の不足している一覧を、リスクの高いものから低いものまですべて報告書に記載します。ペネトレーションテスト報告書へは、「目的達成までの侵入経路や行った攻撃シナリオ」や「シナリオ実行過程で使用した脆弱性や攻撃手法、セキュリティの問題」について記載します。脆弱性診断もペネトレーションテストも、対象とするシステムの規模や範囲、作業期間や掛ける労力によって費用が変わります。一般的には、ペネトレーションテストの方が、より高度な技術が必要な分、脆弱性診断に比べて費用・期間ともに高コストになります。実施期間については1週間〜数ヶ月と、設定されたゴールや予算などによって大きく変わります。年末から年度末にかけてはテストベンダーの繁忙期にあたります。実施希望時期が決まっている場合、早期に依頼することで、希望時期でのテスト実施が可能となります。ペネトレーションテスト実施の前提ペネトレーションテストを実施すべき組織ペネトレーションテストはセキュリティシステム全体のテストであり、その運用状況なども含めたテストです。そのため、セキュリティ対策が十分でない組織よりも、セキュリティ対策のレベルがある程度成熟している組織が実施する方が効果が見込めます。運用した結果顕在化する問題点もありますので、システム構築直後よりは一定期間運用したシステムを対象とした方が効果が見込めます。自分たちの組織が下記に該当するようでしたらペネトレーションテストを実施すべきでしょう。十分なセキュリティ対策を実施している自信がある各種対策を導入しているが、役に立っていることをあまり実感していない組織のセキュリティ対策が機能しているか確認したいペネトレーションテスト実施に関する注意事項ペネトレーションテストでは実際の攻撃者と同様の攻撃を行います。攻撃者もペンテスター(ペネトレーションテストの実施者)もシステムや業務に影響がなるべく出ないような攻撃手法を選びますが、場合によってはシステムや業務への影響が避けられないこともあります。テストによって各種システムなどにログが残る以外にも、下記のような影響が出ることがあります。監視機器や監視サービスからのアラート発報システム停止、高負荷システム上の情報や設定が変更されるアカウントロック状態になるペネトレーションテストを受ける際には、これらの影響が出る可能性があることを考慮する必要があります。ペネトレーションテスト実施の頻度ペネトレーションテストを実施すると、組織のセキュリティ対策の不備や運用の問題などさまざまな事項が判明します。そのため、実施後にはさまざまな改善を行う必要が生じます。その改善策が十分機能しているかを確認するためにも、再びペネトレーションテストを実施する必要があります。改善した新たなセキュリティ対策がうまく運用されているかを確認するためにも年に1度程度のペネトレーションテストの実施が望ましいでしょう。準備ペネトレーションテストを実施する前に検討すべき点について説明します。ゴール設定(攻撃者・被害の想定)ペネトレーションテストを受ける側は守るべき資産を把握しておくことが適切なゴールを設定する上では望ましいといえます。対象が決まったら次に、攻撃者とその攻撃者が目的とする被害(ゴール)を想定します。以下のようなゴールがあります。内部犯行による機密文書の外部への持出しすべての想定ゴールを検証できることが理想ですが、こちらも期間やコストに影響するためシステムの重要度も勘案して、検証するゴールを選定してください。スコープ設定(対象システム)テストの対象とするシステムの範囲を決めます。組織にあるすべてのシステムを対象範囲にするのか、あるいは一部のシステムに限定するのかを決定します。対象範囲を限定すればするほど、短期間・低コストで実施できますが、対象外のシステムの問題点は見つかりません。複数のシステムにまたがった問題点も見つからない可能性が高まります。できるだけ広い範囲を対象とすることが望ましいですが、システムの重要度やコストも勘案し対象システムを決定してください。スコープにはパブリッククラウドなどのシステムも含める場合があります。レギュレーションスコープとゴールの設定後、テストベンダーは実際にどのように疑似攻撃を行うかテストシナリオを検討し、円滑にテストができるよう計画を作成します。そのために必要な情報をテストベンダーに提供してください。以下のような情報です。実施時間プラットフォーム環境の情報(クラウド利用有無など)特に、禁止事項は重要です。実際の攻撃に近いテストであるとはいえ、通常業務を阻害するような影響はできるだけ避けるべきです。悪影響が予想できる行為は禁止事項としてテストベンダーと共有しておくことで、このようなリスクを低減できます。あまりにも禁止事項が厳しい場合、一部のテストを実施できなくなることがあります。アカウントロックを禁止事項とした場合は、既に誰かが連続して認証に失敗していると意図せずアカウントロックしてしまう可能性があるため、事実上認証試行を禁止することになります。そのため、テストベンダーと事前によく協議してレギュレーションを合意してください。テストは期間を限定して行うことが一般的です。実際の攻撃者は期間の制約なく攻撃が可能です。この差を埋めるために、ある程度時間をかければ収集されてしまう情報(既知の脆弱性情報、システム構成、メールアドレスの一覧など)についてはあらかじめテスト担当者に提供してテストを効率化する場合があります。こちらもテストベンダーと協議し、必要に応じて情報を提供してください。バックアップなどテストベンダーは、対象を意図的に破壊や停止させるテストは行いません(DoSがゴールの場合以外)。攻撃は通常とは異なる行為であるため予期しないことが起こる可能性があり、影響が起きないことを100%保証することはできません。万が一の場合に備え、システムの再起動や、バックアップからの復旧手順について事前に確認し備えておいてください。本番システムではなく検証環境に対してテストを行うことも考えられます。その際は、できるだけ本番システムと同等の状態を再現することが望ましいです。一時ファイルなどが侵入の糸口になることが多々あります。これらを含め本番システムを可能な限り再現することで、検証環境に対してテストを行う効果が高まります。実施中に行うことベンダーのテストを見守り、何らかの不都合があった場合の調整を行います。リスクの高い疑似攻撃の実施可否を相談されたり、社内の運用チームからの問い合わせを受けることもあるでしょう。万が一業務に影響が出た場合、テストの中断や中止をするか判断してください。実施後に行うことペネトレーションテスト実施後は、その結果を評価し、問題点の改善計画を立て、対策を進めていきます。脆弱性の対策テストベンダーから報告される問題点は、主に次の2種類です。システムの脆弱性テスト対象システムに残存していたシステムの脆弱性です。脆弱性のあるバージョンのソフトウェアを使用している問題、設定ミス、Webアプリケーションの脆弱性などがこれにあたります。場合によっては未知の脆弱性が見つかることもあります。前述の通り、システムの脆弱性すべてが網羅されて報告されるわけではなく、テストで設定したゴールにたどり着くために有用だった脆弱性が報告されます。加えて、ゴールとは関係しないものでも、テスト中に偶然見つけてしまった脆弱性も報告されることがあります。継続して運用していたことで初めて生まれる、または見つかる脆弱性です。パスワードの使い回しや容易に推測が可能なパスワードを設定してしまった、機密情報が書かれた手順書や設定ファイルがアクセス制限や暗号化されずにサーバーに置かれてしまった、などです。脆弱性が報告された場合、その内容を評価して対策が必要です。これらの脆弱性の対策は、従来の脆弱性診断で報告された問題への対処手順と同じです。現状の脆弱な状態を解消する必要があります。それぞれの脆弱性に対して、危険度や対策コストから対応の要否と優先度を検討し、対策を行ってください。人が原因で生まれた運用の脆弱性には、人のミスをシステム的に検出・防止する仕組みの導入や、ユーザーの教育も検討する必要があるでしょう。サイバーレジリエンス能力の評価ペネトレーションテストの効果はこれだけではありません。1つ、最も重要な評価ポイントがあります。それが、サイバーレジリエンス能力の評価です。サイバーレジリエンス能力とは、侵入による組織への影響を最小化し早急に平常状態に戻せる能力です。テストの実施によって、通常ではあり得ない攻撃パケットがネットワーク上を飛び交い、様々なサーバーや機器に攻撃の痕跡を示す不審なログが残るはずです。あなたの組織は、どの攻撃を検知できましたか?検知したのは攻撃が行われてどのくらい経ってからですか?被害の拡大を食い止める対応ができていましたか?組織にはこのような対応能力が必要です。この能力を評価するには、個々のシステムの検出状況だけではなく、運用監視チームやCSIRTの対応状況まで含め、組織全体の対応に課題がないか検証すべきです。「侵入されないシステム」を作ることは重要ですが、「侵入された前提の対応」も重要度を増してきています。CSIRTの構築・運用についてはJPCERT/CCのCSIRTマテリアルも参考になります。ケーススタディ報告書に記載されるゴール達成までのシナリオ例あらかじめ設定したゴールに対して、テストベンダーがゴールを達成できた場合、「目的達成までの侵入経路や行った攻撃シナリオ」や「シナリオ実行過程で使用した脆弱性や攻撃手法、セキュリティの問題」が報告書に記載されます。ここでは実際にテストで利用されたシナリオ例を紹介します。調査時には、様々な攻撃手法によりゴールを達成可能か試行錯誤していますが、実施内容が全て報告書に記載されるわけではなく、ゴール達成に関連した手法のみが記載されることが一般的です。本事例では、年に一度、計3回のペネトレーションテストを実施した企業Aの事例を紹介します。企業Aは、約1000人の社員が働いています。拠点が複数に分かれており、各拠点でネットワークを分けていますが、一部ではつながっています。自社のシステム担当部門が主にセキュリティ対策の検討や運用の一部を行っています。主要な拠点には自社の担当者を置き、外部からの攻撃に関するログ監視など一部の運用業務については、外部の業者に委託しています。以前に外部から攻撃を受けて情報漏えいの被害が発生したことから、主担当者やその他社員のセキュリティ意識は非常に高いものでした。1回目の実施内容検討ペネトレーションテストを実施したいということで担当者から話を聞いたところ、企業Aではインターネットに公開されているサーバーを対象に、以前から脆弱性診断を実施しており、発見された脆弱性への対策も行われていました。そのため、今回は標的型攻撃への耐性を評価することを希望されていました。そこで、社員の端末が感染した前提で重要情報の持出しができるかどうかを確認するため、社内ネットワークからペネトレーションテストを実施することになりました。テストは、複数ある拠点のうち、最も主要な拠点の端末が感染した前提で実施しました。実施した結果、以下の問題が検出されました。C2サーバーへ重要情報の持出しが可能テスト結果は、標的型攻撃に対する改善が必要な状況でした。1-3については早急に対策を行いましたが、その他の問題についてはすぐに対策することが難しく、軽減策等を検討することになりました。報告会には別拠点のシステム担当者も参加しており、同様の問題点があれば対策を行うという話でした。話を聞いたところ、「インターネットに公開しているサーバーは侵入されない想定だが、もし、侵入された場合には、どのような被害が発生し、それを検知できるのかを知りたい。そこで、公開しているサーバーに侵入された前提で、社内ネットワークから重要情報の持出しができるかどうかをチェックするペネトレーションテストを実施することになりました。テストは、個人情報を取り扱うWebサーバーが侵入された前提で実施しました。実施した結果、以下の問題が検出されました。アクセスすることを想定していないネットワークにアクセスが可能テスト結果は、Webサーバーに侵入された場合に遠隔操作が行われ、他サーバーにも侵入されることで重要情報が持出し可能という状況でした。それを検知することができない状況でした。メンテナンス時に利用する認証情報をサーバー上に配置していたことが問題2-2の原因でしたが、他サーバーへの攻撃が容易になってしまうため、認証情報を配置しないようにしました。問題2-3の原因はアクセス制御の不備だったので早急に対応することになりました。これらの攻撃を検知できるように、検知設定の見直しを行いました。3回目の実施内容検討さらに翌年、担当者から話を聞いたところ、「以前検出された問題点が適切に対策されたのか、その対策が全社にも行われたのかを確認したい。」との要望があり、再度社内ネットワークからのペネトレーションテストを実施したいということでした。そこで、1回目にテストを実施した際と同じ拠点に加え、2番目に主要な拠点からもテストを実施することになりました。実施した結果、1回目と同じ拠点からのテストでは、以下の問題が検出されました。C2サーバーへ重要情報の持出しが可能3-1と3-2について確認したところ、緩和策が取られており、問題無いという判断でした。その他問題については対策されていました。2番目に主要な拠点からのテストでは、以下の問題が検出されました。ローカル管理者のパスワードが取得可能1回目の実施結果を基に対策されているため、最も主要な拠点とほぼ同じ結果となりました。運用の不備により、ローカル管理者のパスワードが漏えいしてしまう可能性がありました。そのため、早急にこの問題について対策を行いました。ポイント本事例は、目的がはっきりしており、ペネトレーションテストを非常に有効活用していました。その結果、高いレベルで対策が行われている状態となりました。本事例のポイントは、以下であると考えます。Test)は、「脅威ベースのペネトレーションテスト」と訳されており、高度なセキュリティが求められる業界における実効性の高いペネトレーションテストの活用方式として、注目を集めています。従来のペネトレーションテストでは、汎用的な脅威による脅威シナリオ(インターネットから特定のサーバに侵入できるかなど)を想定しテストを行い、主にシステムや運用の問題点を評価することを目的としています。それに対してTLPTはサイバーレジリエンス能力を評価し、高めていくことを目的とします。Teamやシステム担当だけではなく、CSIRTや経営層を含めた組織全体のインシデントレスポンスをテストし、攻撃被害からの復旧や事業の継続が適切にできるかどうかを評価します。金融機関向けには、関連するドキュメントが金融庁から公開されています。https://www.fsa.go.jp/inter/etc/20181015/20181015.htmlTLPTで求められる具体的な実施内容は、『「脅威ベースのペネトレーションテスト」及び「サードパーティのサイバーリスクマネジメント」に関するG7の基礎的要素の公表について』において「TLPTのG7基礎的要素」として以下が定義されています。テストの対象となる範囲を定義します。ベンダーなどを含む重要な役割やサービスの担当者やプロセス、技術も明確にし、テスト実施によるリスクを踏まえて、リスクを適切に管理する必要があります。Providerの選定は実績などを参考にして慎重に行う必要があります。脅威情報の収集・分析を行い、脅威シナリオなどを作成します。Teamが実践的なテストを実施します。Teamの攻撃を検知・ブロックします。Teamへの調整を行い、適切にテストが実行できるようにリスクコントロールを行います。Teamでの検知・ブロック結果なども含めてペネトレーションテストの結果を分析し、サイバーレジリエンス能力を高めるための改善策を作成します。業界全体のサイバーレジリエンス能力の改善に貢献するために、各機関の間で類型化したデータを共有します。