SecDevOps, DevSecOps oder DevOpsSec?

Die Art und Weise wie Anwendungen heute entwickelt werden, ändert sich mit der Verbreitung von Cloud-Technologien frappant. Microservices, welche z.B. als Dockerservices zur Verfügung gestellt werden und sich miteinander kombinieren lassen, bringen die Infrastruktur-Welt arg in Bedrängnis. «Network is Code», «Infrastructure is Code», «Everything is Code». Die Zeiten von reinen Virtualisierungsumgebungen und von Prinzipien wie «pro Applikation ein Server» sind bald einmal gezählt.

Brave new world

Bei der Anwendungsentwicklung ist heute die Sprache von DevOps. Die engmaschige Verzahnung von Entwicklung und Betrieb ist unlängst mittels moderner Deployment-Methoden und -Tools umsetzbar. In der Cloud ist es möglich, ohne aufwendige Test-, Integrations- und Produktionsumgebung auszukommen. Von der Entwicklung direkt in die Produktion heisst die Devise. Beta-Tester sind innovative Benutzer direkt aus der Community. Die neuen Softwareverteilmechanismen auf der Ebene der Anwendungen und Microservices sowie der Möglichkeit, in der Cloud via Loadbalancing feingranular Netzwerkverkehr auf Teile von Anwendungen zuzulassen, um etwa nur wenige Testuser auf einen neuen Build zu leiten, machen dies möglich.

Doch wo bleibt die IT-Sicherheit in diesem Prozess?

Ganz grundsätzlich bestehen bei den neuen Entwicklungsmöglichkeiten drei Optionen die IT-Sicherheit einzubauen:

  1. SecDevOps: Die IT-Sicherheit wird in der Planungs- und Entwicklungsphase bereits berücksichtigt (Security by Design)
  2. DevSecOps: Die IT-Sicherheit wird nach der Entwicklung, in der Phase des Deployments, analysiert und sichergestellt
  3. DevOpsSec: Die IT-Sicherheit wird nachgelagert, z.B. mittels einer Sicherheits-Architektur oder -Infrastruktur bis hin zu einer rein reaktiven Strategie, im Sinne eines Response- oder Security Incident Management-Prozesses, behandelt.

Was ist die beste Möglichkeit?

Eine eindeutige Antwort auf die Frage nach der besten Option gibt es nicht. Zunächst einmal ist festzuhalten, dass es es sich bei diesen Optionen nicht um fixfertige Konzepte handelt. Es geht primär darum, eine ausgewogene Balance an Grundsätzen in der Entwicklung von Anwendungen zu finden anstatt fixe Regeln aufzustellen. Nur so ist die notwendige Agilität in der Software-Entwicklung sichergestellt.

Und dann entscheidet schlussendlich der «Risiko-Appetit» einer Unternehmung darüber, wie die Entwicklungsgrundsätze im Detail lauten.

Als Beispiel: In einem Start-Up geht es darum, mit möglichst geringen Kosten so rasch wie möglich Marktanteile zu gewinnen und am Markt überhaupt Fuss zu fassen. In einer solchen Situation kann es durchaus Sinn machen, die Security zunächst zur Seite zu legen und diese im Nachgang zu bearbeiten. Dabei ist darauf zu achten, dass mit wachsendem Interesse an einem Produkt auch das Interesse von Akteuren mit negativen Absichten und damit das Risiko eines Zwischenfalls zunimmt.

Risiken induzieren Sicherheitsmassnahmen und nicht umgekehrt

Ein risikobasierter Ansatz berücksichtigt die Wirtschaftlichkeit der Entwicklung. Bezogen auf DevOps heisst dies, dass eine laufende Risikoanalyse notwendig ist. Rein die Diskussion um SecDevOps, DevSecOps oder DevOpsSec induziert bereits, dass in der Praxis heute immer häufiger eine Absurdität mit dem Umgang mit Sicherheitsmassnahmen passiert: Auf Basis von umfangreichen IT Security-Regelwerken soll eine Vielzahl an Security Controls und Massnahmen umgesetzt werden, welche oft in keinerlei Verhältnis zum vorhandenen Risiko stehen. Kein Wunder wird die IT Security in einem agilen DevOps-Umfeld sofort als Verhinderer bezeichnet. Lassen Sie es uns einmal ganz klar festgehalten haben: Die Massnahmen für eine sichere Entwicklung werden durch die Risikoanalyse vorgegeben. Eine Umkehr würde bedeuten, dass die Massnahmen selbst zum Risiko werden und dies ist für niemanden ein Gewinn.

Unsere Empfehlung: RiskDevSecOps

Cloud, Microservices, Mikrosegmentierung und neue Deployment-Methoden in der Entwicklung von Anwendungen, legen nahe, dass eine laufende Beurteilung des Risikos notwendig ist. Wir plädieren deshalb für den Ansatz: Risikoanlayse vor SecDevSecOpsSec, also RiskDevSecOps.

Gehen Sie den Schritt in Richtung DevOps strukturiert an, ohne an Agilität zu verlieren und lassen Sie sich von uns unterstützen. Unserer Erfahrung nach werden Risiken intern oft bewusst oder unbewusst über- oder gerne auch unterschätzt. United Security Providers unterstützt Sie in Ihrem Risk Assessment gerne mit einer externen Sicht. Mit einem Digital Risk Assessment erfahren Sie in kurzer Zeit, wie es rund um die Risiken bei der Entwicklung Ihrer geschäftsrelevanten Applikationen steht.

Digital Risk Assessment

Ein Digital Risk Assessment hilft Klarheit zu schaffen. Wir sind überzeugt, dass bei der Erstellung einer solchen Risikoanalyse ein Top-Down-Approach am meisten Sinn macht und das zielgerichtetste Vorgehen darstellt. Bei einem Top-Down-Approach steht zuerst die Frage nach Ihrem Geschäftsumfeld, Ihren Geschäftszielen und Geschäftsprozessen im Vordergrund. In welchem Markt sind Sie tätig? Was möchten Sie mit einer Anwendung erreichen? Welches sind die wirklich kritischen Prozesse, die mit einer Anwendung unterstützt werden? Wieviel Risiko sind Sie effektiv bereit in diesem Umfeld in Kauf zu nehmen?

Auf dieser Basis lassen sich mit Hilfe von Szenarien handfeste Risiken identifizieren und quantifizieren. Daraus leiten wir geeignete gemeinsam mit Ihrer Entwicklungsabteilung geeignete Massnahmen ab.

IT-Security Assessment

Details zum Autor

Andres Wohler

Andres Wohler

Senior Security Consultant bei United Security Providers

Kommentar hinterlassen?