Unabhängig davon, wie gut Sie Ihre Cybersicherheit verwalten, besteht immer die Möglichkeit, dass Sie Opfer eines Cyberangriffs werden. Deshalb sollte jedes Unternehmen, unabhängig von der Größe, für einen Cyber-Vorfall gewappnet zu sein. Das Schlüsselelement einer solchen Vorbereitung ist ein Cyber Incident Response Plan (IRP) / Vorfallreaktionsplan.

Elemente eines Cyber Incident Response Plans

Wenn Sie Ihren IRP erstellen, gibt es viele Punkte zu berücksichtigen, von denen jeder gleichermaßen wichtig ist. Ignorieren Sie einen dieser Punkte, kann eine effiziente Reaktion nicht gewährleistet werden. Dadurch kann es zu einem Chaos im Unternehmen kommen, was dann wiederum schwerwiegende Auswirkungen auf den Geschäftsbetrieb, die Informationssicherheit und vieles mehr hat.

Incident Response Team

Es ist nicht gerade die beste Option für ein Unternehmen, extra ein ganzes Team in Bereitschaft zu haben, das auf einen möglichen Vorfall wartet. Daher sollten Sie beim Aufbau eines Computer Security Incident Response Teams (CSIRT) die vorhandenen Personalressourcen berücksichtigen. Ein solches Team wird nur im Falle eines Vorfalls zusammengestellt. Aber jedes Mitglied muss sich seiner Rolle im Team und den Auswirkungen auf die tägliche Arbeit bewusst sein.

• Entscheidungsträger: Die wichtigsten Ressourcen in einer CSIRT sind Menschen, die in der Lage sind, Entscheidungen zu treffen. Das bedeutet, dass Ihr Team das Top-Management, möglicherweise sogar Führungskräfte des Unternehmens miteinbeziehen muss. Es ist durchaus üblich, dass ein Security Incident Response Team vom Chief Information Security Officer (CISO), dem Chief Security Officer (CSO), dem Chief Information Officer (CIO) oder sogar dem Chief Technology Officer (CTO) geleitet wird. Je nach Organisationsstruktur kann das Team aber auch den Chief Operations Officer (COO) und den Chief Executive Officer (CEO) einbeziehen. Bei der Reaktion auf einen Vorfall ist Schnelligkeit entscheidend, daher müssen Entscheidungen schnell getroffen werden und können nicht angefochten werden.

• Technische Ressourcen: Ein Cyber Security Incident Response Team muss Personen umfassen, die in der Lage sind, den Vorfall zu untersuchen, mit technischen Assets zu arbeiten und die betroffenen Assets wiederherzustellen/zu reparieren. Das bedeutet, dass das Team Ihr Security Operations Center, aber auch Systemadministratoren, IT-Betriebe und in einigen Fällen sogar Entwickler einbeziehen muss. Da dies das Personal ist, das den größten Teil der Arbeit erledigt, müssen sie sich der Prioritäten und Aufgabenzuweisungen bewusst sein und die Auswirkungen auf die Business Continuity berücksichtigen. Beispielsweise muss Ihr Team in der Lage sein, unbeeinflusste Systeme zu warten und zu sichern, damit Ihr Unternehmen nicht völlig zum Erliegen kommt, bis der Vorfall behoben ist.

• Ressourcen für Rechtliches und Compliance: Bei vielen Unternehmen kann ein Cyber-Vorfall rechtliche Konsequenzen haben und sich auf die Einhaltung von DSGVO, PCI DSS, HIPAA und mehr auswirken. Daher müssen auch Vertreter Ihrer Rechts- und Compliance-Abteilungen an der CSIRT beteiligt sein, um die damit verbundenen Risiken (nicht nur Sicherheitsrisiken) zu bewerten. Wie bei den technischen Ressourcen müssen sie sich der Prioritäten bewusst sein. Um die Business Continuity zu gewährleisten, kann es jedoch sein, dass sie dem Vorfall nicht die volle Aufmerksamkeit widmen.

• Kommunikation: Fast jedes Cyber-Ereignis wird in irgendeiner Weise externe Parteien betreffen. Zum Beispiel Ihre Kunden, Ihre Partner oder die breite Öffentlichkeit (je nach Art Ihres Unternehmens). Daher muss Ihr Security Incident Response Team Ressourcen aus den Bereichen Kundenservice, Öffentlichkeitsarbeit, Account-Management und mehr umfassen. Beachten Sie, dass eine klare Kommunikation mit Offenlegung (einschließlich technischer Details) eine gute Praxis ist und Ihrem Marken-Image zu Gute kommt.

• Externe Ressourcen: Bei einem Vorfall können Sie auch externe Ressourcen wie Forensik-Experten, Risikomanagement-Analysten und mehr einbeziehen. Falls Sie das tun, müssen Sie diese auswählen, bevor ein Vorfall eintritt, damit sie bei Bedarf helfen können. Dies kann zusätzliche Verträge oder Vereinbarungen beinhalten, die abgeschlossen werden müssen.

Unabhängig davon, ob es sich bei den an Ihrer CSIRT beteiligten Ressourcen um interne oder externe Ressourcen handelt, müssen Sie die folgenden Faktoren berücksichtigen:

• Verantwortlichkeiten: Jede Personalressource, die am Security Incident Response Team beteiligt ist, muss den Umfang ihrer Rollen, Verantwortlichkeiten und Prioritäten in Bezug auf ihre tägliche Arbeit genau kennen. Die Verantwortlichkeiten dürfen nicht kollidieren, und wenn externe Ressourcen beteiligt sind, sollten sie einen internen Ansprechpartner haben, falls interne Geschäftsentscheidungen erforderlich sind.

• Kontaktinformationen: Vorfälle können außerhalb der Geschäftszeiten auftreten und erfordern in der Regel eine Reaktion in Echtzeit. Sie können es sich nicht leisten, mit der Eindämmung bis zum nächsten Werktag zu warten, denn der Verbrecher kann sich diese Zeit nehmen, um noch mehr Schaden anzurichten. Daher müssen Sie über Abwesenheits-Kontaktinformationen zu allen beteiligten Ressourcen verfügen und die Ressourcen müssen sich darüber im Klaren sein, dass sie im Falle eines Cyber-Ereignisses außerhalb der Geschäftszeiten kontaktiert werden.

• Backup-Ressourcen: Für jedes wichtige Teammitglied müssen Sie ein Backup haben. Sie können es sich nicht leisten, zu warten, bis z.B. Ihr Teamleiter aus dem Urlaub zurück ist.

Technische Assets

Da es sich bei einem Cyber-Vorfall immer um technische Assets handelt, ist ihre klare Sichtbarkeit der Schlüssel zu einer effektiven Reaktion. Wenn Assets nicht klar definiert, aufgezählt und ihre Beziehung nicht klar ist, ist es eventuell unmöglich, den Vorfall einzudämmen und vollständig zu lösen.

• Asset-Identifikation: Sie sollten einen klaren Überblick über alle Ihre technischen Assets haben, sowohl innerhalb des Unternehmens als auch außerhalb. Dies ist allgemein eine gute tägliche Praxis, aber gewinnt noch an Bedeutung, wenn die Assets von einem Vorfall betroffen sind.

• Asset-Korrelationen: Viele technische Assets sind miteinander verbunden, so dass ein Krimineller ein Asset verletzen und auf andere übertragen könnte. Abhängig von der technischen Struktur Ihres Unternehmens kann potenziell jedes Asset von einem Vorfall betroffen sein und sollte Teil einer Untersuchung und Behebung sein. Wenn ein Krimineller beispielsweise über eine SQL-Injektion auf eine Webanwendung zugreift, greift er mit größter Sicherheit auf den Datenbankserver (der ein separates System sein kann) zu, der möglicherweise das Betriebssystem erreicht und das interne Netzwerk für den Zugriff auf andere Systeme nutzt. Daher ist es von größter Bedeutung zu verstehen, wie die Assets miteinander verbunden sind.

• Asset-Besitz: Einige der miteinander verbundenen technischen Assets können außerhalb Ihres Unternehmens liegen, beispielsweise wenn Sie Cloud-Services oder Partnersysteme nutzen. Oder auch, wenn Ihr Unternehmen in separate Einheiten mit unterschiedlichem Management unterteilt ist. Hier verflechten sich die technischen Assets mit den Personalressourcen, wodurch Sie bei der Zusammensetzung Ihrer CSIRT möglicherweise technische Aspekte berücksichtigen müssen. Im Falle eines Vorfalls können Sie es sich nicht leisten, plötzlich zu entdecken, dass Sie gar keine Kontrolle über ein Asset haben und es daher auch nicht eindämmen oder reparieren können. Jedes Asset sollte einen klar definierten verantwortlichen Vertreter haben, der die volle Kontrolle darüber hat.

Tools

Ein Vorfallreaktionsplan kann Tools beinhalten, die vor einem Vorfall identifiziert, gekauft und implementiert werden müssen:
• Identifizierungs-Tools: Es gibt viele verschiedene IT-Sicherheitstools, die bei der Identifizierung eines Vorfalls hilfreich sein können. Zum Beispiel ein Intrusion Detection System (IDS) zum Erkennen eines möglichen Eindringens, ein Vulnerability Scanner zum Erkennen einer Schwachstelle (den Sie am besten regelmäßig verwenden), manuelle Tools für Penetration Tests zum Bestätigen einer Schwachstelle sowie andere Tools zur Bedrohungserkennung, Web-Sicherheit, Netzwerksicherheit und Security Information and Event Management (SIEM).

• Planungs- und Modellierungs-Tools: Sie können zusätzliche Tools verwenden, um Ihre Assets zu managen, die Aktivitäten während der Reaktion auf Vorfälle zu organisieren, Bedrohungsinformationen bereitzustellen und vieles mehr. Bei solchen Tools kann es sich sowohl um Projektplanungs-Software als auch um verschiedene Arten von Modellierungssoftware handeln.

• Kommunikations-Tools: Während eines Vorfalls können einige der üblichen Business-Kommunikationstools als unsicher gelten. Wenn es sich beispielsweise bei einem Vorfall um eine Verletzung des internen E-Mail-Servers handelt, können Sie während der Reaktion auf einen Vorfall keine interne E-Mail zur Kommunikation verwenden, da die Gefahr besteht, dass der Angreifer Ihre Aktivitäten erkennt und ihnen entgegenwirken kann. Daher sollten Sie einen Backup-Plan für die Kommunikation haben.

• Andere Tools: Es können auch andere Tools zum Einsatz kommen. So können beispielsweise Besprechungsräume als Tool für die Zusammenarbeit des Vorfallreaktionsteams angesehen werden. Wenn Sie externes Personal einbeziehen, muss dieses auch mit geeigneten Tools und Berechtigungen für den Zugriff auf Ihre Systeme und ggf. Ihre Räumlichkeiten ausgestattet sein.

Klare Vorfalldefinition

Jedes Unternehmen kann eine unterschiedliche Definition eines Vorfalls haben, abhängig von den Auswirkungen auf das Unternehmen und anderen Faktoren. Beispielsweise könnte ein Unternehmen einen kleinen Denial-of-Service (DoS)-Angriff nicht als Cyber-Vorfall betrachten, da er die Business Continuity nicht beeinträchtigt. Für ein anderes Unternehmen hingegen kann selbst eine Stunde Nichtverfügbarkeit schwerwiegende geschäftliche Folgen haben. Außerdem können einige Unternehmen kleinere interne Sicherheitsverletzungen als Vorfälle betrachten, andere nicht (z.B. ein Mitarbeiter einer Abteilung, der auf Ressourcen aus einer anderen Abteilung zugreift, für die er keinen Zugriff haben sollte). Andere Faktoren, die zu berücksichtigen sind, könnten die Ursache des Angriffs sein (z.B. lone script kiddie vs. kriminelle Organisation).
Daher ist eins der Schlüsselelemente des IRP, eine sehr klare Definition zu haben, welche Art von Cyber-Bedrohungen und Sicherheitsereignissen als Vorfälle angesehen werden und wann sie zu einem tatsächlichen Ereignis werden. Wird beispielsweise ein Trojaner-Virus, der auf einem Mitarbeitercomputer gefunden und per Phishing verbreitet wird, als Vorfall betrachtet? Meldet ein Kunde, dass eine schwache Cross-Site Scripting (XSS)-Schwachstelle auf Ihrer Marketing-Site ausgenutzt wird, als Vorfall? Handelt es sich um einen Vorfall, wenn eine geringfügige Datenschutzverletzung dadurch verursacht wird, dass ein Mitarbeiter ein Spreadsheet öffentlich zugänglich macht, das nur ein paar Marketing-E-Mail-Adressen enthält?

Ein guter Ausgangspunkt für Ihre eigene Definition eines Vorfalls ist die offizielle NIST-Definition: „Verletzung oder unmittelbare Gefahr einer Verletzung von Computersicherheitsrichtlinien, Richtlinien für die zulässige Nutzung oder Standardsicherheitspraktiken.“ Sie sollten jedoch Ihre eigene, detailliertere Definition erstellen, die unternehmensspezifische Faktoren wie mögliche Geschäftsauswirkungen, potenzielle Datenverluste und mehr berücksichtigt.

Eine klare Definition ist für die Entscheidungsträger sehr wichtig, da sie erklären müssen, ob ein Vorfall eingetreten ist oder nicht. Ein Vorfall ist keine Grauzone, er startet entweder den Prozess, an dem das gesamte Team beteiligt ist, oder er startet ihn nicht. Jeder Vorfall, der gemeldet wird, sollte gleich behandelt werden, ohne Bewertung des Schweregrads. Da die am Prozess beteiligten Aktivitäten umfangreich sind und Auswirkungen auf die Business Continuity haben können, muss der Entscheidungsträger genau wissen, wann er „den roten Knopf drücken“ muss.

Hinweis: „Incident“ und „Disaster“ sind unterschiedliche Begriffe. Daher sollten Disaster Recovery und Incident Recovery nicht von den gleichen Prozessen abgedeckt werden und einer separaten Planung unterliegen. Disaster Recovery ist der Prozess der Wiederherstellung nach natürlichen oder vom Menschen verursachten Katastrophen, z.B. Naturkatastrophen, Bränden, versehentlichem Löschen der gesamten Datenbank, etc. Disaster Recovery erfordert unterschiedliche Ressourcen, dabei muss beispielsweise das Sicherheitsteam nicht so stark einbezogen werden wie beim Incident Recovery.

Vorfallreaktionsphasen

Der Reaktionsprozess auf Vorfälle ist in mehrere Phasen unterteilt, die in den Plan einbezogen werden müssen. Diese Phasen sollten strikt eingehalten werden:

1. Vorbereitung: Dies ist die wichtigste Phase des IRP und beinhaltet die Definition aller oben genannten Elemente: die CSIRT, die Assets und die Definition eines Vorfalls. Es beinhaltet auch das Training der Ressourcen und sogar die Durchführung von Tests, Tabletop-Übungen und Scheinangriffen, um zu sehen, ob alles wie vorgesehen funktioniert. Der Schlüssel zum Erfolg der Vorbereitungsphase liegt darin, jedes Chaos in der Organisation zu vermeiden, falls ein Vorfall gemeldet wird.

2. Identifizierung: Diese Phase umfasst zwei Hauptaktivitäten. Eine davon ist die Voruntersuchung, die zur Feststellung eines Vorfalls führt. Diese Phase betrifft nur einen Teil des Teams: die Entscheidungsträger und die technischen Ressourcen, die Informationen liefern. Beachten Sie, dass der Bericht über einen potenziellen Vorfall auch von externen Quellen stammen kann, z.B. von Ihren Kunden, Partnern oder sogar von der Strafverfolgung, so dass auch Kommunikationspersonal beteiligt sein kann. Der Vorfall wird in dieser Phase gemeldet. Wird er gemeldet, ist eine detaillierte Untersuchung erforderlich, um zu wissen, welche Assets möglicherweise von dem Vorfall betroffen sind und in die nächsten Phasen einbezogen werden müssen. Wenn beispielsweise ein Angreifer gegen Ihre Webanwendung verstößt, müssen Sie feststellen, ob dies verbundene Server oder sogar das gesamte Netzwerk betrifft. Beachten Sie, dass nach Abschluss der Identifizierung Ihre Kommunikations- und Rechts- und Compliance-Ressourcen bereits mit der Bearbeitung ihrer Aufgaben beginnen sollten.

3. Eindämmung: Sobald die Art und der Umfang des Vorfalls durch technische Ressourcen eindeutig identifiziert sind, müssen Sie entscheiden, welche Assets enthalten sein müssen. Die Eindämmung ist absolut notwendig und Sie können diese Phase nicht auslassen, auch wenn Sie versucht sind, die Bedrohung so schnell wie möglich zu beseitigen. Wenn er nicht enthalten ist, arbeitet der Angreifer möglicherweise immer noch parallel zu Ihrem Team und verbreitet sich weiter auf andere, derzeit nicht betroffene Systeme. Eindämmung bedeutet, die betroffenen Vermögenswerte von den nicht betroffenen Vermögenswerten zu trennen. Sie werden jedoch oft nicht (auch nicht vorübergehend) offline genommen, da dies die Ausrottung erschweren kann. Die Eindämmungsphase endet mit der Entscheidung, dass die betroffenen Vermögenswerte sicher isoliert werden und der Angreifer abgeschnitten wird.

4. Eliminierung: Nachdem die betroffenen Anlagen eingedämmt sind, beginnen Ihre technischen Ressourcen, die Folgen des Vorfalls zu beseitigen. Dies bedeutet z.B. das Entfernen von Malware, das Beheben von Schwachstellen, das Wiederherstellen von Systemen aus sicheren Backups, etc. Die Eliminierungsphase endet mit der Entscheidung, dass alle technischen Folgen des Vorfalls beseitigt und die Systeme gesichert sind.

5. Recovery: Die gesicherten Systeme müssen nun wieder online gehen, mit anderen Assets verbunden werden und alle technischen und geschäftlichen Prozesse wieder normalisiert werden. Die Wiederherstellungsphase endet mit der Entscheidung, dass die gesamte technische Infrastruktur sowohl vor als auch nach dem Vorfall funktioniert. Beachten Sie, dass die Wiederherstellungsphase auch den Abschluss der Arbeiten Ihrer Kommunikations- und Rechts- und Compliance-Ressourcen beinhaltet. Das Endergebnis dieser Phase ist, dass Ihre Entscheidungsträger den Vorfall als abgeschlossen erklären und Ihre Teammitglieder zu ihren regulären Aktivitäten zurückkehren.

6. Lessons learned: Diese Aktivität muss nicht unmittelbar nach dem Beenden des Vorfalls durchgeführt werden. Irgendwann nach dem Vorfall ist es sinnvoll, die wichtigsten Mittel des Incident Response Teams, insbesondere aller Entscheidungsträger, wieder zusammenzustellen und zu analysieren, wie gut der Vorfall behandelt wurde. Infolgedessen kann der Prozess bis zur Vorbereitungsphase zurückgehen, um mehr Ressourcen im Team einzubinden, Verantwortlichkeiten zu verlagern oder zusätzliche Schulungen anzubieten, wenn nicht alle Teammitglieder gut genug waren.

Ein IRP für Web Security?

Selbst wenn Ihr Hauptgeschäft im Web liegt und Sie sich vor allem mit webbezogenen Bedrohungen befassen, können Sie den Reaktionsplan für Cybervorfälle nicht nur auf Web-Sicherheit beschränken. Da die IT-Systeme in jedem Unternehmen miteinander verbunden sind, muss das IRP alle Ihre Unternehmen und verbundenen Parteien sowie alle Assets umfassen. Nur dann können Sie mit einem vollständigen Erfolg bei der Beseitigung der Folgen von Vorfällen rechnen.