Security-Incident

Informationssicherheit dient dem Schutz vor Gefahren bzw. Bedrohungen, der Vermeidung von wirtschaftlichen Schäden und der Minimierung von Risiken. Dabei werden drei primäre Schutzziele verfolgt:

• Vertraulichkeit: Daten dürfen lediglich von autorisierten Benutzern gelesen werden.
• Integrität: Daten dürfen nicht unbemerkt verändert werden.
• Verfügbarkeit: Der Zugriff auf Daten/Systeme muss innerhalb vereinbarter Parameter gewährleistet sein.

Werden diese Schutzziele bedroht oder verletzt, dann wird bei items ein entsprechender Prozess zur Behandlung der Situation ausgelöst.  Wir unterscheiden dabei zwei „Stufen“:

• Sicherheitsrelevantes Ereignis bzw. Security-Event
  Als sicherheitsrelevantes Ereignis bzw. englisch Security-Event wird ein Ereignis bezeichnet, das sich auf die Informationssicherheit auswirkt und die Vertraulichkeit, Integrität, Authentizität oder Verfügbarkeit eines Systems beeinträchtigen. Beispiele: Mehrfache fehlgeschlagene Anmeldeversuche eines Benutzers an einem System, Detektion einer Schadsoftware, Missachtung einer Sicherheitsrichtlinie
• Sicherheitsvorfall bzw. Security-Incident
  Als Sicherheitsvorfall bzw. englisch Security-Incident wird ein unerwünschtes Ereignis bezeichnet, das Auswirkungen auf die Informationssicherheit hat und in der Folge große Schäden nach sich ziehen kann. Typische Folgen von Sicherheitsvorfällen können die Ausspähung, Manipulation oder Zerstörung von Daten sein. Die Einstufung als Security-Incident erfolgt durch das Security Incident Response Team bei items. 

Ein Security-Event stellt sozusagen die Vorstufe zum Security-Incident dar.  Auch Sie als Kunde können ein Security-Event bzw. einen potenziellen Security-Incident melden.  Dies können Sie entweder über unsere telefonische Hotline oder als IT-Koordinator auch selbständig über unser Serviceportal erledigen.

Anlass für einen Security-Incident sind alle Ereignisse oder Begebenheiten, die entweder

• den Verlust der Integrität, Vertraulichkeit oder Verfügbarkeit von Daten und Informationen,
• eine Beeinträchtigung der physischen Sicherheit der IT-Infrastruktur oder
• Personenschäden

verursacht haben oder verursachen könnten. Um diese abstrakten Kriterien etwas zu illustrieren, seien folgende Beispiele für sicherheitsrelevante Vorfälle genannt:

• die Infektion eines oder mehrerer Systeme durch schadhafte Software, wie beispielsweise Viren, Würmer oder trojanische Pferde
• der Verdacht auf unberechtigten Zugang zu Systemen, z. B. durch gestohlene Zugangsdaten
• der Verdacht auf Missbrauch von Diensten oder Ressourcen, z. B. zum Verbreiten unzulässiger Inhalte
• ein Denial-of-Service-Angriff (DoS-Angriff), durch den die Verfügbarkeit von Diensten eingeschränkt wird
• ein Verdacht auf Spionage, z. B. hinsichtlich Geschäftsgeheimnissen 
• der Verlust von IT-Hardware, z. B. wenn ein Laptop oder ein Handy verloren oder gestohlen wird, oder nach einem Einbruch in Geschäftsräume

Diese Beispiele sind selbstverständlich nicht abschließend. Grundsätzlich gilt, dass jede Störung, die sich wesentlich auf die Schutzziele Vertraulichkeit, Integrität und Verfügbarkeit auswirkt, als Security-Incident zu bewerten ist.

items hat eine Reihe von Schutzmaßnahmen implementiert, die das Risiko des Eintretens von Sicherheitsvorfällen minimieren sollen. Die Erfahrung zeigt, dass es keinen hundertprozentigen Schutz vor Angriffen auf die Verfügbarkeit, die Vertraulichkeit oder die Integrität von Daten geben kann. Daher werden auch bei der items sicherheitsrelevante Störungen auftreten. Wichtig ist es, die entsprechenden Sicherheitsvorfälle als solche zu klassifizieren und das weitere Vorgehen dahingehend zu steuern. 

In den meisten Fällen wird items diese Vorfälle selbst erkennen, insbesondere wenn es sich um Infrastruktur-Komponenten oder von mehreren Kunden genutzte Systeme handelt. Dann greifen die definierten Prozesse und Kriterien, mit denen items Vorfälle als Security-Event oder Security-Incident einstuft und bearbeitet. 

In vielen weiteren Fällen muss allerdings der Kunde den Vorfall melden, insbesondere wenn es sich um Client-Hardware oder nicht durch items betreute Anwendungen handelt. In diesen Fällen greifen natürlich auch items-Prozesse, aber die Kriterien auf Kundenseite müssen im Vorfeld durch die Kunden festgelegt werden. Es gibt dabei keine eindeutige Vorschrift, weswegen die bewusste Ausgestaltung des Themas auf Kundenseite sehr wichtig ist.  items steht hierbei gerne beratend mit einschlägigem Fachwissen zur Seite.