Sicherheit und DevOps vereinen – so geht es in der Praxis Der Weg zu DevSecOps

Anbieter zum Thema

Insider Research

Vogel IT-Akademie

OutSystems

Security muss eng mit den DevOps-Prozessen integriert und gleich zu Anfang der Entwicklung berücksichtigt werden. Doch wie schafft man diese Veränderung, die weniger die Technik als vielmehr die Organisation und Unternehmenskultur betrifft? Beratungshäuser und Marktforscher geben Empfehlungen, die sich zu einem Vorgehensmodell entwickeln lassen.

Im Mittelpunkt steht die Unternehmenskultur

Wer DevSecOps zu technisch sieht, kann sein Ziel nicht erreichen. Tools und technische Verfahren werden zwar benötigt, doch sie machen nicht den wesentlichen Unterschied zu klassischen Vorgehensmodellen bei der Softwareentwicklung aus.

E-Book zum Thema

Das eBook „DevOps und Security“ erläutert die Unterschiede von DevSecOps, SecDevOps und DevOpsSec und befasst sich mit dem Warum und Wie.

eBook herunterladen

Von Beratern hört man oft einen Satz zu DevSecOps, der zeigt, wie sehr es um Organisation und Firmenkultur geht: Wenn Fehler geteilt und nicht verborgen werden, kann dies das Lernen im gesamten Unternehmen beflügeln und zu zukünftigen Verbesserungen führen.

Bei DevSecOps geht es um Veränderungen in der Kultur des Unternehmens, nicht nur um neue Verfahren und um Tools, um die Transparenz, die Zusammenarbeit und die Agilität zu optimieren, während die Security in jede Phase der Entwicklung Einzug hält.

Von DevOps für DevSecOps lernen

Wer bereits DevOps eingeführt hat, kann diese Erfahrungen nutzen, um DevOps zu DevSecOps zu erweitern, wie zum Beispiel Empfehlungen der Marktforscher von Gartner zeigen:

• Zuerst muss es eine Business-Entscheidung geben, warum DevSecOps eingeführt werden muss. Die steigenden Cyberrisiken und die möglichen, hohen Schäden bei erfolgreichen Attacken bieten ebenso Argumente wie die Compliance-Forderungen zu Security by Design.

• Dann gilt es ein gemeinsames Verständnis für DevSecOps zu entwickeln, damit jeder im Unternehmen weiß, was dies bedeutet und was es bringen soll.

• Man sollte immer mit der Entwicklung einer Applikation anfangen und nicht versuchen, DevSecOps gleich in ganzer Breite anzuwenden.

• Für diese erste Applikation muss es dann ein übergreifendes Team aus Entwicklung, Betrieb und Security geben, mit klaren Zielen, die messbar sein sollten.

• Dann geht es schließlich um die Verfahren und Tools (Toolchain). Die Implementierung umfasst eine integrierte Toolchain, die einen Ansatz zur Bewertung und Auswahl von Tools ermöglicht, sodass jedes Tool im Anwendungslebenszyklus mit dem benachbarten Tool gekoppelt werden kann. Durch die Verknüpfung aller Automatisierungs-Touchpoints und Informationsflüsse wird die Entwicklung von Releases durch die Toolchain beschleunigt und gleichzeitig Fehler, Nacharbeiten und Ausfälle reduziert.

Was es mit der Automatisierung der Security auf sich hat

Die DevSecOps-Bausteine „Kommunikation“ und „Zusammenarbeit“ scheinen dem dritten Baustein „Automatisierung“ entgegenzulaufen: Denn wenn Menschen sich austauschen, kann dies als kontinuierlicher Prozess gesehen werden, aber automatisch geht dies nur auf Tool-Ebene, nicht bei uns Menschen.

Tatsächlich bedeutet die Automatisierung auch, dass wir Menschen Aufgaben an die Technik delegieren. Im Fall von Security sollen also Security-Maßnahmen delegiert und automatisiert werden. Dies spart Zeit und Aufwände für Aufgaben, die der menschlichen Expertise bedürfen. Gerade im Bereich der Softwaretests stehen viele Tools zur Verfügung, die automatische Funktionen vorhalten. Diese gilt es in den Entwicklungsprozess zu integrieren.

Wie die Security an die richtige Stelle gerückt wird

Betrachtet man den Entwicklungsprozess genauer, wird deutlich, wo die Security ansetzen muss und wo etwas automatisiert werden kann. Der übliche, kontinuierliche Prozess bei der Entwicklung sollte sein:

• Erstellung neuer Module, Funktionen und Updates

• Überwachung und Kontrolle des Codes und der Einhaltung der Security-Anforderungen

• Einstellen des aktualisierten und getesteten Codes in das zentrale Repository

Security muss dabei aber gleich zu Anfang berücksichtigt werden. Security-Standards müssen also Teil der Entwicklungsstandards werden. Security ist somit eine Anforderung an das Development, wie alle anderen Qualitätskriterien auch.

Abweichungen von den Anforderungen und damit auch von der Security müssen durch eine Feedback-Schleife direkt und kontinuierlich an die Entwickler gehen. Dazu gehören auch Fehlermeldungen, die bei den automatisierten Security-Tests erzeugt werden und die nicht nur an die Security gehen sollten, sondern an alle Beteiligten im Team. An der Behebung arbeiten dann auch alle im Team mit, Security gemeinsam mit der Entwicklung und dem Betrieb.

Es geht also darum, automatisierte Sicherheitsprüfungen in den Entwicklungsprozess zu integrieren, um die Security-Risiken gleich an der Quelle zu beheben. Auch Code Reviews müssen fortlaufend erfolgen und nicht erst bei Abgabe eines fertig entwickelten Moduls.

Die Praxis zeigt zudem, dass es Sinn machen kann, Belohnungen für das Aufdecken von Fehlern zu vergeben, intern im Team, also ein internes Bug-Bounty-Programm zu etablieren. Dabei sollen die aufgedeckten Fehler belohnt und nicht etwa die entdeckten Fehler bestraft werden. Die Unternehmenskultur muss fehlertolerant sein, damit sich Agilität ausbreiten kann.

Dieser Artikel ist ursprünglich in unserem eBook „DevOps und Securiy“ erschienen. Dieses beleuchtet die aktuellen Entwicklungen oder auch die Unterschiede zwischen DevSecOps, SecDevOps und DevOpsSec.

E-Book zum Thema

DevOps und Security

Sicherheit sollte eng mit den DevOps-Prozessen integriert und gleich zu Beginn der Entwicklung berücksichtigt werden. Die Frage lautet, wie man eine Veränderung am besten umsetzt, die Organisation und die Unternehmenskultur betrifft.

Dieses eBook umfasst die folgenden Themen:

• Wozu DevOps um Security erweitern?
• DevSecOps, SecDevOps und DevOpsSec
• DevSecOps: So geht es in der Praxis

eBook „DevOps und Security“ herunterladen

(ID:47006309)