Man liest und hört immer mehr über Software Defined Security (SDS). Ursache der zunehmenden Verwendung dieses Begriffs scheint aber mehr das Marketing als Technologie zu sein. Seit Jahrzehnten sind die meisten, wenn nicht sogar alle Sicherheitsfunktionen software-definiert. Was ist bei SDS anders und was ist neu?
Aus dieser Perspektive macht Software-Defined Security noch weniger Sinn als Software-Defined Networking. Es gibt übrigens Netzwerkgeräte, die Forwarding-Funktionalität in Hardware implementieren...
Es ist ein aussichtsloses Unterfangen die gesamte aktuelle "Software-Defined"-Terminologie so zu ändern, das sie effektiv Sinn macht. Zumindest kann man aber versuchen, eine brauchbare Definition für "Software-defined" zu finden. Die Definition, welche den Fokus auf das Verwalten von Services mittels Abstraktion der zugrundeliegenden Funktionalität legt, funktioniert relativ gut.
Für SDS braucht es meiner Ansicht nach dazu zwei Dinge:
- Ein gut dokumentiertes API, über das man den Betriebszustand abfragen und die Gerätekonfiguration (Hard State) und den Soft State ändern kann;
- Die Möglichkeit, auf Verlangen Sicherheitsdienste einzurichten und sie je nach Bedarf in den Übermittlungspfad einzufügen.
Sicherheit ist keine einzelne Funktion sondern ein Prozess. Das Ziel dieses Prozesses ist Daten- und Netzwerksicherheit. Verschlüsselung, Intrusion Detection, Intrusion Prevention, Schutz vor DDoS-Attacken und Data Loss Prevention sind einige der Funktionen, welche den Prozess unterstützen. Wie passt Software Defined Security da rein?
Man kann alle erwähnten Funktionen abstrahieren und deren Verwendung vereinfachen. Ich nenne einige Beispiele:
- Lösungen für Mikrosegmentierung verteilen automatisch Regeln für Firewalls. Diese Regeln werden mit Hilfe der Daten aus dem Orchestrierungssystem erstellt. Dazu gehören zum Beispiel die Namen von Virtual Machines oder die IP-Adressen, die zu einer Gruppe gehören;
- Software-definierte WAN-Lösungen schützen automatisch allen Verkehr, der über öffentliche Netzwerke geführt wird;
- Unterschiedliche Funktionen lassen sich mittels Service Chaining verketten. Dies ermöglicht das bedarfsgesteuerte Zusammenstellen mehrerer sequentieller Sicherheitsfunktionen;
- Frameworks für Network Function Virtualization (NFV) erlauben es Benutzern, Instanzen von Sicherheitsfunktionen bedarfsgesteuert einzusetzen.
Eine vollständige Automatisierung erfordert, dass sämtliche benötigte Ressourcen ständig online und erreichbar sind. Kann dies zu einer vergrösserten Angriffsfläche führen, die ausgenutzt werden kann?
Absolut. Jedes API bietet eine zusätzliche Angriffsfläche. In der zentralisierten Verwaltung und in den Orchestrierungssystemen befinden sich zudem die von allen Angreifern begehrten Kronjuwelen. Die Sicherheitsproblematik ist aber nichts Neues. Diese Herausforderungen bestehen seit Jahrzehnten.
Was sind die typischen Nutzungsszenarien für SDS? Ist die Nutzung von SDS auf virtualisierte Rechenzentren beschränkt oder findet SDS eine breitere Verwendung?
Die meisten operationellen Nutzungsszenarien von SDS, die ich kenne, sind tatsächlich in Rechenzentren im Einsatz. Vorwiegend in Private und Public Clouds. Dazu gehören:
- Mikrosegmentierung, inklusive automatischer Erstellung von Sicherheitsregeln und der automatischen Validierung der Einhaltung der Sicherheitsvorgaben;
- Werkzeuge zum Entdecken und Abmildern von Denial-of-Service-Angriffen, inklusive automatischem Umleiten auf spezialisierte Dienste, welche den Datenfluss reinigen;
- Umgehung des Firewalls für hochvolumige Datenflüsse;
- Programmierbare Network Taps und Tap Aggregation Networks;
- hoch-skalierbare Netzwerkdienste;
- Hochgeschwindigkeitsnetzwerkanalyse;
- konsistente Durchsetzung von Richtlinien an den Rändern
Was sind die wichtigsten Punkte, auf die man bei einer Suche nach einer SDS-Lösung beachten sollte?
Ich würde mit Gartner’s Checkliste für "Shiny New Object" beginnen:
- Gibt es ein Problem?
- Kann die zugrundeliegende Ursache für Problem mittels Änderung der Richtlinien und Prozesse eliminiert werden?
- Wird einer meiner Lieferanten innert Jahresfrist eine vergleichbare Lösung im Angebot haben?
- Verfüge ich über Netzwerk- oder Sicherheitsfunktionalitäten, welche die meisten der benötigten technischen Anforderungen abdecken?
- Wenn wir Produkte mit neuen Technologien kaufen: Haben wir die richtigen Prozesse und das nötige Know-How, um sie richtig einsetzen zu können?
In vielen Fällen zeigt sich, dass die Ursache für das zu lösende Problem nicht in der Technologie, sondern in Leuten, Silos, untauglichen Prozessen und starren Richtlinien zu finden ist. Die Anschaffung neuer Technologie ändert in solchen Fällen nichts an der zugrundeliegenden Ursache und hilft entsprechend wenig bei der Lösung des Problems.
Steht eine Anschaffung neuer Technologie an – auch für Neuausbau und Ersatz im Rahmen normaler Erneuerungszyklen – so würde ich sicherstellen, dass:
- die Funktionalität auch in virtuellem Format als reine Softwarelösung verfügbar ist, auch wenn man schliesslich doch eine Appliance kauft;
- via eine gut dokumentierte API Interaktionsmöglichkeiten mit den Sicherheitsfunktionen (Sicherheitslösungen, VMs, physikalische Appliance) bestehen;
- die geplante Lösung so wenig bewegliche Teile wie möglich hat (Gateways, Integrationspunkte, Plugins, etc.)
Dieses Interview wurde am 1. Juni 2016 auf Inside-IT publiziert. Die englische Orginalversion findet sich auf Ivan Pepelnjak's Blog IPspace.net.