<Firmenname>

SLA für SOC

Bereitgestellt von <Name des Outsourcing-Partners oder Name der internen Abteilung>

<im gesamten Dokument <text> weist auf etwas hin, das Sie in dieser Vorlage ändern müssen.
Aber zögern Sie nicht, etwas zu ändern.
Inhaltsverzeichnis (Entwurf)
1 Dokumentinformationen und -historie................................................ ............................. 3
1.1

Versionsgeschichte................................................ ................................................. ......................

............... 3
1.2

Verteilung................................................. ................................................. ....................................

..... 3
1.3

Dokumentenstruktur................................................. ................................................. ....................

........ 3
3 Einführung................................................. ................................................. ............ 4
4 Allgemein................................................. ................................................. .................... 4
4.1 Zweck dieses
Dokuments................................................ ................................................. ...................... 4
4.2 Ziele für dieses
Dokument................................................ ................................................. ........................ 4
4.3 Verpflichtung des Managements zur
Informationssicherheit................................................ ................................. 4
4.4 Umfang und
Zielgruppe................................................ ................................................. ...................... 5
5 Verantwortung und formale Organisation................................................ ...................... 5
5.1 Widersprüchliche Aufgaben und
Verantwortlichkeiten................................................ ................................................. ..... 6
6 Vorfallmanagement................................................. ................................................. 7
6.1

Vorfallmanagement................................................. ................................................. .....................

.... 7
7 Modellierung von
Unternehmensbedrohungen................................................ ......................................... 7
8 Risikomanagement............................................... ........................................ 7
8.1

Anwendungssicherheit................................................. ................................................. ................

............ 8
8.2
Datenklassifizierung................................................ ................................................. .....................
............ 8
8.3

System-/Geschäftsanwendungs-/Infrastrukturpriorisierung............................................ ................
...... 8
8.4 Geschäftskontinuitäts- und
Geschäftswiederherstellungsplanung............................................ .................................... 8
8.5 Ständige
Verbesserung................................................ ................................................. .................... 8
9 Outsourcing und Lieferantenmanagement................................................ ........................
9
9.1

Politik................................................. ................................................. ...........................................

...... . 9
9.2

Besonderheiten................................................. ................................................. ...........................

...................... 9
9.2.1 Outsourcing-Aktivitäten, die nicht wesentlich
sind................................................. ................................. 9
9.2.2 Wesentliche Outsourcing-
Aktivitäten................................................ .................................... 9
9.2.3 Auswahl des Outsourcing-Partners und
Vertragsverhandlungen................................................ ......... 9
9.2.4 Die Outsourcing-
Entscheidung................................................ ................................................. ............ 9
10 Ermächtigung................................................. ................................................. .... 10
11 Definitionen und Abkürzungen............................................... ................................. 10
Aktuelles Inhaltsverzeichnis
1 Dokumentinformationen und -verlauf 5
1.1 Versionsgeschichte 5
1.2 Vertrieb 5
2. Einführung 6
3 Allgemeines 6
3.1 Zweck dieses Dokuments 6
4 Verantwortung und formale Organisation 6
4.1 Widersprüchliche Aufgaben und Verantwortlichkeiten 7
5 Vom SOC zu erbringende Leistungen 7
5.1 Protokollüberwachung über SIEM 8
5.2 Entwicklung und Wartung von SIEM-Anwendungsfällen mithilfe von Threat
Modeling 9
5.3 Konfiguration und Verwaltung von Sicherheitsgeräten 9
5.4 DDoS-Abwehr 10
5.5 Sicherheitsbewertung – Schwachstellenscan und -bewertung 11
5.6 Konfigurationsmanagement 11
5.7 Änderungsmanagement 12
5.8 Vorfallmanagement 12
5.9 Forensik und Reaktion auf Vorfälle, einschließlich Malware-Umkehrung und -
Analyse 13
6 Umgang mit Fehlern auf SLA-Ebene 14
1 Dokumentinformationen und -verlauf

1.1 Versionsgeschichte

Ausfüh Datum Datum der Änderungen und Dokumentbearbeitungs

rung ändern Genehmigung Beschreibung verfolgung

xx xx.xx.xxxx Noch nicht Entwurfsversion 0.1 <Name>

genehmigt

1.2 Vertrieb
Neue genehmigte Versionen dieses Dokuments müssen an die unten aufgeführten Funktionen
verteilt werden. Es liegt in der Verantwortung des Dokumenteneigentümers, (erneute)
Genehmigungsprozesse einzuleiten, und danach liegt die Verantwortung des <Genehmigers>
darin, die Änderungen am SLA zu genehmigen.

Ständige Mitglieder des <Genehmigungsgremiums>: (<Diese gesamte Tabelle löschen, wenn

sie in einer separaten Richtlinie behandelt wird>)
Funktion

<Unternehmensfunktion 1>

<Unternehmensfunktion 2>

<Unternehmensfunktion x>

…
Angabe von Dritten, an die die Weitergabe genehmigter Versionen dieses Dokuments
genehmigt wurde.
Unternehmen & Funktion

<Drittanbieter und Funktion 1>

<Drittanbieter und Funktion 2>

<Drittanbieter und Funktion x>

2. Einführung
In diesem Dokument werden die Dienste beschrieben, die vom Security Operations Center bei
<Anbieter oder interne Abteilung> für den Namen <Firma> bereitgestellt werden.

3 Allgemeines
3.1 Zweck dieses Dokuments
Der Zweck dieses SLA besteht darin, die zwischen den Parteien vereinbarten Servicelevel
festzulegen.
Das SLA muss beschreiben, welche Leistungen das SLA umfasst, wie diese erbracht werden
müssen und wie die Meldung der Lieferung erfolgen muss.

4 Verantwortung und formale Organisation

Einzelpersonen können bei Bedarf mehr als eine der folgenden Rollen übernehmen.

Die folgenden Rollen müssen innerhalb des Auftragnehmers und Vertragspartners dieses SLA
ernannt werden:
1. Leiter des SOC-Teams.
A. Verantwortlich für die Verwaltung der SOC-Dienste und die Berichterstattung
an den Auftragnehmer
2. SOC-Analysten
 A. Verantwortlich für die Bereitstellung der SOC-Dienste für den Auftragnehmer
3. Incident Manager, beauftragt
A. Kann der SOC-Teamleiter sein. Verwaltet Vorfälle und eskaliert sie bei
Bedarf (wenn eine manuelle Bearbeitung von Vorfällen erforderlich ist).
Verantwortlich für die Kommunikation mit dem beauftragten Incident Manager
4. Incident Manager, Auftragnehmer
A. Verantwortlich für die Kommunikation mit den Vertragspartnern und die
Koordinierung, wenn Vorfälle auftreten, die eine manuelle Bearbeitung
erfordern
5. Vertragsinhaber, vertraglich vereinbart
A. Verantwortlich für den Vertrag beim Vertragspartner,
Dokumenteneigentümer. Verantwortlich für die Organisation regelmäßiger
Statusbesprechungen
6. Vertragsinhaber, Auftragnehmer
A. Verantwortlich für die Überwachung der SOC-Servicebereitstellung und
deren Nachverfolgung. Verantwortlich für die interne Kommunikation des
Status der SOC-Dienste beim Auftragnehmer
7. Change Manager, unter Vertrag
A. Verantwortlich für die Koordinierung der Leistungserbringung in Change-
Management-Situationen sowohl intern als auch mit dem Auftragnehmer
8. Change Manager, Auftragnehmer
A. Verantwortlich für die Kommunikation mit dem Vertragspartner, wenn die
Umsetzung von Änderungen erforderlich ist
9. Vertrag <Genehmigungsstelle>
A. Verantwortlich für das Budget hinter dem Vertrag/SLA

4.1 Widersprüchliche Aufgaben und Verantwortlichkeiten

Eine widersprüchliche Zuweisung von Aufgaben und Verantwortlichkeiten ist nach Möglichkeit
zu vermeiden.

5 Vom SOC zu erbringende Leistungen

<Entfernen Sie alle unten aufgeführten Dienste, die Ihr SOC nicht bereitstellt>

5.1 Protokollüberwachung über SIEM

Die Protokollverwaltung über SIEM umfasst:

· Sicherstellung der Vollständigkeit der Protokolle, die dem SIEM kontinuierlich

hinzugefügt werden
· Sicherstellung der unterbrechungsfreien Hinzufügung von Protokollen zum SIEM,
einschließlich Endpunkt-Agent-Diensten

Der Auftragnehmer muss zunächst die Protokolle angeben, die in die SIEM-Protokollsammlung
aufgenommen werden sollen, und der Auftragnehmer muss die anfängliche Spezifikation
bewerten und auf Mängel hinweisen, um die Vollständigkeit sicherzustellen. In Change-
Management-Situationen muss die Vollständigkeit proaktiv gewahrt bleiben, d. h. sichergestellt
werden, dass die Protokolldateien neu hinzugefügter Systeme auch zum SIEM hinzugefügt
werden.

SLA-Metriken für die Berichterstellung :

Durchschnittliche Anzahl von Tagen zwischen der Inbetriebnahme einer neuen Protokollquelle
(Begriff definiert als: ab dem Datum, an dem der Vertragspartner darüber informiert wurde, dass
eine neue Protokollquelle zur Erfassung aktiv ist) und dem kontinuierlichen Hinzufügen von
Protokolldateien zum SIEM. Die durchschnittliche Anzahl der Tage muss 0 betragen. Neu
hinzugefügte Systeme bergen höhere Risiken, insbesondere wenn sie mit dem Internet
verbunden sind. Die Anzahl muss pro Monat aufgeführt und monatlich per E-Mail gemeldet
werden.

Der Vertragspartner muss die ununterbrochene Hinzufügung von Protokollen zum SIEM
sicherstellen. Dazu gehört auch, sicherzustellen, dass Endpunkt-Protokollweiterleitungsagenten
ausgeführt werden und dass die SIEM-Empfänger empfangsbereit und funktionsfähig sind.

SLA-Metriken für die Berichterstellung

Die Gesamtzahl der Minuten, in denen einzelne Systeme keine Protokolldateien übertragen
haben, Servicefenster nicht inbegriffen.
Die durchschnittliche Anzahl der Minuten ohne Service für alle Geräte.
Die Gesamtzahl der Minuten, in denen das SIEM keine aktiven Protokolldateien empfing.

Die Zahlen müssen pro Monat aufgeführt und monatlich per E-Mail gemeldet werden. Die
durchschnittliche Zeitspanne, in der die Protokolldateierfassung inaktiv ist, muss weniger als 1
Stunde pro Asset und Monat betragen, genehmigte Servicefenster nicht eingerechnet.

5.2 Entwicklung und Wartung von SIEM-

Anwendungsfällen mithilfe von Threat Modeling
Der Auftragnehmer muss eine ausreichende Anzahl von Anwendungsfällen entwickeln und
aufrechterhalten, um Bedrohungen zu erkennen. Die Anwendungsfälle müssen die Erkennung
sowohl von Angriffen von außen als auch von internen Insider-Bedrohungen ermöglichen.

Die Anzahl der Anwendungsfälle muss mindestens <20> für Assets mit Priorität 1 und <10> für
Systeme mit niedrigerer Priorität betragen und die Anwendungsfälle müssen pro Asset-Typ für
eine optimale Bedrohungserkennung optimiert werden. Um sicherzustellen, dass
Anwendungsfälle realistischen Bedrohungsvektoren entsprechen, muss eine
Bedrohungsmodellierung für alle Assets und etablierten Anwendungsfälle durchgeführt und
gepflegt werden, die Bedrohungsmodellen zugeordnet sind. Jedes etablierte Bedrohungsmodell
muss die Anzahl der Anwendungsfälle angeben, die zur Überwachung der Bedrohung
erforderlich sind.

SLA-Metriken für die Berichterstellung

Anzahl der Assets, die nicht über die erforderliche Mindestanzahl an Anwendungsfällen
verfügen
Anzahl der Bedrohungsmodelle insgesamt pro Asset, mit denen nicht die erforderliche Anzahl
an SIEM-Anwendungsfällen verknüpft ist

Die Zahlen müssen pro Monat aufgeführt und monatlich per E-Mail gemeldet werden. Die
Anzahl der Assets der Priorität 1, denen Bedrohungsmodelle mit weniger als der erforderlichen
Anzahl an Anwendungsfällen zugeordnet sind, muss innerhalb eines Monats nach Aktivierung
dieses Assets 0 sein. Die Anzahl der Assets der Priorität 1, denen Bedrohungsmodelle mit
weniger als der erforderlichen Anzahl an Anwendungsfällen zugeordnet sind, muss innerhalb
von 3 Monaten nach Aktivierung dieses Assets 0 sein.

5.3 Konfiguration und Verwaltung von Sicherheitsgeräten

Alle Sicherheitsgeräte müssen korrekt konfiguriert und verwaltet werden. Das beinhaltet:

· Tägliche Überprüfung, ob Geräte oder Anwendungen, die Signaturaktualisierungen

benötigen, diese erhalten, dh IDS-Geräte erhalten neue Signaturen
· Überwachung der Verfügbarkeit neuer Firmware- oder Softwareversionen
· Standardpasswörter und Community-Strings ändern
· Passwörter in Passwortmanagern dokumentieren
· Dokumentieren von Asset-Konfigurationen in der CMDB mit dem vereinbarten
Detaillierungsgrad der Konfigurationselemente.
· Gewährleistung der Aufgabentrennung zwischen Produktionssystemen und Backup-
Systemen, die Backup-Daten speichern

Alle Sicherheitsgeräte müssen eine Erstkonfigurationsüberprüfung bestehen, nachdem der

Auftragnehmer sie konfiguriert hat. Dieses Audit wird vom Auftragnehmer (oder einem vom
Auftragnehmer zu diesem Zweck beauftragten Dritten) durchgeführt und muss innerhalb eines
Monats nach Inbetriebnahme des Geräts durchgeführt werden.

SLA-Metriken für die Berichterstellung

1. Anzahl der monatlich durchgeführten Erstkonfigurationsprüfungen, die angeben, ob

Prüfungen erfolgreich bestanden wurden oder nicht. Die Anzahl der fehlgeschlagenen
Audits muss über einen Zeitraum von 6 Monaten betrachtet weniger als 1 von 3 betragen
2. Anzahl der Tage pro Gerät, in denen keine Signaturaktualisierungen empfangen
wurden. Die Anzahl muss weniger als 1 Tag pro 10 pro Gerät betragen.
3. Anzahl der Assets, für die neue Firmware- oder Softwareversionen, einschließlich
Verfügbarkeitsdatum, vorhanden sind, für die jedoch kein Änderungsantrag vom
Auftragnehmer für die Durchführung dieses Updates gestellt wurde. Die Zahl muss unter 1
von 10 liegen und mangelnde Kenntnis der Verfügbarkeit eines Firmware- oder Software-
Updates muss in diesem Fall im Folgemonat rückwirkend korrigiert werden.

Die Zahlen müssen pro Monat aufgeführt und monatlich per E-Mail gemeldet werden.
Rollierende Zahlen müssen außerdem monatlich per E-Mail gemeldet werden.

5.4 DDoS-Abwehr
Zur bedarfsgesteuerten DDoS-Abwehr:

SLA-Metriken für die Berichterstellung

· Die Anzahl der Minuten pro Angriff von der Erkennung eines Angriffs bis zur aktiven
Abwehr.
· für bedarfsgesteuerte DDoS-Angriffe, deren Aufhebung eine zusätzliche Abwehr
erforderte: Die Anzahl der Minuten pro Angriff von der ersten aktiven Abwehr bis zur
Aktivierung zusätzlicher Abwehr

Für eine stets aktive DDoS-Abwehr:

Für Angriffe, die zu groß sind, um sie zu bewältigen:
· Die Anzahl der Minuten pro Angriff, bis zusätzliche Abwehrmaßnahmen aktiv wurden

Die Zahlen müssen pro Monat aufgelistet und monatlich per E-Mail gemeldet werden, in der
Angriffsdaten, Ein-/Ausschaltzeiten und Ziele aufgeführt sind.

5.5 Sicherheitsbewertung – Schwachstellenscan und -

bewertung
Das Scannen von Schwachstellen muss <täglich|wöchentlich|monatlich> durchgeführt werden
und die Ergebnisse müssen manuell von kompetenten Mitarbeitern bewertet werden. Die
Ergebnisse müssen dem Auftragnehmer <täglich|wöchentlich|monatlich> mit
Folgenabschätzungen und Sanierungsempfehlungen mitgeteilt werden

SLA-Metriken für die Berichterstellung

1. Termine für Schwachstellenscans und zugehörige Berichtstermine. Berichte müssen
weniger als <1|2|3> Tage nach Abschluss eines Scans versendet werden.
2. Die Scans müssen in den vereinbarten Abständen 9 von 10 Mal über einen rollierenden
Berichtszeitraum von 6 Monaten erfolgen.
3. Berichte müssen innerhalb der vereinbarten Anzahl von Tagen fertiggestellt und
versandt werden, durchschnittlich 9 von 10 Mal über rollierende Berichtszeiträume von 6
Monaten
4. Bei kritischen Schwachstellen oder Schwachstellen mit hohem Schweregrad muss eine
manuelle Vorfallbehandlung durchgeführt werden. Die Berichterstattung muss die Anzahl
der identifizierten hohen oder kritischen Schwachstellen, die identifizierten Daten und die
Einleitungsdaten für die manuelle Vorfallbehandlung umfassen. Identifizierte
Schwachstellen mit hoher oder kritischer Auswirkung müssen stets manuell und innerhalb
von 24 Stunden telefonisch gemeldet werden.

5.6 Konfigurationsmanagement
Unter Konfigurationsmanagement versteht man die Sicherstellung, dass die CMDB immer
aktuelle und genaue Informationen über alle Assets und die pro Asset installierte Software
enthält. Dies bedeutet, dass die CMDB auch während des Änderungsmanagements und des
Vorfallmanagements aktualisiert werden muss.

SLA-Metriken für die Berichterstellung

1. Der Auftragnehmer führt alle zwei Jahre CMDB-Prüfungen auf Genauigkeit und
Vollständigkeit durch. Die Anzahl der Fehler einschließlich Auslassungen pro
Asset/Software muss weniger als 1 pro Asset oder Softwarepaket betragen

Die Meldung der Auditergebnisse muss innerhalb einer Woche nach Abschluss des Audits per
E-Mail erfolgen.

5.7 Änderungsmanagement
Unter Change Management versteht man den Umgang mit Änderungen in der Abstimmung
zwischen Auftragnehmer und Auftragnehmer. Der Vertragspartner muss Änderungsanfragen
initiieren, wenn neue Firmware- oder Software-Updates verfügbar sind oder wenn die Situation
des Incident-Managements dies erfordert.

Change-Management-Prozesse müssen der offiziellen Change-Management-Richtlinie folgen

und werden an deren Einhaltung gemessen.

SLA-Metriken für die Berichterstellung

1. Die Anzahl der Tage, die dem Vertrag zur Bestätigung des Erhalts einer
Änderungsanforderung oder Änderungsmitteilung zur Verfügung stehen. Die Anzahl der
Tage sollte für Änderungen der Priorität 1 weniger als <1>, für Änderungen der Priorität 2
weniger als <3> und für Änderungen der Priorität 3 weniger als <5> betragen.
2. Der Vertragspartner muss beim Änderungsmanagement interaktiv mit dem
Auftragnehmer zusammenarbeiten, was bedeutet, dass Leistungen des Vertragspartners
bezüglich einer Änderung immer innerhalb von <1 Tag> für Änderungen der Priorität 1,
weniger als <3 Tagen> für Änderungen der Priorität 2 und weniger als <5 Tagen> geliefert
werden müssen für Änderungen der Priorität 3, sofern keine Fehler oder Verzögerungen
seitens des Auftragnehmers vorliegen

Die Zahlen müssen als Änderungen pro Monat, initiierende Partei, Datum der
Empfangsbestätigung, Lieferdatum der Leistungen, Änderungspriorität aufgeführt und monatlich
per E-Mail gemeldet werden. Die Zahlen sollten als fortlaufende Zahlen für einen Zeitraum von
sechs Monaten beibehalten werden.

5.8 Vorfallmanagement
Das Incident Management umfasst:

· Vorfälle erstellen, aktualisieren und schließen

· Bei Bedarf manuelles Eskalieren von Vorfällen
· Automatische Eskalation für Vorfälle, die nicht innerhalb der definierten
Lösungszeiträume gelöst werden
· Verfolgen Sie Warnungen, stellen Sie fest, ob eine Warnung falsch positiv ist oder
nicht, und aktualisieren Sie die Incident Management-Datenbanken mit diesen
Informationen
· Bei Warnungen, bei denen es sich nicht um Fehlalarme handelt, erfordert das
Vorfallmanagement eine Nachverfolgung, um zu überprüfen, ob ein betroffenes
System für eine potenziell übermittelte Nutzlast anfällig war, sowie eine Behebung
(in Abstimmung mit dem Auftragnehmer), wenn ein System infiziert war
· Schwerwiegende Vorfälle müssen während ihres gesamten Lebenszyklus aktiv
gemanagt werden
SLA-Metriken für die Berichterstellung

1. Anzahl der erstellten Vorfälle, ihr Erstellungsdatum und ihr Abschlussdatum

2. Anzahl der Vorfälle, die automatisch eskaliert wurden, ihre Eskalation von/bis,
Eskalationszeit/-datum. Vorfälle müssen nach <3> Tagen automatisch von Priorität <5> auf
<4>, nach <2> Tagen von <4> auf <3>, nach <1> Tagen von <3> auf <2> und nach <2>
Tagen automatisch eskalieren > bis <1> nach <3> Stunden und nicht abgeschlossene
Vorfälle der Priorität 1, die nicht 3 Stunden nach der Meldung durch den Auftragnehmer
oder der beauftragten Erstellung dieser Vorfälle geschlossen wurden, müssen zur
Bearbeitung schwerwiegender Vorfälle eskaliert werden
3. Anzahl der schwerwiegenden Vorfälle, ihre Melde-/Erstellungszeit, ihre Abschlusszeit/-
tag und ob ein schwerwiegender Vorfall automatisch eskaliert wurde oder nicht und wenn ja,
ab welcher anfänglichen Priorität
4. Durchschnittliche Zufriedenheit des Auftragnehmers mit der Bearbeitung
schwerwiegender Vorfälle. Nach Abschluss eines größeren Vorfalls führt der Auftragnehmer
intern immer eine Zufriedenheitsumfrage durch, und die prozentuale Zufriedenheit muss
über einen Zeitraum von sechs Monaten immer über 80 % bleiben
5. Anzahl und Prozentsatz der manuell eskalierten Vorfälle sowie Gründe dafür
6. Anzahl und Prozentsatz der weiterverfolgten Warnungen, Anzahl und Prozentsatz der
als falsch positiv eingestuften Warnungen, Anzahl und Prozentsatz der Warnungen ohne
potenzielle Auswirkungen, Anzahl und Prozentsatz der Warnungen mit potenziellen
Auswirkungen sowie ergriffene Maßnahmen.
7. Jede Warnung, die einen potenziellen Verstoß bedeuten könnte, wird wie ein
schwerwiegender Vorfall behandelt und die Meldung sollte gemäß dem oben beschriebenen
Prozess zur Behandlung schwerwiegender Vorfälle erfolgen

Die Zahlen müssen pro Monat aufgeführt und monatlich per E-Mail gemeldet werden.
Rollierende Zahlen müssen außerdem monatlich per E-Mail gemeldet werden.

5.9 Forensik und Reaktion auf Vorfälle, einschließlich

Malware-Umkehrung und -Analyse
Bei größeren Vorfällen ist das SOC für die Forensik und die Reaktion auf Vorfälle zuständig.
Dies kann auch bedeuten, Schadsoftware rückgängig zu machen und zu analysieren.

SLA-Metriken für die Berichterstellung

1. Die Anzahl der durchgeführten forensischen Untersuchungen und deren Ergebnisse
6 Umgang mit Fehlern auf SLA-Ebene
<Wenn der Vertragspartner die vereinbarten SLA-Werte nicht einhält, müssen Bußgelder oder
Konsequenzen vereinbart werden

Für einen SOC-Drittanbieter sollte die Feinstruktur in % der monatlichen Zahlungen bis maximal
100 % liegen, zuzüglich einer Haftung für schwerwiegende Verstöße, die hätten verhindert
werden müssen.

Für ein intern bereitgestelltes SOC ist dies nicht machbar und Sie müssen sich etwas anderes
einfallen lassen, das für Ihre Organisation sinnvoll ist, um Anreize für das SOC zu schaffen –
Zuckerbrot ist besser als Peitsche