Nehmen wir uns einen Moment Zeit und denken wir über die Sicherheit in Ihrem Unternehmen nach. Die Sicherheit ist oft von anderen Engineering-Teams wie Entwicklung, Betrieb, Netzwerk, IT usw. getrennt. Wenn Sie Ihren Fokus gezielt auf die Veröffentlichung neuer Software oder Features und Funktionen in vorhandener Software beschränken, werden Sie feststellen, dass Entwicklung und Betrieb zwar sehr schnell und effizient zusammenarbeiten, diese Funktionen und Features jedoch immer noch in die Sicherheit übertragen. Und die Sicherheit überträgt sie zurück – ähnlich wie Entwicklung und Betrieb vor DevOps funktionierten.

DevSecOps leistet für Entwicklung, Betrieb und Sicherheit das, was DevOps für Entwicklung und Betrieb geleistet hat: Es ist eine kulturelle Praxis – mit technologischer Unterstützung –, die die Arbeit dieser Teams rationalisiert, damit sie zusammenarbeiten können. Ähnlich wie bei DevOps besteht ein Teil der kulturellen Transformation von DevSecOps darin, Empathie füreinander zu entwickeln, indem man die unterschiedlichen Anforderungen jedes Teams versteht.

Das Was und Wie von DevSecOps

DevSecOps macht das Sicherheitsteam nicht überflüssig und macht Sicherheit als Disziplin auch nicht überflüssig (es sei denn, Sie möchten lernen, wie Sie Ihre eigenen Penetrationstests und andere Dinge ohne deren Hilfe oder Anleitung durchführen – was ich nicht empfehle). Ähnlich verhält es sich mit DevOps, das den Bedarf an Betriebsabläufen nicht überflüssig gemacht hat – es hat die Art und Weise verändert, wie Betriebs- und Entwicklungsteams zusammenarbeiten.

DevSecOps unterscheidet sich in der Art und Weise, wie dies geschieht, ein wenig von DevOps. Zur Auffrischung: Das DevOps-Modell sieht folgendermaßen aus:

Im obigen Workflow können Sie sehen, dass Entwicklung und Betrieb immer noch getrennt sind, nur nicht mehr isoliert. Das DevSecOps-Modell sieht folgendermaßen aus:

Wie Sie sehen, ist Sicherheit in jeden Aspekt des DevOps-Zyklus integriert – sie ist nicht wie Entwicklung und Betrieb getrennt.

Dies geschieht durch ein sogenanntes „Shifting Left“ (d. h., die Sicherheit wird immer früher in den Zyklus integriert, beginnend mit der Entwurfs-/Erstellungsphase). In jeder Phase müssen unterschiedliche Tests und andere Aktivitäten durchgeführt werden. Wenn beispielsweise die Sicherheit in der Codephase berücksichtigt wird, muss die Sicherheit an Codeüberprüfungen teilnehmen und Tests wie einen SAST (Static Application Security Test) und/oder eine SCA (Software Composition Analysis) durchführen. Wenn hier Probleme gefunden werden, werden sie hier behoben – vor dem Erstellen, Testen usw. Das Gleiche gilt für jede Phase: Je früher eine Sicherheitslücke gefunden wird, desto weniger Zeit und Fachwissen erfordert ihre Behebung.

Schaffen Sie funktionsübergreifende Empathie

Viele Sicherheitsspezialisten haben keine Erfahrung mit dem Betrieb von Diensten in der Produktion. Ebenso haben viele Entwickler und Betriebsspezialisten keine Erfahrung im Bereich Sicherheit. Um diese Lücken zu schließen, ist es wichtig, sich in die Lage des anderen zu versetzen.

Für die Sicherheit bedeutet dies, dass ein Dienst in der Produktion verwaltet wird. Beachten Sie, dass es wichtig ist, dass das Team die Verantwortung für den gesamten Lebenszyklus dieses Dienstes übernimmt – es führt nicht nur eine einzelne Bereitstellung durch. Die Sicherheitsabteilung muss mit der Entwicklung und dem Betrieb zusammenarbeiten, um zu bestimmen, welcher Dienst gut passt, nicht nur im Hinblick darauf, was für den Betrieb und die Wartung erforderlich ist, sondern auch, was für das Unternehmen sinnvoll ist. Ein kurzes Beispiel: Wenn es sicherheitsbezogene Dienste gibt, wäre es sinnvoll, wenn die Sicherheitsabteilung die Verantwortung für diesen Dienst übernimmt.

Weitere Informationen zum Erwerb eines Dienstes finden Sie in unserem Vollständiger Service Ownership Ops-Leitfaden .

Für Entwicklung und Betrieb müssen sie Übungen durchführen, die ihr Sicherheitsbewusstsein und ihre allgemeine Sicherheitslage verbessern. Eine Möglichkeit hierzu besteht darin, in der Entwurfsphase für verschiedene Funktionen und Releases an Übungen zur Bedrohungsmodellierung teilzunehmen. Bei der Bedrohungsmodellierung arbeiten Teams zusammen, um die Sicherheitsauswirkungen neuer oder geänderter Software, Dienste oder Umgebungen zu ermitteln. Wenn beispielsweise eine Änderung am Netzwerkdesign vorgenommen wird, muss dieses neue Design einer Bedrohungsmodellierung unterzogen werden, damit es angemessen geschützt werden kann.

Schaffen Sie eine Kultur der Zusammenarbeit

Es ist wichtig, mit dem menschlichen Verstand zu arbeiten, nicht gegen ihn. Wir sind eine neugierige Spezies und wir mögen es, beschäftigt zu werden und zu interagieren. Wir sind auch eine Spezies mit einer starken Negativitätsvoreingenommenheit. Lassen Sie uns überlegen, was das Zusammenspiel dieser beiden Faktoren für das Lernen bedeuten kann. Nehmen Sie sich jetzt, während Sie diesen Satz dieses Absatzes lesen, einen Moment Zeit und denken Sie an einige der denkwürdigsten Inhalte, die Sie je gesehen haben, oder an eine besonders denkwürdige Lektion.

Was war daran unvergesslich? War es eine positive Erfahrung? Konnten Sie das Gelernte später auf eine Weise anwenden, die Ihnen oder anderen geholfen hat? War es einfach nur interessant? Oder war es vielleicht Kritik? Wenn Sie an diese Kritik denken, erinnern Sie sich dann besser daran, was kommuniziert wurde oder wie es kommuniziert wurde?

Jetzt, da Sie vorbereitet und bereit sind, werde ich etwas wiederholen, das ich auch in unseren DevSecOps-Betriebsleitfaden aufgenommen habe: Hier bei PagerDuty haben wir die Richtlinie, Mitarbeiter niemals auszutricksen. Ein bekanntes Beispiel sind Unternehmen, die Phishing-E-Mails an Mitarbeiter senden und Sicherheitsschulungen verlangen, wenn die E-Mails geöffnet und/oder darin enthaltene Links angeklickt werden. Das Ziel dieser Übung wird normalerweise darin angegeben, zu demonstrieren, dass echte Phishing-Angriffe sowohl gut konzipiert als auch schädlich sein können und werden, aber wenn wir darüber nachdenken, wie Menschen lernen, ist dies die Lektion, die gelehrt wird?

Das Hauptziel der Sicherheit – im Sinne der Schulung – besteht darin, das allgemeine Bewusstsein der Mitarbeiter für mögliche Sicherheitsverletzungen zu schärfen. Ein weiteres Ziel besteht darin, bei auftretenden Vorfällen präsent zu sein, um Abhilfe zu schaffen. Dazu muss das Team jedoch genügend Vertrauen gewinnen, damit sich die Mitarbeiter psychologisch sicher genug fühlen, um Vorfälle zu melden.

Oder wählen Sie einen anderen Ansatz: Nutzen Sie Sicherheitsschulungen als Gelegenheit, Interesse und Vertrauen zu wecken und aufrechtzuerhalten. Durch die Bereitstellung individueller Sicherheitsschulungen können Sie Ihr Team dazu bringen, Inhalte für Bereiche bereitzustellen, in denen Ihr Unternehmen schwächer ist, und allgemeinere Inhalte für Bereiche bereitzustellen, in denen Ihr Unternehmen stark ist. Außerdem können Sie so wirklich mit Ihren Mitarbeitern interagieren – tun Sie etwas, um ihre Aufmerksamkeit zu erregen. Führen Sie vielleicht einen Cross-Site-Scripting-Angriff vor oder zeigen Sie, wie man ein Schloss knackt, und verknüpfen Sie Letzteres mit Konzepten, die Sie in der Schulung vermitteln möchten.

Da die Anpassung des Trainings von Grund auf ein riesiges Unterfangen ist, verwenden Sie bitte unsere Unsere Schulungsmaterialien sind Open Source unter der Apache-Lizenz , Sie können es also gerne verwenden und entsprechend den Anforderungen Ihrer Organisation umfunktionieren.

Schauen Sie sich unseren neuen Ops-Leitfaden an

Um mehr über das zu erfahren, was ich hier geschrieben habe, schauen Sie sich bitte unsere neue DevSecOps-Leitfaden ! Unsere Ops-Leitfäden werden ständig aktualisiert und dieser Leitfaden ist keine Ausnahme. Wenn Sie also etwas beitragen möchten, können Sie sich gerne an uns wenden oder eine Pull-Anfrage auf GitHub senden. Wenn Sie über DevSecOps chatten möchten, können Sie auch gerne in unserem Community-Foren oder kontaktieren Sie mich direkt unter Þjórsárden , ich würde mich freuen, von Ihnen zu hören!