Thought Leadership
Als ich vor fast 30 Jahren meine berufliche Laufbahn begann, war die IT-Sicherheit, zuvor eher ein akademisches Thema, gerade in der öffentlichen Diskussion angekommen. Mit der breiten Einführung des Internets begann für die Kryptographie ein neues Zeitalter: Nun sollte sie mit Standards wie SSL/TLS und IPsec „das Internet sicher machen“. Diese Standards verwenden wir heute immer noch, und zwar auf ziemlich ähnliche Weise. Viele grundlegende Sicherheits- und Vertrauenskonzepte wurden damals in der Wissenschaft entwickelt, z. B. die multilaterale Sicherheit, die ich kürzlich in einem anderen Artikel mit dem Zero-Trust-Paradigma in Verbindung gebracht habe.
Vielleicht haben Sie schon von den “CIA-Zielen” gehört, wenn es um die Entwicklung und Implementierung von Sicherheitsprotokollen geht. Diese Ziele haben nichts mit dem US-amerikanischen Auslandsnachrichtendienst zu tun, sondern sind nach den Anfangsbuchstaben der englischsprachigen Begriffe benannt: Confidentiality (Vertraulichkeit), Integrity (Integrität) und Authenticity (Authentizität). CIA-Ziele sind nach wie vor das Grundprinzip von Sicherheitsarchitekturen. Alle diese Ziele können heute durch gut erforschte kryptografische Bausteine erreicht werden: Verschlüsselung (AES), kryptografische Prüfsummen (HMAC-SHA-3) und Signaturen (EC-DSA) – zumindest, wenn wir die Post-Quantum-Krypto-Debatte für den Moment beiseitelassen. Und glauben Sie mir, in der Praxis ist es ist immer noch eine hohe Kunst, beim Verfolgen der drei Ziele alles richtig zu machen!
Doch damit nicht genug. Meine Lehrer haben immer insistiert: “Vergiss bitte nicht die Verfügbarkeit als viertes Sicherheitsziel!”. Oder, eng damit verwandt, die Resilienz (Widerstandsfähigkeit). Der Einwurf meiner Lehrer erwies sich als sehr relevant, denn in meinem späteren Leben bin ich vielen Sicherheitsapologeten begegnet, die behaupteten: “Das sicherste System ist eines, das man gar nicht an das Netz anschließt.” Oder sogar, im Ton der Verzweiflung angesichts der zunehmenden Komplexität: „Noch besser ist es, das System überhaupt nicht einzuschalten.”
Klar, das ist natürlich im Hinblick auf die CIA-Ziele supersicher! Doch leider wird dabei vergessen, dass in der realen Welt oftmals Abhängigkeiten von der Verfügbarkeit eines Systems bestehen. Wenn zum Beispiel ein Notrufsystem oder ein sicherheitskritisches Steuerungssystem ausfällt oder nicht erreichbar ist, können ernsthafte Risiken entstehen.
Was ich daher aus dem Appell meiner Lehrer gelernt habe, ist: Eine gute Sicherheitsarchitektur muss sowohl sichere als auch verfügbare Lösungen ermöglichen. Doch das ist manchmal schwierig, da die Ziele oft auseinanderdriften oder sogar im Widerspruch zueinanderstehen. Beispiele? Digitale Zertifikate haben ein Verfallsdatum. Die Überprüfung der Gültigkeit und des Ablaufs eines Zertifikats anhand von Zeit, CRL, OCSP oder was auch immer führt früher oder später zu der Entscheidung, eine Verbindung z. B. in TLS oder IKE zu verweigern. Meistens geschieht dies aus guten Gründen, z. B. weil ein Zertifikat manipuliert ist. Manchmal ist aber auch ein Administrationsfehler der Grund, z. B. wenn die Aktualisierung des Zertifikats fehlt. Wollen Sie einen unsicheren Fallback einbauen, um solche Situationen zu verhindern?
Ein anderes – ähnliches – Beispiel ist die Sicherheitszertifizierung. Bugfixes müssen schnell her, die Zertifizierung dauert aber nicht selten Monate oder Jahre. Installiere ich nun den Bugfix oder behalte ich lieber einen zertifizierten Zustand bei? Um nicht allzu oft in solche Situationen zu kommen, sollten wir an diesen Prozessen arbeiten.
Ein verwandtes Konzept, das dem Ziel der Verfügbarkeit zuträglich sein kann, ist die “Fehlertoleranz”. Im Grunde ist sie die Antwort auf Murphys Gesetz: Dinge können kaputtgehen, und Dinge werden auch kaputtgehen. Daher sollte es Fallback-Möglichkeiten geben, die je nach Anforderungen vielleicht weniger funktional und weniger leistungsfähig sein können als das Original-Setup, aber im Falle einzelner Ausfälle immer noch eine Grundfunktionalität gewährleisten. Raumfahrtmissionen sind ein gutes Beispiel für Projekte, bei denen viel technischer Aufwand in die Fehlertoleranz investiert wird. Schließlich wären die Kosten enorm, wenn man bei jedem Fehler direkt von vorn beginnen müsste – und wäre ich Astronaut, würde ich mich sicher nicht auf eine solche Mission einlassen!
Hier kommen wir zum gemeinsamen Nenner all dieser Konzepte: Natürlich hängt die Investition in physische Sicherheit, Fehlertoleranz – und Cybersicherheit – davon ab, welchen Wert man schützen will. Bei einer Weltraummission ist das recht einfach zu berechnen. Manchmal vergessen wir jedoch, strategische Werte zu berücksichtigen. Probleme in der Lieferkette, Abhängigkeiten von einer einzigen Quelle usw. sind das Ergebnis unterschätzter langfristiger Risiken (und Kosten), wie wir in diesen Tagen lernen mussten und immer noch müssen. Aber ich möchte hier nicht tiefer in das Thema (digitale) Souveränität eintauchen – das ist einen eigenen Beitrag wert.
Lassen Sie uns stattdessen einen Blick auf die Widerstandsfähigkeit oder Resilienz unserer kritischen Infrastrukturen werfen. Infrastrukturen beginnen auf der physischen Ebene: Kabel und Glasfasern, Rohre (wenn es um Flüssigkeiten geht) und so weiter. Manchmal vergessen wir diese Tatsache im Hype um Virtualisierung und „Software-Defined Everything“. Die Angriffe auf Kabel der Deutschen Bahn im Jahr 2022 haben eine Diskussion über das Schutzniveau dieser kritischen Infrastruktur ausgelöst. Warum konnten die Angreifer diesen Kommunikationsring so einfach durchtrennen? Weil allgemein bekannt ist, dass die Kabel entlang der Schienen verlaufen. Und wenn man diese an zwei hinreichend weit auseinander liegenden Stellen durchtrennt, führt dies naturgemäß zu einer erheblichen Störung. Bislang war man bei der Deutschen Bahn immer froh, seine Kabel selbst zu besitzen, weil man sich dadurch sicher und unabhängig fühlte. Ist das heute noch angemessen – in Zeiten, in denen nicht nur mit zufällig auftretenden Störungen gerechnet werden muss, sondern auch mit Sabotageangriffen, die möglicherweise von staatlichen Akteuren intendiert sind?
Es scheint ein weit verbreitetes (Miss-)Verständnis zu sein, dass eigene Kabel „sicherer“ sind als die Übertragung sensibler Daten (z. B. die Steuerung von Eisenbahnsignalen und Weichen) über die Infrastruktur Dritter. Das ist jedoch nicht unbedingt der Fall, wenn man auch Ausfallszenarien bis hin zu vorsätzlichen Sabotageangriffen in die Betrachtungen mit einbezieht. Aus dem Blickwinkel der CIA-Ziele gibt es Protokolle wie IPsec VPN oder Technologien wie Layer-2-Verschlüsselung, durch die solche Verbindungen genauso sicher und privat werden wie mit eigenen Kabeln. Unter dem Gesichtspunkt der Resilienz wird oft argumentiert, dass es besser ist, sich auf die Verfügbarkeit seiner eigenen Kabel zu verlassen. Das ist durchaus ein guter Punkt. Allerdings braucht man dann sehr viel mehr – Kabel, aber auch Technologie in den darüberliegenden Netzwerkschichten. Vor allem müssen über diese vielen Kabel (und Funk-/Satellitenverbindungen) robuste Protokolle und Anwendungsschichten betrieben werden, die z. B. den Ausfall einzelner Verbindungen erkennen und reagieren. Und hier kommt die gute Nachricht: Es gibt heute solche robusten Protokolle und Orchestrierungs-Stacks.
Lassen Sie uns kurz in die 1960er Jahre zurückreisen. Es war die Zeit des Kalten Krieges und der atomaren Bedrohung – und der ersten Netzwerkexperimente zwischen Computern. In dieser Zeit wurden das Internet und paketvermittelte Netze geboren. Das allererste Ziel bei der Entwicklung des Internetprotokolls war die Resilienz. Routing-Protokolle, die ein verteiltes Wissen über Erreichbarkeit, Verbindungsqualität und Verfügbarkeit bereitstellen, sind das Herzstück des Internets. Trotz lokaler Ausfälle und in einigen Ländern politisch motivierter Zentralisierung zu Überwachungszwecken können wir das Internet heute als eine der robustesten Infrastrukturen nutzen.
Reicht dann zur Vernetzung einer kritischen Infrastruktur etwa ein einfacher DSL-Zugang aus? Nein, natürlich nicht. Zurück zur Physik: Es ist nicht ausreichend, ein superrobustes Protokoll über eine physische Verbindung laufen zu lassen, wenn diese der einzige Weg zu einer kritischen Anwendung ist. Das gilt ebenso, wenn Protokolle und Anwendungen über meine eigenen (und einzigen) Kabel laufen, wenn das Netz nicht hinreichend ausfall- und sabotagetolerant ausgelegt ist.
Wenn es um Sicherheit geht, beobachten wir oft, dass VPNs die CIA-Ziele auf Basis eines öffentlichen paketvermittelten Netzes umsetzen. Eine sehr sichere und bewährte Technologie ist IPsec. Aber das Design von IPsec führt oft zu statischen Konfigurationen, die sich so unflexibel verhalten wie virtuelle Kabel. Je nach Konzept konterkariert das dann die Ausfallsicherheit der zugrunde liegenden Infrastruktur, oder zumindest entsteht ein sehr statisches Overlay-Netz. Vor einigen Jahren machten wir uns bei secunet daran, diesen statischen Aufbau zu überwinden, und entwickelten eine neue automatisierte VPN-Overlay-Konfiguration namens SOLID. Sie nutzt ein Peer-to-Peer-Protokoll, um das Wissen über Erreichbarkeit in einer geschützten logischen Ringstruktur mit vielen zusätzlichen „Querverbindungen“ zu verteilen. Wir ließen uns dabei von dem Ziel eines dezentralisierten Wissens leiten. Das Ergebnis ist ein supersicheres IPsec-VPN, das auch bei Ausfall oder Kompromittierung einzelner Verbindungen oder Systeme für den Rest des VPNs supersicher bleibt, und dabei noch sehr einfach zu konfigurieren und robust zu betreiben ist.
Interessanterweise beruhen nun wieder viele aktuelle Netzwerk-Hypes wie Software-Defined Networking (SDN) auf zentralisiertem Wissen. Ehemals verteilte Routing-Protokolle werden nun zentralen “Controllern” und der Durchsetzung von Richtlinien untergeordnet. Wir plädieren stattdessen für vollständig dezentralisiertes Wissen. Auch die Richtliniendurchsetzung kann dezentralisiert aufgesetzt werden, wobei es durchaus sinnvoll ist, übergreifende Richtlinien zentral zu erstellen und zu verwalten. Unsere Forschungen zu sicheren SDN/SDWAN-Konzepten zeigen, dass dies möglich ist.
Um es kurz zusammenzufassen: Gemischte physische Infrastrukturen in Verbindung mit der Robustheit der Internet-Protokolle und einer ausgereiften Sicherheitsschicht können heute eine sehr resiliente UND sichere Netzwerkschicht bieten. Eigene Kabel und alte Protokolle können das nicht.
Aber die Netzwerkschicht ist nur ein Teil der Geschichte. Werfen wir also einen Blick auf die nächste Ebene des Protokoll-Stacks – die Anwendungen. Große monolithische Anwendungsdesigns führten zu den geliebten (oder gefürchteten) Neunen: 99,999… Prozent Verfügbarkeit von Rechenzentren, geografische Redundanz, große Notstromaggregate und so weiter. Das alles passt nicht so recht zum dezentralen Ansatz paketvermittelter Netzwerke. Aber es geht auch anders: Schließlich sind wir im Zeitalter der Cloud-Technologie, und mit der Cloud machen auch die Microservices Karriere. Damit stehen wir wahrscheinlich vor einem Paradigmenwechsel, ähnlich dem Schritt zum Internet-Design in der Netzwerktechnologie der 60er Jahre. Modulare Microservices erlauben, intrinsisch resiliente Anwendungen zu bauen, ohne dass die Rechenzentren mit den vielen Neunen nötig wären. Denn die Anwendungen sind nicht mehr von der physischen Infrastruktur wie etwa einem bestimmten Computer abhängig. Sie können transparent verlagert werden, wenn die Hardware ausfällt. Die “Routing-Infrastruktur” wird von einer Microservice-Orchestrierungsschicht wie Kubernetes bereitgestellt.
Dies erfordert natürlich neue Paradigmen beim Anwendungsdesign. Mir gefallen die Begriffe „Eventual Consistency“, „Immutable VMs“ und „Chaos Engineering“. Bei der Resilienz geht es nicht um alles oder nichts, sondern darum, dass immer eine sinnvolle Funktionalität erhalten bleibt. Weg mit den endlosen Neunen an einem einzigen Ort! Her mit der Verteilung von Konnektivität, Daten und Arbeitslast. Das Aufkommen von Edge Clouds ist daher vielversprechend. Doch aktuell sind wir immer noch sehr abhängig von zentralisierten Rechenzentren und noch mehr von einem Oligopol von Cloud-Anbietern. OK, ich habe versprochen, das Thema Souveränität fürs Erste aufzuschieben. Aber auch das gehört letztlich zur Frage der Resilienz.
Natürlich erfordert ein Konzept der verteilten Arbeitslast auch neue Paradigmen in der Sicherheitstechnologie. Alles basiert auf virtualisierten Infrastrukturen (Speicher, Netzwerk, Rechenleistung) – auf der Cloud, sozusagen. Und diese Infrastruktur muss Sicherheitskonzepte bieten, um Microservices sicher verlagern zu können. Ich möchte nicht unbedingt feststellen müssen, dass mein k8s-Container plötzlich auf einem Computer in einem nicht vertrauenswürdigen Land läuft, so wie meine IP-Pakete mit sensiblen Daten nicht ungeschützt im Klartext durch nicht vertrauenswürdige Telekommunikationsnetze geleitet werden sollten. Dafür gibt es VPNs, aber heute brauchen wir auch so etwas wie eine “Virtual Private Cloud”, die mit kryptografischen Mitteln hergestellt wird und dezentralisiert sowie resilient ist. So weit sind wir noch nicht, wir stehen erst am Anfang. Aber die Zutaten dafür sind schon vorhanden, und sie werden immer besser: sichere Virtualisierungsmöglichkeiten und dynamische und skalierbare VPNs wie unser SOLID, dazu sichere Mandantentrennung.
Gehen wir also auf die Reise, nehmen unsere reichhaltige Erfahrung in der Entwicklung von Sicherheitstechnologien mit und behalten immer im Kopf, was meine Lehrer gesagt haben: Verfügbarkeit – oder auch Resilienz – gehören zu den Sicherheitszielen. Kommen Sie mit uns auf die Reise?
P.S.: Normalerweise reise ich ja gern mit der Deutschen Bahn, aber diesmal möchte ich umgekehrt die Deutsche Bahn einladen, mit uns auf die Reise zu gehen. Es lohnt sich bestimmt.
