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.
"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.
| YaSM-Rolle / Sub-Prozess | Compli.-Mgr. | Oper. | Proz.-Owner | Sicherh.-Mgr. | Serv.-Kontin.-Mgr. | Serv.-Owner | Techn.- Fachexp. | |
|---|---|---|---|---|---|---|---|---|
| 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
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
