Warum DevSecOps nach effektiver Durchsetzung streben sollten
This post is also available in:
Englisch
Französisch
Italienisch
Portugiesisch, Brasilien
Spanisch
Russisch
Gespräche mit potenziellen Kunden bringen oft mehr Erkenntnisse als Marktforschungsstudien. Aus aktuellen Kundenkontakten (nach wie vor leider nur virtuell) geht eindeutig hervor: Unternehmen benötigen effektive Sicherheit.
1. Die Definition effektiver Sicherheit
Das Rad muss nicht ständig neu erfunden werden. Moderne Applikationsentwicklung, Bereitstellungsarchitekturen und Frameworks verschaffen Forschungs- und Entwicklungs-Teams eine maximale Flexibilität. Darüber hinaus sind standardmäßige Services, Module und Funktionen für eine einfache Integration verfügbar. Trotzdem gibt es eine Anforderung, die alles komplizierter macht: Die Verfügbarkeit der Applikation sowie die Integrität und Vertraulichkeit ihrer Daten müssen geschützt werden.
Der Kauf von Sicherheitslösungen ist schnell erledigt – einfach die geeignete Technologie zur Abwehr der Bedrohung(en) erwerben. Schwieriger wird es beim Management dieser Lösungen. Zuallererst sorgen die Vorteile dafür, dass Sicherheit und Produktivität bei den Entwicklungsteams wieder im Gleichgewicht stehen. Dies bedeutet, dass Unternehmen von kürzeren Release-Zyklen und Markteinführungszeiten für neue Funktionen zu geringeren Kosten profitieren. Die Mitarbeiter der Applikationsentwicklung und -bereitstellung (AD&D) erhalten mehr Mitsprache bei sicherheitsrelevanten Entscheidungen. Effektive Sicherheit sollte einen festen Bestandteil Ihrer Strategie bilden. Oder anders gesagt: Sie müssen Fehler, Ausfälle oder Verzögerungen vermeiden.
[Das könnte Sie auch interessieren: Sicherheit und DevOps: Alles fest im Griff]

2. „Effektive“ Sicherheit muss erkennen
Technologie für Applikationsschutz lässt sich auf unterschiedliche Weise in die CI/CD-Pipeline integrieren. Jeder Ansatz versucht, nicht nur auf Geschwindigkeit zu achten und die Auswirkungen auf die Umgebung zu minimieren, sei es die Latenzzeit, der Ressourcenbedarf oder die Workload-Kosten. Meistens weisen „entwicklungsfreundliche“ Ansätze mindestens einen von zwei Schwachpunkten auf:
i. Die Lösung deckt nicht die gesamte Angriffsfläche ab.
ii. Die Lösung sorgt nicht für aktive Durchsetzung der Sicherheit.
i. Heutige Bedrohungen nutzen nicht nur die Code- und Logikschwachstellen von Applikationen aus – was schon mehr als genug Analyse- und Abwehraufwand verursacht. Unternehmen haben alle Hände voll zu tun, um bekannte Schwachstellen, die neuesten Authentifizierungs- und Autorisierungsprotokolle sowie die verschiedenen Möglichkeiten der Hacker im Auge zu behalten.
Heutige Anwendungen – vor allem in modernen Entwicklungsumgebungen – nutzen in großem Umfang APIs, um sensible Daten auszutauschen und zu verarbeiten. Diese APIs sind genauso gefährdet und erfordern dedizierte Technologie, die Token-Missbrauch, exzessive Nutzung oder Datendiebstahl durch Injections verhindert.
Neben den APIs sind viele Dienste auf Bots angewiesen, die integriert oder bedient werden. Dabei muss eine klare Unterscheidung zwischen guten Bots und Bots mit böswilligen Absichten getroffen werden. RASP (Runtime Application Self Protection) wird von AD&D in der Regel nur akzeptiert, wenn eine gewisse Anfälligkeit für Angriffe bestehen bleibt, z. B. Denial of Service.
ii. Aus dem Blickwinkel von DevOps ist die Durchsetzung von Sicherheit mit Risiken verbunden. Sie kann die Benutzererfahrung beeinträchtigen oder sogar Abläufe unterbrechen und zu Laufzeitfehlern führen. Der Softwareentwicklungs-Lebenszyklus (SDLC) weist in puncto Sicherheit einige Lücken auf, insbesondere in der hybriden Multi-Cloud-Architektur von heute. Genau aus diesem Grund verfügen viele Technologien über Alarmfunktionen, die sehr hilfreich sind.
[Das könnte Sie auch interessieren: Sicherheit und DevOps: Alles fest im Griff]
3. „Effektive“ Sicherheit muss schützen
Tools, die nur Transparenz bieten, sind heute überholt. Echte Durchsetzung kommt bei automatisierten Sicherheitstests und Schwachstellen-Scannern für Webserver, Betriebssysteme oder sogar Container-Images zu kurz. Dann muss der Entwickler ein paar Schritte zurückgehen und Fehler ausbügeln. Werden solche Alarme massenhaft ausgegeben, fällt es schwer, Prioritäten zu setzen und alle zu beheben.
Eine freigegebene Version ist für Entwicklungsteams eigentlich Schnee von gestern – bis ein Sicherheitsmitarbeiter ihnen erklärt, dass sie noch eine Schwachstelle ausmerzen müssen. Alles, was sich erkennen lässt, sollte blockiert werden. Die Kunst dabei: Sie müssen das gesamte Spektrum der Bedrohungen abdecken. Niemand möchte zu viele Einzellösungen, da dies nicht unbedingt zu einer robusteren Sicherheitslage führt.
4. „Effektive“ Sicherheit muss effektiv bleiben
Aufgrund der dynamischen Natur eines agilen SDLC mit häufigen, teils täglichen Änderungen und Updates von Apps werden Sicherheitsrichtlinien von Tag zu Tag immer ungenauer. Dieser nicht skalierbare Prozess erfordert einen Mitarbeiter, der sich ganz auf das Update von Regeln, Whitelisting und Ausnahmebehandlung konzentriert.
Erfahren Sie mehr über Radwares entwicklungsfreundliche Sicherheit und automatische Engine für Richtliniengenerierung und -optimierung.