基準 · 頻度 · 証跡

コンプライアンス要件に基づくペネトレーションテスト

ペネトレーションテストの多くは、規制が求めるために発注されます。基準が決めるのは範囲と頻度、そして——最も過小評価されがちな部分ですが——実施後に提示できなければならない証跡です。このページでは私が対応している規制を比較し、どれが実際に自社に適用されるのかを判断できるようにします。

各基準の比較

以下の規制はいずれも独立した security テストを義務づけるか、実質的に要求しています。重要な違いは、誰を拘束するか、頻度はどれくらいか、そして実施後に何を示せなければならないかです。

サウジアラビア

  • NCA Essential Cybersecurity Controls(英語)— 政府機関、その請負業者、重要インフラに適用される国家基準。管理策 2-11 がペネトレーションテストを扱います。定義・文書化・承認・実施が求められ、範囲は少なくともインターネットに面したサービスとその背後の技術基盤を含む必要があります。定期的に実施します。
  • NCA Critical Systems Cybersecurity Controls — システムが重要と分類された場合、頻度は少なくとも6か月ごとに上がります。予算前提を崩すのはたいていこの頻度変更です。
  • SAMA Cyber Security Framework(英語)— サウジ中央銀行の監督下にある銀行、保険会社、金融会社、決済事業者。少なくとも年1回の独立した外部テストで、インターネットに面したシステム、Webアプリケーション、ネットワーク基盤を対象とします。

アラブ首長国連邦

  • NESA / UAE Information Assurance Standards(英語)— 連邦政府機関および重要と指定された情報インフラ。脆弱性評価とペネトレーションテストを実施し追跡することが求められ、実務上は年次です。重大および高の指摘には、定められた期限内の是正記録と再テスト証跡が必要です。監査人は実施者の資格を確認します。
  • Dubai ISR(DESC) — ドバイ政府機関とその供給業者。NESA と並行して適用され、1件の案件で双方の証跡になりえます。
  • CBUAE、DFSA、ADGM(英語)— オンショアの銀行・金融会社、DIFC の企業、ADGM の企業。いずれも定期的な独立テストが期待されます。
  • VARA — ドバイの仮想資産サービス提供者。Technology and Information Rulebook に基づき少なくとも年1回の独立したペネトレーションテスト、VARA が相当と判断する場合はインテリジェンス主導のテストも。
  • ADHICS(英語)— アブダビの医療機関とその技術供給業者。

国際基準

  • PCI DSS — カード会員データを保存・処理・送信するすべての事業者向け。要件 11.4 は少なくとも年1回および重大な変更後の内部・外部ペネトレーションテストを義務づけ、範囲縮小にセグメンテーションを用いる場合はその検証も求めます。
  • SOC 2 — 明文の義務ではありませんが、CC4.1 および CC7.1 に対して多くの監査人が期待する証跡がペネトレーションテストであり、大企業顧客が報告書での提示を求める例が増えています。
  • ISO 27001 — 附属書 A の技術的脆弱性管理。管理策が機能していることを示す実務的な方法がテストです。

監査人が実際に要求するもの

報告書は必要ですが十分ではありません。完全な証跡一式は四つの文書から成り、多くの組織は二つ目だけを持って現れます。

  • 範囲定義書 — 何をテストし、何を除外し、なぜその範囲が管理策に適合していたか。管理策が対象とするシステムを除外したテストは、内容がどれほど良くても通りません。
  • 報告書 — 指摘、深刻度、再現手順、該当する管理策への紐づけ。
  • 是正の記録 — 何をいつ修正したか、どれをどの理由でリスク受容としたか。リスク受容は認められますが、判断を記録しないことは認められません。
  • 再テストの証跡 — 重大および高の指摘が実際に解消されたことの確認を、基準の定める期限内に。NESA の90日という期待が最もつまずきやすく、11か月目のテストではサイクル終了前に再テストの余地が残りません。

誰が・どの範囲で・いつ実施したかを記したアテステーションレターが一式を束ね、通常はこれが保管されるか顧客に転送されます。当方の案件にはすべて含まれます。

読み違えられやすい要件は「独立性」

これらの基準のいくつかは独立したという語を用い、その意味は明確です。対象システムを構築または運用している者がテストを実施してはなりません。自社インフラをテストする社内セキュリティチームは一部の基準を満たしますが他は満たさず、アプリケーションを書いたチームがそれをテストする場合はどれも満たしません。

この市場に外部コンサルタントが存在する理由の大きな部分がここにあり、社内体制で足りると判断する前に、自社の具体的な義務と照らし合わせる価値があります。ここでの誤りは高くつきます。範囲設定時ではなく監査時に判明するからです。

コンプライアンス案件の範囲設計

最初の会話は技術ではなく義務の話です。どの基準か、どの管理策か、期限はいつか、前回のテストから実質的な変更があったか。そこから通常は1回の打ち合わせで、1件の案件で適用されるすべてを賄えるか、監査に耐える証跡を生むために範囲へ何を含める必要があるかをお伝えできます。

提供するもの。着手前の固定価格、お話しした本人によるテスト実施、重大な指摘の即時連絡(最終文書での不意打ちにしません)、経営層と技術者の双方に向けて書かれた報告書、是正期間中のサポート、再テスト、そしてアテステーションレター。形式を先に確認したい場合はサンプル報告書(英語)があり、金額感は料金ページをご覧ください。

地域別

湾岸地域であれば、地域ページで適用される規制と相互関係をより詳しく扱っています。サウジアラビアのペネトレーションテストとUAE のペネトレーションテストです。それ以外はサービスページでテスト自体を説明しており、お問い合わせが明確な回答への最短経路です。

コンプライアンステストに関する質問

多くの場合は可能で、別々に実施するより大幅に安く済みます。技術的な範囲は大きく重なり——外部攻撃面、Webアプリケーションと API、内部ネットワーク、Active Directory、クラウド——異なるのは管理策への紐づけと報告形式であって、テストそのものではありません。条件は一つ、最初からそのように範囲を設計することです。PCI だけを想定して範囲を切ったテストは、基盤となる作業がほぼ同一であっても NESA が求める証跡を生みません。範囲設定の際に適用されるすべての規制をお知らせいただければ、報告書は各指摘をそれぞれに紐づけます。

不十分であり、これは証跡が却下される最も多い理由です。スキャンは既知のシグネチャを既知のバージョンと照合して一覧を出すだけですが、ペネトレーションテストは個々の指摘をつなぎ、攻撃者が実際に何を達成しうるかを示します。各基準はこの点を明確に述べるようになっており、監査人もペネトレーションテストの表紙がついたスキャン報告書を見分けられます。見分け方は、すべての指摘が CVE であり、互いにつながっていないことです。違いの詳細(英語)。

四つあり、多くの組織は二つ目しか保管していません。何をテストし、なぜその範囲が妥当だったかを示す範囲定義書。指摘、深刻度、再現手順を含む報告書そのもの。重大および高の指摘に対する是正の記録。そして修正が有効だったことを確認する再テストの証跡を、基準が定める期限内に——90日が一般的です。誰が、どの範囲で、いつ実施したかを記したアテステーションレターがこれらを束ね、通常はこの一枚が記録として保管されます。

年次が一般的な基本線で、SAMA、NESA、VARA、PCI DSS はいずれもここに落ち着きます。この間隔を短くする要因は二つ。サウジ CSCC における重要システムとしての分類で、少なくとも6か月ごとのテストが必要になること、そして重大な変更です。ほぼすべての基準が、前回の年次テストの時期にかかわらず環境への実質的な変更後の再テストを求めるため、大規模な移行やインターネットに面した新規アプリケーションは事実上カウンターをリセットします。

通常は可能で、原因は予測できます。管理策が求める内容に対して範囲が狭すぎた、システムを構築したチームが実施したため独立性がなかった、再テストの証跡が作られなかった、スキャンをペネトレーションテストとして提出した。いずれも是正可能で、解決策は通常、正しく範囲設定された1件の案件であってプログラムではありません。監査人の指摘と前回の報告書をお送りいただければ、費用を使う前にどの類型かをお伝えします。

どの基準が適用されるか分かりませんか。

短い打ち合わせでたいてい判明します。1回のテストで全部を賄えるかどうかも分かります。

お問い合わせ