Eine veränderte Sicherheit in DevOps bedeutet eine veränderte Denkweise

Vor sehr langer Zeit, als ich noch ein dummer junger UNIX-Systemadministrator war (heute bin ich nicht mehr so ein Ding), habe ich auf einem der Server, auf denen unsere Backup-Systeme liefen, einen ziemlich schwerwiegenden Sicherheitsfehler begangen. Ich werde nicht ins Detail gehen, aber es hatte mit dem sudo-Befehl, einem Texteditor und Unwissenheit zu tun.

Glücklicherweise stand mir einer der erfahreneren (und ehrlich gesagt intelligenteren) Systemadministratoren zur Seite. Sie hatten mein neues Vorgehen bemerkt, untersucht … und mich dann höflich beiseite genommen, um mir meinen Fehler zu erklären. Sie verbrachten dann Zeit damit, mir dabei zu helfen, eine Lösung zu erarbeiten, die den Leuten noch immer die Selbstbedienungsfunktion bot, die sie brauchten, bei der aber die Katastrophengefahr geringer war. In meiner selbst korrigierten und unzuverlässigen Erinnerung war ich für die Verbesserungen dankbar – sowohl für mich als auch für meine Konfiguration.

Dieses Verhalten des Teilens, der Zusammenarbeit und der Fehlersuche ohne Schuldzuweisung ist mir über die Jahre geblieben und ich hoffe, dass ich gelegentlich jemandem bei seinen Sicherheitspannen helfen konnte.  

Vor diesem Hintergrund war es beim Lesen des Puppet State of DevOps Report keine Überraschung, dass eine frühere Integration der Sicherheit in den Softwarebereitstellungszyklus das Ergebnis – Achtung – einer besseren Sicherheit ist.

Aus dem Bericht geht klar hervor, dass die Vorteile einer Verlagerung der Sicherheit in den Software-Lebenszyklus ebenso stark (wenn nicht sogar stärker) auf der Verlagerung dieser DevOps-Verhaltensprinzipien in die Sicherheitsteams beruhen wie auf der Verlagerung der Sicherheitstools in die Pipelines.

Während sich traditionellere Sicherheitspraktiken auf Tests und Kontrollen konzentrieren (die meisten App-Teams haben schon einmal einen von einem Tool generierten Sicherheitsbericht erhalten, der mehrere Probleme auflistet, die behoben werden müssen), fördert ein auf DevOps-Prinzipien basierender Ansatz eine frühzeitige Zusammenarbeit, den Austausch und die gemeinsame Verantwortung.

Beim Lesen des Abschnitts „Verbesserung der Sicherheitslage“ des Berichts (ab Seite 31) wird deutlich, wie viel davon abhängt, dass Sicherheitsüberlegungen reibungslos in die Entwicklung und den Aufbau von Software und Infrastruktur einfließen, und nicht nur, dass die richtigen Kontrollen und Technologien implementiert werden.

Wenn die Vorteile auf der Weitergabe und Integration der Fähigkeiten und Denkweisen von Sicherheitsexperten in den Kern der Softwarebereitstellungspipeline beruhen, werden einige der bedeutendsten Änderungen verhaltensbezogener Natur sein.

Wird ein Sicherheitsteam schon früh in den Softwareentwicklungszyklus eingebunden, ist sicherlich eine Anpassung des Teams erforderlich, diese Änderungen müssen jedoch in beide Richtungen erfolgen. Während Sicherheitsexperten neue Arbeitsweisen übernehmen müssen – und wahrscheinlich mehr in der Sprache der Entwickler sprechen lernen als bisher –, muss sich das Entwicklungsteam möglicherweise auch dem Tao der Andon-Schnur verschreiben.

Wenn Sie sich noch nicht mit dem Andon-Kabel und seiner Rolle im von Toyota entwickelten Herstellungsprozess zur Qualitätskontrolle befasst haben, lohnt es sich auf jeden Fall, sich die Zeit dafür zu nehmen. Es gibt Artikel, wissenschaftliche Arbeiten, ganze Bücher und sogar Hochschulkurse zu diesem Thema. Aber bevor Sie Ihre Karriere im Technologiebereich aufgeben, um den MBA zu machen, den Sie sich immer vorgenommen haben, lesen Sie diesen Artikel zu Ende, denn ich glaube, das Wichtigste am Andon-Kabel ist sowohl das Einfachste als auch das Am schwersten zu erreichende.

Wenn ein Arbeiter in einer Produktionslinie an seinem Andon-Seil zieht, um die Produktion aufgrund eines Defekts zu stoppen, ist das Erste, was seine Kollegen und das Managementteam tun, herbeizueilen und ihm zu danken. Und sie müssen es ernst meinen. Das Ziehen der Andon-Reißleine wird als eine gute Sache angesehen, da es einen Schritt in Richtung Qualitätsverbesserung darstellt. Manager und Kollegen sind dankbar , wenn die Produktionslinie aufgrund eines Problems angehalten wird – denn das ist eine Chance zur Verbesserung.

Kann Ihr Entwicklungsteam es als dankbar empfinden, dass das Sicherheitsteam Mängel findet und den (virtuellen) Reißverschluß zieht? Kann ein DevOps-Team lernen, Builds oder Bereitstellungen, die die Sicherheitstests nicht bestehen, genauso wertzuschätzen wie solche, die sie bestehen?

Können die erwartungsvollen Geschäftsinhaber lernen, dass wir bei der Entwicklung großartiger Software auf häufigere Testfehler achten sollten, indem wir immer bessere Tests entwickeln, die Probleme identifizieren, bevor sie bei einer Bereitstellung sichtbar werden?

Das kann eine schwierige mentale Anpassung sein.

Obwohl ich für die unvermeidlichen redaktionellen Korrekturen dankbar bin, die bis zu dem Zeitpunkt, an dem Sie diesen Artikel lesen, bereits vorgenommen wurden, ist es nicht immer leicht zu sehen, wie andere Ihr Werk zerpflückt haben. Ihr rationaler Verstand weiß, dass es ein besseres Produkt liefert, aber Ihr innerer Schimpanse möchte einfach nur mit den Armen herumfuchteln.

Auch wenn es schwer ist, sich diese Denkweise anzueignen, ist sie für den Erfolg entscheidend, denn sie ist eine frühzeitige Integration der Sicherheit in den Software-Lebenszyklus und viel besser als die bestehenden nachträglichen Überprüfungen und hastigen Abhilfemaßnahmen.

Die Änderung von Einstellungen ist ein ganz anderes Studiengebiet, aber Führungskräfte und Praktiker in der IT müssen sich darin auskennen, insbesondere in dieser Zeit revolutionärer Veränderungen in der Arbeitsweise. Dies ist oft (viel) schwieriger, als einfach nur eine neue Technologie einzuführen. Wenn Sie in Sachen Sicherheit erfolgreich einen „Shift nach links“ durchführen möchten – und die Daten aus diesem Bericht sprechen dafür –, dann sollten Sie den menschlichen wie auch den technischen Aspekten ebenso viel Zeit widmen.