Security und Softwareentwicklung hinterfragt:Warum DevOps die Sicherheit verändern muss

Setzt ein Unternehmen auf die DevOps-Methodik, dann verändert sich die Art und Weise stark, wie Anwendungen entwickelt werden. Das Hinzufügen von Sicherheit in diese Methodik stand bislang jedoch nicht im Vordergrund des Denkprozesses der Entwickler. Dies kann zu vielen Lücken in bereitgestellten Anwendungen führen. Daher sollten man beim DevOps-Ansatz das Thema Sicherheit berücksichtigen.

DevOps-Teams können durch die Integration von Sicherheit während der Build-Zeit zusätzliche wertvolle Einblicke gewinnen, um die Sicherheit zu gewährleisten. Aber was sind die erforderlichen Änderungen, und welche Auswirkungen haben diese auf die Sicherheitsarchitektur und den Betrieb? Was muss gleichbleiben und was muss geändert werden?

• Bei Sicherheit kommt es auf Tempo an: Selbst mit manuellen Approval Points, die in den Workflow eingebaut sind, werden traditionelle Sicherheitsbetriebsmodelle einen Engpass darstellen. Um effektiv arbeiten zu können, müssen Sicherheitsteams das DevOps-Modell umsetzen und die Sicherheit integrieren, um Tests und Kontrollen als Teil der Pipeline zu liefern. Dies wird die Einführung einiger neuer Tools, die Verlagerung der betrieblichen Praktiken und einige neue Fähigkeiten erfordern. In einem von DevOps gesteuerten Unternehmen ist dies die einzige Möglichkeit, damit ein verantwortliches Team den Schutz des Unternehmens gewährleisten kann.
• Shift Left, Verschiebung an den Anfang: Die „Verschiebung der Sicherheit nach links“ bedeutet, Sicherheitsüberlegungen frühzeitig in den Lebenszyklus der Software-Lieferung einzubringen, möglichst weit links in der Zeitleiste. Dies ist sinnvoll, weil einige Sicherheitsschwächen während der Konstruktionsphase der Anwendungsentwicklung leichter zu erkennen – und viel kostengünstiger zu beheben – sind als nach der Bereitstellung der Software. Was dies jedoch nicht bedeuten kann, ist die vollständige Übertragung der Verantwortung für die Anwendungs- und Laufzeitsicherheit auf ein Entwicklungsteam. Sicherheits- und Entwicklungsteams müssen zusammenarbeiten, um Bedrohungen und Kontrollen früher zu erkennen und Sicherheitstests in den Workflow der Softwarebereitstellung einzufügen. Die spezifischen Werkzeuge, die ein Entwicklerteam zur Automatisierung von Sicherheitstests benötigen, sind verfügbar, auch wenn sie nicht überall eingesetzt werden.
• Analyse von Bedrohungen: Entwickler übernehmen mehr Verantwortung für den Runtime-Stack, auf dem ihr Code ausgeführt wird. Sie nutzen Ansätze wie Infrastructure-as-Code, um eine gesamte laufende Anwendungsumgebung zu definieren, oder Dockerfiles, um ihre Anwendungscontainer zu definieren. Im Gegenzug müssen die Sicherheitsteams die möglichen Bedrohungen innerhalb dieser Entwicklungsumgebungen verstehen. Sie müssen Tools bereitstellen, die sich bereits in den frühesten Phasen der Anwendungscodierung integrieren lassen. Auf diese Weise können Teams unsichere Konfigurationen erkennen, so dass sie noch vor der ersten Codeübergabe behoben werden können.
• Umfassende DevSecOps: Das von DevOps inspirierte Modell der Softwarebereitstellung findet immer mehr Verbreitung. Daher müssen sich die anderen Teile der IT, insbesondere die Sicherheit, an schnellere Entwicklungszyklen und neue Angriffsvektoren innerhalb einer hochautomatisierten Softwarebereitstellungs-Pipeline anpassen. Dies soll zusätzlich zur Implementierung von Best Practices im Bereich der Sicherheit und zum Schritthalten mit den sich ständig ändernden Bedrohungen und Kompromisstechniken erfolgen. Das einzige Risiko, das im Gegensatz zu Cyberbedrohungen abnimmt, besteht darin, in Sachen Sicherheit nichts zu tun zu haben, denn tatsächlich gibt noch jede Menge zu tun. (rhh)

Palo Alto Networks