Security Engineering in vier Ebenen

Das Denkmodell besteht aus den vier Ebenen „Function“ (FC), „Risk“ (RI), „Requirements“ (RE) und „Implementation“ (IP), die inhaltlich aufeinander aufbauen. Zweck der FC-Ebene ist eine systematische Beschreibung der zu schützenden Systemfunktionen und ihrer Abhängigkeiten von Menschen, Hardware und Software. Die zweite Ebene „Risk“ (RI) beinhaltet die Risikoidentifikation und -bewertung, die dritte Ebene „Requirements“ (RE) die Ableitung von Security-Anforderungen und die vierte und letzte Ebene „Implementation“ (IP) definiert, wie Security-Lösungen ­integriert und umgesetzt werden sollen. Eine nähere ­Beschreibung des methodenneutralen Denkmodells ist in
[1 – 3] zu finden. Im Folgenden spielt jedoch vor allem eine konkrete Methode für die unterste Turmebene (FC) eine Rolle – denn hier wird die Datenbasis für den gesamten Security-Engineering-Prozess gelegt.

Die Autoren schlagen vor, als Dreh- und Angelpunkt des Security-Engineerings nicht länger Einzelsysteme zu sehen, sondern deren Funktionen. Dreh- und Angelpunkt des ­Security Engineerings sollten nicht länger die Einzelsysteme, sondern deren Funktionen sein. Anwender sollten als erste die Fragen „Was sind die kritischen Funktionen in meiner Anlage, die ich auf jeden Fall schützen möchte?“ sowie „Von welchen Systemen und welcher Kommunikation hängen sie ab?“ beantworten. Diese Denkweise ist intuitiv, weil sie die rein technische Netzwerkbetrachtung um eine Semantik ­ergänzt, die den Zweck der Einzelsysteme, aber auch ihre Interaktionen miteinander und mit den Menschen wiedergibt. Dabei werden aus Security-Sicht nur diejenigen Funktionen betrachtet, welche die Anwendung von IT-/OT-­Systemen enthalten, also als Anwendungsfälle darstellbar
sind. Ein Beispiel für einen einfachen Anwendungsfall („Steuern eines Außenstandorts“) zeigt Bild 2. Für die Analyse hat sich die intuitive Klarheit einer standardisierten grafischen ­Darstellung in sogenannten Teilnetzmodellen bewährt.

Anwendungsfälle und Netzmodelle dokumentieren

Für die weitere Security-Analyse sind Anwendungsfälle fortan die „kleinste Betrachtungseinheit“. Aggregiert man diese Anwendungsfälle und ihre Teilnetzmodelle, ergibt sich das Gesamtnetzmodell [1 – 3] – eine Dokumentation aller für Security relevanten Systeme (und im Vergleich zu einem Netzplan auch nur dieser Systeme), Rollen und deren Kommunikationsverbindungen. In diesem Netzmodell ist dann genau dokumentiert, was funktionieren muss, damit die kritischen Systemfunktionen sicher ablaufen können. Somit stellen die folgenden Prozessschritte nicht mehr als logische Schlussfolgerungen dar. Weiß man, was im Detail für einen sicheren Betrieb funktionieren muss, kann man auch ableiten, welche Bedrohungen diesen Betrieb gefährden – und was dagegen hilft.  

Die Dokumentationen der Anwendungsfälle sowie des Netzmodells sind grundlegend für den Security-Engineering-Prozess. Sie sind gewissermaßen Security-Engineering-Basisdaten – die Sprache der Security. Diese Sprache enthält auch Informationen, die über reine Security-Analysen hinaus wertvoll sind: Das Netzmodell stellt in maximal komplexitätsreduzierter (und damit auch sehr einfach pflegbarer) Form die Netzwerkstruktur dar. Die Anwendungsfälle geben Auskunft darüber, welche Systeme in welchen Funktionen involviert sind – und aus welchem Grund die Systeme ­welche Protokolle sprechen müssen. Damit treffen sie im Umkehrschluss auch eine Aussage dazu, welche Protokolle diese Systeme nicht sprechen müssen, was quasi nebenbei eine Grundanforderung der Security, die Systemhärtung, erledigt.

Die Verwendung der Basisdaten bietet auch für die ­Ergebnisse des Security-Engineering-Prozesses ein großes Potenzial: Was, wenn man ein aus dem Security Engineering resultierendes technisches Konzept, beispielsweise ein Firewall-Regelwerk, direkt in Security-Eigenschaften beziehungsweise Konfigurationen realer Systeme übersetzen könnte?