Ist Ihr Unternehmen wirklich bereit für DevSec? Machen Sie den Test.

Wir sind kaum in der Mitte des Jahres 2020 angekommen und steuern bereits auf einen traurigen Rekord bei Datenpannen zu, mit einem Anstieg gestohlener Daten um 273 % im Vergleich zur ersten Jahreshälfte 2019. Heutzutage ist es treffender zu fragen, welche Daten noch nicht gestohlen wurden. Durch Weltereignisse wie die COVID-19-Pandemie haben diese Angriffe in Häufigkeit und Intensität zugenommen, wobei die Ziele immer anfälliger werden.

Wir wissen es alle schon lange: Sicherheit ist kein optionales Extra mehr, sondern erfordert proaktives Handeln. Damit dies effektiv gelingt, muss jeder im SDLC ein Sicherheitsbewusstsein entwickeln, insbesondere die Entwickler. Das ist der „DevSec“-Teil von DevSecOps, einer idealen Softwareentwicklungsmethodik für die heutige Zeit, für deren Umsetzung viele Unternehmen jedoch noch nicht ausreichend gerüstet sind.

Denken Sie im Hinblick auf Ihr Unternehmen über diese Fragen in Ihrem spezifischen Kontext nach. Wie würde es bei einem DevSec-Test abschneiden?

DevSec-Selbstbewertung: Ist Ihr SDLC-Umfeld bereit für sicherheitsbewusste Entwickler?

1. Hat Sicherheit im internen Entwicklungsprozess Priorität?
   Eine Reihe von Cybersicherheitsrisiken mag den durchschnittlichen CISO nachts wach halten, doch die besorgniserregende Realität ist: Auch wenn viele Unternehmen Sicherheit stärker priorisieren, ist ihr interner Ansatz oft nicht robust genug, um potenzielle Katastrophen (oder zumindest massive Probleme für das AppSec-Team und verzögerte Software-Releases) abzuwenden.
   DevSecOps mag der aktuelle Goldstandard der Sicherheit sein, doch nur wenige Unternehmen arbeiten nach dieser Methodik. Wenn Sie noch in agilen oder gar klassischen Wasserfall-Modellen arbeiten, wird Sicherheit oft als Aufgabe von Spezialisten betrachtet, die weit vom Prozess entfernt sind und erst spät im SDLC hinzugezogen werden, um den Entwicklern mit Hotfixes den Tag zu verderben. In einem solchen Umfeld ist es schwierig, eine DevSec-Kultur zu etablieren: Entwickler lieben und priorisieren das Erstellen von Features und hatten oft nicht genug praktische Erfahrung mit Sicherheit, um sie als erstrebenswerte Kompetenz zu sehen. Tatsächlich sind ihre Berührungspunkte damit oft von Frustration und Negativität geprägt. Dies muss schnell behoben werden, um ein sicherheitsorientiertes Denken bei allen Beteiligten zu verankern.
   ‍
2. Hinkt Ihr Unternehmen beim Thema Threat Modeling noch hinterher?
   Es ist eine ernüchternde Statistik, dass 60 % der KMUs innerhalb von sechs Monaten nach einem erfolgreichen Cyberangriff ihr Geschäft aufgeben müssen, und wie bei anderen Katastrophen ist die Auswirkung ohne angemessene Planung weitaus größer.
   Threat Modeling ist ein entscheidendes Element bewährter Sicherheitspraktiken. Es ermöglicht AppSec-Profis, die Angriffsfläche vollständig zu bewerten und geeignete Abwehrmaßnahmen, Gegenstrategien und Planungen zu strukturieren. In Unternehmen, die DevSecOps vollständig verinnerlicht haben, ist Sicherheit früh in der CI/CD-Pipeline integriert, ohne die Produktion so stark zu verlangsamen wie früher. Sicherheit, sichere Programmierung und Continuous Delivery sind Teil des Prozesses, und Entwicklungsteams erhalten die Ressourcen und Einblicke, die sie benötigen, um maßgeblich zur Erstellung absolut sicheren Codes beizutragen.
   ‍
3. Priorisieren Entwicklungsleiter bewährte Sicherheitspraktiken?
   Ob sie wollen oder nicht, Entwicklungsleiter sind Vorbilder für ihr Team. Und das gilt nicht nur für die Unternehmenskultur, wie etwa den Dresscode oder das „Management nach oben“. Ihre Arbeitsprioritäten werden unweigerlich von ihren Teammitgliedern übernommen. Wenn Sicherheit nicht Teil der Hauptziele ist oder nicht durch Schulungen und Unterstützung geplant wird, werden die Ingenieure darunter das Nachsehen haben und das Unternehmen einem unnötigen Risiko ausgesetzt sein.
   ‍
4. Haben Entwickler einen Grund, sich für Sicherheit zu interessieren?
   Meiner Erfahrung nach verliert man jemanden am schnellsten, wenn man ihn zwingt, etwas zu tun, das seinem bisherigen Ansatz fremd ist, ohne ihm das „Warum“ zu erklären.
   
   Die Aufforderung zur „Veränderung“ impliziert, dass der bisherige Ansatz falsch war, obwohl es sich in vielen Fällen lediglich um eine Verbesserung handelt, die die Arbeit später hoffentlich einfacher und effizienter macht. Um die DevSec-Bewegung wirklich zu leben, müssen Entwickler zunächst einen Grund haben, sich für Sicherheit zu interessieren – schließlich ist es in den meisten Unternehmen immer noch „das Problem der anderen“ (d. h. der AppSec-Zauberer, die weit weg in einem anderen Raum eingeschlossen sind).
   
   DevSecOps funktioniert einfach nicht, wenn Sicherheit keine gemeinsame Verantwortung ist. Entwickler benötigen die richtigen Tools, Unterstützung und Schulungen, um ihren Teil beizutragen... und dies erfordert Zeit, um es als Teil eines umfassenden Sicherheitsprogramms einzuführen und zu perfektionieren. Der schlechteste Ansatz ist der, der überfordert und entfremdet – was passieren kann, wenn Entwickler zu viele konkurrierende Prioritäten haben und keine Hilfe bei deren Bewältigung erhalten. Dies ist ein kultureller Wandel, der nicht über Nacht geschieht.
   ‍
5. Verlassen Sie sich auf eine Handvoll magischer Sicherheits-Einhörner, um die Arbeit vieler zu erledigen?
   Sicherheitsexperten sind sehr rar gesät, und wir brauchen weit mehr, als derzeit verfügbar sind. Das ist eine Tatsache, aber es gibt immer mehr Entwickler, die in sicherheitsorientierte Rollen wechseln. Typischerweise tragen sie Titel wie „Security Engineer“ oder „DevOps Engineer“ (mit etwas Glück wird sich dieser Titel langsam zu DevSecOps Engineer wandeln!). Ein fähiger DevOps-Ingenieur kann Features für nahezu jede Anwendung entwickeln und dabei eine echte CI/CD-Pipeline nutzen. Sie erledigen alles von Anfang bis Ende und bringen meist ein gesundes Maß an Sicherheitsbewusstsein mit. In diesem Sinne sind sie eine Art magische und daher seltene Spezies.
   
   Einige Unternehmen machen jedoch den Fehler, diese spezialisierten Ingenieure einzustellen, sie in ein Team zu setzen und zu erwarten, dass sie alle Sicherheitsprobleme in jeder Phase des Entwicklungsprozesses lösen und dies allein das Allheilmittel ist. Überlasten Sie Ihre DevSecOps-Magier, und Sie landen wieder dort, wo Sie angefangen haben: Sie liefern unsicheren Code ohne die Kontrollen, Ausgleiche und die Sicherheitspräzision, für die sie eigentlich eingestellt wurden. Es ist von größter Bedeutung, dass das gesamte Entwicklungsteam weitergebildet und in einem positiven Sicherheitsumfeld gefördert wird, damit es in der Lage ist, die Last sinnvoll mitzutragen.

Finden Sie die Veränderung, die Sie in Ihrem Unternehmen sehen möchten.

Wenn Sie fundierte Schulungen als Teil Ihres Sicherheitsprogramms implementieren, werden Sie einige verborgene Talente in Ihrem Entwicklungsteam entdecken. Das sind die Leute, die trotz negativer Erfahrungen in ihrer täglichen Arbeit eine gewisse Leidenschaft für sichere Programmierung und bewährte Sicherheitspraktiken mitbringen. Diese Personen sind ideale Kandidaten für Security Champions im Team – eine Kontaktperson zwischen Sicherheit und Entwicklung, die ein gutes Beispiel gibt, das Bewusstsein hochhält und bei Engagement-Initiativen hilft. Ihre zwischenmenschlichen Fähigkeiten sind zudem sehr wichtig, um die Freude an der Sicherheit zu verbreiten und die Bedürfnisse der Entwickler gegenüber dem Management und dem Sicherheitsteam zu vertreten.

Die Frage „Was habe ich davon?“ ist ein positiver Schritt nach vorn.

Selbst die edelsten Menschen brauchen eine „Karotte“, um sich auf unbekanntes Terrain zu wagen oder eine Aktivität zu beginnen, deren Lernkurve nicht unbedingt die angenehmste ist.
Der Sprung von „Dev“ zu „DevSec“ ist ein fantastischer Karriereschub für Entwickler. Sicherheitsbewusste Entwickler haben hart daran gearbeitet, Sicherheit zu verstehen, Verantwortung in ihren kontrollierbaren Bereichen zu übernehmen und mit dem Verständnis zu arbeiten, dass nur sicherer Code auch qualitativ hochwertiger Code ist. Entwickler wollen sich im Allgemeinen verbessern, neue Probleme angehen und beneidenswerte Features schaffen, die sie von ihren Kollegen abheben. Geben Sie ihnen einen Weg, ein höheres Niveau in der Softwareentwicklung zu erreichen, und es ist eine Win-Win-Situation.

Es ist nie zu spät, Ihr DevSec-Dreamteam aufzubauen.

Wenn Sie Entwickler leiten, ein AppSec-Awareness-Team führen oder zu den vielen Köpfen gehören, die an Strategien für Sicherheitsprogramme arbeiten, ist jetzt der richtige Zeitpunkt, mehr als nur „Shift Left“ zu tun. Mit den richtigen Schulungen, Tools und Umgebungen können Sie einen Sicherheits-Inkubator für Entwickler schaffen, der sich für alle Beteiligten auszahlt. Wenn diese Checkliste einige Bereiche mit Verbesserungsbedarf aufgezeigt hat, haben Sie eine großartige Gelegenheit, Ihr Unternehmen auf eine DevSec-geführte Entwicklungsabteilung vorzubereiten, die Risiken von Beginn des SDLC an reduziert.