it-swarm.com.de

Sollte eine Sicherheitsanfälligkeit in einem Dienst, der auf dem Gerät vorhanden ist, aber nicht ausgeführt wird und überhaupt nicht verwendet wird, im Sicherheitsanfälligkeitsbericht erwähnt werden?

Angenommen, ich habe unseren Cisco Router gescannt und er hat 20 Sicherheitslücken zurückgegeben. Die meisten von ihnen sind jedoch an bestimmte Dienste gebunden, auf denen dieser Router nicht ausgeführt wird, z. B. CVE-2016-6380. Auf unserem Cisco wird kein DNS-Server ausgeführt, daher sind wir nicht dafür anfällig.

Einerseits sollte ich diese Sicherheitsanfälligkeit aus dem Bericht ausschließen - wir sind nicht WIRKLICH anfällig, und all dieses weiße Rauschen summiert sich schnell und der Bericht wird unbrauchbar, weil niemand ihn liest.

Was ist andererseits, wenn wir eines Tages beschließen, DNS oder einen anderen Dienst einzuschalten? Wir werden nicht wissen, dass wir verwundbar sind, weil es nicht mehr im Geltungsbereich liegt.

Ich frage mich also, ob Sie mich hier in die richtige Richtung weisen können. Ich überfliege derzeit NIST 800-115, kann aber noch keine Antwort finden. Sagt NIST überhaupt etwas darüber?

TLDR

Sollte eine Sicherheitsanfälligkeit in einem Dienst, der auf dem Gerät vorhanden ist, aber nicht ausgeführt wird und überhaupt nicht verwendet wird, im Sicherheitsanfälligkeitsbericht erwähnt werden?

25
shivelin

Dies hängt davon ab, wie Ihre Organisation diese Art von Berichten verwendet.

Wenn die Personen, die für die Planung und/oder Implementierung von Sicherheitskontrollen verantwortlich sind, diese Dokumente einmal lesen und sie dann nie wieder ansehen OR sehen sie eher als Richtlinie als als tatsächliche Regeln zum Einrichten einer Umgebung, Ich kann sehen, dass Sie möglicherweise nicht zu viele Informationen in den Bericht aufnehmen möchten, nur weil Sie sicherstellen möchten, dass die akut vorhandenen Sicherheitslücken mit Sicherheitsmaßnahmen erfüllt werden.

Wenn es sich dagegen um "lebende" Dokumente handelt, die Regeln für die Planung und Implementierung von Kontrollen festlegen, UND die Verantwortlichen diese Dokumente aktualisieren, wenn sich die Infrastruktur zu einem bestimmten Zeitpunkt ändert, möchten Sie diese Sicherheitsanfälligkeiten auf jeden Fall einbeziehen.

IMHO als jemand, der Informationssicherheit in einer Institution organisiert, ist dies die Art von Kultur, auf die Sie drängen sollten.

Wenn Sie befürchten, dass Ihr Dokument zu unübersichtlich wird, können Sie jederzeit mit seiner Struktur arbeiten. In einer Organisation, mit der ich zusammengearbeitet habe, wurden Sicherheitslücken wie diese oder mögliche zukünftige Sicherheitslücken in einem Anhang zum Hauptdokument hinzugefügt. Wenn die Infrastruktur in irgendeiner Weise geändert wurde, konnten Administratoren zuerst den Anhang überprüfen, wenn eine der Änderungen die dort aufgeführten Schwachstellen mit sich bringen würde.

Ein letzter Punkt, den ich ansprechen möchte: Obwohl SIE diese Funktionen nicht aktiviert haben, bedeutet dies nicht, dass ein Angreifer dies nicht tut, nachdem er Zugriff auf den Router erhalten hat. Die Umsetzung von Sicherheitsmaßnahmen für alle Fälle kann daher sinnvoll sein. Dies könnte jedoch in einer Risikoanalyse bewertet werden.

So zitieren Sie ISO/IEC 27005:

Das Vorhandensein einer Sicherheitsanfälligkeit verursacht an sich keinen Schaden, da eine Bedrohung vorhanden sein muss, um sie auszunutzen. Eine Sicherheitsanfälligkeit ohne entsprechende Bedrohung erfordert möglicherweise keine Implementierung eines Steuerelements, sollte jedoch erkannt und auf Änderungen überwacht werden.

32
Tom K.

Als Kunde von Schwachstellenberichten würde ich ja sagen, aber es ist sicherlich Zeitverschwendung, ihm das gleiche Gewicht wie anderen Schwachstellen zu geben. Zum Beispiel würden lebende, ausnutzbare, massive RAS-Lücken oder aktive böswillige Hintertüren nicht die gleiche Abdeckung erhalten wie eine DoS-Sicherheitsanfälligkeit oder in diesem Fall eine Sicherheitsanfälligkeit in einer deaktivierten Software.

Meiner Meinung nach sollte der Bericht eine Zusammenfassung und technische Ergebnisse enthalten und dann auf die mühsamen Details eingehen.

So etwas wie das, was Sie beschreiben, wäre ein Einzeiler in den technischen Ergebnissen und enthält einige Informationen im Abschnitt mit den langwierigen Details.

CVE-2016-6380 würde jedoch bedeuten, dass Sie die Geräte nicht regelmäßig patchen oder einen sehr langsamen Patch-Zyklus haben. Dies kann ein akzeptiertes Risiko für den Kunden sein, sollte jedoch überprüft werden. Es kann erwähnenswert sein, dies in der Zusammenfassung zu erwähnen. Kein CVE # Zeug, Execs ist das egal.

Siehe weiter in NIST 800-115 7.3

...

Während einzelne Schwachstellen identifiziert und behoben werden müssen, ist die Ermittlung der Hauptursache für Schwachstellen der Schlüssel zur Verbesserung der allgemeinen Sicherheitslage des Unternehmens, da eine Grundursache häufig auf Schwachstellen auf Programmebene zurückgeführt werden kann. Einige häufige Ursachen sind:

  • Unzureichende Patch-Verwaltung, z. B. nicht rechtzeitig Patches anwenden oder Patches nicht auf alle anfälligen Systeme anwenden

...

10
mgjk

Zunächst müssen Sie wissen, wonach Sie suchen und worüber Sie berichten.

Zum Beispiel ist der Umfang des Scannens, um alle Schwachstellen zu erkennen und zu melden, einschließlich Schwachstellen mit geringem Risiko oder nur Schwachstellen mit hohem Risiko oder möglicherweise nur kritische Schwachstellen. Dies sollte definiert worden sein, bevor Sie überhaupt mit dem Scannen von Sicherheitslücken begonnen haben.

Wenn es sich um ein bestätigtes falsches Positiv handelt, entfernen Sie es aus dem Bericht.

Wenn es sich um einen Dienst handelt, der vorhanden ist, aber nicht verwendet wird und dessen Sicherheitsanfälligkeit im Bereich bestätigt wurde, fügen Sie ihn in den Bericht ein, damit der Dienst vom Ziel entfernt werden kann.

6
TheJulyPlot

Wenn jemand eine Kaufentscheidung trifft, könnte er sagen: "Dieser Router unterstützt die DNS-Auflösung im Router. Wir verwenden dies derzeit nicht, aber möglicherweise in Zukunft. Daher kaufen wir diesen Router und keinen etwas billigeren ohne." Merkmal".

Diese Sicherheitsanfälligkeit bedeutet, dass der Router nicht auf diese Weise verwendet werden kann, sodass die Funktion nicht für die Kaufentscheidung verwendet werden darf. Mit anderen Worten, es sollte aus diesem Grund in Ihrem Bericht enthalten sein. Und wenn der Dienst vom Gerät entfernt werden kann, sollte er entfernt werden. (Sie könnten herausfinden, dass Ihre Annahme, dass es nicht verwendet wurde, tatsächlich falsch war, wenn der Dienst entfernt wird und sich Leute beschweren).

2
gnasher729