RiLi-Sicherheitsvorfallmanagement

Aus ISMS-Ratgeber WiKi
Version vom 6. Mai 2024, 06:01 Uhr von Dirk (Diskussion | Beiträge) (→‎Kriese)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Zur Navigation springenZur Suche springen

Mustervorlage: "Richtlinie Sicherheitsvorfallmanagement"

Einleitung

Das Management von Sicherheitsvorfällen (Incident Response) ist ein Prozess zur Reaktion auf und Behebung von Sicherheitsvorfällen. Er umfasst die Schritte

  1. Erkennung von Sicherheitsvorfällen durch Überwachung von Aktivitäten, Meldungen von Benutzern oder automatische Alarme.
  2. Untersuchung des Vorfalls, um die Art und den Umfang des Vorfalls zu bestimmen.
  3. Behebung des Vorfalls durch Anwendung von Korrekturmaßnahmen, z. B. Isolierung von Systemen, Schließen von Sicherheitslücken, Entfernen von Malware usw.
  4. Dokumentation des Vorfalls und Durchführung von Folgemaßnahmen zur Vermeidung künftiger Vorfälle.

Geltungsbereich

Diese Richtlinie gilt für den gesamten Geltungsbereich des ISMS der Organisation und ist für alle Mitarbeitenden verbindlich.

Zielsetzung

Das Ziel des Sicherheitsvorfallmanagements ist es, die Auswirkungen von Sicherheitsvorfällen auf die Organisation zu minimieren und zukünftige Vorfälle zu verhindern. Es beinhaltet die schnelle Erkennung und Reaktion auf Sicherheitsvorfälle, um Schäden und Datenverluste zu minimieren und eine schnellstmögliche Wiederherstellung von Geschäftsprozessen und Systemen zu gewährleisten. Auch die Nachverfolgung und Dokumentation von Vorfällen kann das Risikomanagement verbessern.

Definitionen

Ein sicherheitsrelevantes Ereignis ist ein Ereignis, das sich negativ auf die Sicherheit hinsichtlich der Schutzziele Vertraulichkeit, Integrität und Verfügbarkeit von Informationen, Systemen oder Ressourcen auswirkt.

Beispiele können technische Fehler, Hackerangriffe, Infektionen mit Schadsoftware oder Sicherheitslücken in Software sein. Es ist wichtig, solche Ereignisse schnell zu erkennen und angemessen zu reagieren, um den Schaden zu minimieren und weitere Gefährdungen zu vermeiden. Dazu gehören Maßnahmen wie die Durchführung von Sicherheitsaudits, die Überwachung von Netzwerken, regelmäßige Backups und das Einspielen von Sicherheitsupdates und Patches.

Sicherheitsproblem

Ein Sicherheitsproblem ist ein sicherheitsrelevantes Ereignis ohne erkennbaren Schaden, wie z.B. eine erkannte Schwachstelle, die offensichtlich noch nicht ausgenutzt wurde.

Sicherheitsvorfall

Ein Sicherheitsvorfall ist ein Sicherheitsproblem, das bereits zu einem Schaden geführt hat.

Sicherheitsvorfälle können durch einen gezielten oder ungezielten Angriff von außen oder innen, durch fahrlässiges Handeln, durch technisches Versagen oder durch Naturgewalten (Feuer, Wasser, Sturm) verursacht werden.

Notfall

Ein Notfall liegt vor, wenn die Auswirkungen eines Sicherheitsvorfalls zu einem längerfristigen Ausfall wichtiger Ressourcen führen und der reguläre Geschäftsbetrieb nicht innerhalb eines vereinbarten Zeitraums wiederhergestellt werden kann.

Krise

Ein Notfall, bei dem die Existenz der Organisation oder das Leben und die Gesundheit von Menschen gefährdet sind, wird als Krise bezeichnet. Eine Krise ist ein schwerwiegendes und lang andauerndes Ereignis. Eine IT-Krise erfordert eine umfassende und strategische Reaktion, um die Auswirkungen auf die Organisation zu minimieren und den Betrieb wiederherzustellen.

Sicherheitsvorfall Management Prozess

In diesem Kapitel wird beschrieben, wie sicherheitsrelevante Ereignisse in der Organisation erkannt werden können und wie im Falle eines solchen Ereignisses zu verfahren ist.

Dieser Prozess beschränkt sich auf Sicherheitsprobleme und Sicherheitsvorfälle. Notfälle und Krisen werden im Notfallmanagement behandelt.

Erkennung

Um sicherheitsrelevante Ereignisse erkennen zu können, werden in der Organisation im Wesentlichen drei Quellen genutzt:

Überwachung (Monitoring und Protokollierung)

Das Netzwerk und alle relevanten Systeme werden überwacht. Ausfälle oder Unregelmäßigkeiten werden automatisiert an die zuständigen Administratoren gemeldet.

Ggf. Einsatz eines SIEM beschreiben, falls vorhanden.

Meldungen (intern und extern)

Alle Mitarbeitenden sind aufgefordert mögliche Sicherheitsprobleme oder -vorfälle unverzüglich zu melden. Dabei reicht bereits ein Verdacht aus.

Sicherheitsprobleme können zum Beispiel sein:

  • offene Fenster und Türen in sicherheitsrelevanten Bereichen
  • bei Abwesenheit nicht gesperrte Clients oder Konsolen
  • ungewöhnliche Geräusche oder ungewöhnliches Verhalten von Clients oder Servern
  • ungewöhnliche E-Mails oder Telefonanrufe
  • unbekannte Personen in nicht öffentlich zugänglichen Bereichen.

Sicherheitsvorfälle können zum Beispiel sein:

  • Diebstahl von Geräten
  • Hacker- oder Phishing-Angriffe
  • Malware-Infektionen (Viren, Trojaner, andere Schadsoftware)
  • Datenlecks (versehentliche oder absichtliche Freigabe vertraulicher Daten an Dritte)
  • Sicherheitslücken und Software-Fehler

Alle sicherheitsrelevanten Ereignisse sind unverzüglich an den Informationssicherheitsbeauftragten (Name, Tel., E-Mail) oder seinem Vertreter zu melden.

(alternativ Ticketsystem, Webformular im Intranet)

Für Externe (Kunden, Geschäftspartner) steht ein Web-Formular zur Verfügung oder die öffentliche E-Mail Adresse unserer Webseite: abuse@organisation.tdl. (hier die entsprechenden Möglichkeiten angeben)

Informationen aus externen Quellen (CERT)

Beschreibung externer Bezugsquellen wie z.B. CERT

Erfassung und Klassifizierung

Die Erfassung und Klassifizierung von Sicherheitsvorfällen ist ein wesentlicher Schritt im Vorfallsmanagementprozess. Sie hilft, einen Überblick zu gewinnen und die Schwere und Dringlichkeit von Sicherheitsvorfällen zu bewerten, was wiederum eine angemessene Reaktion und Ressourcenzuweisung ermöglicht.

Die folgenden Informationen sollten so weit wie möglich erfasst und dokumentiert werden:

Art des Vorfalls

Die Art des Vorfalls kann erheblichen Einfluss auf die Klassifizierung haben.

Art Beschreibung
Denial of Service (DoS) Ein eingehender oder ausgehender, einzelner oder verteilter Angriff (DoS oder DDos), der darauf abzielt, Systeme oder Dienste zu beeinträchtigen.
Schadsoftware Würmer, Viren oder Trojaner, Botnets, Keylogger, Rootkits.
Verschlüsselung Unautorisierte Verschlüsselung von Daten, z.B. durch Ransomware.
Phishing Phishing-Angriffe zielen darauf ab, Benutzer zur Preisgabe vertraulicher Informationen wie Benutzernamen, Passwörter oder Kreditkartendaten zu verleiten, indem sie sich als vertrauenswürdige Quelle ausgeben.
Spam Massenhaftes versenden von E-Mails in die Organisation oder aus der Organisation heraus.
Social Engineering Dies umfasst verschiedene Techniken, bei denen Angreifer die Manipulation von Menschen verwenden, um Informationen oder Zugriffe zu erhalten. Dazu gehören Täuschung, Überredung und Manipulation.
Unautorisierter Zugriff Unautorisierter Zugriff auf Informationen oder Konfigurationen der Organisation
Unautorisierter Zutritt Physische Eindringversuche oder Einbrüche in Gebäude oder Räume, unbekannte Personen in sicherheitsrelevanten Bereichen.
Datendiebstahl Unbefugte haben Zugang zu sensiblen oder vertraulichen Daten und können diese kopieren oder stehlen.
Konfigurationsfehler Unsichere oder fehlerhafte Systemkonfigurationen, die Angreifern einen leichten Zugang zu Systemen ermöglichen.
Diebstahl/Verlust (Hardware) Der Verlust oder Diebstahl von Laptops, Mobilgeräten, Datenträgern oder anderen physischen Geräten.
Scan/Monitoring Unautorisiertes scannen von Ports, unautorisiertes scannen von Schwachstellen (Vulnerability Scanning), unautorisiertes Monitoring/Überwachung von Netzwerkaktivitäten.
Sicherheitslücke Noch nicht geschlossene Sicherheitslücken in Software oder Hardware, die von Angreifern ausgenutzt werden können.
Verstoß gegen Regelwerk Verstöße gegen sicherheitsrelevante Regelungen der Organisation.
Sonstiges Weitere Erläuterungen im Beschreibungstext des Vorfalls.
Schweregrad

Die Einschätzung des Schweregrads kann anhand der potenziellen Auswirkungen auf die Vertraulichkeit, Integrität und Verfügbarkeit von Daten und Systemen erfolgen. Ist der Schweregrad nicht sofort bestimmbar, ist der Schweregrad 2 "mittel" zu wähle.

Stufe Vertraulichkeit Integrität Verfügbarkeit
1 leicht Informationen sind nur geringfügig beeinträchtigt oder offenbart. Die Auswirkungen sind begrenzt, und es handelt sich um Informationen, die nicht als hoch sensibel gelten. Informationen sind in geringem Maße verändert oder beeinträchtigt. Die Beeinträchtigung hat nur begrenzte Auswirkungen auf die Genauigkeit oder Zuverlässigkeit der Daten. Ressourcen oder Dienste sind nur minimal eingeschränkt oder gestört. Die Beeinträchtigung hat begrenzte Auswirkungen auf die Erreichbarkeit und Nutzung dieser Ressourcen oder Dienste.
2 mittel Es sind sensiblere Informationen gefährdet, aber die Auswirkungen sind noch kontrollierbar und begrenzt. Es erfordert Maßnahmen zur Wiederherstellung der Vertraulichkeit und zur Minimierung potenzieller Schäden. Informationen sind in einem Maße beeinträchtigt, das die Genauigkeit und Zuverlässigkeit erheblich beeinflusst. Es erfordert erhebliche Anstrengungen zur Wiederherstellung der Integrität. Wichtige Ressourcen oder Dienste sind erheblich gestört, was zu einer erheblichen Beeinträchtigung der Erreichbarkeit und Nutzung führt.
3 schwer Hochsensible Informationen sind gefährdet und können erheblich offenbart werden. Die Auswirkungen sind schwerwiegend und erfordern sofortige Maßnahmen zur Eindämmung und Wiederherstellung der Vertraulichkeit. Informationen sind in einem Maße beeinträchtigt, das ihre Nutzbarkeit erheblich beeinträchtigt oder zerstört. Es erfordert umfassende Anstrengungen zur Wiederherstellung der Integrität. Kritische Ressourcen oder Dienste sind schwerwiegend gestört oder nicht verfügbar, was zu erheblichen Geschäftsunterbrechungen führt.

Der Gesamtschweregrad bestimmt sich nach dem Maximumprinzip aus dem jeweils höchsten Einzelwert.

Umfang

Handelt es sich um einen isolierten Vorfall oder ist eine breitere Auswirkung auf Systeme und Daten zu erwarten? Ein größerer Umfang kann zu einer höheren Klassifizierung führen.

Stufe Beschreibung
1 gering es ist nur ein System oder es sind sehr wenige nicht kritische Systeme betroffen.
2 mittel es sind mehrere Systeme betroffen oder die Anzahl der betroffenen Systeme ist noch nicht bekannt.
3 hoch es sind viel Systeme oder einzelne kritische Systeme betroffen.
Dringlichkeit

Erste Einstufung der Dringlichkeit der Reaktion. Wie schnell muss auf den Vorfall reagiert werden, um weitere Schäden zu verhindern oder zu minimieren? Ist die Dringlichkeit noch nicht bestimmbar, ist die Dringlichkeit 2 "mittel" zu wähle.

Stufe Beschreibung
1 niedrig Sicherheitsvorfälle die begrenzte Auswirkungen auf die Sicherheit und den Betrieb haben. Sie erfordern normalerweise keine unmittelbare Reaktion und können in einem geplanten Zeitrahmen behandelt werden. Diese Vorfälle können beispielsweise kleinere Sicherheitslücken oder nicht kritische, eher formale Verletzungen von Sicherheitsrichtlinien sein.
2 mittel Sicherheitsvorfälle die eine raschere Reaktion erfordern. Sie können potenziell größere Auswirkungen auf die Sicherheit, Verfügbarkeit oder Integrität von Systemen und Daten haben. Ein mittlerer Sicherheitsvorfall erfordert eine angemessene Untersuchung und Maßnahmen, um die Situation zu bewältigen und zukünftige Vorfälle zu verhindern.
3 hoch Sicherheitsvorfälle mit hoher Dringlichkeit sind äußerst ernst und erfordern sofortige Aufmerksamkeit und Maßnahmen. Diese Vorfälle können schwerwiegende Auswirkungen auf die Sicherheit, Verfügbarkeit und Integrität von Informationen und Systemen haben. Ein hoher Sicherheitsvorfall erfordert unverzügliche Maßnahmen, um den Vorfall einzudämmen, die Ursache zu ermitteln und Schäden zu minimieren.
Compliance

Hat der Vorfall Auswirkungen auf die Einhaltung von Sicherheitsstandards, Datenschutzvorschriften oder gesetzlichen Anforderungen, kann dies die Klassifizierung beeinflussen, insbesondere wenn rechtliche Verpflichtungen bestehen.

Betroffene Daten oder Systeme

Welche Daten oder Systeme sind betroffen. Informationen von höchster Sensibilität oder kritische Infrastruktur können einen Vorfall schwerwiegender machen.

Eskalationsstufe

Legen Sie Eskalationsstufen fest, um sicherzustellen, dass die richtigen Personen informiert werden, je nach Klassifizierung des Vorfalls.

Bewertungstabelle der o.g Stufen....

Meldepflicht

Sind gesetzliche oder vertragliche Meldepflichten für Sicherheitsvorfälle betroffen?

Hier sind potenzielle Meldepflichten aufzulisten, die im Rahmen des Incident Managements zu prüfen sind:

  • Datenschutzgrundverordnung (DSGVO): Datenschutzverletzungen, bei denen personenbezogene Daten kompromittiert werden, müssen innerhalb von 72 Stunden nach Feststellung an die zuständige Datenschutzbehörde gemeldet werden.
  • IT-Sicherheitsgesetz (BSIG): Betreiber kritischer Infrastrukturen im Sinne des BSIG müssen erhebliche Störungen unverzüglich melden.
  • Weitere gesetzliche Regelungen ....
  • Ggf. vertragliche Regelungen zu Meldepflichten von IT-Dienstleistern gegenüber ihren Kunden ....

Hier ist zu beschreiben wer meldet wann an wen?

Laufende Aktualisierung

Die Klassifizierungkriterien sind mit jedem Arbeitsschritt zu überprüfen, um sicherzustellen, dass sie den aktuellen Umständen und dem Erkenntnisstand entsprechen.


Die genaue Klassifizierungskriterien können je nach den spezifischen Anforderungen und Richtlinien der Organisation variieren. Es ist wichtig, dass die Klassifizierung von Sicherheitsvorfällen ein integraler Bestandteil des Incident-Management-Prozesses ist und kontinuierlich verbessert wird, um angemessene Reaktionen sicherzustellen.

Zuständigkeiten

Beschreibung der zuständigen Organisationsstrukturen von ISB bis Administrator

Behandlung von Sicherheitsproblemen und Sicherheitsvorfällen

Auftretende Sicherheitsvorfälle und -probleme werden per E-Mail / im Ticketsystem erfasst und die Bearbeitung erfolgt durch das jeweils zuständige Team in Absprache mit dem ISB. Die Dokumentation ist obligatorisch, unabhängig davon, wie das Problem oder der Vorfall gemeldet oder erkannt wurde.

Abschluss und Dokumentation

Nach der Bearbeitung des Vorfalls erstellt das verantwortliche Team in Zusammenarbeit mit dem ISB eine kurze Abschlussanalyse. Bestandteile der Dokumentation sind die Bewertung des Vorfalls und die Umsetzung der gewonnenen Erkenntnisse (z.B. zukünftige Präventivmaßnahmen).

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