Die Kluft überbrücken: Flexibilität und Sicherheit

Was tun Sie, wenn Sie zwei Dinge brauchen, aber „jeder weiß“, dass sich die beiden gegenseitig ausschließen?

In der Netzwerk- und Sicherheits-Community hält sich seit langem ein Mythos: Sichere Softwarearchitekturen sind unflexibel und agil bereitgestellte Software ist weniger sicher.  Aber Moment mal – gibt es irgendwelche Beweise dafür, dass Software, die mit einem iterativen Modell entwickelt wurde, grundsätzlich weniger sicher ist? Wenn ja, dann ist meine „Forschung“ (lies: Googeln hat nicht wirklich etwas gebracht.   

Tatsächlich lässt sich glaubhaft argumentieren, dass ein schnellerer Lieferzyklus und ein automatisierter, optimierter Veröffentlichungsprozess das Risiko durch die Verkürzung der Gesamtdauer der Schwachstelle verringern.    

Gibt es also wirklich eine Kluft zwischen Flexibilität und Sicherheit? Traurigerweise würde ich immer noch sagen: Ja, das gibt es. 

Ich bin jedoch nicht davon überzeugt, dass ein agiler Software-Lebenszyklus mehr inhärente Schwachstellen im Code mit sich bringt (obwohl einige der neuen Plattformen – wie etwa Container-Management-Systeme – sicherlich neue Angriffsflächen schaffen), da der Anwendungscode nur einen Teil der allgemeinen Sicherheitslage eines Unternehmens ausmacht.

Angesichts der Tatsache, dass jede Software Fehler aufweist, enthalten IT-Technologie-Stacks auch externe Sicherheitskontrollen außerhalb des Anwendungscodes, wie Netzwerk-Firewalls, Intrusion Detection Systems und Web Application Firewalls. Viele dieser Systeme müssen das Anwendungsverhalten verfolgen und auf neu entdeckte Bedrohungen in Frameworks oder Betriebssystemen reagieren. Idealerweise müssen diese Systeme so agil sein wie der Softwarebereitstellungszyklus. Denn wenn dies nicht der Fall ist, wird eines von zwei Dingen passieren: Entweder erweisen sich die Sicherheitskontrollen als Beeinträchtigung der Liefergeschwindigkeit und der Wertschöpfungszeit oder sie bieten nicht den Schutz, für den sie eingerichtet wurden. Keines dieser Dinge ist wirklich optimal.  

Die naheliegende Lösung besteht darin, das Sicherheitskontrollmodell näher an das Lebenszyklusmodell der Softwarebereitstellung anzupassen. Tatsächlich beginnt die DevSecOps-Bewegung damit, Softwareentwicklungs- und DevOps-Praktiken auf die Bereitstellung von Sicherheitskontrollen anzuwenden und die Verantwortung für die Sicherheit auf alle Teammitglieder zu verteilen, auch wenn das Fachwissen weiterhin bei einem sehr erfahrenen, spezialisierten Team von Praktikern verbleibt.

Dieser kulturelle Wandel geht mit einer technologischen Entwicklung einher, bei der die Implementierung von Sicherheitskontrollen in die Softwarebereitstellungspipeline integriert wird. Dabei begleiten die Sicherheitskontrollen jede neue Softwareiteration durch Test, Staging und Bereitstellung und werden nicht erst am Ende hinzugefügt. Hier werden Telemetrie- und Nachverfolgbarkeitselemente eingefügt und über mehrere Punkte im Stapel verfolgt. Hier können neue Messwerte schnell erfasst und analysiert werden, um Angreifer zu identifizieren, zu verfolgen und zu melden. 

Um dies zu ermöglichen, muss Ihr Technologie-Stack ebenso eng zusammenarbeiten wie Ihre Teams. Das ist eine der interessantesten Möglichkeiten in einer zukünftigen F5 + NGINX-Organisation. Mit einem Portfolio, das von der Netzwerk-Firewall bis zum Anwendungsserver und über alle dazwischen liegenden Schichten reicht, sind die Möglichkeiten für einen flexibleren, besser integrierten und aussagekräftigeren Satz von Sicherheitskontrollen enorm. Das Versprechen von Sicherheit und Transparenz der Enterprise-Klasse gepaart mit leichter Agilität hat das Potenzial, jedem im Team die Tools, Informationen und (relative) Sicherheit zu geben, die es sucht.

Weitere Informationen zu den Vorteilen der Zusammenführung von F5 und NGINX finden Sie in einem Beitrag des CEO von F5, in dem er die Blogserie „Bridging the Divide“ vorstellt.