Was ist Incident Management? 

Was ist ein IT Incident?

Laut der Information Technology Infrastructure Library (ITIL) ist ein „Incident“ oder „Incedent“ (im Deutschen in der Regel als „Vorfall“ bzw. „IT-Vorfall“ bezeichnet) eine „ungeplante Störung oder drohende Störung eines IT-Service“. Nach dieser Beschreibung kann man den Begriff „Incident“ sehr weit fassen – von einer Verschlechterung der Netzwerkqualität über mangelnden Speicherplatz bis hin zu einem Cyberangriff. Die Erkennung von sicherheitsrelevanten Vorfällen und die Reaktion darauf wird als Security Incident Management bzw. Incident Response Management bezeichnet.

Warum Incident Management?

Es gibt zahlreiche Möglichkeiten, das Incident Management anzugehen: Richtlinien, Tools und SLAs (Service-Level Agreements) können sich von Unternehmen zu Unternehmen stark unterscheiden. Im Allgemeinen versuchen IT-Teams, Probleme und Incidents durch regelmäßige Software-Updates, Event-Monitoring und andere Methoden zu verhindern. Hierfür wird in der Regel ein Incident Response-Plan etabliert, um Incidents bzw. Incedents schnell zu beheben und deren Ursache zu ermitteln, sodass sich die Incidents in Zukunft gezielt verhindern lassen.

Incident Management ist wichtig, da die Störung von Services extrem kostspielig sein kann und sich auf Hunderttausende Euro pro Stunde belaufen – gesetzliche Bußgelder und Kundenverluste nicht mitgerechnet.

Was beinhaltet die Security Incident Response?

Bei der Reaktion auf Sicherheits-Incidents handelt es sich um den Prozess, bei dem Sicherheitsbedrohungen oder -vorfälle in Echtzeit erkannt, analysiert und behoben werden. Dabei kommt eine Kombination aus Untersuchung und Analyse – entweder computergestützt oder durch Mitarbeiter – zum Einsatz, um negative Auswirkungen auf das Unternehmen zu minimieren bzw. einen möglichen Incident zu verhindern

Der Prozess beginnt in der Regel damit, dass das Sicherheitssystem das Incident-Response-Team über einen aufgetretenen Incedent informiert. Das Response-Team untersucht und analysiert den Incident, um seine Echtheit und seinen Umfang zu bestimmen. Ebenso werden die Auswirkungen des Incident bewertet und im Rahmen des Incident Response Managements ein Plan zur Schadensbegrenzung entwickelt.

Was ist ein Security Incident?

Ein Security Incident bzw. Sicherheitsvorfall kann alles sein – von einer aktiven Bedrohung bis hin zu einem Datensicherheitsverstoß. Ferner kann ein Incident sowohl innerhalb als auch außerhalb eines Unternehmens entstehen. Dementsprechend kann ein Mitarbeiter einen Incident verursachen, indem dieser einen Computer an seinem Arbeitsplatz nutzt und auf eine Glücksspiel-Website zugreift. Oder ein Lieferant lädt Daten herunter, für die er keine Berechtigung besitzt. Ebenso gelten auch Malware-Angriffe als Security Incidents.

Neben dem Troubleshooting beinhaltet die Reaktion auf einen Incident auch das präventive Reagieren und Implementieren von Maßnahmen, mit denen zukünftige Angriffe oder Incidents abgewehrt werden. Beispielsweise sicherten und überprüften die Administratoren der betroffenen Unternehmen nach den berüchtigten Angriffen Heartbleed und EternalBlue sofort die Systeme und die IT-Infrastruktur, um zu verhindern, dass böswillige Angreifer Zugang erhalten und die Systeme erneut kompromittieren können.

Was ist Incident Management nach ITIL?

Die Reaktion auf Sicherheits-Incidents ist ein spezifischer Prozess innerhalb des umfassenden Incident Response Managements. Gemäß der ITIL (Information Technology Infrastructure Library) befasst sich das Incident Management mit jeder „ungeplanten Störung eines IT-Service oder der Minderung der Qualität eines IT-Service“. Störungen bzw. Incidents können durch menschliches oder technisches Versagen, Sicherheitsverstöße oder verschiedene andere Ereignisse hervorgerufen werden. Ziel des Incident Managements ist es, die Ursache eines Vorfalls zu identifizieren, seine Auswirkungen und seine Dringlichkeit zu kennen und eine Reaktion festzulegen, um den normalen Betrieb so schnell wie möglich wiederherzustellen.

Wie hängt die Security Incident Response mit dem Incident Management zusammen?

Bei der Security Incident Response handelt es sich um einen ähnlichen Prozess wie beim Incident Management, der jedoch speziell auf Sicherheits-Incidents angewendet wird. Ein Security Incident kann ein versuchter Einbruch, ein Richtlinienverstoß, eine Malware-Infektion oder ein anderes Event sein, das eine Bedrohung für die Computersicherheit darstellt. Wenn eine Organisation einen Sicherheits-Incident feststellt, bewertet das Incident-Response-Team – zuweilen auch als CSIRT (Computer Security Incident Response Team) bezeichnet – den Umfang, legt die notwendigen Schritte zur Behebung fest und führt sie durch. Eine solide Behebung von Sicherheitsvorfällen ist unerlässlich, um Schäden und Verbindlichkeiten, die aus Sicherheits-Incidents resultieren, zu verhindern oder zu mindern.

Welche Phasen weist der Lebenszyklus einer Incident Response auf?

Das National Institute of Standards and Technology (NIST) beschreibt vier Phasen im Lebenszyklus einer Incident Response:

1. Vorbereitung: Die erste Phase soll Unternehmen dabei helfen, die Risiken für ihre Systeme und Daten zu ermitteln, Strategien für das Problem-Management zu skizzieren und Mechanismen für den Umgang mit Sicherheits-Incidents einzurichten. Dies kann die Durchführung einer formalen Risikobewertung oder die Implementierung von Tools und Prozessen zur Analyse und Eindämmung von Vorfällen sein. Aber auch die Priorisierung von Bedrohungen, die Bildung und Schulung eines Incident-Response-Teams und die Erstellung eines Incident Response-Plans (IRP) in Übereinstimmung mit den NIST-Lifecycle-Richtlinien können Teil des Incident Response Managements sein.

2. Erkennung und Analyse: In dieser Phase richtet die Service Operations-Abteilung Systeme zur proaktiven Überwachung, Erkennung, Priorisierung und Analyse von Vorfällen und Incidents mit hoher Priorität ein. Mit dem Ziel, alle unregelmäßigen und verdächtigen Bedrohungen oder Aktivitäten in der Netzwerkumgebung zu erkennen, die den Arbeitsablauf stören könnten. Erkennung und Analyse von Incidents bzw. Incedents erfolgen in der Regel durch eine Kombination aus manuellen Untersuchungen und Sicherheitstools, die Sicherheitsprozesse automatisieren. Durch Automatisierung und eine effektive Ausführung kann in dieser Phase oft die Ausbreitung des Incidents minimiert werden, sodass geringere Auswirkungen spürbar sind.

3. Eindämmung, Beseitigung und Wiederherstellung: Die dritte Phase befasst sich mit der Behebung von Security Incidents. Die Eindämmung zielt darauf ab, weiteren Schaden infolge eines Inciedents zu verhindern. Malware-Vorfälle lassen sich beispielsweise stoppen, indem der betroffene Server vom Netzwerk getrennt wird und indem Firewall-Regeln zum Blockieren des Angreifers implementiert werden. Sicherheitsadministratoren, Support-Mitarbeiter oder Incident Manager entfernen die Bedrohung am Ort des Geschehens, indem sie die Malware vom infizierten Server beseitigen und sicherstellen, dass sie nirgendwo anders im System vorhanden ist. Schließlich versetzen die Support-Mitarbeiter das System in den Zustand vor der Malware-Infektion zurück und stellen die Servicequalität wieder her, indem sie Anwendungen neu laden oder Daten aus Sicherungen wiederherstellen.

4. Aktivitäten nach dem Vorfall: Phase vier umfasst Schritte, um zu verhindern, dass sich ähnliche Incidents wiederholen. Anhand der aus dem Incident und den Post Mortem Besprechungen gesammelten Daten ermittelt das Unternehmen, wie es zu dem Incident gekommen ist, welche Präventivmaßnahmen verstärkt oder neu eingeführt werden müssen, wie die Überwachungs- und Benachrichtigungsprozesse verbessert werden können und wie Helpdesk- und Service-Anfragen, Abhilfe- und Wiederherstellungsprozesse optimiert werden können. In dieser Phase müssen Sie sich außerdem mit Fragen der Einhaltung von Gesetzen und Compliance-Vorschriften befassen.

Insgesamt basiert das Konzept der vier Phasen auf einer fundierten Wissensbasis. Die Wirksamkeit von Phase drei hängt stark vom Erfolg der Phasen eins und zwei ab. Wenn das Incident Management optimalen Schutz bieten soll und Sie die Widerherstellung von IT-Services im Unternehmen gewährleisten wollen, müssen alle vier Phasen zusammen erfolgreich implementiert werden.

Wie lässt sich ein moderner Security-Incident-Response-Plan erstellen?

Eine effektive Reaktion auf Sicherheits-Incidents hängt davon ab, dass eine entsprechende Strategie für ein wirksames Incident Response Management etabliert wurde, bevor ein Incident überhaupt eintritt. Der ISO/IEC-Standard 27035 skizziert einen fünfteiligen Prozess für das Incident Response-Management:

1. Vorbereiten auf den Umgang mit Incidents.

2. Identifizieren und Melden potenzieller Security Incidents.

3. Bewerten der Incidents und Entscheidung über die einzuleitenden Maßnahmen.

4. Reagieren auf Incidents durch ihre Eindämmung, Untersuchung und Behebung.

5. Dokumentieren der wichtigsten Erkenntnisse und Lehren aus jedem Incident.

Jede Organisation führt diesen Plan auf ihre eigene Weise aus. Allerdings gibt es eine Reihe von Best Practices, die dabei helfen können, die Reaktion auf Sicherheits-Incidents an die Bedürfnisse Ihres Unternehmens anzupassen:

• Bestandsaufnahme aller Assets. Bestimmen Sie, welche Systeme und Daten für Ihre Geschäftstätigkeit am wichtigsten sind, und legen Sie die Reihenfolge fest, in der diese nach einem Security Incident untersucht und wiederhergestellt werden müssen.
• Zusammenstellen eines Security Incident Response-Teams. Weisen Sie den Teammitgliedern Rollen und Zuständigkeiten zu, und achten Sie darauf, Vertreter von Abteilungen außerhalb der IT mit einzubinden, wie etwa aus der Finanz-, der operativen und der Rechtsabteilung, damit sie mit den entsprechenden Personen während eines Sicherheitsvorfalls sprechen können.
• Suche nach Sicherheitshinweisen. Definieren Sie zunächst, was für Ihr Unternehmen ein Security Incident ist, damit Sie wissen, worauf Sie achten müssen. Entwickeln Sie dann Richtlinien dafür, wie sie erkannt und gemeldet werden.
• Erstellen eines Aktionsplans für Security Incidents. Dieser sollte, ausgehend von der Bedrohung bzw. vom jeweiligen Incident, eine Liste aller relevanten Aufgaben und der für sie zuständigen Personen enthalten. Testen Sie den Plan, um seine Wirksamkeit zu ermitteln, und arbeiten Sie ihn bei Bedarf weiter aus.
• Bewertung der Reaktion Ihres Teams. Indem Sie die Erfolge und Misserfolge einer Reaktion hinsichtlich der Servicebereitstellung analysieren, können Sie den Plan für den nächsten Incident verbessern.

Wie werden Bedrohungen bewertet, und wie wird die angemessene Reaktionsebene ermittelt?

Die Bewertung von Bedrohungen und die Reaktion auf kritische Incidents ist von Unternehmen zu Unternehmen unterschiedlich. Es gibt jedoch eine Reihe von Best Practices für die Kategorisierung und Priorisierung von Incidents, die einen Rahmen für einen effektiven und effizienten Prozess innerhalb des Incident Response Management setzen können:

• Identifizieren: Nachdem ein Incident bestätigt wurde, sollten Sie damit beginnen, Beweise zu sammeln. Dazu gehört die Analyse von Logdateien und anderen Datenquellen, um beschädigte oder infizierte Endpunkte zu identifizieren.
• Untersuchen: Sobald Sie alle Beweise zu einem Incident gesammelt haben, können Sie sie zusammensetzen, um sich ein Bild von dem Weg zu machen, den der Angreifer genommen hat. Wenn Sie dem Verlauf des Incidents folgen, können Sie auch das Ziel des Angreifers ermitteln.
• Beheben: Die Visualisierung des Angriffspfads ermöglicht es Ihnen, die geschäftskritischsten Ziele zu identifizieren und Ihre Reaktionen entsprechend zu priorisieren. Sie können die Malware mithilfe der während der Priorisierungsphase gesammelten Informationen entfernen und die infizierten Systeme in der Reihenfolge der Prioritäten für Ihren Geschäftsbetrieb wiederherstellen.

Tools für Cybersicherheit können den Bewertungsprozess unterstützen und ihn sogar effektiver machen. Automatisierung und Orchestrierung können Sicherheitsteams bzw. Incident Manager von der zeitaufwändigen Datenanalyse und -erfassung entlasten, sodass sie sich auf die Untersuchung und Behebung kritischer Vorfälle und Incidents fokussieren können.

Welche Rolle spielt DevOps für das Incident Management?

DevOps unterstützt das Sicherheits-Monitoring in Softwareanwendungen und der Entwicklungsumgebung mithilfe des Incident Response Managements. Während ITIL das Incident Management für ITSM mit Informationen versorgt, gibt es keinen offiziellen Leitfaden für DevOps-Teams. Vielmehr basiert das Incident Management in diesem Zusammenhang auf den DevOps-Kernprinzipien des Überwindens von organisatorischen Hindernissen, der Verbesserung der Zusammenarbeit und Transparenz sowie der Fokussierung von schlanken Prozessen. Dieser Vorgang lässt sich in wenigen Schritten zusammenfassen:

Erkennung: DevOps-Incident-Response-Teams identifizieren gemeinsam Systemschwachstellen und planen Reaktionen auf potenzielle Incidents. Darüber hinaus richten die Incident-Manager verschiedene Monitoring-Tools und Benachrichtigungssysteme ein und pflegen Runbooks, in denen beschrieben wird, was zu tun ist, wenn ein Incident festgestellt wird.

Reaktion: Die meisten DevOps-Incident-Management-Teams erhalten ihre Informationen von den Monitoring-Tools, bewerten den Schweregrad und die Auswirkungen des Incidents und folgen dem Runbook, um das Problem über die entsprechenden Kommunikationskanäle an die richtigen Ansprechpartner zu eskalieren.

Behebung: Der Incident-Manager arbeitet mit den entsprechenden Teams zusammen, um das Problem zu beheben, Systeme und Daten wiederherzustellen und die App wieder in den Normalbetrieb zu bringen.

Analyse:In dieser „Abschlussphase“ kommt das Incident-Management-Team zusammen, um die gewonnenen Erkenntnisse in einer „Überprüfung nach dem Incident ohne Schuldzuweisung“ (blameless post-incident review) auszutauschen. Das Ziel ist hierbei, die Systeme zu verbessern und zu verhindern, dass sich ähnliche Incidents wiederholen.

Bereitschaft: Die Incident-Management-Teams bewerten ihre Bereitschaft für den nächsten Incident und wenden dabei an, was sie in der Überprüfung nach dem Incident ohne Schuldzuweisung gelernt haben. Um ihre Monitoring- und Benachrichtungs-Tools anzupassen, ihre Runbook-Prozesse und Team-Verantwortlichkeiten zu aktualisieren, mögliche Workarounds zu diskutieren und Korrekturen für das behobene Problem bzw. den festgestellten Incident in der Entwicklungspipeline dauerhaft zu implementieren.

Was ist eine Überprüfung nach einem Incident ohne Schuldzuweisung?

Die Überprüfungen nach einem Incident ohne Schuldzuweisung sind ein wichtiger Bestandteil des Incident-Lebenszyklus bzw. ein wichtiger Vorgang im Rahmen des Incident Response Managements. DevOps-Teams benötigen eine offene Analyse ihres Incident-Response-Prozesses, um ihre betriebliche Effizienz kontinuierlich zu verbessern. Die Überprüfung nach einem Incident ohne Schuldzuweisung ermöglicht diese Analyse, indem sowohl die technischen als auch die menschlichen Unzulänglichkeiten ihrer Reaktionsbemühungen betrachtet werden.

In einer Überprüfung nach einem Incident ohne Schuldzuweisung kommen die Mitglieder des Incident-Response-Teams und andere, die an dem Vorfall beteiligt oder davon betroffen waren, zusammen, um einen Incident besser zu verstehen und um zu verhindern, dass sich der Vorfall wiederholt. Die Überprüfung dient dazu, Tools und Prozesse zu ermitteln, die verbessert werden können, und nicht dazu, Schuld zuzuweisen. Dies ermöglicht es nicht nur den On-Call-Mitarbeitern bzw.Incident Managern, während eines Incidents ohne Zögern zu handeln, sondern führt auch zu innovativeren Ideen und besseren Anwendungen.

Welche Techniken gibt es für das Incident Response Management bei größeren Sicherheitsvorfällen innerhalb von Systemen?

Ein vorbereiteter Angriffsplan im Rahmen eines erfolgreich implementierten Incident Management sind der beste Weg, um die Belastungen und die Ungewissheit eines größeren Incidents durchzustehen. ITIL bietet zwar einen detaillierten Major Incident Management Guide, aber auch die folgenden Schritte stellen einen allgemeinen Rahmen für die Herangehensweise an jeden Incident dar:

• Alle Fakten sammeln. Bevor Sie handeln, ist es wichtig, die Art und den Umfang des Incident zu kennen. In jedem Fall müssen Sie schnell feststellen, welche Services und welche Benutzer betroffen sind, was die potenziellen Auswirkungen auf das Geschäft sind, wer sich mit dem Problem befasst und benachrichtigt werden muss und ob das Problem Compliance- oder rechtliche Bedenken aufwirft.
• Mit den richtigen Personen kommunizieren. Im Falle eines Incidents benötigen Sie eine Liste mit den Kontaktdaten der zuständigen Personen. Über die Mitglieder des Incident-Management-Teams hinaus sollten Sie auch mit anderen Beteiligten im gesamten Unternehmen, der Benutzerbasis des betroffenen Service und allen zuständigen Aufsichtsbehörden kommunizieren.
• Einen Aktionsplan entwickeln. Die wichtigsten Teams müssen auf der Grundlage der gesammelten Fakten die optimale Reaktion auf den Vorfall festlegen und umsetzen. Der Incident-Manager muss alle Teamaktivitäten koordinieren und daran arbeiten, den Reaktionsplan effizient und den Vorgaben des Incident Response Managements entsprechend umzusetzen.
• Alle Beteiligten auf dem Laufenden halten. Während die Teams an dem Problem arbeiten, muss sich der Incident-Manager regelmäßig nach dem Stand der Dinge erkundigen, um sicherzustellen, dass alle Fristen eingehalten werden. Gleichzeitig muss er andere Beteiligte proaktiv über den Fortschritt informieren.
• Genehmigungen für Notfalländerungen anfordern. Sobald Sie eine Lösung für den Incident gefunden haben, führen Sie Tests durch, um sicherzustellen, dass sie funktioniert. Bei Bedarf muss der Incident-Manager den Prozess der Notfalländerung einleiten, damit die Reaktionsteams die Korrektur schnell implementieren können.
• Den Beteiligten mitteilen, dass das Problem behoben ist. Sobald die Korrekturmaßnahme ermittelt und überprüft wurde, überprüft eine kleine Benutzerkontrollgruppe, ob der Service ordnungsgemäß funktioniert. Das Incident-Response-Team benachrichtigt anschließend alle darüber, dass der Incident behoben wurde.
• Eine kurze Überprüfung durchführen. Nehmen Sie sich die Zeit, mit den Teams kurz zu rekapitulieren, welche Maßnahmen sie ergriffen und welche Lehren sie daraus gezogen haben. Idealerweise solange das Ereignis noch bei allen Beteiligten präsent ist. Planen Sie eine Überprüfung nach dem Incident ohne Schuldzuweisung für eine tiefergehende Bewertung, sobald alles wieder reibungslos funktioniert.

Laut einer ITIC-Umfrage zu den stündlichen Kosten von Ausfallzeiten aus dem Jahr 2020 gaben 40 % der befragten Unternehmen an, dass eine einzige Stunde Ausfallzeit zwischen 1 Mio. und mehr als 50 Mio. USD kosten kann – ohne Rechtskosten, Bußgelder oder Compliance-Strafen.

Daten legen nahe, dass jede Art von Unterbrechung der Arbeitsproduktivität – einschließlich Ausfallzeiten – massive Auswirkungen haben kann. Eine UC Irvine-Studie zeigt, dass es etwa 23 Minuten dauert, bis man sich nach einer Unterbrechung der Arbeitsproduktivität wieder konzentrieren kann. Die tatsächlichen Kosten im Zusammenhang mit Ausfällen aufgrund eines Incidents unterscheiden sich zwar von Unternehmen zu Unternehmen, aber es ist allgemein bekannt, dass ein einziger Systemausfall ein Unternehmen Millionen von Dollar kosten kann – und das, ohne die damit verbundenen Kosten aufgrund verpasster Geschäftschancen, einer geringeren Produktivität und eines geschädigten Rufs mit einzubeziehen.

Systemausfälle aufgrund von Incidents sind für jedes Unternehmen unvermeidlich, aber ihre Häufigkeit und ihre Auswirkungen können durch den Wechsel des Incident Managements von einem reaktiven zu einem proaktiven Ansatz beim Incident Response Management deutlich reduziert werden.

Was bedeutet MTTD/MTTR?

MTTD steht für „Mean Time To Detect“ oder „Mean Time To Discover“ (durchschnittliche Zeit bis zur Entdeckung), und MTTR steht für „Mean Time To Respond“ (durchschnittliche Zeit bis zur Reaktion). Beides sind Kennzahlen, mit denen die Effektivität der Prozesse des Incident Managements eines Teams quantifiziert werden.

MTTD: Dabei handelt es sich um einen wichtigen Leistungsindikator für das Incident Response Management. Mit ihm wird gemessen, wie lange ein Problem bzw. Incident besteht, bevor die Organisation oder die zuständigen Stellen auf das Problem aufmerksam werden. Eine kürzere MTTD weist darauf hin, dass Unternehmen weniger lange unter Ausfällen und anderen Störungen leiden als bei einer längeren MTTD. Außerdem gilt: Je niedriger die MTTD, desto weniger Kosten entstehen einer Organisation aufgrund von Ausfallzeiten. Unternehmen stellen Probleme entweder durch Endbenutzer fest, die einen Ausfall an den Service Desk melden, oder durch die verschiedenen, im Rahmen des Incident Managements zum Einsatz kommenden Monitoring- und Management-Tools.

MTTR: Steht für die durchschnittliche Zeit, die benötigt wird, um eine betroffene Komponente oder ein betroffenes System zu reparieren und wieder funktionsfähig zu machen. Mit ihr wird das Wartungslevel der Ausrüstung eines Unternehmens sowie die Effizienz des Teams bei der Lösung von IT-Incidents gemessen. Die MTTR beginnt in dem Moment, in dem ein Fehler oder Incident festgestellt wird. Sie umfasst die Diagnosezeit, die Reparaturzeit, die Tests und alle anderen Aktivitäten, die anfallen, bis der Service wieder normal funktioniert. Die Kombination aus MTTR und MTTD umfasst die Dauer eines Cyber-Incidents.

Die MTTR ist wichtig, weil sie ein starker Indikator für die Kosten von IT-Incidents ist. Je höher die MTTR eines IT-Teams ist, desto größer ist das Risiko, dass das Unternehmen bei IT-Störungen erhebliche Ausfallzeiten erleidet, die zu Geschäftsunterbrechungen, einer geringen Kundenzufriedenheit und zu Umsatzverlusten führen können.

Was sind Beispiele für Incident-Management-Tools, die Sie implementieren können, um Schutzmaßnahmen zu ergreifen?

Eine Incident Response Management Plattform ist die erste Verteidigungslinie bei einem Incident. Sie bietet wichtige Unterstützung in jeder Phase des Incident-Management-Prozesses. Sie beinhaltet Funktionen wie die Identifizierung von Vorfällen, das Logging von Incidents, die Diagnose und Untersuchung, die Eskalation und die Lösung von Problemen. Es stehen zahlreiche Plattformen zur Verfügung. Welche Plattform letztendlich für Ihr Incident Management geeignet ist, hängt weitgehend von der Größe und dem Umfang Ihres Unternehmens, den Compliance-Anforderungen und Budgetaspekten ab.

Wie beginnen Sie mit der Implementierung einer effektiven Incident Response Management Strategie?

Der erste Schritt zur Implementierung eines effektiven Incident Management Plans besteht in der Gründung eines Incident-Response-Teams, das aus internen oder externen Mitarbeitern oder einer Mischung aus beiden besteht. Danach müssen Sie entscheiden, was für Ihr Unternehmen ein Incident ist, und eine Analyse der Bedrohungslage durchführen, indem Sie die potenziellen Bedrohungen, Risiken und den Ausfall der Infrastruktur bewerten.

Anschließend können Sie Reaktionspläne für verschiedene Szenarien entwerfen, Mitarbeiter bzw. Incident Manager schulen und anhand von simulierten Verstößen üben, um Ihre Incident Response kontinuierlich zu verbessern.

Mit der wachsenden Komplexität von IT-Umgebungen und der zunehmenden Zahl und Raffinesse von Bedrohungen sind Unternehmen mit einem noch nie dagewesenen Risiko konfrontiert. Mit einem effektiven Incident Response Management können Sie dieses Risiko mindern, indem Sie Incidents schneller erkennen und beheben. Während Ausfälle und andere Vorfälle für jedes Unternehmen unvermeidlich sind, ist Incident Management der effektivste Weg, eine sofortige Reaktion einzuleiten und kostspielige Ausfallzeiten zu verhindern, die den Ruf und das Geschäftsergebnis Ihres Unternehmens gefährden können.