SP7: Gewährleisten der Sicherheit

 

Prozessname: Gewährleisten der Sicherheit - Teil von: Unterstützende Prozesse

Vorhergehender Prozess: Managen von Projekten

Nächster Prozess: Gewährleisten von Kontinuität

 

Prozess-Beschreibung

Der Security-Management-Prozess in YaSM (Abb. 1) garantiert die Sicherheit der vom Service-Provider gemanagten Service-Palette und gleicht die Sicherheitserfordernisse des Service-Providers mit denjenigen der Kunden an. Dies schließt mit ein, sicherzustellen, dass Systeme und Daten vor Einbrüchen geschützt werden und dass Zugriffe nur von autorisierten Parteien erfolgen.

 

Abb. 1: 'Gewährleisten der Sicherheit'
Der YaSM Security-Management-Prozess SP7.

"Gewährleisten der Sicherheit" beginnt mit der Erstellung eines Registers der Sicherheitsrisiken, in dem die identifizierten Sicherheitsrisiken und ihre Charakteristika ebenso wie geeignete Risikobewältigungsmaßnahmen (Sicherheitsvorkehrungen oder andere Maßnahmen zur Risikoverringerung) aufgelistet sind.

Die YaSM-Prozesse geben dem Sicherheitsmanager für seine Aufgabe eine Reihe von Einflussmöglichkeiten an die Hand. Hierzu gehört insbesondere, dass der Sicherheitsmanager in den Design- und Erstellungsprozess der Services einbezogen wird, um so die Sicherheit neuer oder aktualisierter Services sicherzustellen. Sobald im Verlauf der Design-Phase des Services feststeht, welche Sicherheitsvorkehrungen und -mechanismen für den neuen Service benötigt werden, können diese installiert werden, und zwar

• über den Prozess "Erstellen von Services" durch Hinzufügen geeigneter Sicherheitsmerkmale zur Service-Infrastruktur, die erstellt oder aktualisiert werden soll,
• über den Prozess "Gewährleisten der Sicherheit" durch Aktualisierung der Sicherheitsrichtlinien sowie der Sicherheitsmechanismen und -vorkehrungen, die unter der Verantwortung des Sicherheitsmanagers betrieben werden.

Der Sicherheitsmanager ist auch in Service- bzw. Prozessverbesserungs-Initiativen mit einbezogen, wenn Sicherheitsaspekte zu beachten sind.

Falls neue Bedrohungen der Sicherheit bekannt werden oder wenn die Sicherheitsvorkehrungen aus anderen Gründen verbessert werden müssen, kann der Prozess "Gewährleisten der Sicherheit" selbständig Sicherheitsinitiativen starten. Solche Initiativen werden über den Sicherheitsverbesserungs-Plan verwaltet.

Schließlich gewährleistet der Sicherheitsmanager auch dadurch die Sicherheit, dass er Regeln definiert und relevante Informationen bereitstellt, z.B. in Form von unterstützenden Sicherheitsrichtlinien, Incident-und Service-Request-Modellen sowie Sicherheitswarnungen.

Anmerkung: YaSM liefert keine ausführliche Erklärung sämtlicher Aspekte des Sicherheitsmanagements, da es hierfür spezielle und detailliertere Quellen gibt (siehe beispielsweise ISO 27001). YaSM zeigt vielmehr die wichtigsten Aktivitäten des Sicherheitsmanagements auf und beschreibt die Schnittstellen zu den anderen YaSM-Prozessen.

 

Kompatibilität: Der YaSM Security-Management-Prozess ist kompatibel mit ISO 20000, dem internationalen Service-Management-Standard (vgl. ISO/IEC 20000-1:2018, Abschnitt 7) und eignet sich zur Umsetzung der Practices 'Information Security Management' und 'ITIL 4 Risk Management'.

Sub-Prozesse

YaSM's Security-Management-Prozess beinhaltet die folgenden Sub-Prozesse:

SP7.1: Bewerten von Sicherheits-Risiken

Prozessziel: Bestimmen der Risiken, die der Service-Provider gemanagt werden müssen, und Definieren geeigneter Vorgehensweisen zur Behandlung der Risiken.

SP7.2: Definieren von Sicherheits-Verbesserungen

Prozessziel: Definieren der Ziele von Sicherheits-Verbesserungs-Initiativen und des Ansatzes zu deren Implementierung. Dies beinhaltet auch die Erstellung von Kosten-/Nutzen-Analysen für die Initiativen.

SP7.3: Starten von Sicherheits-Verbesserungs-Initiativen

Prozessziel: Starten von Sicherheits-Verbesserungs-Initiativen. Dies beinhaltet auch das Einholen der Genehmigung durch Beantragung eines Budgets und Einreichen eines Requests for Change.

SP7.4: Implementieren von Sicherheits-Vorkehrungen

Prozessziel: Implementieren, Testen und Ausrollen von neuen oder verbesserten Sicherheits-Vorkehrungen und -Mechanismen.

SP7.5: Betreiben der Sicherheits-Vorkehrungen

Prozessziel: Durchführen geeigneter Sicherheits-Schulungen für die Mitarbeiter und Kunden des Service-Providers. Sicherstellen, dass die Kontinuitäts-Vorkehrungen und -Mechanismen regelmäßig gewartet und getestet werden.

SP7.6: Überprüfen der Sicherheits-Vorkehrungen

Prozessziel: Die Sicherheits-Vorkehrungen und -Mechanismen regelmäßigen Reviews zu unterwerfen, um Potentiale für Verbesserungen zu identifizieren, die mit Sicherheits-Verbesserungs-Initiativen adressiert werden sollen.

Prozess-Outputs

Die folgenden Dokumente und Records werden von 'Security-Management' erzeugt. YaSM-Datenobjekte [*] sind mit einem Sternsymbol markiert, und andere Objekte werden in grau dargestellt.

Aktualisierungs-Daten für den Projektplan

Ist-Daten zu Projekt-Fortschritt und Ressourcen-Verbrauch, die von unterschiedlichen Service-Management-Prozessen an den Projektmanager übermittelt werden. Diese Daten sind ein Input für das Projekt-Controlling.

Anforderung zur Bewertung der Compliance-Auswirkungen

Eine Anforderung zur Bewertung, welche Compliance-Anforderungen für einen neuen oder geänderten Service relevant sind, typischerweise erteilt während des Service-Designs.

Anforderung zur Bewertung von Kontinuitäts-Risiken

Eine Anforderung zur Bewertung von Risiken im Zusammenhang mit kritischen Ereignissen; diese wird typischerweise während des Service-Designs erteilt, falls evtl. neue oder geänderte Kontinuitäts-Vorkehrungen für einen neuen oder verbesserten Service benötigt werden.

Bericht zum Sicherheits-Review

Ein Bericht zum Sicherheits-Review zeichnet die Details und Ergebnisse eines Sicherheits-Reviews auf. Dieser Bericht ist eine wichtige Grundlage für die Definition von Initiativen zur Verbesserung der Sicherheit. [*]

Beschaffungs-Anforderung

Eine Anforderung zur Beschaffung von Gütern von einem externen Lieferanten. Beschaffungs-Anforderungen werden typischerweise an den Supplier-Manager gerichtet, wenn z.B. Anwendungen, Systeme oder andere Infrastruktur-Komponenten für die Erstellung eines neuen Service notwendig sind, oder wenn Standard-Infrastruktur-Komponenten oder Verbrauchsgüter für den Service-Betrieb benötigt werden.

Budget-Anforderung

Eine Budget-Anforderung wird typischerweise erstellt, um finanzielle Mittel für das Erstellen, Verbessern oder Betreiben eines Service oder Prozesses zu erhalten. Eine genehmigte Budget-Anforderung bedeutet, dass die finanziellen Ressourcen vom Finanz-Manager zugeteilt wurden. [*]

Change Record

In einem Change Record sind alle Einzelheiten eines Changes enthalten; er dokumentiert somit den Lebenszyklus eines einzelnen Changes. Zu Beginn beschreibt ein Change Record einen Change-Antrag (Request for Change, RFC), der vor der Implementierung des Changes zu bewerten und freizugeben ist. Weitere Informationen werden im Verlauf des Changes hinzugefügt. [*]

CI Record

Konfigurations-Information wird für alle Konfigurations-Elemente (Configuration Items, CIs) in CI Records gepflegt, die unter der Kontrolle des Konfigurations-Managers stehen. In diesem Zusammenhang gibt es unterschiedliche Typen von CIs: Anwendungen, Systeme und andere Infrastruktur-Komponenten werden als CIs behandelt, aber oft auch Services, Richtlinien, Projektdokumente, Mitarbeiter, Lieferanten usw. Konfigurations-Informationen sind im Konfigurations-Management-System (Configuration Management System, CMS) verzeichnet. [*]

Incident-Modell

Incident-Modelle enthalten die vordefinierten Schritte zum Umgang mit einem bestimmten Incident-Typ. Incident-Modelle dienen dem Zweck, wiederkehrende Incidents effektiv und effizient zu bearbeiten. [*]

Informationen zum Change-Status

Aktuelle Status-Informationen zur Implementierung eines Changes. Diese Informationen werden dem Change-Manager von den verschiedenen Prozessen zur Verfügung gestellt, die freigegebene Changes implementieren. Der Change-Manager wird so in die Lage versetzt, die Change Records und die Change-Planung aktuell zu halten.

Register der Sicherheits-Risiken

Das Register der Sicherheits-Risiken ist ein vom Sicherheits-Manager genutztes Tool, das eine Übersicht über sämtliche Sicherheits-Risiken bietet, die zu managen sind. Das Register der Sicherheits-Risiken spezifiziert auch, wie die identifizierten Risiken behandelt werden; insbesondere nennt es die Sicherheits-Vorkehrungen und -Mechanismen zur Risikominderung. [*]

Security Alert

Ein Security Alert (Sicherheits-Alarm) wird typischerweise vom Sicherheits-Manager herausgegeben, wenn Bedrohungen der Sicherheit absehbar oder bereits eingetreten sind. Sicherheits-Warnungen werden mit dem Ziel veröffentlicht, Anwender und Mitarbeiter in die Lage zu versetzen, Angriffe auf die Sicherheit zu erkennen und sich mit geeigneten Maßnahmen zu schützen.

Service-Request-Modell

Service-Request-Modelle enthalten die vordefinierten Schritte zum Umgang mit einem bestimmten Typ von Serviceauftrag. Request-Modelle dienen dem Zweck, häufig wiederkehrende Serviceaufträge effektiv und effizient zu bearbeiten. [*]

Sicherheits-Betriebshandbuch

Das Sicherheits-Betriebshandbuch spezifiziert die in der Verantwortung des Sicherheits-Managers liegenden Aktivitäten, die für den Betrieb der Sicherheits-Vorkehrungen und -Mechanismen erforderlich sind. Einige Anweisungen für den Betrieb bestimmter Sicherheits-Systeme können in separaten technischen Handbüchern oder 'Standardarbeitsanweisungen (Standard Operating Procedures, SOP)' dokumentiert werden. [*]

Sicherheits-Verbesserungs-Plan

Einträge im Sicherheits-Verbesserungs-Plan (Security Improvement Plan) dienen dem Sicherheits-Manager zur Erfassung und dem Management von Sicherheits-Verbesserungs-Initiativen über ihren gesamten Lebenszyklus. Initiativen im Sicherheits-Verbesserungs-Plan können vorbeugende Maßnahmen zur Erhöhung der Sicherheit implementieren, oder Mechanismen einrichten, mit denen effektiv auf Sicherheitsverletzungen reagiert werden kann. [*]

Testprotokoll

Ein Testprotokoll stellt einen detaillierten Bericht zu Testaktivitäten bereit. Ein solches Protokoll wird z.B. während der Tests neuer oder geänderter Service-Komponenten erstellt, oder während der Tests von Sicherheits- oder Service-Kontinuitäts-Mechanismen. [*]

Testskript

Ein Testskript bzw. Testdrehbuch spezifiziert einen Satz von Testfällen einschließlich der erwarteten Ergebnisse. Die Art der Testfälle hängt davon ab, was zu testen ist. [*]

Unterstützende Sicherheits-Richtlinie

Unterstützende Sicherheits-Richtlinien sind spezielle Richtlinien, die die übergeordnete Sicherheits-Richtlinie ergänzen. Sie stellen bindende Regeln auf, z.B. für die Nutzung von Systemen und Daten oder die Nutzung und Erbringung von Services. [*]

Vorschlag zur Prozess-Änderung

Ein Vorschlag zur Änderung eines oder mehrerer Service-Management-Prozesse. Vorschläge für Prozess-Änderungen oder -Verbesserungen können an jeder Stelle innerhalb der Organisation entstehen.

Vorschlag zur Service-Änderung

Ein Vorschlag zur Änderung eines Service, z.B. zur Verbesserung der Qualität oder Wirtschaftlichkeit des Services. Solche Vorschläge können an jeder Stelle innerhalb oder außerhalb der Service-Provider-Organisation entstehen.

Vorschlag zur Sicherheits-Optimierung

Ein Vorschlag zur Verbesserung der Service-Sicherheit. Solche Vorschläge können an jeder Stelle innerhalb der Organisation entstehen.

 

---

Anmerkungen:

[*] "YaSM-Datenobjekte" sind Dokumente und Records, für die YaSM detaillierte Empfehlungen bereithält: Für jedes YaSM-Objekt gibt es eine Checkliste (siehe Beispiel), die die typischen Inhalte beschreibt, und ein Lifecycle-Diagramm, das darstellt, wie sich der Zustand des Objekts ändert, während es von verschiedenen YaSM-Prozessen erstellt, geändert, gelesen und archiviert wird (siehe Beispiel).

"Andere Objekte" sind eher informelle Daten oder Informationen. Es gibt aus diesem Grund keine zugehörigen Lifecycle-Diagramme oder Checklisten.

Prozess-Kennzahlen

Prozesskennzahlen werden benötigt, wenn gemessen werden soll, ob die Service-Management-Prozesse "zufriedenstellend" laufen.

Vorschläge zu geeigneten Prozess-Kennzahlen entnehmen Sie der Liste von Kennzahlen zum Security-Prozess.

Rollen und Verantwortlichkeiten

Prozess-Owner: Der Sicherheits-Manager ist verantwortlich für die Sicherheit des Service-Providers und dessen Kunden. Dies schließt unter anderem die Verantwortung für die Sicherheit der vom Service-Provider verarbeiteten Informationen und Daten mit ein.

 

Verantwortlichkeits-Matrix 'SP7: Gewährleisten der Sicherheit'

YaSM-Rolle / Sub-Prozess		Compli.-Mgr.	Oper.	Proz.-Owner	Sicherh.-Mgr.	Serv.-Kontin.-Mgr.	Serv.-Owner	Techn.- Fach­exp.
SP7.1	Bewerten von Sicherheits-Risiken	-	-	R	AR	-	R	-
SP7.2	Definieren von Sicherheits-Verbesserungen	R	-	-	AR	R	-	-
SP7.3	Starten von Sicherheits-Verbesserungs-Initiativen	-	-	-	AR	-	-	-
SP7.4	Implementieren v. Sicherheits-Vorkehrungen	-	R	-	AR	-	-	R
SP7.5	Betreiben der Sicherheits-Vorkehrungen	-	R	-	AR	-	-	-
SP7.6	Überprüfen der Sicherheits-Vorkehrungen	-	-	-	AR	-	-	-

 

Anmerkungen

Security Management: Prozess-Ziele

Basiert auf: Der Security-Management-Prozess aus der YaSM-Prozesslandkarte.

Von:  Stefan Kempter   und  Andrea Kempter , IT Process Maps.

 

Prozess-Beschreibung  › Sub-Prozesse  › Prozess-Outputs  › Kennzahlen  › Rollen