デバイスに存在するが、実行されておらず、まったく使用されていないサービスの脆弱性を脆弱性レポートに記載する必要がありますか？
たとえば、Ciscoルーターをスキャンしたところ、20個の脆弱性が返ってきました。ただし、それらのほとんどは、このルーターが実行していない特定のサービス（CVE-2016-6380など）に関連付けられています。シスコではDNSサーバーを実行していないため、脆弱性はありません。
一方で、私はこの脆弱性をレポートから除外する必要があります-私たちは実際には脆弱ではありません、そしてこのすべてのホワイトノイズはすぐに追加され、誰もそれを読まないため、レポートは役に立たなくなります。
一方、DNSやその他のサービスをオンにするとしたらどうでしょうか。対象ではなくなったため、脆弱であることはわかりません。
ですから、ここで私を正しい方向に向けることができるかどうか疑問に思います。現在、NIST 800-115をざっと見ていますが、まだ答えを見つけることができません。 NISTはそれについて何か言いますか？
[〜＃〜] tldr [〜＃〜]
デバイスに存在するが、実行されておらず、まったく使用されていないサービスの脆弱性を脆弱性レポートに記載する必要がありますか？
組織がこれらの種類のレポートをどのように使用しているかによって異なります。
セキュリティ管理の計画および/または実装の責任者がこれらのドキュメントを一度読んだ後、それらを二度と見ない場合OR環境のセットアップ方法に関する実際のルールよりもガイドラインとしてそれらを参照してください、レポートに情報を追加しすぎないようにする必要があるかもしれませんが、実際に存在する脆弱性が安全対策で満たされていることを確認したいだけなのです。
一方、これらが制御の計画と実装方法に関するルールを設定する「生きている」ドキュメントであり、インフラストラクチャが特定の時点で変更された場合に責任者がこれらのドキュメントを更新する場合は、これらの脆弱性を確実に含める必要があります。
機関で情報セキュリティを組織する誰かとしての私見これは、あなたが押し付けるべき文化の一種です。
ドキュメントが乱雑になるのを恐れている場合は、いつでもその構造で作業できます。私が協力した組織で行われたことの1つは、このような脆弱性または将来起こりうる脆弱性が、メインドキュメントの付録に追加されたことです。インフラストラクチャが何らかの方法で変更された場合、管理者は最初にアネックスをチェックし、変更のいずれかがそこにリストされている脆弱性をもたらすかどうかを確認できます。
最後に、これらの機能を有効にしていなかったとしても、攻撃者がルーターにアクセスした後で攻撃者がその機能を使用できないわけではありません。したがって、万が一に備えてセキュリティ対策を実施することは合理的です。これは、リスク分析で評価する必要があるかもしれません。
ISO/IEC 27005を引用するには：
脆弱性を利用するには脅威が存在する必要があるため、脆弱性が存在してもそれ自体に害はありません。対応する脅威がない脆弱性は、コントロールの実装を必要としない場合がありますが、変更を認識して監視する必要があります。
脆弱性レポートの顧客として、私はイエスと言いますが、他の脆弱性と同じ重みを与えることは確かに時間の無駄です。たとえば、ライブで悪用可能な大量のリモートアクセスホールやアクティブな悪意のあるバックドアは、DoSの脆弱性やこの場合は無効にされたソフトウェアの脆弱性のようなものと同じカバレッジを取得しません。
私見レポートは、エグゼクティブサマリー、技術的知見を持っている必要があり、退屈な詳細に入る必要があります。
あなたが説明するようなものは、技術的な発見のワンライナーであり、退屈な詳細セクションにいくつかの情報があります。
ただし、CVE-2016-6380は、デバイスに定期的にパッチを適用していないか、パッチサイクルが非常に遅いことを意味します。これは、お客様側で許容されるリスクである可能性がありますが、確認する必要があります。 mayエグゼクティブサマリーでこれについて言及する価値があります。 CVE＃のものはありません、幹部は気にしません。
NIST 800-115 7.3を参照してください
...
個々の脆弱性を特定して解決する必要がありますが、根本的な原因は多くの場合プログラムレベルの脆弱性に起因する可能性があるため、脆弱性の根本的な原因を特定することは、組織の全体的なセキュリティ態勢を改善する鍵となります。一般的な根本原因には次のものがあります。
- パッチの管理が不十分、たとえば、パッチを適時に適用できない、またはすべての脆弱なシステムにパッチを適用できない
...
まず最初に、スキャン対象とレポート対象の範囲を把握する必要があります。
たとえば、低リスクの脆弱性、高リスクの脆弱性、または重大な脆弱性など、すべての脆弱性を検出して報告するスキャンの範囲です。これは、脆弱性スキャンを開始する前に定義しておく必要があります。
確認済みの誤検知である場合は、レポートから削除してください。
存在するが使用されていないサービスであり、スコープ内で確認された脆弱性である場合は、レポートに含めて、サービスをターゲットから削除できるようにします。
誰かが購入を決定した場合、「このルーターはルーターでDNS解決をサポートしています。現在は使用していませんが、将来的には使用する可能性があるため、このルーターを購入します。特徴"。
この脆弱性は、ルーターをそのように使用できないことを意味するため、この機能を購入の決定に使用してはなりません。言い換えれば、それはあなたがこの理由であなたの報告書にあるはずです。サービスがデバイスから削除できる場合は、削除する必要があります。 （サービスが削除され、人々が不平を言った場合、それが使用されなかったというあなたの仮定が実際には間違っていたことがわかるかもしれません）。