Data Insider

Was ist Incident Management?

Incident Management ist der Prozess, bei dem IT-Incidents, die die Services eines Unternehmens bedrohen oder stören, erkannt und behoben werden. Als Bestandteil des IT-Service-Managements (ITSM) zielt das Incident Management darauf ab, den Betrieb von Services aufrechtzuerhalten oder – sofern sie offline genommen werden – so schnell wie möglich wiederherzustellen und dabei die Auswirkungen auf das Unternehmen zu minimieren.

Laut der Information Technology Infrastructure Library (ITIL) ist ein „Incident“ eine „ungeplante Störung oder drohende Störung eines IT-Service“. Nach dieser weit gefassten Beschreibung würde alles, von einer Verschlechterung der Netzwerkqualität über mangelnden Speicherplatz bis hin zu einem Cyberangriff, als Incident gelten. Die Erkennung von sicherheitsrelevanten Vorfällen und die Reaktion darauf wird als Security Incident Management bezeichnet.

Es gibt zahlreiche Möglichkeiten, das Incident Management anzugehen. Richtlinien, Tools und SLAs (Service-Level Agreements) unterscheiden sich von Unternehmen zu Unternehmen. Im Allgemeinen versuchen IT-Teams, Incidents durch regelmäßige Software-Updates, Event-Monitoring und andere Methoden zu verhindern und haben einen Incident Response-Plan etabliert, um Incidents schnell zu beheben und ihre Ursache zu ermitteln, sodass sie sich in Zukunft verhindern lassen.

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

In den folgenden Abschnitten schauen wir uns die verschiedenen Phasen und Best Practices des Incident Managements an und erfahren, wie es Unternehmen dabei helfen kann, schädliche Ausfallzeiten zu reduzieren.

Security Incident Response

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 mit einer Kombination aus Untersuchung und Analyse – entweder computergestützt oder durch Mitarbeiter – erkannt, analysiert und behoben werden, um negative Auswirkungen auf das Unternehmen zu minimieren. Der Prozess beginnt in der Regel damit, dass das Sicherheitssystem das Incident-Response-Team über einen aufgetretenen Incident informiert. Das Response-Team untersucht und analysiert den Incident, um seine Echtheit und seinen Umfang zu bestimmen, seine Auswirkungen zu bewerten und einen Plan zur Schadensbegrenzung zu entwickeln.

Ein Security Incident kann alles sein – von einer aktiven Bedrohung bis hin zu einem Datensicherheitsverstoß. Ferner kann er innerhalb oder außerhalb eines Unternehmens entstehen. Ein Mitarbeiter, der einen Computer an seinem Arbeitsplatz nutzt, um auf eine Glücksspiel-Website zuzugreifen, ein Lieferant, der Daten herunterlädt, für die er keine Berechtigung hat, und ein Malware-Angriff sind Beispiele für Security Incidents.

Neben dem Troubleshooting beinhaltet die Reaktion auf Sicherheits-Incidents auch das präventive Reagieren und das Implementieren von Maßnahmen, mit denen zukünftige Angriffe 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.

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

Die Reaktion auf Sicherheits-Incidents ist ein spezifischer Prozess innerhalb des umfassenden Incident Managements. Gemäß der ITIL-Definition befasst sich das Incident Management mit jeder „ungeplanten Störung eines IT-Service oder der Minderung der Qualität eines IT-Service“. Störungen können durch menschliches Versagen, 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.

Die Security Incident Response ist ein ähnlicher Prozess, 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 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, die Implementierung von Tools und Prozessen zur Analyse und Eindämmung von Vorfällen, 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 umfassen.

2. Erkennung und Analyse: In dieser Phase richtet die Service Operations-Abteilung Systeme zur proaktiven Überwachung, Erkennung, Priorisierung und Analyse von Vorfällen 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 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 Vorfalls 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 oder Support-Mitarbeiter entfernen die Bedrohung am Ort des Geschehens, indem sie die Malware vom infizierten Server entfernen 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 Vorfälle 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 sie optimalen Schutz bieten und den Service schnell wiederherstellen wollen, müssen Unternehmen alle vier Phasen zusammen implementieren.

Incident Response Life Cycle

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

Eine effektive Reaktion auf Sicherheits-Incidents hängt davon ab, dass eine Strategie etabliert wurde, bevor ein Incident 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, 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 darauf ist von Unternehmen zu Unternehmen unterschiedlich. Es gibt jedoch eine Reihe von Best Practices für die Kategorisierung und Priorisierung, die einen Rahmen für einen effektiven und effizienten Prozess 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 von der zeitaufwändigen Datenanalyse und -erfassung entlasten, sodass sie sich auf die Untersuchung und Behebung kritischer Vorfälle konzentrieren können.

Incident Management-Systeme

Welche Rolle spielt DevOps für das Incident Management?

DevOps unterstützt das Sicherheits-Monitoring in Softwareanwendungen und der Entwicklungsumgebung mithilfe des Incident 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 sie Monitoring-Tools und Benachrichtigungssysteme ein und pflegen Runbooks, in denen beschrieben wird, was zu tun ist, wenn ein Vorfall 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 Vorfälle 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 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. DevOps-Teams benötigen eine offene Analyse ihres Incident Response-Prozesses, um ihre betriebliche Effizienz kontinuierlich zu verbessern. Die Überprüfung nach einem Vorfall 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 ein Ereignis besser zu verstehen und um zu verhindern, dass es sich 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, 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 Management von größeren Incidents innerhalb von Systemen?

Ein vorbereiteter Angriffsplan ist der beste Weg, um die Belastungen und die Ungewissheit eines größeren Incidents durchzustehen. ITIL bietet einen detaillierten Major Incident Management Guide, aber 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 Problems 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 Reaktionsteams 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 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, 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.

Risiken durch Ausfallzeiten

Welche Kosten verursacht ein Systemausfall?

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 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 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 reduziert werden.

Risks of Downtime

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 Incident Management-Prozesse eines Teams quantifiziert werden.

Die MTTD ist ein wichtiger Leistungsindikator für das Incident Management. Mit ihm wird gemessen, wie lange ein Problem 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 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 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.

Erste Schritte

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

Eine Incident 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, die Diagnose und Untersuchung, die Eskalation und die Lösung von Problemen. Es stehen zahlreiche Plattformen zur Verfügung. Welche Plattform letztendlich 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 eines effektiven Incident Management-Plans?

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 schulen und anhand von simulierten Verstößen üben, um Ihre Incident Response kontinuierlich zu verbessern.

Fazit: Effektives Incident Management ist für jedes Unternehmen unerlässlich

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 dem Incident 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.