Ist Ihre Organisation wirklich bereit für DevSec? Stellen Sie es auf die Probe.

Wir haben gerade die Hälfte des Jahres 2020 hinter uns, und doch sind wir bereits auf dem besten Weg, einen düsteren Rekord bei Datenschutzverletzungen aufzustellen. verzeichnet einen Anstieg der gestohlenen Daten um 273% im Vergleich zum ersten Halbjahr 2019. Heutzutage ist es genauer zu fragen, wie viele Daten hat nicht wurde schon gestohlen. Angesichts von Weltereignissen wie der COVID-19-Pandemie haben Häufigkeit und Stärke dieser Angriffe nur zugenommen, und ihre Ziele wurden immer anfälliger.

Das wissen wir alle seit einiger Zeit: Sicherheit ist nicht mehr optional, und unser Fokus muss auf einem Präventivschlag liegen. Damit das wirksam ist, jedermann im SDLC müssen sicherheitsbewusst sein, insbesondere Entwickler. Dies ist der „DevSec“ -Teil von DevSecOps, eine ideale Softwareentwicklungsmethode für das Klima, aber viele Organisationen sind nicht vollständig darauf vorbereitet, dies effektiv umzusetzen.

Denken Sie unter Berücksichtigung Ihrer Organisation über diese Fragen im Zusammenhang mit Ihrer Rolle nach. Wie würde es abschneiden, wenn es dem DevSec-Test unterzogen würde?

DevSec-Selbstbeurteilung: Ist Ihr SDLC-Garten bereit, sicherheitsbewusste Ingenieure auszubilden?

1. Steht Sicherheit im internen Entwicklungsprozess im Vordergrund?
   Eine Reihe von Cybersicherheitsrisiken mag den durchschnittlichen CISO nachts auf Trab halten, aber die besorgniserregende Realität ist, dass viele Unternehmen zwar der Sicherheit mehr Priorität einräumen, ihr interner Ansatz jedoch möglicherweise nicht robust genug ist, um potenzielle Katastrophen abzuwehren (oder zumindest massive Kopfschmerzen für das AppSec-Team und verzögerte Softwareauslieferung).
   DevSecOps mag das aktuelle Sicherheits-Nirvana sein, aber nur wenige Unternehmen arbeiten mit dieser Methode. Wenn Sie noch Agile verwenden — oder sogar Waterfall — dann wird Sicherheit oft immer noch als die Domäne von Spezialisten betrachtet, die weit vom Prozess entfernt sind und erst spät im SDLC aktiviert werden und auftauchen, um den Tag eines Entwicklers mit Hotfixes für seinen Code zu ruinieren. In einer solchen Umgebung wird es eine Herausforderung 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 zur Weiterbildung anzusehen. Tatsächlich können ihre Berührungspunkte damit Frustration und Negativität sein. Dies muss schnell behoben werden, um allen am Softwareentwicklungsprozess Beteiligten einen ganzheitlichen Ansatz zu vermitteln.
   ‍
2. Hat Ihr Unternehmen immer noch Nachholbedarf, wenn es um Bedrohungsmodellierung geht?
   Es ist eine ernüchternde Statistik, die 60% der KMUs gehen innerhalb von sechs Monaten nach einem erfolgreichen Cyberangriff aus dem Geschäft, und wie bei anderen Katastrophen sind die Auswirkungen ohne angemessene Planung weitaus größer.
   Die Bedrohungsmodellierung ist ein entscheidendes Element der Best Practices im Bereich Sicherheit. Sie ermöglicht es AppSec-Experten, den gesamten Umfang der Angriffsfläche zu beurteilen und angemessene Abwehrmaßnahmen, Gegenmaßnahmen und Planungen zu strukturieren. In Unternehmen, die DevSecOps in vollem Umfang eingeführt haben, wird die Sicherheit schon früh in der CI/CD-Pipeline aktiviert, sodass die Produktion nicht so stark verlangsamt wird wie in der Vergangenheit. Sicherheit, sichere Codierung und kontinuierliche Bereitstellung sind allesamt Teil des Prozesses, und die Entwicklungsteams erhalten die Ressourcen und die Aufmerksamkeit, die erforderlich sind, um wichtige Komponenten der Engine zu sein, die luftdichten Code ausspucken.
   ‍
3. Priorisieren Entwicklungsmanager bewährte Sicherheitsmethoden?
   Ob es ihnen gefällt oder nicht, Entwicklungsmanager sind Vorbilder für ihr Team. Und es geht nicht nur um die Kultur und die Stimmung, wie zum Beispiel das Tragen von Flip-Flops im Büro oder darum, wie sie „aufwärts zurechtkommen“. Ihre Arbeitsprioritäten werden unweigerlich von ihren Teammitgliedern übernommen, und wenn Sicherheit nicht zu den Hauptzielen gehört oder in Bezug auf Schulung und Support nicht geplant ist, dann werden die ihnen unterstellten Techniker etwas verpassen und das Unternehmen ist stärker gefährdet, als es sein sollte.
   ‍
4. Haben Entwickler einen Grund, sich um Sicherheit zu kümmern?
   Meiner Erfahrung nach ist der schnellste Weg, jemanden ins Abseits zu bringen, indem man ihm sagt, dass er etwas tun muss, das seinem aktuellen Ansatz fremd ist, ohne ihm zu sagen, warum.
   
   Wenn man sagt, man solle sich „ändern“, bedeutet das, dass der vorherige Ansatz falsch war, obwohl es sich in vielen Fällen lediglich um eine Verbesserung handelt, die die Dinge später hoffentlich einfacher und effizienter macht. Um die DevSec-Bewegung wirklich begrüßen zu können, müssen Entwickler einen Grund haben, sich überhaupt um Sicherheit zu kümmern — schließlich ist es in den meisten Organisationen immer noch das „Problem eines anderen“ (d. h. die AppSec-Assistenten sind in einem anderen Raum eingesperrt, weit, weit, weit, entfernt).
   
   DevSecOps funktioniert einfach nicht, wenn Sicherheit keine gemeinsame Verantwortung ist. Entwickler benötigen die richtigen Tools, den richtigen Support und die richtigen Schulungen, um ihren Beitrag zu leisten... und das erfordert Zeit, um es als Teil eines umfassenden Sicherheitsprogramms einzuführen und zu perfektionieren. Der schlechteste Ansatz ist derjenige, der überfordert und abschreckt. Das kann der Fall sein, wenn Entwickler zu viele konkurrierende Prioritäten haben und keine Hilfe dabei haben, sie zu verwalten, ohne sich selbst in den Wahnsinn zu treiben. Das ist ein kultureller Wandel, und er kommt nicht über Nacht.
   ‍
5. Verlassen Sie sich auf eine Handvoll magischer Sicherheitseinhörner, um die Aufgabe vieler zu übernehmen?
   Sicherheitsexperten sind dabei sehr knappes Angebot, und wir brauchen weit mehr als derzeit verfügbar sind. Das ist eine Selbstverständlichkeit, aber es gibt immer mehr Entwickler, die in stärker sicherheitsorientierte Rollen wechseln. In der Regel tragen sie Titel wie „Sicherheitsingenieur“ oder „DevOps-Ingenieur“ (langsam werden wir sehen, wie sich dieser Titel in DevSecOps-Ingenieur, mit etwas Glück!). Ein erfahrener DevOps-Ingenieur ist in der Lage, Funktionen für praktisch jede Anwendung zu entwickeln und die Bereitstellung mithilfe einer echten CI/CD-Pipeline durchzuführen. Sie erledigen alles von Anfang bis Ende und verfügen in der Regel über ein gesundes Maß an Sicherheitsbewusstsein. In diesem Sinne sind sie irgendwie magisch und daher selten.
   
   Einige Unternehmen machen jedoch den Fehler, diese Fachingenieure einzustellen, sie in ein Team zusammenzustellen und zu erwarten, dass sie in jeder Phase des Entwicklungsprozesses alle Sicherheitsprobleme lösen werden, und das allein ist das Allheilmittel. Überlasten Sie Ihre DevSecOps-Zauberer, und Sie werden dort enden, wo Sie angefangen haben: Sie versenden unsicheren Code ohne die Kontrollen, Abwägungen und Sicherheitsvorgaben, für die sie von Anfang an beauftragt wurden. Es ist von größter Bedeutung, dass das Entwicklungsteam im Allgemeinen weitergebildet und in einem positiven Sicherheitsumfeld gefördert wird, damit es in der Lage ist, die Last sinnvoll zu verteilen.

Finden Sie die Änderung, die Sie in Ihrer Organisation sehen möchten.

Wenn Sie solide Schulungen als Teil Ihres Sicherheitsprogramms implementieren, werden Sie einige versteckte Juwelen in Ihrer Entwicklungskohorte entdecken. Dies sind die Leute, die trotz aller negativen Erfahrungen, die sie in ihrer täglichen Arbeit gemacht haben, eine gewisse Leidenschaft für sichere Codierung und bewährte Sicherheitsmethoden haben. Diese Leute sind die besten Kandidaten für Sicherheitsexperten im Team. Sie sind ein Ansprechpartner zwischen Sicherheit und Technik, der anderen ein gutes Beispiel gibt, das Bewusstsein hoch hält und bei Engagement-Initiativen hilft. Ihre zwischenmenschlichen Fähigkeiten sind auch sehr wichtig, um die Freude am Thema Sicherheit weit und breit zu verbreiten und sich gegenüber dem Management und dem Sicherheitsteam für die Bedürfnisse der Entwickler einzusetzen.

Das „Was ist für mich drin?“ Das Gespräch ist ein positiver Schritt vorwärts.

Selbst die edelsten Menschen brauchen so etwas wie eine „Karotte“, um ihren Zeh in unbekanntes Terrain zu tauchen, oder eine Aktivität, die vielleicht nicht gerade die angenehmste Lernkurve hat.
Der Sprung von „Dev“ zu „DevSec“ 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 gehen davon aus, dass Sicherheitscode der einzige Qualitätscode ist. Im Allgemeinen wollen Entwickler sich verbessern, neue Probleme angehen und beneidenswerte Funktionen entwickeln, die ihnen helfen, sich von ihren Mitbewerbern abzuheben. Geben Sie ihnen einen Weg, um ein höheres Niveau 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 leiten oder einer der vielen Köpfe sind, die hart daran arbeiten, Strategien für Sicherheitsprogramme zu entwickeln, ist es jetzt an der Zeit, noch einen Schritt besser zu machen, als nach links zu „wechseln“. Mit der richtigen Schulung, den richtigen Tools und der richtigen Umgebung können Sie einen Sicherheitsinkubator für Entwickler einrichten, der sich für alle Beteiligten auszahlt. Wenn diese Checkliste einige Bereiche mit Verbesserungspotenzial aufgezeigt hat, dann haben Sie eine großartige Gelegenheit, Ihr Unternehmen auf eine von DevSec geleitete Entwicklungsabteilung vorzubereiten, die das Risiko von Beginn des SDLC an reduzieren kann.