前書き#
個人の経験から見ると、ペネトレーションテストのレポートは 2 つのカテゴリに分けられます。1 つは簡単なレポートで、脆弱性の内容を簡潔にまとめたものです。このようなレポートは技術的なものであり、上司には適していません。もう 1 つは複雑で公式なレポートであり、プロジェクトのまとめや受け入れのためのレポートとして使用できます。
以前、この記事を見て、高品質なレポートの作成についてのガイドラインをまとめました。海外のペネトレーションテストレポートに対してまとめたもので、他の多くのレポートも参考になるかもしれません。
簡単なレポート#
名称 | 説明 |
---|---|
要約 | 問題とその範囲についての簡単な説明を提供する |
影響 | 脆弱性の危険性 |
再現手順 | スクリーンショット、HTTP リクエスト、POC、Exp などの再現手順を含む |
提案 | 修正の提案 |
参考資料 | 通常は含めない |
脆弱性の評価と脆弱性の危険性レベルは、危険性レベルを示すように一般的に表されます。情報、低、中、高などのレベルがあります。
公式なレポート#
このレポートはsecuritum-protonmail-security-auditを参考にしています。より実践的な内容で、リンクの添付ファイルには他にも多くの情報がありますので、興味があれば参照してください。
- 概要(作業、ペネトレーション)
- テスト範囲
- テスト手法(OWASP TOP10、OWASP ASVS)
- 発見された脆弱性
テストプロセスでは、データの機密性、完全性、可用性に対して負の影響を与える可能性のある脆弱性に特に注意しました。
テストの一環として、上記の方法論を使用した手動テストと、Burp Suite Professional、DirBuster、ffuf、nmap、Visual Studio Code、semgrep、grep、sonarqube などのさまざまな自動化ツールを使用してテストを行いました。
脆弱性はレポートの後半で詳細に説明されています。
== 脆弱性リスクレベル:==
脆弱性は 5 段階の評価で分類され、脆弱性が悪用される可能性とそれによってもたらされるビジネスリスクを反映しています。以下は各重要度レベルの簡単な説明です。
- 重大
- 高リスク
- 中リスク
- 低リスク
- 情報
脆弱性の統計:
グラフで表示
- バージョン変更履歴
- 日付
- バージョン
- 変更の説明
- 脆弱性の再現プロセスの記録
- 脆弱性の名前
- 脆弱性の説明
- 攻撃の前提条件
- 技術の詳細(POC)
- 脆弱性の位置
- 修正の提案
学んだこと
レポートを書く際には、一人称ではなく受動態を使用することをお勧めします。
脆弱性の修正提案を書く際には、通常は提案で始めることができます。脆弱性を修正するための強制的な方法ではなく、提案として書くことが一般的です。
海外のレポートと私たちのレポートを比較すると、異なる点が 1 つあります。それは、最終的なまとめの位置です。海外ではまとめを冒頭に置く傾向がありますが、私たちは終わりに置くことが多いです。時には冒頭にまとめることもあります。
脆弱性の再現の部分では、海外のレポートは非常に詳細で、情報の脆弱性も記載されます。脆弱性の修正提案はシステムに密接に関連しており、一般的な解決策ではありません。
脆弱性のシナリオを再現する際には、攻撃者と被害者の視点で考えることで、他の人が簡単に理解できるようになります。国内の脆弱性報告と比較すると、図がなく、テキストとリンクの説明しかない場合があり、この脆弱性を理解するには一定の知識が必要です。
海外では脆弱性に番号を付けることもあります。プロジェクト名に基づいて脆弱性を明確に区別することができます。
レポートの作成自体は技術的な作業ではありませんが、他の人が理解できるように書くことは難しいです。筆者自身もこの経験があり、1 つのレポートを顧客の意見に基づいて 5〜6 回修正するまで満足しませんでした。レポート自体は手順的なものであり、テンプレートを作成し、他の人がテンプレートを使用して修正するだけです。一部の場合は、ソースコードのレポートを提出することもありますが、その場合は簡単なレポートで十分です。
参考:best-practices-for-writing-quality-vulnerability-reports
他のいくつかのレポートの参考:更多渗透测试报告