Experten nehmen das Verhältnis von Security und Softwareentwicklung unter die Lupe.

Foto: pixabay DevOps muss den Ansatz beim Thema Sicherheit ändern In Unternehmen, die auf die DevOps-Methodik setzen, hat sie die Art und Weise, wie Anwendungen entwickelt werden, stark verändert. 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, wie Sicherheitsexperte Palo Alto Networks berichtet. DevOps muss den Ansatz beim Thema Sicherheit ändern. 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? Die Palo Alto-Experten geben vier Tipps zum Verhältnis von DevOps und Security.

1. 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.

2. 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.

3. 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.

4. 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.