Im Maschinenbau eine Konstruktion zu entwickeln, die man als „Failsave“ bezeichnet, ist eine Kunst und eine Auszeichnung. Denn eine solche Konstruktion hat die Funktionssicherheit eingebaut, sie funktioniert unter allen Umständen. Eine solche Konstruktion ist der klassische Rauchmelder.
Entgegen der Erwartung, dass ein tiefer Druck auf den schwarzen Knopf (nach dem Einschlagen der Scheibe) einen Stromkreis schließt und den Alarm auslöst, wird durch den Druck ein bestehender, schwacher Stromkreis unterbrochen und durch diesen Abfall der Alarm ausgelöst. Damit ist sichergestellt, dass ein Defekt der Verkabelung erkannt wird und somit die Funktionssicherheit des Alarmsystems gewährleistet ist.
Der Ingenieur formuliert: „Eine Konstruktion soll so gestaltet sein, dass bei einem Defekt eines Bauteils die Gesamtkonstruktion einen einem sicheren Zustand bleibt“.
Leider lässt sich dieser Satz und das dahinter stehende Konstruktionsprinzip nur bedingt auf IT-Systeme übertragen. Dies liegt im Wesentlichen an zwei Dingen. Zum einen berücksichtigt das Konstruktionsprinzip nur einen Teilaspekt einer IT-Risikobetrachtung – die Sicherheit gegen technisches Versagen. In einer IT-Risikoanalyse wird auch die Sicherheit gegen menschliches Versagen, Naturkatastrophen und böswillige Handlungen betrachtet. Andererseits können IT-Systeme – z.B. durch böswillige Handlungen – nicht nur ausfallen, sondern sich auch falsch verhalten und damit das Gesamtsystem in seinem Verhalten manipulieren. /1/
In der Folge dieser Erkenntnis ist der „Security by Design“ Ansatz ein hehres Ziel geblieben, in der Praxis wird IT-Sicherheit nicht als Design-, sondern als Zusatzelement verstanden. Sie wird in der Regel dem eigentlichen Systementwurf nachgestellt und eigenständig betrachtet. Diese Denkweise wird durch die meisten Security Frameworks noch verstärkt, da diese in der Regel Sicherheitsfunktionen – Mitigations oder Controls – isoliert beschreiben und deren Anwendung auf bestehende Systeme fordern. /2/
Dies muss heute nicht mehr so sein. Mit dem logischen Sicherheitsmodell „Zero Trust“ wie es von der NIST beschrieben wird /3/ ist eine Möglichkeit geschaffen worden, „Security by Design“ mit einem einfachen Entwurfsmodell in den Gestaltungsprozess von IT-Lösungen zu integrieren.
Das NIST Zero Trust Modell
Das logische „Zero Trust“ Modell (ZTM) des NIST basiert auf dem einfachen Gedanken, dass ein Subjekt beim Zugriff auf eine Ressource, dem Objekt, durch einen Kontrollpunkt (Enforcement Point – Ep) alimentiert wird. Dieser Kontrollpunkt erhält seine Freigaben von einer unabhängigen Managementebene (Control Point – Cp).
Kernelemente dieses Denkmodells sind also die Kontrolle der Kommunikation zwischen zwei Systemelementen durch einen Kontrollpunkt und die Trennung von Kontroll- und Managementebene. Soll die Funktion eines Systemelementes sichergestellt bzw. überprüft werden, so muss dieses Element in seine Bestandteile zerlegt werden. Diese stellen sich dann wiederum als (Sub)Elemente und die Kommunikation zwischen den Subelementen dar, auf die wiederum das Zero Trust Modell angewendet wird. Dieser Ablauf lässt sich wiederholen, bis ein hinreichendes Detail- und Sicherheitsniveau erreicht worden ist.
Damit ist dieses Vorgehensmodell bereits während der Entwicklung sehr einfach auf beliebige IT-Systemmodelle anwendbar.
Security by Design
Als einfaches Beispiel soll das Szenario „Überprüfung des Bestandes einer Ware im Lagersystem“ dienen. Dieses Szenario besteht vereinfacht aus einem Benutzer, der mit einen Client über das Nutzer LAN und das DC LAN auf die Lagerverwaltungssoftware zugreift, die wiederum ihre Informationen aus einer Datenbank bezieht.
An jeder dieser Systemgrenzen kann nun ein Kontrollpunkt definiertwerden. Zwischen Nutzer und Client ist das die User Access Control, zwischen Client und Nutzer LAN ist es die Network Access Control und die Kommunikation zwischen Nutzer LAN und Datacenter LAN wird durch die Macro Segmentierung gesteuert. Im DC LAN kontrolliert ein Network Access Control Element wiederum den Zugriff zwischen Netzwerk und Anwendung und eine Microsegmentierung isoliert und kontrolliert die Interaktionen zwischen verschiedenen Datacenter Services, wie in diesem Beispiel die Kommunikation zwischen dem Anwendungs- und dem Datenbank Service.
Dies ist ein einfaches Beispiel mit ausgewählten Technologien zur Umsetzung der Security Control Points. Selbstverständlich lassen sich diese Kontrollpunkte auch durch alternative Technologies absichern – die Anwendung eines Zero Trust basierten Vorgehensmodells in einem Security by Design Prozess ist grundsätzlich Technologieneutral. Auch haben wir die Vorgehensweise bereits an komplexeren Systemen validiert – diese würden aber Rahmen dieses Blogs sprengen.
Cisco bietet mit der SecureX Plattform für seine Sicherheitsprodukte eine offene Plattform zu technischen Realisierung von Security by Design Informationssystemen. Die skizzierte Lösung lässt sich zum Beispiel durch eine Kombination aus der Identity Service Engine, Secure Access, Secure Firewall, Secure Workload und Secure Network Analytics mit der Digital Network Architecture (DNA) und der Application Centric Infrastructure (ACI) realisieren.
Mein herzlicher Dank gilt Markus Pfaff für die stets inspirierenden Architektur- und Modellierungsdiskussionen!
/1/ Sicherheitsarten: https://dserver.bundestag.de/btd/17/120/1712051.pdf
/2/ Übersicht der Securityframeworks: https://www.computerweekly.com/de/feature/IT-Sicherheits-Frameworks-und-Standards-COBIT-und-ISO-IEC-27000
/3/ NIST Special Publication 800-207: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf
Authors
Dietmar Hilke
Geschäftsleiter Cybersecurity - Deutschland
Cybersecurity Federal Government & Defence
