DevOps hat die Arbeitsweise von Unternehmen grundlegend verändert. Unternehmen bringen innovative Produkte schneller auf den Markt und erzielen dabei größere Einsparungen. Angesichts zunehmender Cyberangriffe können es sich Organisationen jedoch kaum leisten, den Sicherheitsaspekt des DevOps-Modells zu ignorieren. Der Datenverstoß bei Equifax im Jahr 2017 ist eines von vielen Beispielen dafür, wie notwendig es ist, Sicherheitsprüfungen in den Produktionsprozess einzuführen. Eine ungepatchte Schwachstelle kostete das Unternehmen im Rahmen eines Vergleichs über einen US-amerikanischen Datenschutzverstoß unglaubliche 700 Millionen US-Dollar.
Eine IDC-Umfrage ergab, dass weltweit mehr als ein Drittel der Unternehmen in den vergangenen 12 Monaten von einem Datenverstoß betroffen war. In einem weiteren Bericht gaben 71 % der CISOs an, dass ihr Code vor dem Livegang in der Produktion nicht frei von Schwachstellen ist. Diese Zahlen sind besorgniserregend.
Teams müssen DevSecOps für eine sichere Infrastruktur einführen , ohne dabei Geschwindigkeit oder Produktivität einzubüßen. In der schnelllebigen Welt der DevOps-Workflows kann Sicherheit nicht länger nachträglich berücksichtigt werden, sondern muss parallel zur Anwendungsentwicklung erfolgen. Je früher Sicherheit in den SDLC integriert wird, desto besser ist dies für die allgemeine Gesundheit der Organisation.
„Bei DevSecOps geht es nicht um Perimetersicherheit rund um Anwendungen und Daten, sondern darum, durchgängige Sicherheit in die Anwendungen zu integrieren“, erklärt Cloud Advisor Kevin Davis von CloudReach. „Dadurch lässt sich die Logistikkette von Software und Systemen nutzen, um Sicherheitslücken schnell zu erkennen, das Risiko negativer Auswirkungen auf Kunden zu senken und die Wahrscheinlichkeit von Cyberangriffen und Ausfallzeiten zu minimieren. Insgesamt können Unternehmen mit DevSecOps die Zusammenarbeit und Kommunikation zwischen Entwicklungs-, Betriebs- und Sicherheitsteams effizient zusammenführen. Eine Win-win-win-Situation.“
Was ist DevSecOps?
DevSecOps ist eine Softwaremethodik, die Sicherheit in den bestehenden DevOps-Zyklus integriert. DevSecOps stellt den traditionellen SDLC auf den Kopf, indem Sicherheitsprotokolle in jeden Schritt des SDLC-Prozesses eingeführt werden. Dadurch befassen sich Teams mit Sicherheitsbedrohungen, sobald sie auftreten, anstatt später im Entwicklungszyklus auf sie zu reagieren.
Früher wurden Softwareversionen nur selten veröffentlicht. DevOps verkürzte den SDLC auf wenige Tage. In einem solchen Szenario führt es zu unnötigen Verzögerungen und widerspricht dem eigentlichen Konzept eines schnellen und agilen DevOps, wenn ein Sicherheitsteam den Code in der Produktion testet. Eine sichere und schnelle Produkt veröffentlichung ist nur mit einem vollständig automatisierten SDLC möglich. Die Implementierung von DevSecOps ermöglicht es Unternehmen, sicher und zugleich agil zu innovieren.
Außerdem lesenswert: NetOps vs. DevOps: Automatisierung für das Netzwerk
Zentrale Elemente der DevSecOps-Implementierung
Sean Wright, leitender SME für Anwendungssicherheit bei Immersive Labs, sagt: „Sie müssen sich wirklich zu DevSecOps bekennen. Das bedeutet, während des gesamten Lebenszyklus des Prozesses für Sicherheit zu sorgen, in den jeweiligen Phasen die passenden und richtigen Tools einzusetzen und vor allem Ihre Mitarbeiter mit dem nötigen Wissen und den richtigen Fähigkeiten auszustatten, damit sie diese Tools nutzen sowie Sicherheitsprobleme verhindern und beheben können. So kann letztlich jeder dazu beitragen, die Sicherheit einer Anwendung oder eines Dienstes zu gewährleisten.“
Im Folgenden finden Sie einige Best Practices, die Sie bei der Implementierung von DevSecOps in Ihrem Unternehmen berücksichtigen sollten.
Schwachstellenscans
Cyberkriminelle können Schwachstellen in Ihrem Code ausnutzen. Daher ist es für DevSecOps entscheidend, sie in jeder Phase der CD-Pipeline zu erkennen. Angesichts der kurzen Bereitstellungszeiten ist es jedoch nahezu unmöglich, Schwachstellen manuell zu durchsuchen.
Automatisierte Schwachstellenscanner verbessern Ihre Sicherheitslage und verhindern, dass Cyberbedrohungsakteure Schwachstellen in Ihrem System ausnutzen. Static Application Security Testing (SAST) und Dynamic Application Security Testing (DAST) sind die bekanntesten automatisierten Technologien zum Schutz von Anwendungen.
Entwickler nutzen SAST in der Anfangsphase des SDLC, um ihren Quellcode auf mögliche Schwachstellen zu untersuchen. DAST ist ein Black-Box-Ansatz zum Testen, bei dem DAST-Tools wie Hacker agieren und eine Anwendung angreifen, sobald sie läuft.
DAST-Tools liefern deutlich mehr relevante Ergebnisse als SAST-Tools, die häufig zahlreiche Fehlalarme melden. Zusammen schützen SAST und DAST Ihre Anwendungen – sowohl in Vorproduktions- als auch in Produktionsumgebungen.
Interactive Application Security Testing (IAST) ist ein relativ neuer Technologieansatz, bei dem der Code „instrumentiert“ und die Anwendung während des Betriebs überwacht wird. Ein innerhalb der Anwendung eingesetzter Agent überwacht sie und identifiziert Sicherheitslücken, die von SAST- und DAST-Tools übersehen werden.
Asaf Karas, JFrog Security CTO, empfiehlt: „Das Scannen von Paketen auf Schwachstellen ist ein grundlegender Schritt zur Absicherung praktisch jeder modernen Softwarebereitstellungspipeline. Indem Paketscanner bekannte Schwachstellen in jedem zur Bereitstellung einer Anwendung verwendeten Paket automatisch identifizieren, können sie das Risiko, unsichere Software in die Produktion zu bringen, erheblich reduzieren. Es ist außerdem ratsam, in eine umfassende Schwachstellendatenbank zu investieren, da öffentliche Schwachstellendatenbanken wie MITRE CVE oder die National Vulnerability Database des NIST nicht immer die neuesten Informationen zu Bedrohungen enthalten.“
Auf unveränderliche Infrastruktur umstellen
Unveränderliche Infrastrukturen sind ein entscheidender Bestandteil einer sicheren DevSecOps-Pipeline. Im Gegensatz zu veränderlicher Infrastruktur verhindert unveränderliche Infrastruktur eine Konfigurationsabweichung und erleichtert dadurch die Diagnose von Schwachstellen. Wird ein unveränderlicher Server kompromittiert, müssen Entwickler ihn nicht patchen, sondern ersetzen ihn durch einen neuen.
„Unveränderliche Infrastruktur ist direkt an die Nutzung von Infrastructure-as-Code gebunden, das die gesamte Anwendungsarchitektur in Code fasst“, erklärt Aakash Shah, CTO und Mitgründer von oak9. „Mit Infrastructure-as-Code können Unternehmen noch weiter nach links verschieben, um sicherzustellen, dass Sicherheit, Stabilität und Qualität bereits beim Entwurf berücksichtigt werden, indem Designlücken gescannt und behoben werden.“
Kate Adam, Juniper Networks’ Senior Director of Security Product Marketing, ist der Ansicht, dass „unveränderliche Infrastruktur zwar eine sehr gute Idee, ihre flächendeckende Umsetzung jedoch unrealistisch ist, weil die Anwendungen einer Organisation wahrscheinlich unterschiedlich ausgereift sind. Außerdem verfügen viele nicht über ausreichend Zeit in ihren Planungszyklen, um alle Serveranforderungen zu ermitteln, die jemals benötigt werden – und Hut ab vor den Organisationen, die das tun!“
Adam ergänzt: „Wenn Teams Anwendungen jedoch zustandslos machen können, ist die Implementierung unveränderlicher Infrastruktur deutlich einfacher und sollte unbedingt erfolgen. Wenn die Infrastruktur auf diese Weise abgesichert ist, haben Angreifer noch größere Schwierigkeiten, sie und die darauf laufenden Anwendungsdienste auszunutzen.“
Außerdem lesenswert: Die besten Tools für Netzwerktests hinsichtlich Geschwindigkeit und Leistung 2021
Laufzeitschutz
Laufzeitschutz ist entscheidend für eine erfolgreiche DevSecOps-Implementierung. Runtime Application Self-Protection (RASP) ist eine vielversprechende Technologie, die nicht nur eine signaturbasierte Erkennung bietet, sondern auch Schwachstellen effektiv diagnostiziert und Angriffe in Echtzeit abwehrt.
RASP instrumentiert den Code und wird zusammen mit den Schwachstellen in einer Anwendung platziert. Die umfassende Transparenz in die Anwendungsebenen ermöglicht äußerst präzise Bewertungen bösartiger Angriffe und beseitigt Fehlalarme. Bei korrekter Implementierung ist der Code bereits darauf ausgelegt, sich selbst zu schützen.
Allerdings weist Aqua Securitys VP of Product, Story Tweedie-Yates darauf hin, dass „derzeit eine große Wissenslücke im Bereich der Laufzeitsicherheit besteht und aktuelle Forschung gezeigt hat, dass sie in Initiativen für Cloud-native Sicherheit nicht ausreichend berücksichtigt wird. Organisationen müssen in Laufzeitschutz investieren, denn ohne ihn könnten andere wichtige Elemente ihrer Sicherheitsstrategien für den Cloud-Lebenszyklus – darunter Shift Left, Härtung und Scans – hinfällig sein, wenn Angreifer Zugriff auf die Produktionsumgebung erhalten.“
Sichere Container-Images
Container werden häufig in DevOps-Umgebungen eingesetzt, da sie kontinuierliche Bereitstellung und kontinuierliche Auslieferung gewährleisten. Aus Sicht von DevSecOps können sie dennoch bestimmte Sicherheitsrisiken bergen. Container-Images können Schwachstellen enthalten, insbesondere wenn sie aus öffentlichen Repositories stammen. Daher muss jeder DevSecOps-Prozess Container-Images während der gesamten CI/CD-Pipeline absichern.
Für eine robuste Sicherheitslage gibt es dafür mehrere Möglichkeiten:
- Kleine Basis-Images verwenden. Das ist ganz einfach. Je kleiner das Image, desto kleiner die Angriffsfläche.
- Image-Scanner in allen Phasen verwenden. Da täglich neue Schwachstellen entdeckt werden, ist es sicherer, in jeder Phase des CI/CD-Lebenszyklus Image-Scanner einzusetzen.
- Images niemals als Root ausführen. Container-Images als Root auszuführen, kann für Entwickler ein kostspieliger Fehler sein. Bedrohungsakteure mit Root-Zugriff können Ihrer Organisation irreversiblen Schaden zufügen.
Außerdem lesenswert: Sicherheitsmanagement in Multi-Cloud-Umgebungen
Eine Veränderung der Unternehmenskultur
DevSecOps führt Sicherheitspraktiken in das DevOps-Framework ein und fordert eine engere Zusammenarbeit zwischen Sicherheits- und Engineering-Teams. Das ist jedoch leichter gesagt als getan. Tatsache ist, dass Entwicklungs-, Betriebs- und Sicherheitsteams isoliert voneinander arbeiten. Sie unter einem gemeinsamen Dach zusammenzuführen, erweist sich als kompliziert.
Da die Unternehmenskultur tief verwurzelt ist und alle Geschäftsbereiche durchdringt, wird die bloße Einführung von DevSecOps-Praktiken keine unternehmensweite Transformation bewirken. Stattdessen müssen Führungskräfte Systeme schaffen, die für die jeweiligen Teams funktionieren, und eine Kultur der Zusammenarbeit zwischen ihnen fördern.
Bei DevSecOps gibt es keine Universallösung.
„DevSecOps-Experten müssen mit Entwicklungsprozessen und -methoden bestens vertraut sein“, sagt Adam. „Sie müssen sich sehr gut mit Sicherheit auskennen und sowohl Diplomaten als auch Sicherheitsbotschafter sein, um in ihren Rollen erfolgreich zu sein. DevSecOps ist kein Produkt und keine bestimmte Technologie – es ist eine Rolle, die einen Menschen erfordert, weil sich Softwareentwicklungsprozesse von Unternehmen zu Unternehmen unterscheiden und auch die Software in jedem Unternehmen anders ist.“
Trotz der Vorteile, die DevSecOps bietet, stehen viele Organisationen der Einführung von DevSecOps noch immer skeptisch gegenüber. Ebenso wie DevOps erfordert DevSecOps ein Umdenken. Unternehmen müssen erkennen dass Sicherheit in der Verantwortung aller liegt und nicht nur in der des Infosec-Teams. Die Implementierung von DevSecOps wird nicht einfach sein, aber die Veränderung wird sich durchaus lohnen.
Als Nächstes lesen: Die besten DevOps-Tools und -Software 2021