IT-Grundschutz-Kompendium Edition 2021
Dieses Dokument ist Teil der Anfrage „Sicherheit des Bürgerportals“
DER: Detektion und Reaktion DER.1 DER.1.A16 Einsatz von Detektionssystemen nach Schutzbedarfsanforderungen (H) Anwendungen mit erhöhtem Schutzbedarf SOLLTEN durch zusätzliche Detektionsmaßnahmen geschützt werden. Dafür SOLLTEN z. B. solche Detektionssysteme eingesetzt werden, mit denen sich der erhöhte Schutzbedarf tech- nisch auch sicherstellen lässt. DER.1.A17 Automatische Reaktion auf sicherheitsrelevante Ereignisse (H) Bei einem sicherheitsrelevanten Ereignis SOLLTEN die eingesetzten Detektionssysteme das Ereignis automatisch melden und mit geeigneten Schutzmaßnahmen reagieren. Hierbei SOLLTEN Verfahren eingesetzt werden, die auto- matisch mögliche Angriffe, Missbrauchsversuche oder Sicherheitsverletzungen erkennen. Es SOLLTE möglich sein, automatisch in den Datenstrom einzugreifen, um einen möglichen Sicherheitsvorfall zu unterbinden. DER.1.A18 Durchführung regelmäßiger Integritätskontrollen (H) Alle Detektionssysteme SOLLTEN regelmäßig daraufhin überprüft werden, ob sie noch integer sind. Auch SOLLTEN die Benutzerrechte kontrolliert werden. Zusätzlich SOLLTEN die Sensoren eine Integritätskontrolle von Dateien durchführen. Bei sich ändernden Werten SOLLTE eine automatische Alarmierung ausgelöst werden. 4 Weiterführende Informationen 4.1 Wissenswertes Das Bundesamt für Sicherheit in der Informationstechnik (BSI) regelt in seinem Mindeststandard „Mindeststandard des BSI zur Protokollierung und Detektion von Cyber-Angriffen“ die Protokollierung und Detektion von sicherheits- relevanten Ereignissen (SRE). Das BSI hat das weiterführende Dokument „BSI-Leitfaden zur Einführung von Intrusion-Detection-Systemen, Ver- sion 1.0“ zum Themenfeld Intrusion Detection veröffentlicht. Das Infomation Security Forum (ISF) macht in seinem Standard „The Standard of Good Practice for Information Security“ im Kapitel TS1.5 Intrusion Detection Vorgaben für den Einsatz von Intrusion Detection Systemen. 5 Anlage: Kreuzreferenztabelle zu elementaren Gefährdungen Die Kreuzreferenztabelle enthält die Zuordnung von elementaren Gefährdungen zu den Anforderungen. Anhand dieser Tabelle lässt sich ermitteln, welche elementaren Gefährdungen durch welche Anforderungen abgedeckt sind. Durch die Umsetzung der aus den Anforderungen abgeleiteten Sicherheitsmaßnahmen wird den entspre- chenden elementaren Gefährdungen entgegengewirkt. Die Buchstaben in der zweiten Spalte (C = Vertraulichkeit, I = Integrität, A = Verfügbarkeit) zeigen an, welche Grundwerte der Informationssicherheit durch die Anforderung vorrangig geschützt werden. Die folgenden elementaren Gefährdungen sind für den Baustein DER.1 Detektion von sicherheitsrelevanten Ereig- nissen von Bedeutung. G 0.18 Fehlplanung oder fehlende Anpassung G 0.21 Manipulation von Hard- oder Software G 0.22 Manipulation von Informationen G 0.23 Unbefugtes Eindringen in IT-Systeme G 0.25 Ausfall von Geräten oder Systemen G 0.26 Fehlfunktion von Geräten oder Systemen G 0.27 Ressourcenmangel G 0.29 Verstoß gegen Gesetze oder Regelungen G 0.30 Unberechtigte Nutzung oder Administration von Geräten und Systemen G 0.31 Fehlerhafte Nutzung oder Administration von Geräten und Systemen 6 IT-Grundschutz-Kompendium: Stand Februar 2021
DER.1 DER: Detektion und Reaktion G 0.32 Missbrauch von Berechtigungen G 0.33 Personalausfall G 0.37 Abstreiten von Handlungen G 0.38 Missbrauch personenbezogener Daten G 0.39 Schadprogramme G 0.40 Verhinderung von Diensten (Denial of Service) G 0.46 Integritätsverlust schützenswerter Informationen IT-Grundschutz-Kompendium: Stand Februar 2021 7
8 Elementare Gefährdungen CIA- G 0.18 G 0.21 G 0.22 G 0.23 G 0.25 G 0.26 G 0.27 G 0.29 G 0.30 G 0.31 G 0.32 G 0.33 G 0.37 G 0.38 G 0.39 G 0.40 G 0.46 Werte Anforderungen DER.1.A1 X DER.1.A2 X X DER.1.A3 X X DER.1.A4 X X DER.1.A5 X X DER.1.A6 X X X X X X DER.1.A7 X X X DER.1.A8 DER: Detektion und Reaktion DER.1.A9 X X DER.1.A10 X X X X DER.1.A11 X X DER.1.A12 X DER.1.A13 X X X DER.1.A14 CI X X X DER.1.A15 CIA X X X X DER.1.A16 CIA X X X X X X DER.1.A17 CI X DER.1.A18 CI X X X IT-Grundschutz-Kompendium: Stand Februar 2021 DER.1
DER.2.1 DER.2: Security Incident Management DER.2.1: Behandlung von Sicherheitsvorfällen 1 Beschreibung 1.1 Einleitung Um Schäden zu begrenzen und um weitere Schäden zu vermeiden, müssen erkannte Sicherheitsvorfälle schnell und effizient bearbeitet werden. Dafür ist es notwendig, ein vorgegebenes und erprobtes Verfahren zur Behand- lung von Sicherheitsvorfällen zu etablieren (Security Incident Handling oder auch Security Incident Response). Ein Sicherheitsvorfall kann sich stark auf eine Institution auswirken und große Schäden nach sich ziehen. Solche Vorfälle sind beispielsweise Fehlkonfigurationen, die dazu führen, dass vertrauliche Informationen offengelegt wer- den, oder kriminelle Handlungen, wie z. B. Angriffe auf Server, der Diebstahl von vertraulichen Informationen sowie Sabotage oder Erpressung mit IT-Bezug. Die Ursachen für Sicherheitsvorfälle sind vielfältig, so spielen unter anderem Malware, veraltete Systeminfrastruktu- ren oder Innentäter eine Rolle. Angreifer nutzen aber auch oft Zero-Day-Exploits aus, also Sicherheitslücken in Pro- grammen, für die es noch keinen Patch gibt. Eine weitere ernstzunehmende Gefährdung sind sogenannte Advan- ced Persistent Threats (APT). Außerdem könnten sich Benutzer, Administratoren oder externe Dienstleister falsch verhalten, sodass Systempara- meter sicherheitskritisch geändert werden oder sie gegen interne Richtlinien verstoßen. Weiter ist als Ursache denk- bar, dass Zugriffsrechte verletzt werden, dass Software und Hardware geändert oder schutzbedürftige Räume und Gebäude unzureichend gesichert werden. 1.2 Zielsetzung Ziel dieses Bausteins ist es, einen systematischen Weg aufzuzeigen, wie ein Konzept zur Behandlung von Sicher- heitsvorfällen erstellt werden kann. 1.3 Abgrenzung und Modellierung Der Baustein DER.2.1 Behandlung von Sicherheitsvorfällen ist für den Informationsverbund einmal anzuwenden. Der Fokus dieses Bausteins liegt auf der Behandlung von Sicherheitsvorfällen aus Sicht der Informationstechnik. Bevor Sicherheitsvorfälle behandelt werden können, müssen sie jedoch erkannt werden. Sicherheitsanforderungen dazu sind im Baustein DER.1 Detektion von sicherheitsrelevanten Ereignissen enthalten und werden im vorliegen- den Baustein vorausgesetzt. Die Vorsorgemaßnahmen, die notwendig sind, um IT-forensische Untersuchungen zu ermöglichen, sind im Baustein DER.2.2 Vorsorge für die IT-Forensik beschrieben. Die Bereinigung nach einem APT- Vorfall ist Thema im Baustein DER.2.3 Bereinigung weitreichender Sicherheitsvorfälle. Ein besonderer Bereich der Behandlung von Sicherheitsvorfällen ist das Notfallmanagement, das im Baustein DER.4 Notfallmanagement the- matisiert und hier nicht weiter betrachtet wird. Es ist jedoch zu beachten, dass die Entscheidung darüber, ob ein Notfall vorliegt oder nicht, im vorliegenden Baustein getroffen wird. IT-Grundschutz-Kompendium: Stand Februar 2021 1
DER.2: Security Incident Management DER.2.1 2 Gefährdungslage Folgende spezifische Bedrohungen und Schwachstellen sind für den Baustein DER.2.1 Behandlung von Sicherheits- vorfällen von besonderer Bedeutung. 2.1 Ungeeigneter Umgang mit Sicherheitsvorfällen In der Praxis kann nie ausgeschlossen werden, dass Sicherheitsvorfälle auftreten. Das gilt auch dann, wenn viele Sicherheitsmaßnahmen umgesetzt sind. Wird auf akute Sicherheitsvorfälle jedoch nicht oder nicht angemessen re- agiert, können daraus große Schäden mit katastrophalen Folgen entstehen. Beispiele hierfür sind: • In den Protokolldateien einer Firewall finden sich auffällige Einträge. Wird nicht zeitnah untersucht, ob dies erste Anzeichen für einen Einbruchsversuch sind, können Angreifer die Firewall mit einem erfolgreichen Angriff unbe- merkt überwinden und in das interne Netz der Institution eindringen. • Es werden Sicherheitslücken in den verwendeten IT-Systemen bzw. Anwendungen bekannt. Beschafft sich die Institution diese Informationen nicht rechtzeitig und leitet sie die notwendigen Gegenmaßnahmen nicht zügig ein, können diese Sicherheitslücken von Angreifern ausgenutzt werden. • Ein Einbruchdiebstahl in einer Filiale wird für einen Fall von Beschaffungskriminalität gehalten, da Notebooks und Flachbildschirme entwendet wurden. Der Tatsache, dass sich auf den Notebooks vertrauliche Informationen und Zugangsdaten für IT-Systeme im Intranet befunden haben, wird keine größere Bedeutung beigemessen. Der ISB wird daher nicht informiert. Auf die nachfolgenden Angriffe auf die IT-Systeme anderer Standorte und der Firmenzentrale ist die Institution daher nicht vorbereitet. Für den Angriff wurden die auf den gestohlenen Notebooks gefundenen Daten verwendet. Wenn für den Umgang mit Sicherheitsvorfällen keine geeignete Vorgehensweise vorgegeben ist, können in Eile und unter Stress falsche Entscheidungen getroffen werden. Diese können z. B. dazu führen, dass die Presse falsch informiert wird. Außerdem könnten Dritte durch die eigenen IT-Systeme geschädigt werden und Schadenersatz fordern. Auch ist es möglich, dass keinerlei Ausweich- oder Wiederherstellungsmaßnahmen vorgesehen sind und sich somit der Schaden für die Institution deutlich erhöht. 2.2 Zerstörung von Beweisspuren bei der Behandlung von Sicherheitsvorfällen Wenn nach einem Sicherheitsvorfall unvorsichtig oder nicht nach Vorgaben gehandelt wird, kann das dazu führen, dass wichtige Beweisspuren für die Aufklärung oder die spätere juristische Verfolgung unbeabsichtigt zerstört oder nicht gerichtsverwertbar gemacht werden. Beispiele hierfür sind: • Auf einem Client hat ein Angreifer eine Schadsoftware platziert, deren Arbeitsweise und Ziel nur im laufenden Zustand analysiert werden kann. Dafür müssten Informationen über die aktiven Prozesse und der Inhalt des Hauptspeichers gesichert und ausgewertet werden. Wird der Client nun voreilig heruntergefahren, können die Informationen nicht mehr für eine Analyse und Aufklärung des Sicherheitsvorfalls herangezogen werden. • Ein Administrator findet auf einem Server einen laufenden Prozess, der eine überdurchschnittliche CPU-Auslas- tung verursacht. Zusätzlich erzeugt dieser Prozess temporäre Dateien und versendet unbekannte Informationen über das Internet. Wird der Prozess voreilig beendet und werden die temporären Dateien einfach gelöscht, kann nicht herausgefunden werden, ob vertrauliche Informationen entwendet wurden. • Ein wichtiger Server wird kompromittiert, weil der Administrator durch die starke Arbeitsbelastung und ein feh- lendes Wartungsfenster die letzten Sicherheitsupdates nicht wie geplant einspielen konnte. Um möglichen dis- ziplinarischen Konsequenzen zu entgehen, spielt der Administrator die fehlenden Updates ein, bevor ein Sicher- heitsteam die Einbruchsursache und den entstandenen Schaden analysieren kann. Eine mangelhafte Fehlerkul- tur hat somit eine Analyse des Problems verhindert. 2 IT-Grundschutz-Kompendium: Stand Februar 2021
DER.2.1 DER.2: Security Incident Management 3 Anforderungen Im Folgenden sind die spezifischen Anforderungen des Bausteins aufgeführt. Grundsätzlich ist der Informationssi- cherheitsbeauftragte (ISB) für die Erfüllung der Anforderungen zuständig. Der Informationssicherheitsbeauftragte (ISB) ist bei strategischen Entscheidungen stets einzubeziehen. Außerdem ist der ISB dafür zuständig, dass alle An- forderungen gemäß dem festgelegten Sicherheitskonzept erfüllt und überprüft werden. Zusätzlich kann es noch andere Rollen geben, die weitere Zuständigkeiten bei der Erfüllung von Anforderungen haben. Diese sind dann jeweils explizit in eckigen Klammern in der Überschrift der jeweiligen Anforderungen aufgeführt. Grundsätzlich zuständig Informationssicherheitsbeauftragter (ISB) Weitere Zuständigkeiten Datenschutzbeauftragter, Fachverantwortliche, IT-Betrieb, Institutionslei- tung, Notfallbeauftragter 3.1 Basis-Anforderungen Die folgenden Anforderungen MÜSSEN für den Baustein DER.2.1 Behandlung von Sicherheitsvorfällen vorrangig erfüllt werden: DER.2.1.A1 Definition eines Sicherheitsvorfalls (B) In einer Institution MUSS klar definiert sein, was ein Sicherheitsvorfall ist. Ein Sicherheitsvorfall MUSS so weit wie möglich von Störungen im Tagesbetrieb abgegrenzt sein. Alle an der Behandlung von Sicherheitsvorfällen beteilig- ten Mitarbeiter MÜSSEN die Definition eines Sicherheitsvorfalls kennen. Die Definition und die Eintrittsschwellen eines solchen Vorfalls SOLLTEN sich nach dem Schutzbedarf der betroffenen Geschäftsprozesse, IT-Systeme bzw. Anwendungen richten. DER.2.1.A2 Erstellung einer Richtlinie zur Behandlung von Sicherheitsvorfällen (B) Eine Richtlinie zur Behandlung von Sicherheitsvorfällen MUSS erstellt werden. Darin MÜSSEN Zweck und Ziel der Richtlinie definiert sowie alle Aspekte der Behandlung von Sicherheitsvorfällen geregelt werden. So MÜSSEN Ver- haltensregeln für die verschiedenen Arten von Sicherheitsvorfällen beschrieben sein. Zusätzlich MUSS es für alle Mitarbeiter zielgruppenorientierte und praktisch anwendbare Handlungsanweisungen geben. Weiterhin SOLLTEN die Schnittstellen zu anderen Managementbereichen berücksichtigt werden, z. B. zum Notfallmanagement. Die Richtlinie MUSS allen Mitarbeitern bekannt sein. Sie MUSS mit dem IT-Betrieb abgestimmt und durch die Insti- tutionsleitung verabschiedet sein. Die Richtlinie MUSS regelmäßig geprüft und aktualisiert werden. DER.2.1.A3 Festlegung von Verantwortlichkeiten und Ansprechpartnern bei Sicherheitsvorfällen (B) Es MUSS geregelt werden, wer bei Sicherheitsvorfällen wofür verantwortlich ist. Für alle Mitarbeiter MÜSSEN die Aufgaben und Kompetenzen bei Sicherheitsvorfällen festgelegt werden. Insbesondere Mitarbeiter, die Sicherheits- vorfälle bearbeiten sollen, MÜSSEN über ihre Aufgaben und Kompetenzen unterrichtet werden. Dabei MUSS auch geregelt sein, wer die mögliche Entscheidung für eine forensische Untersuchung trifft, nach welchen Kriterien diese vorgenommen wird und wann sie erfolgen soll. Die Ansprechpartner für alle Arten von Sicherheitsvorfällen MÜSSEN den Mitarbeitern bekannt sein. Kontaktinfor- mationen MÜSSEN immer aktuell und leicht zugänglich sein. DER.2.1.A4 Benachrichtigung betroffener Stellen bei Sicherheitsvorfällen [Institutionsleitung, IT-Betrieb, Datenschutzbeauftragter, Notfallbeauftragter] (B) Von einem Sicherheitsvorfall MÜSSEN alle betroffenen internen und externen Stellen zeitnah informiert werden. Dabei MUSS geprüft werden, ob der Datenschutzbeauftragte, der Betriebs- und Personalrat sowie Mitarbeiter aus der Rechtsabteilung einbezogen werden müssen. Ebenso MÜSSEN die Meldepflichten für Behörden und regulierte Branchen berücksichtigt werden. Außerdem MUSS gewährleistet sein, dass betroffene Stellen über die erforderli- chen Maßnahmen informiert werden. IT-Grundschutz-Kompendium: Stand Februar 2021 3
DER.2: Security Incident Management DER.2.1 DER.2.1.A5 Behebung von Sicherheitsvorfällen [IT-Betrieb] (B) Damit ein Sicherheitsvorfall erfolgreich behoben werden kann, MUSS der Zuständige zunächst das Problem ein- grenzen und die Ursache finden. Danach MUSS er die erforderlichen Maßnahmen auswählen, um das Problem zu beheben. Der Leiter des IT-Betriebs MUSS seine Freigabe erteilen, bevor die Maßnahmen umgesetzt werden. An- schließend MUSS die Ursache beseitigt und ein sicherer Zustand hergestellt werden. Eine aktuelle Liste von internen und externen Sicherheitsexperten MUSS vorhanden sein, die bei Sicherheitsvorfäl- len für Fragen aus den erforderlichen Themenbereichen hinzugezogen werden können. Es MÜSSEN sichere Kom- munikationsverfahren mit diesen internen und externen Stellen etabliert werden. DER.2.1.A6 Wiederherstellung der Betriebsumgebung nach Sicherheitsvorfällen [IT-Betrieb] (B) Nach einem Sicherheitsvorfall MÜSSEN die betroffenen Komponenten vom Netz genommen werden. Zudem MÜS- SEN alle erforderlichen Daten gesichert werden, die Aufschluss über die Art und Ursache des Problems geben könn- ten. Auf allen betroffenen Komponenten MÜSSEN das Betriebssystem und alle Applikationen auf Veränderungen untersucht werden. Die Originaldaten MÜSSEN von schreibgeschützten Datenträgern wieder eingespielt werden. Dabei MÜSSEN alle sicherheitsrelevanten Konfigurationen und Patches mit aufgespielt werden. Wenn Daten aus Datensicherungen wieder eingespielt werden, MUSS sichergestellt sein, dass diese vom Sicherheitsvorfall nicht betroffen waren. Nach einem Angriff MÜSSEN alle Zugangsdaten auf den betroffenen Komponenten geändert werden, bevor sie wieder in Betrieb genommen werden. Die betroffenen Komponenten SOLLTEN einem Penetrationstest unterzogen wer- den, bevor sie wieder eingesetzt werden. Bei der Wiederherstellung der sicheren Betriebsumgebung MÜSSEN die Benutzer in die Anwendungsfunktionstests einbezogen werden. Nachdem alles wiederhergestellt wurde, MÜSSEN die Komponenten inklusive der Netzüber- gänge gezielt überwacht werden. 3.2 Standard-Anforderungen Gemeinsam mit den Basis-Anforderungen entsprechen die folgenden Anforderungen dem Stand der Technik für den Baustein DER.2.1 Behandlung von Sicherheitsvorfällen. Sie SOLLTEN grundsätzlich erfüllt werden. DER.2.1.A7 Etablierung einer Vorgehensweise zur Behandlung von Sicherheitsvorfällen [Institutionsleitung] (S) Es SOLLTE eine geeignete Vorgehensweise zur Behandlung von Sicherheitsvorfällen definiert werden. Die Abläufe, Prozesse und Vorgaben für die verschiedenen Sicherheitsvorfälle SOLLTEN dabei eindeutig geregelt und geeignet dokumentiert werden. Die Institutionsleitung SOLLTE die festgelegte Vorgehensweise in Kraft setzen und allen Be- teiligten zugänglich machen. Es SOLLTE regelmäßig überprüft werden, ob die Vorgehensweise noch aktuell und wirksam ist. Bei Bedarf SOLLTE die Vorgehensweise angepasst werden. DER.2.1.A8 Aufbau von Organisationsstrukturen zur Behandlung von Sicherheitsvorfällen (S) Für den Umgang mit Sicherheitsvorfällen SOLLTEN geeignete Organisationsstrukturen festgelegt werden. Es SOLLTE ein Sicherheitsvorfall-Team aufgebaut werden, dessen Mitglieder je nach Art des Vorfalls einberufen wer- den können. Auch wenn das Sicherheitsvorfall-Team nur für einen konkreten Fall zusammentritt, SOLLTEN bereits im Vorfeld geeignete Mitglieder benannt und in ihre Aufgaben eingewiesen sein. Es SOLLTE regelmäßig geprüft werden, ob die Zusammensetzung des Sicherheitsvorfall-Teams noch angemessen ist. Gegebenenfalls SOLLTE das Sicherheitsvorfall-Team neu zusammengestellt werden. DER.2.1.A9 Festlegung von Meldewegen für Sicherheitsvorfälle (S) Für die verschiedenen Arten von Sicherheitsvorfällen SOLLTEN die jeweils passenden Meldewege aufgebaut sein. Es SOLLTE dabei sichergestellt sein, dass Mitarbeiter Sicherheitsvorfälle über verlässliche und vertrauenswürdige Ka- näle schnell und einfach melden können. Wird eine zentrale Anlaufstelle für die Meldung von Störungen oder Sicherheitsvorfällen eingerichtet, SOLLTE dies an alle Mitarbeiter kommuniziert werden. Eine Kommunikations- und Kontaktstrategie SOLLTE vorliegen. Darin SOLLTE geregelt sein, wer grundsätzlich infor- miert werden muss und wer informiert werden darf, durch wen dies in welcher Reihenfolge erfolgt und in welcher 4 IT-Grundschutz-Kompendium: Stand Februar 2021
DER.2.1 DER.2: Security Incident Management Tiefe informiert wird. Es SOLLTE definiert sein, wer Informationen über Sicherheitsvorfälle an Dritte weitergibt. Ebenso SOLLTE sichergestellt sein, dass keine unautorisierten Personen Informationen über den Sicherheitsvorfall weitergeben. DER.2.1.A10 Eindämmen der Auswirkung von Sicherheitsvorfällen [Notfallbeauftragter, IT-Betrieb] (S) Parallel zur Ursachenanalyse eines Sicherheitsvorfalls SOLLTE entschieden werden, ob es wichtiger ist, den entstan- denen Schaden einzudämmen oder den Vorfall aufzuklären. Um die Auswirkung eines Sicherheitsvorfalls abschät- zen zu können, SOLLTEN ausreichend Informationen vorliegen. Für ausgewählte Sicherheitsvorfallsszenarien SOLL- TEN bereits im Vorfeld Worst-Case-Betrachtungen durchgeführt werden. DER.2.1.A11 Einstufung von Sicherheitsvorfällen [IT-Betrieb] (S) Ein einheitliches Verfahren SOLLTE festgelegt werden, um Sicherheitsvorfälle und Störungen einzustufen. Das Ein- stufungsverfahren für Sicherheitsvorfälle SOLLTE zwischen Sicherheitsmanagement und der Störungs- und Fehler- behebung (Incident Management) abgestimmt sein. DER.2.1.A12 Festlegung der Schnittstellen der Sicherheitsvorfallbehandlung zur Störungs- und Fehlerbehebung [Notfallbeauftragter] (S) Die Schnittstellen zwischen Störungs- und Fehlerbehebung, Notfallmanagement und Sicherheitsmanagement SOLLTEN analysiert werden. Dabei SOLLTEN auch eventuell gemeinsam benutzbare Ressourcen identifiziert wer- den. Die bei der Störungs- und Fehlerbehebung beteiligten Mitarbeiter SOLLTEN für die Behandlung von Sicherheitsvor- fällen sowie für das Notfallmanagement sensibilisiert werden. Das Sicherheitsmanagement SOLLTE lesenden Zugriff auf eingesetzte Incident-Management-Werkzeuge haben. DER.2.1.A13 Einbindung in das Sicherheits- und Notfallmanagement [Notfallbeauftragter] (S) Die Behandlung von Sicherheitsvorfällen SOLLTE mit dem Notfallmanagement abgestimmt sein. Falls es in der Insti- tution eine spezielle Rolle für Störungs- und Fehlerbehebung gibt, SOLLTE auch diese mit einbezogen werden. DER.2.1.A14 Eskalationsstrategie für Sicherheitsvorfälle [IT-Betrieb] (S) Über die Kommunikations- und Kontaktstrategie hinaus SOLLTE eine Eskalationsstrategie formuliert werden. Diese SOLLTE zwischen den Verantwortlichen für Störungs- und Fehlerbehebung und dem Informationssicherheitsmana- gement abgestimmt werden. Die Eskalationsstrategie SOLLTE eindeutige Handlungsanweisungen enthalten, wer auf welchem Weg bei welcher Art von erkennbaren oder vermuteten Sicherheitsstörungen wann einzubeziehen ist. Es SOLLTE geregelt sein, zu welchen Maßnahmen eine Eskalation führt und wie reagiert werden soll. Für die festgelegte Eskalationsstrategie SOLLTEN geeignete Werkzeuge wie z. B. Ticket-Systeme ausgewählt wer- den. Diese SOLLTEN sich auch dafür eignen, vertrauliche Informationen zu verarbeiten. Es SOLLTE sichergestellt sein, dass die Werkzeuge auch während eines Sicherheitsvorfalls bzw. Notfalls verfügbar sind. Die Eskalationsstrategie SOLLTE regelmäßig überprüft und gegebenenfalls aktualisiert werden. Die Checklisten (Matching Szenarios) für Störungs- und Fehlerbehebung SOLLTEN regelmäßig um sicherheitsrelevante Themen er- gänzt bzw. aktualisiert werden. Die festgelegten Eskalationswege SOLLTEN in Übungen erprobt werden. DER.2.1.A15 Schulung der Mitarbeiter des Service Desk [IT-Betrieb] (S) Den Mitarbeitern des Service Desk SOLLTEN geeignete Hilfsmittel zur Verfügung stehen, damit sie Sicherheitsvor- fälle erkennen können. Sie SOLLTEN ausreichend geschult sein, um die Hilfsmittel selbst anwenden zu können. Die Mitarbeiter des Service Desk SOLLTEN den Schutzbedarf der betroffenen IT-Systeme kennen. DER.2.1.A16 Dokumentation der Behebung von Sicherheitsvorfällen (S) Die Behebung von Sicherheitsvorfällen SOLLTE nach einem standardisierten Verfahren dokumentiert werden. Es SOLLTEN alle durchgeführten Aktionen inklusive der Zeitpunkte sowie die Protokolldaten der betroffenen Kompo- nenten dokumentiert werden. Dabei SOLLTE die Vertraulichkeit bei der Dokumentation und Archivierung der Be- richte gewährleistet sein. IT-Grundschutz-Kompendium: Stand Februar 2021 5
DER.2: Security Incident Management DER.2.1 Die benötigten Informationen SOLLTEN in die jeweiligen Dokumentationssysteme eingepflegt werden, bevor die Störung als beendet und als abgeschlossen markiert wird. Im Vorfeld SOLLTEN mit dem ISB die dafür erforderlichen Anforderungen an die Qualitätssicherung definiert werden. DER.2.1.A17 Nachbereitung von Sicherheitsvorfällen (S) Sicherheitsvorfälle SOLLTEN standardisiert nachbereitet werden. Dabei SOLLTE untersucht werden, wie schnell die Sicherheitsvorfälle erkannt und behoben wurden. Weiterhin SOLLTE untersucht werden, ob die Meldewege funkti- onierten, ausreichend Informationen für die Bewertung verfügbar und ob die Detektionsmaßnahmen wirksam wa- ren. Ebenso SOLLTE geprüft werden, ob die ergriffenen Maßnahmen und Aktivitäten wirksam und effizient waren. Die Erfahrungen aus vergangenen Sicherheitsvorfällen SOLLTEN genutzt werden, um daraus Handlungsanweisun- gen für vergleichbare Sicherheitsvorfälle zu erstellen. Diese Handlungsanweisungen SOLLTEN den relevanten Perso- nengruppen bekanntgegeben und auf Basis neuer Erkenntnisse regelmäßig aktualisiert werden. Die Institutionsleitung SOLLTE jährlich über die Sicherheitsvorfälle unterrichtet werden. Besteht sofortiger Hand- lungsbedarf, MUSS die Institutionsleitung umgehend informiert werden. DER.2.1.A18 Weiterentwicklung der Prozesse durch Erkenntnisse aus Sicherheitsvorfällen und Branchenentwicklungen [Fachverantwortliche] (S) Nachdem ein Sicherheitsvorfall analysiert wurde, SOLLTE untersucht werden, ob die Prozesse und Abläufe im Rah- men der Behandlung von Sicherheitsvorfällen geändert oder weiterentwickelt werden müssen. Dabei SOLLTEN alle Personen, die an dem Vorfall beteiligt waren, über ihre jeweiligen Erfahrungen berichten. Es SOLLTE geprüft werden, ob es neue Entwicklungen im Bereich Incident Management und in der Forensik gibt und ob diese in die jeweiligen Dokumente und Abläufe eingebracht werden können. Werden Hilfsmittel und Checklisten eingesetzt, z. B. für Service-Desk-Mitarbeiter, SOLLTE geprüft werden, ob diese um relevante Fragen und Informationen zu erweitern sind. 3.3 Anforderungen bei erhöhtem Schutzbedarf Im Folgenden sind für den Baustein DER.2.1 Behandlung von Sicherheitsvorfällen exemplarische Vorschläge für An- forderungen aufgeführt, die über das dem Stand der Technik entsprechende Schutzniveau hinausgehen und BEI ERHÖHTEM SCHUTZBEDARF in Betracht gezogen werden SOLLTEN. Die konkrete Festlegung erfolgt im Rahmen einer Risikoanalyse. DER.2.1.A19 Festlegung von Prioritäten für die Behandlung von Sicherheitsvorfällen [Institutionsleitung] (H) Es SOLLTEN Prioritäten für die Behandlung von Sicherheitsvorfällen vorab festgelegt und regelmäßig aktualisiert werden. Dabei SOLLTE auch die vorgenommene Einstufung von Sicherheitsvorfällen berücksichtigt werden. Die Prioritäten SOLLTEN von der Institutionsleitung genehmigt und in Kraft gesetzt werden. Sie SOLLTEN allen Ent- scheidungsträgern bekannt sein, die mit der Behandlung von Sicherheitsvorfällen zu tun haben. Die festgelegten Prioritätsklassen SOLLTEN außerdem im Incident Management hinterlegt sein. DER.2.1.A20 Einrichtung einer dedizierten Meldestelle für Sicherheitsvorfälle (H) Eine dedizierte Stelle zur Meldung von Sicherheitsvorfällen SOLLTE eingerichtet werden. Es SOLLTE gewährleistet sein, dass die Meldestelle zu den üblichen Arbeitszeiten erreichbar ist. Zusätzlich SOLLTE es möglich sein, dass Si- cherheitsvorfälle auch außerhalb der üblichen Arbeitszeiten von Mitarbeitern gemeldet werden können. Die Mitar- beiter der Meldestelle SOLLTEN ausreichend geschult und für die Belange der Informationssicherheit sensibilisiert sein. Alle Informationen über Sicherheitsvorfälle SOLLTEN bei der Meldestelle vertraulich behandelt werden. DER.2.1.A21 Einrichtung eines Expertenteams für die Behandlung von Sicherheitsvorfällen (H) Es SOLLTE ein Team mit erfahrenen und vertrauenswürdigen Spezialisten zusammengestellt werden. Neben dem technischen Verständnis SOLLTEN die Teammitglieder auch über Kompetenzen im Bereich Kommunikation verfü- gen. Die Vertrauenswürdigkeit der Mitglieder des Expertenteams SOLLTE überprüft werden. Die Zusammensetzung des Expertenteams SOLLTE regelmäßig überprüft und, wenn nötig, geändert werden. Die Mitglieder des Expertenteams SOLLTEN in die Eskalations- und Meldewege eingebunden sein. Das Experten- team SOLLTE für die Analyse von Sicherheitsvorfällen an den in der Institution eingesetzten Systemen ausgebildet 6 IT-Grundschutz-Kompendium: Stand Februar 2021
DER.2.1 DER.2: Security Incident Management werden. Die Mitglieder des Expertenteams SOLLTEN sich regelmäßig weiterbilden, sowohl zu den eingesetzten Sys- temen als auch zur Detektion und Reaktion auf Sicherheitsvorfälle. Dem Expertenteam SOLLTEN alle vorhandenen Dokumentationen sowie finanzielle und technische Ressourcen zur Verfügung stehen, um Sicherheitsvorfälle schnell und diskret zu behandeln. Das Expertenteam SOLLTE in geeigneter Weise in den Organisationsstrukturen berücksichtigt und in diese integriert werden. Die Zuständigkeiten des Expertenteams SOLLTEN vorher mit denen des Sicherheitsvorfall-Teams abge- stimmt werden. DER.2.1.A22 Überprüfung der Effizienz des Managementsystems zur Behandlung von Sicherheitsvorfällen (H) Das Managementsystem zur Behandlung von Sicherheitsvorfällen SOLLTE regelmäßig daraufhin geprüft werden, ob es noch aktuell und wirksam ist. Dazu SOLLTEN sowohl angekündigte als auch unangekündigte Übungen durch- geführt werden. Die Übungen SOLLTEN vorher mit der Institutionsleitung abgestimmt sein. Es SOLLTEN die Mess- größen ausgewertet werden, die anfallen, wenn Sicherheitsvorfälle aufgenommen, gemeldet und eskaliert wer- den, z. B. die Zeiträume von der Erstmeldung bis zur verbindlichen Bestätigung eines Sicherheitsvorfalls. Außerdem SOLLTEN Planspiele zur Behandlung von Sicherheitsvorfällen durchgeführt werden. 4 Weiterführende Informationen 4.1 Wissenswertes Die International Organization for Standardization (ISO) gibt in der Norm ISO/IEC 27001:2013 „Information tech- nology – Security techniques – Information security management systems – Requirements“ im Anhang A16 „Infor- mation security incident management“ Vorgaben für die Behandlung von Sicherheitsvorfällen. Die International Organization for Standardization (ISO) gibt in der Norm ISO/IEC 27035:2016 „Information tech- nology – Security techniques – Information security incident management“ Vorgaben für die Behandlung von Si- cherheitsvorfällen. Das National Institute of Standards and Technology (NIST) macht in seiner Special Publication 800-61 Revision 2 „Computer Security Incident Handling Guide“ generelle Vorgaben zur Behandlung von Sicherheitsvorfällen. Das National Institute of Standards and Technology (NIST) macht in seiner Special Publication 800-83 Revision 1 „Guide to Malware incident Prevention and Handling for Desktops and Laptops“ spezifische Vorgaben zum Um- gang mit Malware-Infektionen bei Laptops und Desktops. Das Information Security Forum (ISF) macht in seinem Standard „The Standard of Good Practice for Information Security“ im Kapitel TS1.4 „Technical Security Management; Identity and Access Management“ Vorgaben für die Behandlung von Sicherheitsvorfällen. 5 Anlage: Kreuzreferenztabelle zu elementaren Gefährdungen Die Kreuzreferenztabelle enthält die Zuordnung von elementaren Gefährdungen zu den Anforderungen. Anhand dieser Tabelle lässt sich ermitteln, welche elementaren Gefährdungen durch welche Anforderungen abgedeckt sind. Durch die Umsetzung der aus den Anforderungen abgeleiteten Sicherheitsmaßnahmen wird den entspre- chenden elementaren Gefährdungen entgegengewirkt. Die Buchstaben in der zweiten Spalte (C = Vertraulichkeit, I = Integrität, A = Verfügbarkeit) zeigen an, welche Grundwerte der Informationssicherheit durch die Anforderung vorrangig geschützt werden. Die folgenden elementaren Gefährdungen sind für den Baustein DER.2.1 Behandlung von Sicherheitsvorfällen von Bedeutung. G 0.15 Abhören G 0.18 Fehlplanung oder fehlende Anpassung G 0.19 Offenlegung schützenswerter Informationen G 0.22 Manipulation von Informationen G 0.23 Unbefugtes Eindringen in IT-Systeme IT-Grundschutz-Kompendium: Stand Februar 2021 7
