Was du schon immer wissen wolltest, ...

WAS IST EIGENTLICH WAS ???

Jeder fängt mal klein an und um auch Einsteigern die konfuse Welt der Informationssicherheit näher zu bringen werde ich hier von Zeit zu Zeit einige der wichtisten Grundlagen-Begriffe erklären.

ISMS

Was ist ein ISMS?

Bei einem ISMS handelt es sich - ähnlich wie bei anderen politischen Systemen auch - um eine - mittels einer Aufbauorganisation und einer Verfassung (BRD: Grundgesetz; ISMS: IS-Leitlinie) beschriebenen Governance-Funktion, welche Vorgaben (BRD: Gesetze, Verordnungen etc., ISMS: IS-Richtlinien; Arbeitsanweisungen etc.) publiziert, um die dem System auferlegten Aufgaben/Ziele zu erreichen.
Das ISMS der ORGA ist kein Selbstzweck, sondern es soll primär dazu dienen, die Prozesse der Wertschöpfungs-kette, in allen Belangen der Informationssicherheit zu supporten ("enabler") und vor allem auch Empfehlungen, aber auch notwendige Vorgaben, hinsichtlich Informationssicherheit zu machen.
In diesem Kontext wird das ISMS - neben den operativen Geschäftsprozessen der Wertschöpfungskette - auch Vorgaben an die für oder von der zu steuernden Organisation betriebene IT-Infrastruktur definieren, die ggfs. - mit Unterstützung der operativen IT-Security Abteilung - in konkrete Lösungen überführt werden.

IKS

Was ist ein internes Kontrollsystem?

Ein internes Kontrollsystem (IKS) bezeichnet alle Maßnahmen, die Risiken in Unternehmensprozessen minimieren. Das IKS ist verantwortlich dafür, dass alle gesetzlichen Vorschriften überwacht und kontrolliert werden. Das IKS hat somit eine präventive Funktion und unterstützt den optimalen Ablauf der Unternehmensprozesse… aller Unternehmensprozesse!

Bei einem IKS unterscheidet man zwischen prozessintegrierten und prozessunabhängigen Kontrollaktivitäten.
Bei den erstgenannten handelt es sich üblicherweise um Kontrollmaßnahmen („Aktivitäten“), die aus den
- operativen Informationssicherheitsrisikoeinschätzungen (z. B. Vieraugenprinzip bei Buchungsfreigabe in einer vom ISMS zu steuernden Fachapplikation),
- aus guten Managementpraktiken (z. B. interne Richtlinien und / oder CIS Controls) oder
- internen und externen Vorgaben resultieren (z. B. PCI-DSS)

. Bei den prozessintegrierten Kontrollaktivitäten handelt es sich um die sogenannte »erste Verteidigungslinie«, die die Ordnungsmäßigkeit von Prozessen und Aktivitäten in unserem Unternehmen sicherstellen soll und durch die Prozesseigner zu identifizieren und zu implementieren sind. Der ORGA IT-Grundschutz unterstützt hier.

Die Existenz und Wirksamkeit der operativen Kontrollen („Aktivitäten“) wird innerhalb einer Organisation durch das ISMS prozessunabhängig gesteuert und überprüft. Das ISMS ist somit die »zweite Verteidigungslinie«.

Die Überprüfung durch das ISMS ersetzt nicht die Tätigkeit der Internen Revision, die wiederum die Wirksamkeit des gesamten IKS als sogenannte »dritte Verteidigungslinie« prüfen soll.

Die Internen Revision prüft somit sowohl die die operativen Geschäftsprozesse und die Tätigkeiten das etablierte ISMS. Das Zusammenspiel der drei Defense-Level wird sicherlich deutlicher, falls dies jetzt noch nicht klar sein sollte.

Wie läuft eine ISMS Einführung ab?

Mit der ISO/IEC 27001:2013 existiert eine internationale Norm im Bereich „Informationssicherheits-managementsysteme“, deren Anforderungen wir als „Blaupause“ nutzen werden.

Zentrale Anforderungen der Norm sind, dass
o eine Aufbauorganisation geschaffen wird, welche mittels angemessener Vorgaben und Regelungen die Informationssicherheitsrisiken - der durch das ISMS gesteuerten Bereiche/Prozesse - auf ein, von der Leitungsebene akzeptiertes Niveau, mitgieren
UND DARÜBER HINAUS
o die Anforderungen der Stakeholder, welche externer (Gesetzgeber, Kunde etc.) oder interner Natur (Vorgaben durch Aufsichtsrat etc.) sein können, zu identifizieren und nach Möglichkeit umsetzen.

Grundsätzlich sollen alle Entscheidungen ISMS – nach Möglichkeit - risikobasiert getroffen werden. Nicht möglich ist es, wenn z.B. eine Anforderung aus einer harten gesetzlichen Anforderung resultierte, wobei man hier auch streng genommen die eventuell zu erwartende Pönale gegen die Kosten abwägen könnte … aber so simmer ja nicht =)

Ich unterscheiden in meinem Verständnis zum Informationssicherheitsrisikomanagement zwischen
- strategischen und
- operativen IS-Risiken / Maßnahmen.

Dies hat den Vorteil, dass die Informationssicherheitsrisikoeinschätzung (ISRE) auf Governance-Ebene schlank und handlungsfähig bleibt und das System an sich beliebig skaliert, da für neue Projekte/Vorhaben in der Organisation „nur“ die vom System vorgesehene Systematik durchgeführt werden muss.

[ISRE GOV] Die strategische Ebene bedient die Governance-Funktion des Managementsystems und formuliert - auf Basis einer übergreifenden Informationssicherheitsrisikoeinschätzung - Steuerungsmaßnahmen sowie KPIs, welche in Summe geeignet sind, um Informationssicherheit in der Organisation zu verankern und die Wirksamkeit der Regelungen zu überwachen, z. B. mittels einem IS-Kennzahlensystemen (nach ISO/IEC 27004:2016).
Die aus der Informationssicherheitsrisikoeinschätzung abgeleiteten Steuerungsmaßnahmen („controls“) orientieren sich im Wesentlichen am Anhang A der ISO/IEC 27001:2013, ergänzt um eigene Aspekte, welche sich z. B. aus der Stakeholder- und Umfeldanalyse ergeben. Die Liste der Steuerungsmaßnahme ist ein zentrales Ergebnisdokument des ISMS und stellt im Wesentlichen die 2. Line of Defense sicher.
[ISRE OPS] Über die Governance-Ebene muss insbesondere sichergestellt werden, dass die Prozess-Owner ihre Informationssicherheitsrisiken in den von ihnen zu verantwortenden Geschäftsprozessen kennen und im Nachgang nachvollziehbar akzeptiert haben, sofern sich dies mit den von der Leitungsebene definierten Risikoakzeptanzkriterien vereinheitlichen lässt.
Neben der strategischen Ebene muss es folglich noch eine operative Ebene geben auf der die Prozess-Owner / Prozesseigner die Informationssicherheitsrisiken, für die von ihnen zu verantwortenden Prozesse identifizieren und sinnvolle Maßnahmen („actions“) ableiten, welche mitigierend auf die Risiken (und insbesondere auf die identifizierten Schwachstellen) wirken. Diese „actions“ stellen als prozessintegrierte Kontrollen im Übrigen die 1. Line of Defense im IKS dar.
[Verantwortlichkeiten] Der ISB hat bzgl. der operativen Ebene eine kontrollierende und koordinierende Funktion. Die Verantwortung zur Durchführung der „operativen Einschätzung“ (nach Vorgabe des Informationssicherheitsbeauftragter /ISB) obliegt den jeweiligen Prozess-Owner / Prozesseigner).
Hinweis: Die Überwachung / Steuerung durch den ISB nennt man üblicherweise die 2. Line of Defense. Da der CISO und seine Prozesse ebenfalls durch die interne Revision überwacht wird, nennt man diese auch die 3. Line of Defense.

PROMO und QUAMO

Wie erfolgt die Operationalisierung des ISMS?

Die Systematik (des ISMS) wird – nach meinem Verständnis - bestenfalls durch ein IT-Prozess- und Qualitätsmodell (PROMO und QUAMO) unterstützt.

Ein IT-Prozessmodell bildet das verbindliche Rahmenwerk für die Abläufe der Aufgaben in der IT-Organisation (z. B. ITIL, ISO 2000) und berücksichtigt hierbei die Anforderungen der IS-Governance (ISMS). Es dient 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 der Organisation.
Das mit dem IT-Prozessmodell verzahnte Qualitätsmodell 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.
Als Prozessmodell für die IT hat sich z. B. ITIL oder die ISO 20000 als brauchbar gezeigt. Als Qualitätsmodell dient die ISO 25010.

Risk

Skalierender Ansatz im Risk-Management

In meinen Augen macht es, u.a. aus wirtschaftlicher Sicht, Sinn eine Art „Vorfilter“ in den Prozess der operativ durchzuführenden Analysen einzubauen. Dieser Vorfilter basiert in der Praxis oft auf einer Scorecard, welche im Wesentlichen zur High-Level Bewertung der Kritikalität (BCS) dient.

Hierzu wird in einer BCS (i.d.R. auf Ebene einer Anwendung) auf Basis der Erhebung verschiedener Grundparameter, wie z. B.
- verarbeitete Daten,
- Erreichbarkeit über öffentliche Netze
- etc.,
eine Entscheidung getroffen wird, wie viel Aufwand (bezogen auf Informationssicherheit) in die weitere Betrachtung/Absicherung des Prozesses investiert werden soll.

Für weniger kritische Systeme greift dann eine zu definierende Standardabsicherung (siehe Standard IT-Maßnahmen) und bei Prozessen mit höheren Risikopotential werden spezifische Sicherheitskonzepte geschrieben.
Die Scorecard dient zur Beschreibung des jeweils betrachteten Hauptprozesses bzw. der dafür genutzten Applikation sowie zur High-Level-Identifizierung, der aus dem Prozess bzw. der Anwendung resultierenden operativen IS-Risiken, um so den notwendigen Aufwand in die Absicherung festlegen zu können.

Weiterer Vorteil einer Scorecard-Lösung ist, dass man über diese auch weitere Themen - für die operativ zu steuernden Prozesse - abfragen kann, die dann Futter für aussagekräftige KPIs hinsichtlich Wirksamkeit der Governance-Regelungen liefern, z. B. Abfrage Compliance-Vorgaben, Bestätigung der Existenz von dokumentierten Betriebsprozessen, wie z. B. Patch- und Schwachstellenmanagement, Logauswertung, Datensicherung, Berechtigungskonzept etc. (generell QK-Resultate nach QUAMO) Auch Ergebnisse aus dem Release-Prozess könnten in der Scorecard abgefragt werden (Testkonzept, Testfälle, Bestätigung der SOLL-IST-Überprüfung hinsichtlich Berechtigungen etc.)

Dank eines IT-Prozess- und Qualitätsmodell haben – so zumindest das ISMS-Ziel – alle vom ISMS gesteuerten Prozesse eine in etwa gleich gute Qualität hinsichtlich der Dokumentation ihrer Gegebenheiten.
Um zu prüfen, ob wir unser ISMS-Ziel erreichen und unsere Regelungen wirksam sind, kann uns die BCS somit helfen. Die konsolidierte Erhebung und Auswertung der sogenannten Qualitätskriterien-Resultate - über alle vom ISMS gesteuerten Prozesse hinweg – bietet Potential für sehr aussagekräftige KPIs, z. B.
- Wie viele unserer Anwendungen haben ausreichend Testfälle
- Wie viele unserer Anwendungen haben eine ausreichende Dokumentation der Betriebsprozesse etc.

Hinweis: Einen ersten Vorschlag für den Aufbau der BCS sowie der IT-Standardmaßnahmen findet ihr bereits im entsprechenden Blog-Beitrag.