Software-Defined Security (SDS): Was, wie und wo.

Ein Interview mit dem Netzwerk- und Rechenzentrumsexperten Ivan Pepelnjak.
 
(Fast) alles ist heute software-definiert, zumindest in den Marketingmaterialien der Anbieter. Und jeder versteht etwas anderes darunter. Hauptsache man kann es als software-definiert anpreisen. Nach den Rechenzentren – Software Defined Data Center (SDDC) – und den Netzwerken – Software Defined Networks (SDN) - hat es nun auch die Sicherheit erwischt. Software Defined Security (SDS) ist das neue Buzzword. Worum es sich dabei genau handelt und was es genau umfasst ist diffus. Um etwas Licht ins Dunkel zu bringen hat sich inside-it.ch mit dem weltweit anerkannten Topexperten Ivan Pepelnjak unterhalten.
 
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?
 
Ivan Pepelnjak: 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?
 
Ivan Pepelnjak: 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?
 
Ivan Pepelnjak: 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?
 
Ivan Pepelnjak: 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?
 
Ivan Pepelnjak: Ich würde mit Gartner’s Checkliste für "Shiny New Object" beginnen:
  1. Gibt es ein Problem?
2. Kann die zugrundeliegende Ursache für Problem mittels Änderung der Richtlinien und Prozesse eliminiert werden?
3. Wird einer meiner Lieferanten innert Jahresfrist eine vergleichbare Lösung im Angebot haben?
4. Verfüge ich über Netzwerk- oder Sicherheitsfunktionalitäten, welche die meisten der benötigten technischen Anforderungen abdecken?
5. 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.) (Gespräch: Christoph Jaggi)
Hinweis: Im Rahmen eines Events der Data Center Interest Group Switzerland (DIGS) leitet Ivan Pepelnjak am Morgen des 7. Juni in Zürich einen Workshop zum Thema Software Defined Networks (SDN). Am Nachmittag desselben Tages hält er am DIGS Special Event, der die Bereiche Microsegmentation, SDS, SDN und NSX abdeckt, ein Referat über Mikrosegmentierung.
 
Wer ist Ivan Pepelnjak? Ivan Pepelnjak gilt als einer der weltbesten Experten auf dem Gebiet von Netzwerken, Cloud, Rechenzentren und skalierbarem Web Application Design. Sein Blog ist eines der meistgelesenen Technologie-Blogs. Als Consultant berät und begleitet er Unternehmen durch Paradigmenwechsel und zeigt auf, wie gleichzeitig die Kosten verringert und die operationelle Effizienz gesteigert werden kann. Seine Webinare, Bücher und Blogeinträge machen sein breitgefächertes Wissen der Allgemeinheit zugänglich. Auf seiner Website findet sich eine grosse Anzahl an Blogposts, Präsentationen und Webinaren. (cj)