PROMO und QUAMO & WEAKEST LINK PROTECTION

Einführung „weakest-link“- Strategie sowie eines in sich integrierten Prozess- und Qualitätsmodells

Den im Blog-Beitrag-1 beschriebenen Herausforderungen folgend, sollte einer der zentralen Aspekte bei der Einführung bzw. Anpassung der ISMS / Cyber Security Strategie die Einführung einer „weakest link“ Strategie sein, denn eine Kette ist bekanntermaßen nur so stark, wie ihr schwächstes Glied, was auch 1:1 für die Wertschöpfungskette (WSK) der vom ISMS zu schützenden Organisation und somit generell für deren Cyber Security Resillience Status zutrifft.

Es bedarf somit – was aber auch nicht wirklich neulich ist - eines durchgängiges Sicherheitsmanagements entlang der Wertschöpfungskette, welches einen Basisschutz im gesamten Unternehmen gewährleistet und die weiteren Aktivitäten risikobasiert ermittelt.

In der Praxis hat sich hierfür eine Scorecard (oder auch manchmal Schutzbedarfsfeststellung genannt) etabliert, mittels deren Basis z. B. Szenarien-basiert eine Einstufung des grundsätzlichen Risiko-Levels des Prozesses bzw. der darin genutzten Applikationen dokumentiert werden kann.

ANMERKUNG: Gemäß einer zu erstellenden Richtlinie muss hierfür gefordert sein, dass vom jeweiligen Prozesseigner – mindestens für jeden Hauptprozess sowie für jede für den Prozess betriebene Applikation in einer BCS, die Kritikalität des Prozesses sowie der Schutzbedarf der darin verarbeiteten Informationen bewertet werden.

Darüber hinaus muss der Projekt-Initialisierungsantrag der Organisation sicherstellen, dass für neue Vorhaben (analog zur Datenschutz- und/oder Betriebsrat-Meldung) eine Scorecard-ID bei der ISMS Abteilung angefragt werden muss, so dass ggfs. frühzeitig Informationssicherheitsanforderungen abgestimmt werden können.

Szenarien-basierte Priorisierung der zu schützenden Geschäftsprozesse (basierend auf einer Business criticality scorecard)

Eine Business criticality scorecard (BCS) kann in den Organisationen dazu dienen,

- die für den darin betrachteten Geschäftsprozess (sowie für die dafür verwendeten IT-Systeme / IT-Applikationen) durchgeführte Kritikalitätsbewertung,

- dessen – mittels der CIA-Szenarien-Analyse – ermittelten Informations¬sicherheitsrisiken sowie

- allgemein den Status hinsichtlich der Erstellung und Pflege der risikomindernden QK-Resultate

zu dokumentieren.

Die Scorecard dient somit zum einem zur Beschreibung des jeweils betrachteten Hauptprozesses bzw. der dafür betriebenen Applikationen und zum anderen Durchführung einer High-Level-Identifizierung, der aus dem Prozess bzw. der Anwendungen resultierenden operativen IS-Risiken, um basierend auf den in der BCS erhobenen Informationen den notwendigen Aufwand in die Absicherung des betrachteten Assets festzulegen, siehe nachfolgende Abbildungen.

Figure 1: Szenarien-basierte Ermittlung des Risiko-Levels.

Neben der Kritikalitäts- und Risikobewertung können – wie bereits beschrieben - weitere Fakten, z. B. zum RTP oder zu betriebsrelevanten Prozessen erhoben werden:

Figure 2: Erhebung von Informationen mittels BCS

Basierend auf den erhobenen Informationen, z. B. Reifegrad Umsetzung der Basis-Anforderungen, der Dokumentationsanforderungen sowie insbesondere basierend auf der erhobenen Kritikalitäts- und Risikobewertung, wird in der BCS vom Informations¬sicherheits¬beauftragten (ISB) also entschieden, welcher Aufwand in die weitere Sicherheitsanalyse (des Prozesses) investiert werden muss, um ein für die Organisation adäquates Sicherheitsniveau zu erreichen.

Für weniger kritische Systeme kann dann z. B. eine zu definierende Standardabsicherung (siehe Standard IT-Maßnahmen / ITSAB) Anwendung finden und bei Prozessen mit höheren Risikopotential werden spezifische Sicherheitskonzepte oder technische Überprüfungen, wie z. B. die Durchführung eines Penetrationstestes eingefordert.

Die möglichen Entscheidungsstufen könnten beispielhaft, wie folgt definiert sein:

Stufe	Aufwand Sicherheitsanalyse
0	Keine weitere Analyse notwendig
1	Standard-Maßnahmen Durchführung einer GAP-Analyse auf die Standardmaßnahmen der Organisation oder alternativ, sofern durch die konzerneigene IT betrieben, eine Bestätigung der IT-Abteilung, dass die Maßnahmen umgesetzt sind.
2	Erweiterte Sicherheitsanalyse Durchführung einer spezifischen Schwachstellenanalyse mittels einer Bedrohungsmodellierung (z. B. STRIDE)
3	Technische Sicherheitsanalyse Durchführung eines Penetrationstest oder einer Quellcodeanalyse durch eine unabhängige dritte Partei.

Die BCS stellt somit auch eine Art „Vor-Filter“ für das Risiko-Management dar, da ausgiebige Analysen nur dann
durchgeführt werden müssen, wenn die initiale High-Level Bewertung der Kritikalität (BCS) einen entsprechenden Bedarf identifiziert, aber über die Methodik dennoch gewährleistet ist, dass jeder Prozess – zumindest High-Level – analysiert und eine angemessene Basis-Absicherung gewährleistet ist, was automatisch zu einer systematisch sichergestellten „weakest link“- Absicherung führt.

Weiterer Vorteil einer Scorecard-Lösung ist, dass man über diese auch weitere Themen - für die operativ zu steuernden Prozesse - abfragen kann, welche dann wertvolles Roh-Material für aussagekräftige KxIs hinsichtlich der Wirksamkeit der Governance-Regelungen liefern, z. B. mittels der Abfrage von Compliance-Vorgaben, Überprüfung auf dokumentierte Betriebsprozessen, samt geklärter Verantwortlichkeiten wie z. B. Patch- und Schwachstellenmanagement, Logauswertung, Datensicherung, Berechtigungskonzept, also generell der definierten QK-Resultate nach QUAMO), dazu aber später mehr.

So können z. B. auch Ergebnisse aus dem Release-Prozess in der Scorecard abgefragt werden (Testkonzept, Testfälle, Bestätigung der SOLL-IST-Überprüfung hinsichtlich Berechtigungen etc.)

Figure 3: Erhebung von Informationen mittels BCS (2)
HIER FINDEN SIE EIN BEISPIEL FÜR EINEN MÖGLICHEN AUFBAU IHRER BCS!

Integriertes ITSM-Prozess- und Qualitätsmodell zur Verankerung von Governance-Vorgaben in das IT- bzw. OTSM

Das ISMS hat als Teil der 2. Line of Defense (2. LoD) – über entsprechende Steuerungsmaßnahmen (Controls) - sicherzustellen, dass auch bereits in den zu steuernden operativen Geschäftsprozesse der WSK – dem Schutzbedarf entsprechende – prozessintegrierte Kontrollen (Sicherheitsmaßnahmen) eingeplant sind.

Hierzu sind zum einen entsprechende Regelungen zu publizieren und zum anderen deren Umsetzung, z. B. in Form von „Guiding“, „Bereitstellung von Templates“ etc. zu supporten. Ebenfalls eingeplant werden muss eine stichprobenartige Auditierung der Umsetzung der Regelungen in den vom ISMS gesteuerten Bereichen sowie ergänzend eine Überprüfung der Wirksamkeit der Regelungen mittels Kennzahlen.

In der Praxis stellt man die Verankerung von Governance-Vorgaben am sinnvollsten durch ein – mit den Vorgaben abgestimmten - IT-Prozess- und Qualitätsmodell (PROMO und QUAMO) sicher.

Das IT-Prozessmodell sorgt in der Folge für einen strukturierten Ablauf im Kontext der Release-Prozesse (Projekt und/oder Change an bestehendem Prozess bzw. Anwendung) sowie im Betrieb bzw. bei der Außerbetriebnahme bestehender Prozesse/Anwendungen. Das Qualitätsmodell QUAMO sorgt – im Rahmen der mittels PROMO definierten Prozesse – für erwartete Ergebnisobjekte, welche auch als Template in der Organisation vorliegen sollten.

Diese Ergebnisse nennt man üblicherweise Qualitätskriterium-Resultate [QKR], da sie auf vorher definierten Qualitätskriterien (QK) basieren. Beispiele für QK-R könnten sein: Testkonzept, Testfälle, Testprotokoll, Betriebshandbuch, Berechtigungskonzept, betriebliche Abnahme etc.

Die Erhebung der QKR in den BCS – also über alle vom ISMS gesteuerten Prozesse hinweg – stellen dann eine zentrale Quelle für Kennzahlen dar, mittels denen man die Wirksamkeit des ISMS prüfen, bestenfalls nachweisen, kann.

Hinweis: Beispiele für ein Prozessmodell, für Qualitätskriterien inklusive Qualitätskriterien-Resultate sowie eines möglichen Aufbaus einer BCS können dem Anhang x entnommen werden.

PROMO

Das Prozessmodell (PROMO) bildet das verbindliche Rahmenwerk für die Abläufe der Aufgaben in der IT-Organisation und berücksichtigt hierbei die Anforderungen der IS-Governance (ISMS+DS+BCM …).

Das Prozessmodell dient primär dazu, Aufgaben der IT-Organisation zu strukturieren, transparent und nachvollziehbar zu machen und sorgt letztendlich auf systematische Weise für Qualität und Sicherheit in den
Prozessen und somit auch in den Produkten / Services der zu steuernden Organisation.

Mittels eines Prozessmodells, welches z. B. auf ITIL, ISO 20000 oder COBIT basieren könnte, können folglich Governance-Vorgaben, unter anderem auch des ISMS, operationalisiert werden.

Eine mögliche Struktur für die IT- / OTSM - Prozesse könnte - abgeleitet aus ITIL – z. B. wie folgt aussehen:

Management & Querschnitt
o Strategie Management
o Organisationsmanagement
o Personalmanagement
o IT-Architektur Management
o IT-Projekt Portfolio Management
o Service Financial Management
o Supplier Management
o Kunden Relationship Management

Qualität & Support
o Daten & Informationsmanagement
o Prozess & Improvement Management
o IT-Qualitätsmanagement
o Risikomanagement
o Information Security Management
o IT Service Continuity Management

PLAN
o Demand Management & Business Analyse

BUILD
o IT-System/IT-Service Entwicklung
o Service Validation & Testing
o Technisches Release Management

RUN
o Change Management
o Deployment Management
o Capacity and Performance Management
o Availability Management
o Service Level Management
o Service Desk
o Service Request Management
o Incident Management
o Problem Management

Für jeden Prozess müssen dann mittels QUAMO entsprechende Ergebnisobjekte eingefordert werden, siehe hierzu nachfolgender Abschnitt.

IT- Qualitätsmodell (QUAMO)

Das Qualitätsmodell QUAMO bildet technisch ein IT-Qualitätsmodell ab, wie es z. B. in der ISO 25010 definiert ist, schafft Transparenz bezüglich der vielfältigen Aspekte der Qualitätsanforderungen innerhalb einer IT-Organisation und bietet zahlreiche Vorlagen & Best Practices für deren Umsetzung an.

Letzteres ist der große Mehrwert des Modells, denn mittels QUAMO sollte es dann für alle - in den Phase-Gates des IT-Prozessmodells geforderten Ergebnisobjekte - entsprechende Templates geben, welche verbindlich in den Phase Gates oder Entwicklungszyklen (agil) zu erstellen bzw. zu aktualisieren sind.

Dadurch wird auf systematische Weise gewährleistet, dass für jedes neue und/oder bereits existierende IT-System hinsichtlich Dokumentation die gleiche Qualität zu erwarten ist und somit die Vorgaben der IS-Governance umgesetzt sind.

Die konsolidierte Erhebung und Auswertung der sogenannten Qualitätskriterien-Resultate - über alle vom ISMS gesteuerten Prozesse hinweg – bieten Potential für sehr aussagekräftige KPIs welche z. B. die Wirksamkeit des ISMS und seiner Steuerungsmaßnahmen (Controls) belegen können.

Mittels PROMO und QUAMO kann somit ein ISMS operationalisiert werden.

Die beiden verzahnten Modelle übersetzen hierfür die Anforderungen der Governance-Ebene (ISMS) in konkrete - Abläufe - mit definierten Ergebnisobjekten. („Schema F bzw. Schema ISMS für alle!").

Mittels der nun systematisch ablaufenden IT-Prozesse wird also eine Systematik in die Organisation integriert, wodurch letztendlich das 2. „S“ im ISMS abbildet, wird.

Die nachfolgende Tabelle gibt einen Überblick über mögliche QK-Kriterien, wobei sicherlich nicht alle für jede Organisation sinnvoll sind.

Design-Phase / Refinement

QK-ID	QK-Resultat (Ergebnisobjekt)	Zweck des QK-Resultats
QK-Plan-x	Projekt-Voranmeldung (inkl. Kostenplanung) Über die Projekt-Voranmeldung werden komplett neue Vorhaben oder größere Changes, für die extra Budget beantragt werden muss, initial beantragt. Hinweis: Die Rückmeldung enthält eine Entscheidung, ob Vorhaben genehmigt wurden oder nicht. Eine Genehmigung impliziert die Erstellung bzw. ggfs. Aktualisierung der QK-Resultate der Plan-Phase, inkl. entsprechender Bestätigungen durch den ISB und DSB (über die BCS oder Formblatt Datenschutz). Hierfür wird das Budget, für die Erstellung der QK-Resultate der Plan-Phase, gemäß kalkulierte Aufwand in der Projektplanung, freigegeben.	Erst wenn alle Nachweise der Plan-Phase vorliegen, darf das Projekt/Vorhaben final genehmigt und das vollständig beantragte Budget freigegeben werden.
QK-Plan-x	BCS Bereits in der Planphase muss ein erster Entwurf der BCS mit dem ISB abgestimmt werden. Eventuell noch nicht bekannte Details, wie z. B. der spätere Betriebsdienstleister, werden dann im Rahmen des Phase-Gates RTP aktualisirt. Die 1. Freigabe des ISB gilt nur für die Plan-Phase.	QK-Plan-2 Schnittstellendokumentation („Grobentwurf“) effiziente Abstimmung, (Weiter-)Entwicklung, Wartung und Betrieb des Datenaustausches
QK-Plan-x	Beteiligung Betriebsrat (Formblatt) Mitbestimmung/Kontrolle des Sozialpartners bei Möglichkeiten zur Verhaltens- und Leistungskontrolle (insbesondere bei personenbezogenen Daten)	Zustimmung des Betriebsrats wird zum Rollout eines Systems, das der Mitbestimmung unterliegt, benötigt. Hinweis: Fehlanzeige erforderlich, weshalb der Betriebsrat immer zumindest angefragt werden muss.
QK-Plan-x	Datenschutzvoranmeldung Erfüllung der Verpflichtung zur Führung des Verzeichnisses aller personenbezogenen Verarbeitungstätigkeiten gemäß Artikel 30 EU Datenschutz-Grundverordnung (EU DSGVO) und Sicherstellung der Datenschutzkonformität Hinweis: Im der Design bzw. Refinement-Phase muss die Voranmeldung beim Datenschutz erfolgen.	Im Diaglog mit dem Datenschutz wird entschieden, ob weitere Maßnahmen, wie z.B. Erstellung „Löschkonzept“ notwendig. Die Voranmeldung muss immer erfolgen, auch wenn keine personenbezogene Daten verarbeitet werden. Dies wird dann entsprechend vom DSB bestätigt auf dem Formblatt. Das Formblatt muss im Rahmen der betrieblichen Abnahme nochmal bestätigt werden, so dass sichergestellt ist, dass sich die Rahmenbedingungen nicht während des Release-Prozesses verändert haben und, z.B. auf Grund neuer, zunächst nicht geplanter Funktionen verändert hat (siehe Datenschutzbewertung). Hinweis: Die Bewertung findet üblicherweise auf Basis einer „Demonstration der fertigen Lösung“ sowie ggfs. durch Prüfung der ggfs. zu erstellenden Dokumentation statt. Im Nachgang bestätigt der DSB die Datenschutzbewertung und kreuzt - sofern weiterhin keine Datenschutzdokumentation zu erstellen ist oder - keine Mängel in der zu erstellenden Dokumentation zu finden war die „Freigabe“ an. Falls Mängel vorliegen und/oder sich – auf Grund von GAPs zwischen Planung und Realisierung – doch die Notwendigkeit weiterer Dokumentation ergibt, obliegt es dem DSB zu entscheiden, ob er die „Freigabe mit Auflagen“ erteilt oder „keine Freigabe“ erteilt. Die „Freigabe mit Auflagen“ kann z. B. die Erstellung der Dokumentation im Nachgang sein. Hinweis: Zum Übergang RTP muss ein aktuelles Statement des DSB eingeholt werden, in dem die – auf Basis der Projektpläne getroffenen - Entscheidungen (Datenschutzvoranmeldung) erneut überprüft werden, ob sie noch angemessen für die realisierte Lösung ist.

Hinweis: Erst wenn alle Nachweise der Plan-Phase vorliegen, darf das Projekt/Vorhaben final genehmigt und das vollständig beantragte Budget freigegeben werden.

RTP-Phase
Hinweis: Zum Übergang RTP muss ein aktuelles Statement des DSB eingeholt werden, in dem die – auf Basis der Projektpläne getroffenen - Entscheidungen (Datenschutzvoranmeldung) erneut überprüft werden, ob sie noch angemessen für die realisierte Lösung ist.

Weitere denkbare Ergebnisdokumente könnten beispielhaft sein:

QK-ID	QK-Resultat (Ergebnisobjekt)	Zweck des QK-Resultats
QK-RTP-x: Berechtigungskonzept	QK-RTP: Berechtigungskonzept Die von der Anwendung bereitgestellten Rollen sowie die damit verknüpften Rechte müssen in einem technischen Berechtigungskonzept beschrieben sein. Ergänzt wird das Konzept durch die Beschreibung der für den Betrieb notwendigen User/Rechte und Rollen, z. B. technische User für die DB, Schnittstellen-User etc. Darüber hinaus müssen die Workflows zur Vergabe, Entzug, regemäßige Re-Zertifizierung („Soll-Ist-Ableich“) für die fachlichen Rollen der neuen Applikation beschrieben sein.	Existierendes Berechtigungskonzept für jedes vom ISMS gesteuerte Verfahren.
QK-RTP: OSLC Scan	QK-RTP: Ergebnis Prüfung Open Source License Compliance Hinweis: Bestenfalls wird der Scan in den CI/CD Prozess integriert.	Einhaltung der auf dem Einsatz der Open Source basierenden Lizenzpflichten
QK-RTP: BHB	QK-RTP: Betriebsdokumentation sowie ggs. Wartungsdokumentation Befähigung des Betriebsdienstleisters zur eigenständigen Erbringung der beauftragten Betriebsdienstleistung. Die Betriebsdokumentation wird – zusammen mit dem späteren Betriebs- und Wartungsdienstleister - noch im Rahmen des RTP erstellt bzw. für das aktuelle Release bei Bedarf aktualisiert und bei der betrieblichen Abnahme geprüft.	Wartungsdokumentation:Befähigung des Wartungsdienstleisters zur Gewährleistung der Wartung des Produktivbetriebs.
QK-RTP: Build- und Runtime-Umgebungskonfiguration	QK-RTP: Build- und Runtime-Umgebungskonfiguration Implementierung des IT-Systems. Die Dokumentation wird – zusammen mit dem späteren Betriebs- und Wartungsdienstleister - noch im Rahmen des RTP erstellt bzw. für das aktuelle Release bei Bedarf aktualisiert und bei der betrieblichen Abnahme geprüft.
QK-RTP: Abnahmeerklärung System	QK-RTP: Abnahmeerklärung System Dokumentation der Abnahmetests des IT-Systems sowie darauf basierende Empfehlung des Testmanagers zur Abnahme des Systems;	Dokumentation der Systemabnahme durch den Projektleiter.
QK-RTP: Betriebliche Abnahme	QK-RTP: Betriebliche Abnahme durch den BDL/WDL, bestenfalls basierend auf einer Checkliste.	Ordnungsgemäßer Übergang in den Betrieb mit sichergestellter Compliance u.a. zu den Vorgaben des ISMS

Im Kontext von eher agil geprägten Organisationen, könnte ein mögliches Szenario, wie folgt aussehen:

MEHR (z. B. Richtlinien für ihre Organisation, Tool-Unterstützung etc.) GERNE AUF ANFRAGE!!