Ist Ihre Organisation wirklich DevSec-ready? Stellen Sie es auf den Prüfstand.

Wir haben kaum die Hälfte des Jahres 2020 hinter uns, und doch sind wir bereits auf dem besten Weg, einen düsteren Datensicherheitsrekord aufzustellen, da die Zahl der gestohlenen Daten im Vergleich zum ersten Halbjahr 2019 um 273 % gestiegen ist. Heutzutage ist es genauer zu fragen, wie viele Daten noch nicht gestohlen worden sind. Angesichts von Weltereignissen wie der COVID-19-Pandemie haben diese Angriffe nur an Häufigkeit und Stärke zugenommen, mit immer anfälligeren Zielen.

Das ist etwas, das wir alle schon seit einer Weile wissen: Sicherheit ist nicht mehr optional, und unser Fokus muss ein Präventivschlag sein. Damit das effektiv ist, muss jeder im SDLC sicherheitsbewusst sein, insbesondere die Entwickler. Dies ist der "DevSec"-Teil von DevSecOps, einer idealen Softwareentwicklungsmethodik für das Klima, aber viele Organisationen sind nicht vollständig darauf vorbereitet, dies effektiv auszuführen.

Denken Sie mit Blick auf Ihr Unternehmen über diese Fragen im Kontext Ihrer Rolle nach. Wie würde sie im DevSec-Test abschneiden?

DevSec Self-Assessment: Ist Ihr SDLC-Garten bereit, sicherheitsbewusste Ingenieure zum Blühen zu bringen?

1. Steht die Sicherheit im internen Entwicklungsprozess an erster Stelle?
   Eine Reihe von Cybersecurity-Risikofaktoren hält den durchschnittlichen CISO vielleicht nachts wach, aber die beunruhigende Realität ist, dass viele Unternehmen der Sicherheit zwar eine höhere Priorität einräumen, ihr interner Ansatz aber möglicherweise nicht robust genug ist, um eine potenzielle Katastrophe zu verhindern (oder zumindest massive Kopfschmerzen für das AppSec-Team und eine verzögerte Auslieferung der Software).
   DevSecOps mag der aktuelle Stand des Sicherheits-Nirwana sein, aber nur wenige Unternehmen arbeiten mit dieser Methodik. Wenn Sie noch in Agile - oder sogar Waterfall - arbeiten, dann wird Sicherheit oft noch als Domäne von Spezialisten betrachtet, die weit vom Prozess entfernt sind und erst spät im SDLC aktiviert werden, um den Tag eines Entwicklers mit Hotfixes für seinen Code zu ruinieren. In einer solchen Umgebung wird es schwierig sein, eine DevSec-Kultur zu fördern: Entwickler lieben und priorisieren die Entwicklung von Funktionen und haben einfach nicht genug praktische Erfahrung mit Sicherheit, um sie als wünschenswerten Weg der Weiterbildung zu sehen. Tatsächlich sind ihre Berührungspunkte mit diesem Thema oft frustrierend und negativ. Hier muss schnell Abhilfe geschaffen werden, damit das Thema für alle am Softwareentwicklungsprozess Beteiligten in den Vordergrund rückt.
   
2. Spielt Ihr Unternehmen bei der Bedrohungsmodellierung immer noch Nachholbedarf?
   Es ist eine ernüchternde Statistik, dass 60 % der KMUs innerhalb von sechs Monaten nach einem erfolgreichen Cyberangriff den Betrieb einstellen, und ähnlich wie bei anderen Katastrophen sind die Auswirkungen ohne angemessene Planung weitaus größer.
   Die Bedrohungsmodellierung ist ein entscheidendes Element der Best Practices für die Sicherheit, das es AppSec-Experten ermöglicht, den vollen Umfang der Angriffsfläche zu bewerten und entsprechende Abwehrmaßnahmen, Gegenmaßnahmen und Planungen zu strukturieren. In Unternehmen, die DevSecOps vollständig umgesetzt haben, wird die Sicherheit schon früh in der CI/CD-Pipeline aktiviert, so dass die Produktion nicht so stark verlangsamt wird, wie es in der Vergangenheit der Fall war. Sicherheit, sichere Kodierung und kontinuierliche Bereitstellung sind Teil des Prozesses, und die Entwicklungsteams erhalten die erforderlichen Ressourcen und das nötige Engagement, um wichtige Komponenten der Maschine zu sein, die luftdichten Code ausspuckt.
   
3. Setzen Entwicklungsleiter Best Practices für die Sicherheit in den Vordergrund?
   Ob sie es mögen oder nicht, Entwicklungsleiter sind Vorbilder für ihr Team. Und das gilt nicht nur für die Kultur und die Stimmung, wie z.B. das Tragen von Flip-Flops im Büro oder wie sie "nach oben managen". Ihre Arbeitsprioritäten werden unweigerlich von ihren Teammitgliedern übernommen, und wenn Sicherheit nicht zu den Hauptzielen gehört oder in Form von Schulungen und Support eingeplant ist, dann kommen die Ingenieure unter ihnen zu kurz, und das Unternehmen ist mehr gefährdet, als es sein sollte.
   
4. Wird Entwicklern ein Grund gegeben, sich um Sicherheit zu kümmern?
   Meiner Erfahrung nach ist der schnellste Weg, jemanden ins Abseits zu stellen, wenn man ihm sagt, dass er etwas tun muss, das seinem bisherigen Ansatz fremd ist, ohne ihm zu sagen, warum.
   
   Wenn man ihm sagt, er solle sich "ändern", impliziert das, dass der bisherige Ansatz falsch war, während es in vielen Fällen einfach eine Verbesserung ist, die die Dinge später hoffentlich einfacher und effizienter macht. Um die DevSec-Bewegung wirklich anzunehmen, muss man den Entwicklern einen Grund geben, sich überhaupt um die Sicherheit zu kümmern - schließlich ist es in den meisten Unternehmen immer noch "das Problem von jemand anderem" (d.h. die AppSec-Assistenten, die in einem anderen Raum weit, weit weg eingeschlossen sind).
   
   DevSecOps funktioniert einfach nicht, wenn die Sicherheit nicht eine gemeinsame Verantwortung ist. Entwickler brauchen die richtigen Tools, den richtigen Support und das richtige Training, um ihren Teil dazu beizutragen ... und das braucht Zeit, um als Teil eines umfassenden Sicherheitsprogramms ausgerollt und perfektioniert zu werden. Der schlechteste Ansatz ist der, der überfordert und entfremdet, was der Fall sein kann, wenn Entwickler zu viele konkurrierende Prioritäten haben und keine Hilfe, um sie zu verwalten, ohne sich selbst verrückt zu machen. Das ist ein Kulturwandel, und der geht nicht über Nacht.
   
5. Verlassen Sie sich auf eine Handvoll magischer Sicherheitseinhörner, die die Aufgabe von vielen übernehmen?
   Sicherheitsexperten sind sehr knapp, und wir brauchen weit mehr, als derzeit verfügbar sind. Das ist eine Selbstverständlichkeit, aber es gibt eine wachsende Zahl von Entwicklern, die in sicherheitsorientierte Rollen wechseln. Typischerweise werden sie unter Titeln wie "Sicherheitsingenieur" oder "DevOps-Ingenieur" geführt (mit etwas Glück werden wir sehen, wie sich dieser Titel langsam in DevSecOps-Ingenieur verwandelt!) Ein DevOps-Ingenieur ist in der Lage, Funktionen für praktisch jede Anwendung zu entwickeln und dabei eine echte CI/CD-Pipeline zu verwenden. Sie machen alles Ende-zu-Ende und bringen in der Regel ein gesundes Maß an Sicherheitsbewusstsein mit. In diesem Sinne sind sie irgendwie magisch, und deshalb selten.
   
   Einige Unternehmen machen jedoch den Fehler, diese spezialisierten Ingenieure einzustellen, sie in ein Team zu stecken und zu erwarten, dass sie sich um alle Sicherheitsprobleme kümmern, und zwar in jeder Phase des Entwicklungsprozesses, und dass dies allein das Allheilmittel ist. Wenn Sie Ihre DevSecOps-Magier überfordern, enden Sie dort, wo Sie angefangen haben - bei der Auslieferung von unsicherem Code ohne die Kontrollen, Abgleiche und Sicherheitspräzision, für die sie in erster Linie eingestellt worden sind. Es ist von äußerster Wichtigkeit, dass das Entwicklungsteam im Allgemeinen gut ausgebildet ist und in einer positiven Sicherheitsumgebung gefördert wird, damit es in der Lage ist, die Last sinnvoll zu teilen.

Finden Sie die Veränderung, die Sie in Ihrer Organisation sehen wollen.

Wenn Sie robuste Schulungen als Teil Ihres Sicherheitsprogramms implementieren, werden Sie einige versteckte Perlen in Ihrer Entwicklungskohorte aufdecken. Das sind die Leute, die trotz aller negativen Erfahrungen, die sie in ihrem Arbeitsalltag gemacht haben, eine gewisse Leidenschaft für sicheres Coding und Security Best Practices haben. Diese Leute sind erstklassige Kandidaten für Sicherheits-Champions innerhalb des Teams; eine Kontaktstelle zwischen Sicherheit und Technik, die ein großes Vorbild für andere ist, das Bewusstsein hoch hält und bei Engagement-Initiativen hilft. Ihre zwischenmenschlichen Fähigkeiten sind auch sehr wichtig, um die Freude an der Sicherheit weit und breit zu verbreiten und sich für die Bedürfnisse der Entwickler gegenüber dem Management und dem Sicherheitsteam einzusetzen.

Das "Was ist für mich drin?"-Gespräch ist ein positiver Schritt nach vorne.

Selbst die edelsten Menschen brauchen so etwas wie ein "Zuckerbrot", um den Zeh in unbekanntes Terrain zu stecken oder in eine Tätigkeit, die vielleicht nicht die angenehmste Lernkurve hat.
Den Sprung von "Dev" zu "DevSec" zu machen, ist ein großartiger Schub für die Karriere eines Entwicklers. Sicherheitsbewusste Entwickler haben hart daran gearbeitet, Sicherheit zu verstehen, Verantwortung dafür in den Bereichen zu übernehmen, die sie kontrollieren können, und mit dem Verständnis zu arbeiten, dass der einzige Qualitätscode sicherer Code ist. Im Allgemeinen wollen sich Entwickler verbessern, neue Probleme angehen und beneidenswerte Funktionen erstellen, die ihnen helfen, sich von ihren Kollegen abzuheben. Geben Sie ihnen einen Weg, ein höheres Niveau der Softwareentwicklung zu erreichen, und es ist eine Win-Win-Situation.

Es ist nie zu spät, Ihr DevSec Dream Team aufzubauen.

Wenn Sie Entwickler verwalten, ein AppSec Awareness-Team leiten oder einer der vielen Köpfe sind, die hart daran arbeiten, Strategien für Sicherheitsprogramme zu entwerfen, ist es jetzt an der Zeit, einen Schritt weiter zu gehen als nur nach links zu gehen. Mit dem richtigen Training, den richtigen Tools und der richtigen Umgebung können Sie einen Sicherheitsinkubator für Entwickler schaffen, der sich für alle Beteiligten auszahlt. Wenn diese Checkliste einige verbesserungswürdige Bereiche aufgezeigt hat, dann haben Sie eine großartige Gelegenheit, Ihr Unternehmen auf eine DevSec-geführte Entwicklungsabteilung vorzubereiten, die das Risiko von Beginn des SDLC an reduzieren kann.