RiLi-Schwachstellenmanagement

Aus ISMS-Ratgeber WiKi
Zur Navigation springenZur Suche springen
Under construction icon-blue.png Diese Seite ist derzeit noch ein Entwurf.

Weitere Informationen sowie Diskussionen über Änderungen an diesem Entwurf gibt es evtl. auf der Diskussion-Seite.


Mustervorlage: "Richtlinie Schwachstellenmanagement"

Einleitung

Diese IT-Sicherheitsrichtlinie für das Schwachstellenmanagement (Vulnerability Management) ist ein wichtiger Baustein, um die IT-Systeme und Daten der Organisation vor Bedrohungen zu schützen. Diese Richtlinie legt fest, wie die Organisation Schwachstellen in ihren Systemen identifiziert, bewertet und beseitigt.

Geltungsbereich

Diese Richtlinie gilt für alle IT-Systeme der Organisation.

Zielsetzung

Durch die Umsetzung der IT-Sicherheitsrichtlinie zum Schwachstellenmanagement stellt die Organisation sicher, dass ihre IT-Systeme und Daten bestmöglich vor Bedrohungen geschützt sind und Schwachstellen schnell und effektiv behoben werden.

Gesetzliche Rahmenbedingungen

Die Organisation muss sicherstellen, dass die geltenden gesetzlichen Bestimmungen und Standards im Bereich der IT-Sicherheit und des Datenschutzes eingehalten werden. Zu beachten sind unter anderem

  • Die Datenschutzgrundverordnung (DSGVO) regelt den Schutz personenbezogener Daten in der Europäischen Union und legt fest, wie personenbezogene Daten verarbeitet werden dürfen, aber auch wann und wie Vorfälle gemeldet werden müssen.
  • Das IT-Sicherheitsgesetz regelt sicherheitsrelevante Aspekte der Informationstechnik für kritische Infrastrukturen. Es schreibt vor, dass Unternehmen angemessene technische und organisatorische Maßnahmen ergreifen müssen, um ihre IT-Systeme zu schützen und Sicherheitsvorfälle zu verhindern.
  • ISO/IEC 27001 ist ein internationaler Standard, BSI IT-Grundschutz ein deutscher Standard für Informationssicherheitsmanagement.

Verantwortliche

Beschreibung, welche Bereiche der Organisation für die Identifizierung und Bearbeitung von Schwachstellen verantwortlich sind. Die Verantwortlichkeiten können zentral (z.B. ein SOC) oder dezentral (im Betrieb) organisiert sein.

Schwachstellenidentifikation

Hier sollte beschrieben werden, wie die Organisation Schwachstellen identifiziert.z.B.:

Arten von Schwachstellen

In der Organisation kann es verschiedene Arten von Schwachstellen geben, die auf unterschiedliche Weise erkannt und behandelt werden müssen:

Personelle Schwachstellen

Die Mitarbeitenden der Organisation können ein Risiko für die IT-Sicherheit darstellen.

  • Da Menschen für den manuellen Betrieb der IT-Systeme und Anwendungen der Organisation verantwortlich sind, kann eine Vielzahl von Risiken allein durch menschliches Versagen entstehen. So können beispielsweise unvollständige Dokumentation, unzureichende Schulung, die fehlerhafte Konfiguration oder Ausführung von Verfahren im Unternehmen zu Problemen führen.
  • Inselwissen, das nur in den Köpfen einzelner Mitarbeitenden existiert, kann zum Problem werden, wenn die betroffenen Mitarbeitenden plötzlich ausfallen oder die Organisation verlassen.
  • Fehlende Sensibilisierung führt zu Anfälligkeit der Mitarbeitenden für Phishing-, Maleware- und Social Engineering-Angriffe.
  • Zu den personellen Schwachstellen gehört auch das Risiko, dass durch die Kopie/Verlagerung wichtiger Organisationsdaten auf lokale Geräte der Mitarbeitenden entsteht. Im Bedarfsfall sind die Daten ggf. nur noch auf einem externen Gerät gespeichert und es besteht die Gefahr, dass sie verloren gehen oder in falsche Hände geraten.

Physische Schwachstellen

Die elementarsten Arten von Schwachstellen sind physische Schwachstellen. Dies kann z.B sein:

  • Mangelnder Schutz gegen Umwelteinflüsse (Wasser, Feuer, Staub, ...),
  • lokale Schwachstellen in der Versorgung (Stromversorgung, Klimatisierung, Netzzugang, ...),
  • mangelnder Schutz gegen schädliche physische Bedrohungen (Einbruch, Diebstahl, Vandalismus, ...).

Schwachstellen in Anwendungen

Bei der Erstellung und Verbesserung von Computerprogrammen können Fehler und Schwachstellen entstehen. Diese Programmschwachstellen und Fehler können von Angreifern ausgenutzt werden oder zu Ausfällen führen.

Schwachstellen in der Konfiguration

Konfigurationsschwachstellen sind Risiken für ein IT-System aufgrund von Fehlkonfigurationen. Fehlkonfigurationen können fehlerhafte oder unzureichende Standardeinstellungen oder technische Probleme sein, die das System unsicher machen.

Quellen

In der Organisation werden folgende Quellen für die Identifikation von Schwachstellen genutzt.

Meldung durch Mitarbeitende

Insbesondere personelle und physische Schwachstellen können nur durch aktive Beteiligung und Wahrnehmung der Mitarbeitenden der Organisation erkannt werden. Jeder Mitarbeitende ist ausdrücklich aufgefordert erkannte Schwachstellen zu melden. Bei personellen Schwachstellen geht es dabei ausdrücklich nicht um die Pflege von Denunziantentum. Hier können Kolleg(inn)en auch direkt angesprochen werden oder erkannter Sensibilisierungsbedarf anonym (ohne Nennung von Betroffenen) gemeldet werden. Jeder persönlich angesprochene Mitarbeitende sollte dabei offen für Verbesserungsvorschläge sein und dies -im Sinne der offenen Kommunikation- nicht als persönliche Kritik interpretieren.

Die Meldung von erkannten physischen Schwachstellen oder die Meldung von anonymisierten personellen Schwachstellen erfolgt über (...Beschreibung der Meldewege, z.B.: Webformular, Ticketsystem, Email-(Funktions-)Postfach...)

Auswertung von CERT-Meldungen

Die Organisation bezieht CERT-Meldungen vom Warn- und Informationsdienst vom CERT-Bund (https://wid.cert-bund.de/portal/wid/start) als Informationsbasis für bekannte Schwachstellen. (ggf. andere oder weitere CERT-Quellen benennen)

Die CERT-Meldungen werden anhand der betroffenen Produkte und Software automatisiert an die zuständigen Verantwortlichen verteilt.

Regelmäßige Schwachstellen-Scans

Das Security Operation Center (SOC) der Organisation führt mindestens vierteljährlich in Abstimmung mit dem Betrieb einen systematischen Schwachstellenscan aller IT-Systeme der Organisation durch. Darüber hinaus werden bei Bedarf, z.B. bei neuen Anwendungen oder erhöhter Risikolage, zusätzliche Scans durchgeführt. Die Ergebnisse der Scans sind zu dokumentieren. Die Dokumentation erfolgt so, dass ein Vergleich mit den Ergebnissen früherer Scans möglich ist und diese systematisch (nicht personenbezogen) ausgewertet werden können.

Schwachstellenbewertung

Die Richtlinie sollte festlegen, wie Schwachstellen bewertet werden, um ihre Auswirkungen auf das Unternehmen zu bestimmen. Hierbei kann es sich um die Kategorisierung von Schwachstellen nach Schweregrad oder die Bewertung der Auswirkungen auf die Geschäftsprozesse handeln.

CVSS und Relevanz für Oganisation -> rot, gelb, blau

Schwachstellenpriorisierung

Die Richtlinie sollte festlegen, wie Schwachstellen priorisiert werden, um sicherzustellen, dass die wichtigsten Schwachstellen zuerst behoben werden.

Schwachstellenbeseitigung

Die Richtlinie sollte festlegen, wie Schwachstellen beseitigt werden. Hierbei kann es sich um die Implementierung von Patches, die Aktualisierung von Systemen oder die Umsetzung von Workarounds handeln.

Überwachung

Die Richtlinie sollte festlegen, wie das Unternehmen den Fortschritt beim Schwachstellenmanagement überwacht, um sicherzustellen, dass Schwachstellen zeitnah und effektiv behoben werden.

Schulung

Die Richtlinie sollte sicherstellen, dass die Mitarbeiter des Unternehmens angemessen geschult sind, um Schwachstellen zu identifizieren und zu melden, um einen effektiven Schutz der IT-Systeme und Daten zu gewährleisten.

Schulung SOC

Extra Budget, externe Schulung, externer Coach für Einrichtung...

Schulung Verantwortliche

interne Schulung für Fachverantwortliche zum Umgang mit CERT-Meldungen.

Schulung Mitarbeitende

Schulung und Sensibilisierung der MA.

Incident Response

Die Richtlinie sollte einen Plan für den Umgang mit Sicherheitsvorfällen enthalten, um sicherzustellen, dass das Unternehmen schnell und angemessen auf Schwachstellen und Bedrohungen reagieren kann.

Schlussbemerkung

Behandlung von Ausnahmen

Ausnahmen von den Regelungen dieser Richtlinie sind nur mit einem begründeten Ausnahmeantrag im Rahmen des Ausnahmemanagements möglich.

Revision

Diese Richtlinie wird regelmäßig, jedoch mindestens einmal pro Jahr, durch den Regelungsverantwortlichen auf Aktualität und Konformität geprüft und bei Bedarf angepasst.

Inkrafttreten

Diese Richtlinie tritt zum 01.01.2222 in Kraft.

Freigegeben durch: Organisationsleitung

Ort, 01.12.2220,

Unterschrift, Name der Leitung