Softwareentwicklungen sind oft im produktiven Einsatz, ohne das Qualitäts- und Sicherheitsüberprüfungen durchgeführt wurden. Richtlinien und Standards sind meist nicht vorhanden und werden nicht im Entwicklungsprozess berücksichtigt. Dies führt dazu, dass lauffähige Entwicklungsstände keine Struktur aufweisen. Sicherheitslücken werden nicht erkannt und somit nicht behoben, wodurch Schwachstellen im System auftreten können. Somit steigt die Wahrscheinlichkeit eines erfolgreichen Angriffes auf das System, was hohe Kosten für eine mögliche Schadensminimierung bzw. Fehlerbehebung bedeuten kann.

Integration von Security in DevOps

Die Erweiterung des in Blogartikel Warum braucht mein Unternehmen DevOps erläuterten DevOps-Paradigmas, wird als „DevSecOps" bezeichnet. Die Hauptmerkmale sind es Qualitäts- und Sicherheitsverbesserungen in Softwareentwicklungen durchzuführen. Dies wird durch Automatisierung, Überwachung und der Integration von Sicherheitsaspekten in die zyklische Prozesskette des Paradigmas erreicht.1
Der Sicherheitsaspekt wird wie in dem zuvor verwiesenen Blogartikel beschrieben, nach dem „Shift-Left"-Prinzip in die Prozesskette integriert, wodurch die Qualitäts- und Sicherheitsverbesserungen bereits frühzeitig möglich werden.²​

 

Phasen des Paradigmas

Grundsätzlich gibt es keinen definierten Standard zur Umsetzung des Paradigmas. Die Umsetzung sollte sich daher nach den gegebenen Anwendungsfällen richten. Die im Folgenden erläuterten Phasen richten sich nach der zyklischen Prozesskette von Larry Maccherone, wodurch eine mögliche Realisierung des Paradigmas erläutert wird.³
Diese wird in der folgenden Abbildung grafisch dargestellt:

Die Prozesskette wird in eine Pre-Produktionsumgebung und eine Produktionsumgebung unterteilt. Dies ermöglicht eine zuverlässige Veröffentlichung der Software, da diese erst nach erfolgreichem Testen produktiv geschaltet wird.
In der Phase „Plan" werden Anforderungen und Vorgehensweisen geplant und Verbesserungsvorschläge sowie Kundenbedürfnisse berücksichtigt. Des Weiteren wird verstärkt Rücksicht auf sicherheitsrelevante Aspekte genommen, die zuvor analysiert wurden. Somit ist es möglich, frühzeitig Risiken zu identifizieren und darauf entsprechend zu reagieren.⁴

Die nächste Phase „Develop Code / Tests" wird um das Testen erweitert. Static Analyse Security Testing (SAST) und Interactive Application Security Testing (IAST) werden an dieser Stelle ergänzt. SAST ermöglicht es hierbei, dem Entwickler Sicherheitslücken oder auch einen potenziell fehlerhaften Code in einer frühen Entwicklungsphase aufzudecken, da die Entwicklung im Source Code mithilfe von Analysetools getestet wird.⁵

IAST wird für das Auffinden von Sicherheitslücken in Webapplikationen verwendet. Erreicht wird dies mithilfe von Analysetools, welche einen Schwachstellenscan auf Webapplikation ausführen.

In der Phase „Build" werden Änderungen aus dem Repository bestenfalls automatisch in den Entwicklungsstand integriert und zusammen mit den benötigten Abhängigkeiten paketiert.

Anschließend wird der gesamte Entwicklungsstand auf bekannte Sicherheitsrisiken analysiert. Hierzu werden Common Vulnerabilities and Exposures (CVE)-Listen verwendet, um die Entwicklungsstände sowie deren Abhängigkeiten mit veröffentlichten Sicherheitslücken bzw. Schwachstellen zu vergleichen.6 Diese Phase wird als „Test" bezeichnet.

Während einer Projektbearbeitung ist das Berücksichtigen der IT-Unternehmensrichtlinien notwendig. Hierbei ist das Ziel, Regularien einzuhalten, um eine strukturierte und ordnungsgemäße Projektabwicklung zu gewährleisten. Dies kann z. B. mithilfe eines Quality Gates projektspezifisch ermöglicht werden. Hierbei werden die Richtlinien, auch Policies genannt, vom Projektbesitzer definiert. Festgelegte Werte der Richtlinien werden zu Beginn eines Projektes gering gehalten und sukzessive erhöht, was zur Akzeptanz und Einhaltung dieser führt. Dieses Verfahren führt zur Erreichung einer kontinuierlichen Qualitätsverbesserung. Die Überprüfung der Richtlinien wird in der Phase „Validate More" durchgeführt. Des Weiteren wird die Entwicklung mittels umfassenderen Sicherheitstests analysiert. Hierzu wird das System verschiedenen Negativtests ausgesetzt. Dies wird als „Fuzzing" bezeichnet. Ziel ist es, das System mit invaliden Daten zu testen, um eventuell anfallende Schwachstellen auszuschließen.7 Zudem werden innerhalb dieser Phase Penetrationstests ausgeführt, die Angriffe auf das System simulieren. Ziel ist es eine Schwachstelle und deren mögliche Auswirkungen auf das System zu erkennen.⁸

Es folgt die Phase „Configure & Deploy"; hierbei wird der Entwicklungsstand vor einer Veröffentlichung mittels einer Konfigurationsvalidierung überprüft. Es werden Spezifikationen festgelegt, die sicherstellen, dass Fehlkonfigurationen nicht innerhalb der Produktionsumgebung auftreten. Fehlerhafte Konfigurationen sind an dieser Stelle z. B. falsche Werte eines Elementes innerhalb einer Konfigurationsdatei oder falsch konfigurierte Rechte für Dateien.⁹ Anschließend werden innerhalb dieser Phase Features getestet, bei denen Funktionalitäten zur Laufzeit ein- oder ausgeschaltet werden können. Dies wird als „Feature Toggle" bezeichnet. Die Phase dient ebenso der Verwaltung der Bandbreite des verwendeten Netzwerkes, um eine funktionierende Netzwerkleistung im Betrieb zu gewährleisten. Der Fachbegriff hierzu lautet „Traffic Shaping".¹⁰

Nachdem die Konfigurationen überprüft und die Entwicklung veröffentlicht wurden, startet die Phase „Monitor". In dieser Phase wird die Anwendung überwacht, um Fehler im produktiven Betrieb zu erkennen und daraus Maßnahmen zur kontinuierlichen Verbesserung abzuleiten.
In der nächsten Phase „Detect" werden Angriffserkennungen in die Prozesskette implementiert. Für die Erkennung von Angriffen auf System oder Netzwerk werden Intrusion Detection Systeme (IDS) verwendet.¹¹

Ein weiterer Ansatz für eine Angriffserkennung ist Run-time Application Security Protection (RASP). Hierbei wird die Anwendung verifiziert, indem der binär geladene Code der Anwendung vor der Laufzeit analysiert und anschließend mit der Anwendung während der Laufzeit verglichen wird.12 Dies erfolgt in der Phase „Contain". Wurde ein potenziell infiziertes System detektiert, müssen umgehend Maßnahmen ergriffen werden. Dabei soll das System nicht heruntergefahren, sondern vom Netzwerk isoliert werden, um eine Ausbreitung zu verhindern. Befindet sich das System innerhalb eines produktiven Netzwerkes, ist von Anmeldungen mit privilegierten Nutzerkonten dringend abzuraten. Anschließend sollte eine forensische Analyse durch Dienstleister oder Strafverfolgungsbehörden durchgeführt werden.¹³

Um Ausfallzeiten gering zu halten, werden in der Phase „Stabilize" Wiederherstellungsmöglichkeiten vorbereitet. Die Datensicherung des produktiven Systems wird vorgenommen, um ggf. nach einem Systemverlust den Stand des letzten Backups aufzuspielen. Die Voraussetzung hierfür ist, dass die Datensicherung in kleinen Intervallen regelmäßig vorgenommen wird.¹⁴

Ziel der Phase „Analyze" ist die Ursachenanalyse von im Betrieb aufgetretenen Fehlern. Diese sowie unerwünschte Ereignisse werden auf ihre Entstehung analysiert, bewertet und ggf. in späteren Phasen an ihrem Ursprung behoben. So wird der Wiederholung des Fehlers entgegengewirkt.¹⁵

Risiken werden in der Phase „Predict" auf ihre Auftrittswahrscheinlichkeit eingeschätzt, um diese in der anschließenden Phase „Plan" zu berücksichtigen. Daraus hervorgehend werden Aktionen festgelegt, die ein solches Risiko reduzieren.¹⁶

Fazit

Die Umsetzung bzw. das Arbeiten nach einem DevSecOps-Paradigma innerhalb eines Unternehmens ist eine Herausforderung. Der Umgang mit den Tools sowie die Integration der Tools in die DevSecOps-Prozesskette erfordern ein umfassendes Know-how, um die einzelnen Prozesse innerhalb der Phasen sinnvoll umzusetzen und anschließend zu betreuen. Ebenso spielt die Benutzerakzeptanz hierbei eine wichtige Rolle. Entwickler müssen mit den Tools vertraut gemacht werden und verstehen, wie mit diesen umzugehen ist. Somit entsteht ein zusätzlicher Zeit- und Kostenfaktor. Dieser wird jedoch bei der Fehlerbehebung eingespart, da die Software mit guter Qualität veröffentlicht wird, soweit es die Analysetools ermöglichen.¹⁷ Aufgrund dessen sinkt zusätzlich der Bedarf für nachträgliche Sicherheitsüberprüfungen. IT Security spezialisierte Fachkräfte, die ein manuelles Überprüfen auf Sicherheitslücken bewerkstelligten, werden somit nur noch bedingt benötigt.¹⁸

Seminarempfehlungen