セキュリティ監査レポートには何を含める必要がありますか？
背景
私は中規模のWebアプリケーションの監査を担当しています。私は以前にWebアプリケーションを数回監査しましたが、常にPDF発生したことをすばやく説明し、通常はこれらの脆弱性を修正するつもりなので、気にかけたことはありません。レポートの実際の内容。
私の現在の仕事では、物事はより組織的に行われています。最初にレポートを作成する必要があります。次にプロジェクトマネージャーがそれをレビューし、問題を修正するのが私なのか他の誰かなのかを彼が決定します。
質問
そのようなレポートには何を含めるべきですか？それがどのように整理されるべきかについての一般的な概要を探しています。
更新：監査レポートについてSecurity.SEで何も見つからなかったため、この質問を少し広げて、Webアプリケーションだけでなく、あらゆる種類のセキュリティ監査を含めることにしました。この場合、もっと多くの人に役立つと思います。
これを実現する方法はいくつかありますが、それぞれに長所と短所があります。
両方のアプローチの共通点の下で@RoryAlsopが指摘しているように、エグゼクティブサマリーは可能な限りビジネスユーザー向けに作成する必要があります（サードパーティに対して行うテストである場合、またはレポートに合格した場合）管理に）。
- 発見による報告。ここでは、通常は重大度（CVSSスコアまたは重大度/可能性などのその他のスケール）でランク付けされた調査結果を一覧表示します。次に、調査結果の技術的な詳細と、その情報があれば軽減策をリストアップします。この種のレポートは非常に迅速にポイントに到達し、ツールの出力でうまく機能します。
- 方法論による報告。ここでは、定義されたテスト方法論に従っていると仮定すると、レポートは方法論の線に沿って構成されており、レビューの各領域のセクションが含まれています。セクションでは、テストが行われた内容と結果（たとえば、このセクションに所見がなかった、または所見がなかったという事実）が詳述されます。ここでの利点は、動作を示していることと、レポートを読んでいる誰かが、実際に何かをテストしたことがあり、見逃しただけでなく、問題がなかったという良いアイデアを得ることができることです。欠点は、レポートが長くなり、自動化が困難になる傾向があることです。もう1つの問題は、テスターが方法論に従うだけでなく、実際に他のことを探すために脳に働きかけることを確認する必要があることです。
調査結果の形式については、通常、以下を含めます
- タイトル（説明はテーブルで使用され、詳細にリンクされます）
- 説明-問題が何であるか、および重要な問題がセキュリティ上の問題を引き起こす可能性があることの技術的説明（たとえば、クロスサイトスクリプティングの場合、潜在的な問題の1つは、攻撃者が不正にアクセスできるようにするセッショントークンの取得に使用されます。アプリケーション）
- 推奨事項-問題を解決する方法。可能な場合は、ベンダーガイダンスに関する特定の詳細を含めて修正します（たとえば、ヘッダーからのWebサーバーバージョンの削除などには、Apache/IISに関する特定の指示があります）。
- 参考資料-調査結果に関連する追加情報へのリンク（例：Webアプリの問題に関連するOWASPページへのリンク）
- 重大度。上で述べたように、これはCVSSか、影響と可能性に基づいた高/中/低などのより一般的なものになります。
- クライアントが必要とするその他の分類。たとえば、一部のクライアントでは、標準やポリシー、またはOWASPトップ10などに対応するものが必要になる場合があります。
もう1つの注意点は、多くのテストを行う場合は、以前の調査結果のデータベースを用意して、参照を繰り返し参照する必要がなく、重大度が一貫していることを確認することをお勧めします。
わくわくする質問！私たちの業界は、セキュリティの最新かつ最大の流行を求めて努力していると感じることがよくあります。私たちは最新のエクスプロイトを追求し、最新のツールに多額の資金を費やし、ギャップをレイヤー8のせいにします。それはひどい一般化であることは知っていますが、このトピックの重要性を強調したいと思います-レポート！
脆弱性レポートに何を含めるべきかについて私の意見があります。構造の観点から、完全なレポートには以下が含まれます。
タイトルページ：これは、レポート名、それが所属する機関または部門、レポートが発行された日付を示します。
目次：明らかなようですが、これらのドキュメントは長くなる可能性があります。礼儀としてこれを含めてください。
エグゼクティブサマリー：これは、結果の概要、見つかったもの、最終的な結果を示します。
はじめに：資格、監査の目的、対象範囲の簡単な説明。
調査結果：このセクションには調査結果が含まれ、修正が必要な脆弱性または問題が一覧表示されます。このリストは、重要なレベルで順序付けする必要があります。これらのレベルは内部ポリシーで定義することが望まれます（つまり、脆弱性スキャナーが環境での脆弱性の実装方法に基づいて高い重要な脆弱性を見つけた場合、真の重要度は高くない可能性があるため、内部ポリシーは、重要なレベルの定義を支援する必要があります）
方法論：ここでは、使用したツール、誤検知が除外された方法、この監査を完了したプロセスについて説明します。これは、一貫性を提供し、調査結果に異議が唱えられたり、管理者が修正する価値がないと判断した場合に監査を繰り返し実行できるようにするためです。
結論：基本的な結論、すでにまとめた情報を要約します。
Appendixes：これは、参照に必要な追加の添付ファイルになります。
PTESに取り組んでいる人々の一部は、いくつかの優れた基盤を築いています。侵入テストに重点が置かれていますが、多くの方法論、特にレポートは、監査のために置き換えることができると思います。 http://www.pentest-standard.org/index.php/Reporting で確認できます。
侵入テストまたはハイブリッドアプリケーション分析の後、結果のレポートは調査結果に集中します。欠陥とシステムへのそれらの集合的な影響を議論する高レベルの概要があるはずです。
発見はセキュリティ違反です。これには CWE違反 が含まれますが、最も一般的なWebアプリケーションの結果はOWASPトップ10に該当します。各結果には、問題、重大度、この欠陥の影響、修正のための推奨事項を再現するための手順が必要です問題と詳細情報へのリンク。たとえば、XSSの脆弱性を見つけた場合、警告ボックスのスクリーンキャップと、問題のトリガーに使用したURLを表示し、XSSのOWASPページにリンクします。 XSSでCookieにアクセスできる場合、問題を使用してセッションをハイジャックできます。それ以外の場合は、CSRF保護を弱体化するために使用できます。
何も見つからない場合はどうなりますか？見続ける！ CWEシステムは巨大であり、最も熟練した開発でさえ間違いを犯します。私が触れたすべてのアプリケーションに文字通り影響を与える脆弱性があります。クリックジャッキング、ブルートフォース保護の欠如、および情報開示がおそらく最も一般的です。たとえば、忘れたパスワードまたはサインアップ機能によるユーザー名/メールアドレスの開示。バージョン番号（httpヘッダーまたはその他の場所）の表示。詳細なエラーメッセージ、ローカルパス、内部IPアドレス...攻撃者に役立つ可能性のあるもの。
これは、レポートのフォーマットが設計された後に配置される構造ではなく、レポートのコアに関するものですが、Rookの言うとおりです。
STARモデル（状況、タスク、アクション、結果）を試してみてください。このモデルを使用して書かれたすばらしいレポートを目にしました。それの素晴らしいところは、ほとんどすべてのコンテキストで使用できることです。自分に関連するものに調整する必要があるだけです。この場合、このモデルを中心にレポートを構造化し、Rookが説明したものを使用して構造を埋めることができます。
また、実際の調査結果がない場合でも、STARモデルに基づいて完全なレポートを作成し、専門的で首尾一貫した何かを提供できます。
私はセキュリティ監査レポートを書いたことはありませんが、私の役割では受け取る傾向があります。関心のある特定の領域で製品全体を調べた中で最高のもの。レポートはそれらの領域に分けられました。全体的な形式は次のとおりです。
- 題名
- エグゼクティブサマリー-監査の目的と範囲の簡単な概要。そして、主要な懸念領域に関する高レベルのコメント、そしてより重要なことに、うまく行われている領域をカバーします
- 評価方法
- システムの説明-調査中の展開をカバー
- 次に、各エリア/ターゲットのセクション
- まとめと推奨事項
セクション5は、ターゲットごとに次のように分類されています。
- 前書き
- 目的
- 意義
- 評価（方法論と実際の脆弱性をカバー）
- 結論
最初に：それは本を書くようなもので、最初の行は読者を維持するかどうかです。 （イントロは少なくとも書くことです。）
イントロ、開始、コンテンツ、終了など。
- 前書き
- 目標
- 契約条件を更新します。
- ターゲットの説明
- メソッドの説明
- 実行
- ステップバイステップ：目標、アクション、反応
- 観察->質問
- フルター操作、ステップバイステップ
- 新しい観察...
- もう一度ファーター...もしあれば
- 結論
- 成功かどうか
- 何が明らかに間違っているのか
- 何が失敗し、修正する必要がある
- 目的
覚えておくべきいくつかのトリック：
- あなたの仕事は技術者が読むことを意図していないので、シンプルさを保つようにしてください、しかし
- 推奨事項を検証または適用するには、技術担当者が作業を読む必要があるため、何も忘れないでください。あなたの仕事は正確で、包括的で、論争の余地がないでなければなりません。
- あなたの仕事はセキュリティの失敗に関係しているので、カップルのユーザー名にJohn Doe：XXXXXを使用するなどの難読化を行うと、パスワードは良い習慣になるかもしれません。イントロで言及されましたが、これはさらに議論するのに役立つかもしれません。
したがって、行政の人々のために光を保つためには、序論と結論を簡単な方法で説明する必要があります。
あなたのテキストを回避しなければならない技術的な人々のために明かりを保つために、正確かつ詳細にしてください。いくつかのコメント付きの単純なコンソールダンプで十分かもしれません。
この状況をどのようにして調整し、どのように対処しますか？
私は生活のためのセキュリティ操作を構築し、設計します。私は10年間アプリケーションセキュリティレポートに取り組んできましたが、何を含めるか、どこに含めるかについてはかなり確信しています。プレゼンテーションは重要です。
私はこれをかなり考えました。すべての回答を見ると、最も明確な回答と知識に加えて、不足している部分に焦点を当てるべきだと感じています。
初めに、私は言って行きたいと思います-査定と監査を混同しないでください。監査には監査証跡があり、評価には細かい技術的な詳細があります。元の投稿によると、監査はそれができなかったアプリケーションに対して行われたとのことです。より厳密には、それは評価でした。
[〜＃〜] cern [〜＃〜]でフォローされている方法論を含むいくつかをピックアップしました。参照： http：// pwntoken.github.io/enterprise-web-application-security-program/ 。驚いたことに、ほとんどの場合、セキュリティ評価としての技術的な詳細は、ビジネスの利害関係者よりも開発者とITの運用に役立つと思われます。パブリックインターフェイスでアプリケーションまたはアプリケーションのセットを監査しようとすると、アプリケーションの利害関係者にそれをもたらします。
私のサンプルアプリケーションレポートのポイントに来て、これはどのように見えるかです（落書きは絶対に必要でしたが、NDAの基準に従って削除する必要があったので、落書きをお詫び申し上げます）。
キーポインターのこれらのコンポーネントについて説明します。
- 1つ目は脆弱性の分類です。 XSSの場合、コードインジェクションとして記述できます。 Shell Injectionの場合、Interpreter Injectionはより正確な用語です。同様に、SQLインジェクションでは、MS-SQLiまたはMySQliではなく、分類はデータベースインジェクションである必要があります。
- 次は脆弱性のタイトル：データベースインジェクションの場合、
UNION BASED MySQL Injection Leads to Command Level Compromiseのような1つのライナーで常により正確になる可能性があります。 - 次はリスクレーティングです：私の考えでは、
WASCまたは何でもいいのですが、私は独自のカスタムレーティング回路を使用しました。特定の方法論に固執するように指示されている場合は、OWASP、WASCなどを探すことができます。NISTは、主にネットワークセキュリティを扱っている場合に1つになります。 - 説明：これはできるだけ詳細にする必要があります。本質的にビジネスロジックであるという脅威が原因で分類セットが見つからない場合があります。それらについては、コンテキストと攻撃シナリオがそのように置かれている理由を理解する優れた感覚が必要です。
- 影響：繰り返しますが、これは箇条書きのハードポインターであることを述べます。それはビジネス関係者にとっても健康的で衛生的です。
- Proof Of Concept：これは自明だと思います。ただし、スクリーンショットなどの詳細を含めます。もう1つの入力は、影響を受けるパラメーターを含めることです。また、POSTパラメーターがある場合は、それとともに影響を受けるAPIである場合は、エンドポイントを書き留めます。
- 推奨と修正：これは説明的なものでもあると思います。
OWASP Top 10、SANS 15、およびWASC Top 26の汎用テンプレートを保持します。それ以外の場合は、手動で書かれたコンテキストベースの推奨事項を使用して、IT運用を支援します。 - Fix Responsibility：だれが修正しているか。あなたの場合、それはあなたです！
これがお役に立てば幸いです。
これは警官のように聞こえるかもしれませんが、そうではありません。それは単に彼らが好きなフォーマットを尋ねることです。私はあらゆる種類のレビューを行ってきましたが、ほとんどの企業は、どのような情報が好きで、どのようにそれが好きかというフォーマットを持っています。以前のレポートをテンプレートとして表示するように依頼すると、時間を大幅に節約できます。
セキュリティ監査レポートの目的が、見つかったセキュリティの弱点を修正するよう経営陣を説得することである場合、次のことを行います問題を修正しないことの影響を説明します IT監査人として、私は非-私が行う推奨事項に関する技術管理メンバー：
- 実装するにはコストがかかりすぎる
- 努力を正当化するのに十分なビジネスへの復帰がありません
- 明確な経済的利益はない
次のようなbusinessの用語で、セキュリティの脆弱性を修正しないことの影響をレポートに記述したいとします。
- セキュリティの脆弱性が攻撃者によって悪用される場合、失われたビジネスのコストは約Xドルになります。
- X時間のダウンタイム（RTO）が発生し、その間、システムの可用性に対する脆弱性を悪用する脅威の結果として、お客様にサービスを提供できなくなります。
要約すると、あなたの目標は、セキュリティがIT機能だけから、脆弱性が考慮されない場合に経済的および非経済的（例：評判の低下）の悪影響をもたらす機能にセキュリティが変換されるように、ビジネスの賛同を得ることです。