Eine Einführung in Edgios Jenseits der Kante Podcast Episode 4: DevSecOps: Shift Left to Avoid Shifting Your Product Roadmap Right moderiert von Lauren Bradley, Global Campaign Manager bei Edgio.
Lauren Bradley: Hey, und willkommen bei Beyond the Edge, wo wir uns mit den Besonderheiten moderner digitaler Unternehmen befassen. Ich bin Lauren Bradley, Ihr Co-Pilot für diese Episode, und heute werden wir uns mit dem Thema Linksverschiebung beschäftigen, insbesondere wie sich Kultur und Technologie verändern, da Webanwendungen und API-Schutz zu einem nativen und inhärenten Bestandteil Ihres DevOps-Lebenszyklus werden.
Beginnen wir mit einer schockierenden Statistik vom Ponemon Institute. Heute dauert es mehr, die meisten Unternehmen, mehr als 200 Tage, bis eine Sicherheitsverletzung erkannt wird. Wenn Sie eine Sicherheitsverletzung nicht schnell genug erkennen, kostet das Sie sehr viel. IBM stellte fest, dass die Kosten für behobene Bugs, die während der Testphase gefunden wurden, 15 Mal höher sein können als die Kosten, die während des Entwurfs gefunden wurden.
Also, um es einfach zu sagen: Je länger Sie warten, um ein Problem zu fangen, desto mehr kostet es Sie. Und wir sprechen nicht nur über Geld, die Nacharbeit, die Zeit und die Energie, die letztendlich zu einer Verschiebung der Produkt-Roadmaps führen kann. Wie können Sie also effektiv nach links wechseln und vermeiden, wertvolle Ressourcen zu verschwenden und Ihren Fortschritt zu stoppen?
Wir haben heute Michael Grimshaw, Director of Platform Engineering von Edgio, und Richard Yew, Senior Director of Product Management für die Edgio Security Platform. Willkommen, Michael und Richard. Es ist toll, dich dabei zu haben.
Michael Grimshaw: Danke, Lauren. Toll, hier zu sein. Vielen Dank.
Lauren Bradley: Könnt ihr mir etwas über euch selbst und eure ersten Gedanken zu diesem Thema erzählen? Mike, wir fangen mit dir an.
Michael Grimshaw: Absolut. Zunächst einmal möchte ich Ihnen danken, Lauren, für Ihr Interesse. In diesem sehr wichtigen Thema und, und Sie graben sich ein, und die Gespräche, die wir zu diesem Thema geführt haben und führen, einschließlich dieses ein Jahr hier, ist nur ein unschätzbarer und unentbehrlicher Faktor für unsere Arbeit, die wir in der Branche leisten.
Michael Grimshaw: Dieses Verständnis muss weit und breit geteilt werden und das Interesse wirklich schätzen. Mein Name ist Michael Grimshaw. Ich bin der Direktor für Plattformtechnik hier bei Edgio. Für diejenigen unter Ihnen, die mit der Plattform nicht vertraut sind oder in der Branche sehr gut vertraut sind, ist es wirklich wichtig, Ihre Anwendungen und Infrastruktur in kohärenten Einheiten zu vereinheitlichen.
Und ich komme zu der Plattform mit einem starken Sicherheitswissen, und dies ist ein Bereich, für den ich ziemlich leidenschaftlich bin, weil es die Nadel in so großer Weise bewegt, was Sicherheit, Rentabilität und so viele der Bereiche angeht, die für unsere Branche so wichtig sind.
Und ich kann mich um DevSecOps kümmern, aber ich übergebe es Richard für sein Intro.
(Richard Yew) Vielen Dank, Michael. Ja. Ja. Dies ist ein sehr wichtiges Thema. Es ist mir sehr nahe und sehr am Herzen, denn ich persönlich habe den gesamten Softwareentwicklungsprozess durchlaufen und diese auch in das Unternehmen übersetzen können.
Apropos, was ich tue… offensichtlich leite ich, wie Lauren erwähnte, unsere Sicherheits-Produktmanagement-Organisationen bei Edgio. Mein tägliches Leben umfasst also die Zusammenarbeit mit dem Forschungs- und Entwicklungsteam, dem Ingenieurteam, um sicherzustellen, dass wir unseren Kunden einen Mehrwert bieten. Und alles, was natürlich dazu gehört, wie die Optimierung unserer Entwicklungspraxis, unsere Sicherheit, CI-CD-Praxis. Um sicherzustellen, dass wir tatsächlich in der Lage sind, sichere Produkte bereitzustellen.
Richtig. Das bietet unseren Kunden tatsächlich einen Mehrwert, liefert sie pünktlich und im Rahmen des Budgets und stellt sicher, dass wir unseren Kunden ein hervorragendes Erlebnis bieten. Mein Ziel dabei ist es also, die gesamte DevSecOps aus der Perspektive der Menschen zu betrachten – den Prozess im Gegensatz zur Technologie und wie wir die Best Practices für die Branche tatsächlich implementieren können.
Was ist DevSecOps?
Zu deinem Punkt, Richard, lass mich einfach den Ball stehlen, wenn es dir nichts ausmacht.
Und ich denke, wir sollten einfach standardisieren, was wir mit DevSecOps meinen, und den Linkswechsel verschieben, richtig? Es gab Gartner, hier sind die Dinge für einige Leute, die sich auf diesem DevSecOps zuhören, und die Begriffe verschieben sich nach links, verschieben sich nach rechts usw. könnten relativ neu klingen. Das ist nicht neu, weißt du, es ist nicht wie das neueste, was gerade vor einem Jahr passiert ist.
Nein, das ist schon eine ganze Weile in der Industrie gebacken. Gartner hatte sogar einen Bericht aus dem Jahr 2017 über den DevSecOps-Lebenszyklus. Es war nur eine echte Erweiterung des DevOps, des DevOps-Trends in der Branche, der sich nur um die Integration von Sicherheit in das Infosec in die Feedbackschleife und den Lebenszyklus Ihrer Softwareentwicklung ausdehnte.
Und wie ich schon sagte, schrieb Gartner 2017 darüber, und es war bereits ein Prozess und eine Bewegung in der Branche. Eine ganze Weile davor. Das sind also keine brandneuen Konzepte. Es ist nur eine Erweiterung dessen, woran wir seit Jahren arbeiten. DevSecOps ist ein ähnliches Modell von DevOps, da man eine Entwicklungsseite und eine operative Seite hat.
Und im Kern: Es baut alle Ihre Sicherheitsanforderungen so schnell wie möglich auf, ich meine, von Beginn der Konstruktion, den ganzen Prozess zu bauen, wo Ihre Entwickler auf der linken Seite des Schiffes auf der Entwicklungsseite sind, entschuldigen Sie, Verschiebung rechts ist mehr auf der Operations Observability Seite. Wir werden uns heute auf die linke Seite konzentrieren, aber es geht im Grunde darum, Ihre Scans zu testen und Ihre Validierung, bereits ganz links, zu testen. Und so früh wie möglich im Entwicklungszyklus in Ihrem SDLC. Eines der Dinge, über die es zum Beispiel spricht, und auch hier geht es um mehr als sieben Jahre zurück, ist Dinge wie Sicherheit, Scannen und Scannen Ihrer, wissen Sie, Open Source-Bibliotheken von Drittanbietern, Repositorys, Codebasis, sowie den Code, den Sie schreiben, das Design, die Architektur, die ganzen neun Meter, und das von Anfang an einbacken. Und eines der Beispiele, das ich genannt habe, ist das Erstellen und Sichern genau der IDEs, die Ihre Entwickler verwenden. Es ist nur ein Beispiel, und es gibt viele davon.
Damit sie beim Schreiben ihres Codes sofort Feedback erhalten. Oh, ich habe gerade die Tür offen gelassen für, wissen Sie, Credential Stuffing oder Sequel Injection, und sie bekommen genau wie ein Syntaxfehler, sie bekommen einen Sicherheitsfehler, genau da ist das Schreiben des Codes. Sie können das also sofort beheben, damit sich kein Kunde darüber beschwert, dass der Kunde oder Endnutzer verpfändet wird. Einen Monat später, nein, es wird direkt dort abgewickelt.
Am günstigsten, am schnellsten, am einfachsten zu Beginn. Richard, du wolltest etwas sagen.
Warum ist die Verlagerung nach links so wichtig, wenn es um Kosten geht?
Richard Yew: Oh ja. Ja. Als ob ich denke, dass die Kosten wirklich sehr wichtig sind, um darüber zu reden, weißt du, nun, jeder kennt eine Menge Betriebskosten, weißt du, jedes Unternehmen, es ist wie die Entwicklung, oder? Der F&E-Prozess.
Wenn es also um die Kosten geht, ist deshalb die Linksverschiebung wichtiger, oder? Weil wir uns viel Mühe geben und darüber reden, warum, weißt du, ich bin mir sicher, dass wir später auf das „wie“ eingehen werden, aber wir wollen auf den Grund eingehen, warum das so wichtig ist, weil wir Daten haben.
Ja. Laut unserer Studie wissen Sie, dass Sie wissen, dass Sie eine Sicherheitslücke beheben, die nach der Freigabe Ihres Codes gefunden wurde, und Produktionen 15-mal mehr Kosten, als Sie wissen, wenn sie in einer Entwurfsphase gefunden werden, wenn Sie die Bedrohung montieren. Natürlich sagen wir nicht, dass Sie wissen, dass die Anfangsphase der Entwicklungsbemühungen alle Sicherheitslücken vollständig auffangen würde.
Deshalb müssen wir die Verteidigung eingehend umsetzen. Aber es ist sehr wichtig, dass Sie wissen, wenn Sie sich die acht Phasen ansehen, wissen Sie, im Allgemeinen, der Schuldenzyklen, der Lebenszyklen von, Sie wissen schon, planen, programmieren, bauen, testen, bis hin zu mögen überwachen und zu betreiben. Richtig. Je weiter man sich die Sicherheitslücke ansieht, desto teurer wird es sein, weißt du, je weiter man sich bewegt.
Damit Ihr Unternehmen das Problem tatsächlich beheben kann. Wir sprechen also über den Unterschied zwischen dem Auffinden einer Schwachstelle bei einem Scan, der passiert, nachdem Sie bereits eine Reihe von Codes für die Produktionen freigegeben haben, und sagen wir, Sie wissen schon, dass Sie eine dynamische Anwendungssicherheitsaufgabe in der Staging-Umgebung durchführen, um sie tatsächlich frühzeitig zu erkennen, bevor Sie diesen Code an die Produktionen senden, oder?
Richard Yew: Vielleicht können Sie diese Probleme entweder beheben oder Sie implementieren eine Art virtuelles Patching direkt im Voraus, bevor Sie eine Codereduzierung veröffentlichen, um dies zu mindern. Aber auch hier ist es sehr wichtig zu verstehen, dass die Sicherheit bereits vom ersten Schritt des Prozesses an integriert werden muss, noch bevor Sie mit dem Schreiben des Codes beginnen, bevor Sie etwas in Ihre IDE eintragen und darüber nachdenken, Bedrohungsmodellierung durchzuführen. Hey, welcher Teil des Entwurfs könnte potenziell anfällig für Ausbeutung sein?
Tägliche Auswirkungen für DevOps und Sicherheitsteams
Lauren Bradley: Ja, und das sind wirklich gute Punkte, Leute. Ich meine, was kann das, abgesehen von den Kosten, für ein DevOps oder ein Sicherheitsteam bedeuten, wenn es dies nicht von Anfang an implementiert?
Außerdem möchte ich darüber sprechen, wie wir es effektiv in den DevOps-Lebenszyklus umsetzen.
Michael Grimshaw: Tolle Frage. Tolle Frage. Und lassen Sie mich in meiner ersten Antwort ganz offen sein. Jeder in der Branche, jeder CEO, jeder CTO, jeder CFO – jeder, Techniker, Benutzer – was wir alle wollen, ist nur eine magische Kugel, die wir tun können, was wir täglich tun.
Und dann haben wir eine magische Sicherheitskugel, dass Sie einfach den Schalter umlegen und Ihre Arbeit plötzlich sicher ist. Das ist es, was jeder will, aber das ist nicht die Realität. Das heißt, wissen Sie, die Leute fragen uns. Ich möchte sie fragen, wie ist das Wetter im Fantasy-Land? Ich höre, es ist schön. Diese Art von Jahr ist, und wenn Sie sich Ihrer Sicherheit nähern, Ihrer Infosec und Ihrer Entwicklung, da dies nur ein Anziehungspunkt ist. Weißt du, „Oh, ich werde ein paar Tools kaufen, die ich anbauen werde, nachdem wir alles entwickelt, gebaut und bereitgestellt haben, und es wird weitergehen und alles sicher machen“, kaufst du einen sehr teuren Briefbeschwerer, um ehrlich zu sein.
Und aus diesem Grund wurde erwähnt, dass es um Menschen, Prozesse und Werkzeuge geht. Aus diesem Grund ist die kohärente Gesamtheit dieses Ansatzes so wichtig. Bist du, wir sind weit, Jahre, Jahrzehnte, wenn es jemals möglich war? Um ehrlich zu sein, haben wir viele Lehren aus der Idee gezogen, dass Sie einfach etwas entwerfen und ein Sicherheitswerkzeug einsetzen, und schon sind Sie bereit, loszulegen.
Es wirkt sich auf alles aus, von Ihren Kosten bis hin zu Ihrer Entwicklergeschwindigkeit und den Kosten für Ihre Kunden. Ein gutes Beispiel dafür ist mein Verdacht, dass fast jeder, der sich diesen Podcast zu einem bestimmten Zeitpunkt seiner Karriere anhört, sich in einer Situation befand, in der eine neue Funktion, ein neuer Service oder ähnliches oder sogar nur ein Patch und Update bereitgestellt wurden. Alles scheint gut zu sein. Alles läuft gut. Und dann erhalten Sie plötzlich einen Anruf von einem Ihrer Kunden oder Infosektoren einen Anruf von einem der Kunden. „Wir wurden gerade verpfändet“ oder „wir hatten gerade einen Sicherheitsvorfall“ oder so. Und der Grund dafür ist, dass Sie es bereitgestellt haben, aber vielleicht waren die Scans noch nicht fertig, oder Sie haben keine Scans durchgeführt, oder Sie hatten sie nicht richtig eingestellt und Sie haben gerade eine massive Sicherheitslücke eingeführt.
Vielleicht betrifft es Sie, aber noch wichtiger ist, dass es Ihre Kunden betrifft. Bei DevSecOps geht es darum, all das in einem kohärenten Prozess zusammenzubacken und das zu vermeiden. Es geht um Kosteneinsparungen. Auf Jeden Fall. Geht es darum, die Margen zu verbessern? Oh, auf eine große Art. Aber es geht auch darum, die Haftung für Ihr Unternehmen und die Ihrer Kunden zu beseitigen.
Integration von Sicherheit in DevOps – es ist wie ein Kuchen backen!
Richard Yew: Absolut. Weißt du, wenn wir über das Backen sprechen, weißt du, als hätte Mike so einen Begriff kohärente Totalität benutzt. Als wäre das so wahr. Das ist sehr mächtig, das ist ein sehr mächtiges Wort, um zu zeigen, warum es wichtig ist, dass das gebacken wird, als ob ich in Edgio der Analogie-Typ bin.
Ich mag es, einen Haufen Analogie herumzuwerfen und ich habe das toll gehört. Analogien würden meiner Meinung nach als starke Grundlage dienen, um die richtigen Kulturen in jedem Unternehmen zu fördern, wie wir alle wissen, dass ein großer Teil unserer Arbeit Evangelisation ist. Es geht nicht nur darum, die richtigen Technologien zu implementieren und einen Prozess zu schaffen, sondern auch um eine Menge internes Marketing.
Um den Leuten zu sagen, dass die Sicherheit für das Unternehmen wichtig ist, oder? Denn als Sicherheitsexperten denken die Menschen nicht nur an Sicherheit, sondern auch an das Hinzufügen zusätzlicher Prozessebenen in Ihren Workflow. Aber die richtige Denkweise ist: Wie kann Sicherheit das Unternehmen beschleunigen?
Wie kann Sicherheit tatsächlich zu mehr Umsatz führen, weil dies eine gute Möglichkeit ist, viele der Sicherheits- und Sicherheitsimplementierungen zu rechtfertigen, die Sie tun müssen, um die Sicherheit des Unternehmens zu gewährleisten? Eine der Analogien, die ich hörte, war, dass Sicherheit nicht wie ein Sahnehäubchen auf dem Kuchen behandelt werden sollte, weißt du, wie man aus dem Kuchen backt und alle Glasuren als letzten Schritt setzt, weißt du, das ist normalerweise das, was Leute tun, wenn sie keinen Sicherheits-, ICD-Workflow haben und nur Firewalls und, weißt du, API-Schutz implementieren, was auch immer in der letzten Phase der Produktionsphase. Was es sein sollte, die Sicherheit, es ist wie Mehl, weißt du, es hätte von Anfang an etwas sein sollen.
Sicherheit ist wie Mehl für dich, um den Kuchen zu backen. Und wenn die Sicherheit richtig gemacht wird, kann man sie nicht sehen. Und der ganze Punkt der Sicherheit ist, wenn es richtig gemacht wurde, sollte es eingekocht werden und es ist nicht sichtbar. Es sollte nicht etwas sein, das Herausforderungen schafft. Es sollte nicht etwas sein, das das Unternehmen verlangsamt.
Wie Analogien, die ich früher dazu beigetragen habe, dem Unternehmen zu zeigen, warum das so wichtig ist, ist, dass ein starker Sicherheitsprozess, eine Kultur der Sicherheitstechnologie, eine Art starke Bremsen haben. In einem Rennwagen weißt du, warum jeder Supersportwagen da draußen große, wirklich große, schicke Bremsen hat, weil er es ihnen ermöglicht, schneller Kurven zu fahren.
Dadurch können sie hart bremsen. Es ermöglicht ihnen, schneller zu fahren und härter zu werden, oder? Es ermöglicht ihnen, das Rennen zu gewinnen. Also, starke Bremsen sind genauso wichtig wie ein starker Motor, richtig? So sollten wir die Sicherheit auf einem philosophischen Blick betrachten. Weißt du, offensichtlich reden wir viel über hohe Ebenen, oder? Also, wir wollen offensichtlich, wissen Sie, irgendwie tiefer in das hineingehen. Im Wesentlichen ist das alles in Ordnung, aber wie genau werden wir das umsetzen?
Michael Grimshaw: Ja. Ich denke, das ist ein toller Ruf, das Bremsen. Kraftvolles Bremsen gibt Ihnen die Kontrolle. Da ist die Strömung oder die Straße, die wir vor uns haben, ist voller Kurven, Haarnadelkurven und all das, und da gibt es, sicher, es gibt Geraden, wo man die Bremsen nicht berührt, aber um alles zu steuern, das, diese Bremse, ich glaube, liebe, ich liebe diese beiden Analogien, Richard, denn diese Bremsanalogie gibt Ihnen Kontrolle, es gibt Ihnen feinere Kornkontrolle, wenn Sie vor Bordsteinkanten, Herausforderungen und, und, und, und, unerwarteten Dingen stehen.
Richard Yew: Toller Anruf. Übrigens, ich will es klarstellen, ich habe nicht die Analogie gefunden, die von diesem Kerl namens Dr. Eric Koh stammt. Das hat er und er führt einen tollen Podcast. Also empfehle ich jedem, sich das anzusehen. Aber ja, ich finde es so angemessen, wenn ich dem Unternehmen das Konzept erklären möchte, insbesondere bei denjenigen, die noch nicht mit diesem Konzept vertraut sind.
Problematische, Isolierte Teams Und Wechselnde Roadmaps
Richard, du sprichst darüber, wie du, du hast erwähnt, weißt du, ob, wenn es, DevSecOps ist, oder? Du siehst es nicht. Und offensichtlich ist eine dieser grellen Sichtbarkeiten Kosten. Es sind auch isolierte Teams. Es fühlt sich auch so an, als ob es eine Trennung zwischen den Teams gibt, wenn diese Probleme auftreten und warum wurden sie nicht zuvor erfasst?
Welche Prozesse, welche Kommunikation fand nicht statt, um diese schnell oder effektiv zu lösen? Also, meine Frage an Sie ist, wissen Sie, nach Ihrer Erfahrung, welche von… Sie wissen, es gibt wahrscheinlich einen Mangel an Transparenz. Die Entscheidungsfindung ist langsam, und es besteht das Potenzial, Ressourcen zu verschwenden.
Welche Probleme sind Ihrer Meinung nach bei Silos am problematischsten, wenn Teams in Silos arbeiten?
(Richard Yew) Ja, ich nehme das hier. Ich denke, eine Sache, die ich persönlich in meinem früheren Leben erlebt habe, ist, dass Sie es wissen, und das ist, wenn wir über ähnliche Produkte sprechen, wissen Sie, wie eine Art Planung, ist es wichtig, dass Sie manchmal ein Sicherheitsteam haben, das nicht irgendwie in die Forschung und Entwicklung eingebettet ist, wie in die CTO-Organisation.
Manchmal beobachten wir in vielen Unternehmen Silos zwischen Sicherheitsteams und der CTO-Organisation, und Sie werden feststellen, dass viele Prozesse später durchgeführt wurden. So stoßen wir beispielsweise auf eine Situation, in der wir eine Menge Produkte und viele Codes veröffentlichen, weil es einfach keine starke Kommunikationszusammenarbeit zwischen den Sicherheitsteams und den Ingenieurteams gibt.
Am Ende haben Sie festgestellt, dass ein Unternehmen Compliance einhalten muss. Manchmal sind die konkreten Beispiele, dass Teams kommen, die Scans durchführen, etwa ein- oder zweimal im Jahr. Was ist das Ergebnis dieser Scans? Nun, mir wird gesagt: „Hey, Richard, wir müssen im nächsten Quartal langsamer werden, weil wir gerade hundert verschiedene große und kleine Sicherheitsfehler gefunden haben. Vielleicht etwa 20, wie die Top 20 Schweregrade 1 und 2 und darüber sind, während der Rest, weißt du, es geht darum, dich auf die Behebung dieser Dinge zu konzentrieren.“
Und es gibt ein SLA innerhalb des Unternehmens, das Sie beheben können. Was am Ende passiert ist, ist, dass Sie damit im Wesentlichen meine Roadmap genommen haben und sie einfach in das nächste Quartal werfen. Indem wir also nicht nach links verschieben, diesen Prozess nicht wirklich in Gang setzen, indem wir diese Dinge nur auf der rechten Seite tun, fördern wir im Wesentlichen unsere Roadmap, die, wie Sie wissen, umsatzsteigernde Ergebnisse darstellt, die möglicherweise zur Erweiterung unseres Geschäfts beitragen könnten. Wir werden es potenziell richtig verschieben, damit wir tatsächlich, wissen Sie, ein Viertel für den Versuch ausgeben können, diese Probleme zu mildern.
Deshalb sage ich, dass es für das Unternehmen und das Unternehmen enorm teuer ist, sich vorzustellen, dass die Roadmap um ein Viertel verschoben werden muss. Also müssen alle Ihre Veröffentlichungspläne Ihrer neuen Produkte, Funktionen und Funktionen verschoben werden, oder? Weil du nicht nach links in deine Praxis verschoben hast.
Und einige dieser Dinge hätten durch eine bessere Zusammenarbeit verbessert werden können, insbesondere zwischen den Teams für Anwendungssicherheit innerhalb eines Unternehmens und dem noch-und-Entwicklungsteam. Aus diesem Grund stellen wir fest, dass viele Unternehmen dieses neue Konzept nutzen. Wisst ihr, ihr habt von HR BP gehört, wisst ihr, HR-Geschäftspartnern, die in verschiedene Geschäftseinheiten eingebettet sind.
Es gibt jetzt ein Konzept von Application Security BP. Sie werden also diese Begriffe wie APP SEC BP hören, die zur Praxis werden könnten, wenn Sie Menschen arbeiten. Fast wie ein halb eingebetteter Manager des Entwicklungsteams, der sicherstellt, dass er in jedem Schritt des Entwicklungs-Workflows die richtige Anleitung, Tools und Prozesse bereitstellt, z. B. bei der Implementierung der Analyse der Softwarezusammensetzung, der Implementierung sicherer ID, der Implementierung aller Black-and-White-Box-Aufgaben, wisst ihr, während des Prozesses, um sicherzustellen, dass wir einige dieser Probleme bereits früh im Entwicklungslebenszyklus erfassen können.
Michael Grimshaw: Und ich liebe alles. Tolle Frage, Lauren. Und ich liebe alles, was du gerade gesagt hast, Richard. Weil damit Kosten verbunden sind. Weißt du, wenn Leute, wenn jemand in einem Produkt ist, wo sie hören, warten, weißt du, wenn ich nach links schalte, muss ich meine Roadmap nicht nach rechts verschieben.
Das ist Musik in ihren Ohren. Aber vielleicht für CFOs, oder sogar für den Betrieb oder andere Bereiche des Unternehmens, könnten Sie sagen, okay, nun, welche Auswirkungen hat das? Die Auswirkungen sind enorm. Du hast gerade deine Verkaufsabteilung geknebelt. Sie haben sich auf Ihre Kunden ausgewirkt, weil Sie, insbesondere im Bereich Sicherheit, viele Kunden haben. Ich weiß, was die Plattform betrifft, wenn ich mit meinen Anbietern spreche, möchte ich wissen, was die Roadmap ist, denn, okay, vielleicht muss ich zu meinen Auditoren gehen und ich muss kompensierende Kontrolle bekommen, bis Sie etwas auf Ihrer Roadmap veröffentlichen. Nun, wenn du mir gerade gesagt hast, okay, was ich erwartet hatte, in einem Viertel geliefert zu werden, wird drei Viertel sein. Ich werde mich jetzt mit anderen Anbietern beschäftigen. Warum? Weil ich meinen Rechnungsprüfern Verpflichtungen gegenüber habe, die ich erfüllen muss.
Und ich liebe es auch, Richard, dass Sie Auditoren und den Compliance-Prozess angesprochen haben. Das ist ein weiteres Beispiel für Sie, Lauren, wo Siloisierung die Dinge radikal in die Luft jagen kann.
Wenn Sie sich mitten in einem PCI, SOC, ISO, FedRAMP oder einem dieser verschiedenen Compliance-Frameworks befinden und Sie sich nicht wirklich integriert haben, Sie immer noch eine Asylmentalität betreiben, werden Sie wahrscheinlich jemanden haben, der Compliance oder Info sec mit Ihren Auditoren spricht, der das über eine oder zwei Ebenen auf die Engineering-Seite übersetzen muss, die hoffentlich alles umsetzen wird, und dann nur, um es umzusetzen. Und dann all die Beweise und das Scannen und alles, was Sie brauchen, um Ihren anderen zurückzugeben, viel Glück.
Wenn sich das tatsächlich ergibt, haben wir alle das alte Gerücht-Spiel aus der Grundschule gespielt. Es ist eine ähnliche Funktion. Wenn Sie integrierte Teams haben, die mit den Auditoren arbeiten, die sofort wissen, wie man das in die spezifische Technologie übersetzt, und Sie haben das Scannen und Sie können es sofort umdrehen und in Ihre Regelsammlung einfügen und sowohl in Echtzeit scannen und validieren, als auch wenn Sie sich mit den Auditoren treffen. Du hast alle Beweise hier zusammen. Das ist eine radikale Veränderung. Damit können Sie Ihre Kunden schneller beliefern, anstatt, wie Richard sagte, Ihre Roadmap jetzt weiter zu verschieben.
Lauren Bradley: Ja. Um das greifbarer zu machen, meine ich, wie können CISOs und AppSec Leader ihre Kennzahlen quantifizieren, um die Kostenauswirkungen oder gar den allgemeinen Erfolg zu verstehen?
Richard Yew: Was, weißt du, es ist lustig, weil wir viel darüber reden, warum, weißt du was, aber lasst uns tiefer in das wie eintauchen, denn ich weiß, dass das ist, wofür ein Großteil unseres Publikums ist. Wir sind nicht hier, um Ihnen flauschige, hochrangige Aussagen zu geben. Was wir hoffentlich bieten wollen, ist ein gewisser Nutzen für die genaue Umsetzung.
Vielleicht können wir also die DevSecOps-Charts herausnehmen, die wir haben, und dann können wir einfach durchgehen, wie wir die Schritte optimieren können. In Ordnung. Wie man also traditionelle Sicherheitstests sehen kann, ist das eine Art linearer Abläufe, oder? Es ist, es ist irgendwie so, als wenn wir über Wasserfall reden, wie dein Plan, du hast, Schönheit, einen Test, richtig?
Während der Phase der Bedienüberwachung wurden zahlreiche Sicherheitstests durchgeführt. Es ist also auf der rechten Seite. Also, jetzt, wo das neue Konzept ist, wenn wir mit den nächsten Bildern fortfahren, richtig? Dass Sie 100 verschiedene Varianten dieses Diagramms finden können. Wenn man heute nur DevSecOps Google, wie Mike vorhin sagte, gibt es dieses Konzept seit 7 Jahren, oder? Sie wissen, dass manche Unternehmen es vielleicht nicht so nennen. Manche Unternehmen nennen es einfach AppSec, oder? Bestimmte Unternehmen nennen sie also eine Sicherheits-Pipeline. Das ist also eine grobe Darstellung dessen, wofür eine Sicherheitspipeline steht. Richtig? Also, von Anfang an haben Sie die Planungsphase, richtig?
Sie haben die Bedrohungsanalyse zur Modellierung. Sie versuchen sicherzustellen, dass Sie all diese Modellierung während der Entwicklung von Lösungen eingespielt haben. Also wie, wie Sie kodieren, wie Sie in eine zweite Phase gehen, Ihre Codierungsphase, richtig? Du willst sichergehen, dass du den Haken hast. Sie möchten sicherstellen, dass Sie über eine sichere IDE verfügen, die jemals wirklich in Echtzeit ist, da Entwickler, die den Code schreiben, einige der Probleme in Echtzeit erfasst haben. Offensichtlich ist das keine silberne Kugel, oder? Aber es handelt sich um eine zusätzliche Schicht, und wir sprechen über zusätzliche Schichten in den Abwehrzyklen. Nun, während wir den Prozess immer weiter und weiter hinunterschreiten, richtig? Sobald du dich zum Code verpflichtet hast, richtig? Sie möchten sicherstellen, dass Sie über einen Prozess verfügen – wer kann einen statischen Scan Ihres gesamten Codes bereitstellen, um sicherzustellen, dass er die automatische Abhängigkeit, die Lieferkette, die Sicherheitslücke usw. überprüft, zusammen mit einer Software-Kompensationsanalyse, um eine Softwareansicht der Materialien zu erstellen, die Ihnen zeigen, welche Art von Software Sie verwenden? Wie alt sind sie?
Denn ich habe vor ein oder zwei Wochen eine Statistik gelesen – 25 % der Downloads von Apache Log4j sind immer noch von der älteren Version, die noch eine Schwachstelle enthält. Es verblüfft mich, dass es immer noch eine Statistik ist, jetzt, wo wir fast zwei Jahre sind. Ich weiß nicht, war es zwei oder drei Jahre, als Anfang Dezember die erste Zero-Days-Schwachstelle von Apache Log4j angekündigt wurde? War es 2021? Wir müssen uns also wirklich darauf konzentrieren, diese Art von Software-Gespräch/-Analyse durchzuführen, um sicherzustellen, dass Sie genau wissen, welche Version der Software Sie ausführen.
Es ist wichtig. Also, dann gehen wir auf Tests zu, oder? Sie wollen sicherstellen, dass Sie interne Tests haben, Sie haben Ihre dynamischen Tests, wissen Sie, implementiert, um sicherzustellen, dass. Wir sind in der Lage, die ausgeführte Anwendung zu testen und festzustellen, ob eine Schwachstelle vorhanden ist, die ausgenutzt werden kann.
Du weißt, dass das normalerweise durch Fuzzing gemacht wird. Was wird hier in einem traditionellen DevSecOps-Zyklus nicht gezeigt? Denn das sieht alles ziemlich normal aus, oder? Während wir uns auf dem Weg zur Bereitstellung, Überwachung und Reaktion bewegen. In der Vergangenheit würden Sie Web Application Firewall, Bot Manager, API Securities und all ihre Web Application API Protection Solutions in die Antwort- und Überwachungsphase versetzen, oder? Wenn Sie Ihren Produktionsverkehr überwachen, stellen Sie sicher, dass keine Ausnutzung stattfindet.
Aber was Sie bedenken sollten, ist, einige dieser von Ihnen vorhandenen API-Schutzmaßnahmen für Webanwendungen zu verschieben. Schieben Sie sie auch nach links. Setzen Sie sie in diesem Fall an, im Bild ist es ein Schritt nach vorne. Setzen Sie sie in die Testphase, während Sie Ihren dynamischen Test zur Anwendungssicherheit durchführen, richtig? Warum testen Sie sie nicht über Ihren Produktionssicherheitsmechanismus? Wissen Sie also, wie viel von einer Schwachstelle zwischen dem Code besteht, wie viele dieser Schwachstellen beseitigt werden können, denn das Wichtigste ist, dass wir immer versuchen, Wege zu finden, um diesen aktuellen Lebenszyklus von Apps zu verbessern, indem wir eine Entwicklung schneller machen. Wenn Sie während dieses Tests eine Sicherheitslücke feststellen, ist es allgemein üblich, dass Sie den Zug im Grunde anhalten. Du gehst zurück, oder? Du reparierst den Code und lässt ihn wieder frei. Du machst die acht Schritte noch einmal durch. Aber was wäre, wenn ich dir sage, dass es vielleicht eine Möglichkeit gibt, zu sagen: „Hey, lass uns den Zug nicht anhalten?“
Lass uns den Zug am Laufen halten. Lassen Sie uns das veröffentlichen, indem Sie vor Schritt vier eine Art zusätzlicher Test mit Sicherheitslösungen durchführen, mit dem Sie rechtzeitig wissen, was Sie virtuell in der Produktion patchen müssen, damit Sie Ihren Zug nicht anhalten müssen. Du hältst deinen Zug am Laufen. Sie behalten Ihre Geschwindigkeit bei.
Sie geben den Code mit dem virtuellen Patch frei, um die Sicherheitsanfälligkeit zu verringern, und beheben sie dann im nächsten Zyklus, hoffentlich sehr schnell. Dies ist auch eine dieser Möglichkeiten, die innovativen Möglichkeiten, wie wir unsere Kunden Schulen und mit ihnen zusammenarbeiten wollen, um den bestehenden CICD-Sicherheitsworkflow zu verbessern.
Ich liebe das, Richard. Ich liebe es, dass du die Tatsache nennst, das in Schicht links ziehst. Wenn dein Spielplan also lautet, lass uns das in die Produktion bringen und dann machen wir uns Sorgen. Sie werden Probleme haben und haben etwas, das Ihre Backside abdecken kann, sowohl durch Ihren Entwicklungs- als auch Bereitstellungs- und Betriebsprozess. Ich liebe, was du da draußen genannt hast. Und eine Analogie, und eine ähnliche Analogie, würde ich sagen, ist wie Chaos Monkey. Hier ist die Sache. Wenn Chaos Monkey in der Produktion arbeitet und Sie nur dann mit Chaos Monkey zu tun haben, wenn es in der Produktion ist, werden Sie eine schreckliche Entwicklungs- und Betriebserfahrung haben.
Sie müssen dafür planen, konstruieren und konstruieren, bevor es in die Produktion geht. Sonst wirst du im Elend sein.
Quantifizierung von Kennzahlen, um Kostenauswirkungen und Erfolg zu verstehen
Richard Yew: Ja, und Lauren, ich beantworte gern frühere Fragen: Wie messen wir den Erfolg gerade jetzt, wenn wir nur den gesamten DevSecOps-Lebenszyklus betrachten und wie wir ihn optimieren können. Was ist Best Practice, richtig?
Sehr schnell. Also müssen wir den Erfolg verfolgen. Sie müssen also in der Lage sein, den Erfolg zu quantifizieren. Richtig. Es gibt also einige der Kennzahlen, die helfen könnten, wenn Sie ein Sicherheitsführer sind und versuchen, den Erfolg der Programme zur Anwendungssicherheit zu messen. Eines der Dinge, die Sie betrachten können, ist auch, was, wie viel von der Anwendungsabdeckung Sie haben, richtig?
Haben Sie beispielsweise mehr als 90/95 Prozent aller Anwendungen oder internetgestützten Anwendungen in Ihrem Unternehmen im selben Prozess? Haben Sie denselben standardisierten Prozess? Richtig. Das alles, einschließlich Softwarezusammensetzung, Analyse, SAS, Test, Test, Test, Test, wissen Sie, wie Webanwendung, API-Schutz.
Haben Sie diese Dinge vor Ort, um die Abdeckung zu verfolgen? Wie oft werden Sie freigeben und wie oft müssen Sie zurückrollen? In welcher Phase müssen Sie aufgrund der Sicherheitslücke, die Sie erkennen, ein Rollback in der Produktionsphase durchführen, im Vergleich zu wie oft müssen Sie während der Phase „Code Commit“ ein Rollback durchführen, in der Sie statische Analysen durchführen, weil die Produktion offensichtlich zurückgesetzt wird.
Es wird viel teurer sein, als den Code nach einer kleinen statischen Codeanalyse zu reparieren. Richtig. Die anderen beiden Statistiken dort, die Sie unbedingt als messen möchten, wie Lauren vorhin andeutete. Die durchschnittliche Zeit für die Erkennung von MTTD beträgt 200 Tage. Ich glaube also, dass man mit dem richtigen Prozess mit Rechtshilfe nach links drastisch die Erkennungszeit reduzieren kann, um viel kürzer zu sein. Versuchen Sie also, Metriken zusammenzustellen, um festzustellen, wie lange es dauert, von der Offenlegung der Schwachstelle bis zur Erkennung dieser Gebäude in Ihrem Unternehmen.
Und implementieren Sie auch Zwischenzeit, um zu reagieren, oder? MTTR-Zwischenzeit, um die Zwischenzeit zu lösen, oder? Der Branchendurchschnitt liegt bei 70 Tagen, also sind es 70 Tage, nachdem die Schwachstelle gefunden wurde, richtig? Ausgenutzt dauert es immer noch 70 Tage, um das Problem zu lösen. Aber wie schnell können Sie mit diesem Start Tracking das Problem lösen? Sobald Sie eine anfällige Version von Protokollen für J finden, die Ihren Code in Ihrer Analyse der Softwarezusammensetzung verwendet, wie schnell können Sie sie virtuell mit einer Firewall patchen oder wie schnell können Sie Ihre Bibliotheken aktualisieren, um eine andere Software zu verwenden, richtig? Ich habe also mit einigen Organisationen gesprochen, die eigentlich vier Stunden mittlere Zeit haben, um die Zeit für log4j-Ereignisse zu lösen.
Das ist äußerst beeindruckend. Und das spricht für die Reife ihrer DevSecOps-Prozesse. Also habe ich alle möglichen gesehen. Und ich habe Kundenorganisationen gesehen, die über Wochen oder sogar Monate Zeit haben, um kritische Probleme wie log4j zu lösen. Daher ist es sehr wichtig, diese Kennzahlen im Auge zu behalten, wenn Sie versuchen, den Prozess insgesamt zu verbessern.
Michael Grimshaw: Und es gibt noch einige andere KPIs, die ich hier einbringen möchte: Wie auf der Plattformseite, wenn es um Infrastruktur geht oder in vielen Fällen um alles Engineering, Kosten waren hier immer ein wichtiges Element. Aber in den letzten Jahren mit steigenden Zinsen, wissen Sie, ist der Hahn bis zum VC-Geld und vieles davon wirklich austrocknen, aber der Name des Spiels und das steigende Zinsumfeld sind ein Schlag up, sehr profitabel.
Und hier gibt es einen Aspekt. Ich liebe diese Technik. Klar, Sie wissen schon, Direktor der Plattformtechnik. Ich liebe die technische Seite, aber vor allem in den letzten Jahren ist ein großer Teil davon, wenn Sie wie gesagt in der Plattform arbeiten, Infrastruktur und dergleichen, der Finanzaspekt und die Klärung und Bereitstellung von Feedback an Ihren CFO sowie Ihren CTO unerlässlich geworden.
Der KPI ist also ein Kosten- und Umsatzfaktor. Dies ist ein weiterer, wichtiger Aspekt auch hier. Und ich möchte nur darauf hinweisen, dass einige der Dinge wie dieses zum Beispiel auf der Einnahmenseite liegen. Wenn Sie mit einer roten Linie sprechen, wenn Sie einen Kunden haben, der Ihren Kauf, aber Ihr Produkt kaufen möchte, durchlaufen Sie eine rote Sicherheitslinie, weil Sicherheit in aller Sorge ist und Ihre Kunden sicher sein möchten, dass sie geschützt sind.
Sie werden ihr Risiko hier minimieren wollen. Und wenn du mit der altmodischen Mentalität zu ihm kommst. Oh ja, wir entwickeln Dinge und dann, lassen wir, stellen wir sicher, dass unsere Infosec sie scannt und all das. Ich habe viele rote Diskussionen und Vertragsgespräche geführt, und das fliegt einfach nicht mehr.
Die Fragebögen und Fragebögen aus der Risiko- und Rechtsabteilung Ihres Kunden sind in den letzten fünf Jahren, geschweige denn 10 Jahren, auf eine ganz andere Detailtiefe gestoßen. Und eine vollständig integrierte Shift-Left-Lösung für Webanwendungen und API-Schutz – all das. Wenn man mit Anwälten anderer spricht, bewegt das die Nadel in großer Weise. Was bedeutet das? Das bedeutet, dass Sie Geschäfte schneller abschließen können. Und wenn Sie nicht gerade den linken Schichtwechsel üben oder nur denken, dass es sich um Infosec als Add-on handelt, möchte ich Sie dazu ermutigen, sich Ihre Abschlussquoten anzusehen und sich genauer anzusehen, wo sie zusammengebrochen sind, und insbesondere die Sicherheitsdiskussionen zu den roten Linien zu betrachten, da diese Art von Produktproblemen zu oft als Kostenstelle angesehen werden. Sie sind es nicht, sie können Einnahmen freisetzen und Ihnen eine riesige Menge Geld sparen.
Zu Beginn des Podcasts haben wir eine Menge der Kosteneinsparungen in Bezug auf die internen Kosten behandelt, aber hier gibt es Einnahmen in Bezug auf Beta-Auswirkungen, die ich für wichtig halte, denn genau dort sind so viele Augen in dieser Welt der steigenden Zinssätze.
Zusammenfassung
Richard Yew: Das ist ein ausgezeichneter Punkt. Ich bin froh, dass wir die Hüte ein bisschen vertauscht haben, wie zum Beispiel meine SDLC-Hüte und du deinen, deinen Business-Hut. Das ist großartig. Ich hoffe, dass all diese Dinge, die wir geteilt haben, unseren Zuschauern einen gewissen Mehrwert bieten.
Lauren Bradley: Vielen Dank. Ich denke, das ist eine tolle Note zum Abschluss. Wir haben die Wichtigkeit einer Verlagerung nach links und die effektive Einbindung von Webanwendungen und API-Schutz in den DevOps-Lebenszyklus erläutert. Und natürlich, wie man Erfolg effektiv messen kann. Gibt es weniger Fehlalarme? Wie lautet Ihre durchschnittliche Zeitauflösung? Wie schnell liefern Sie Software? Und erzielen Sie mehr Umsatz?
All diese Kennzahlen sind für den Erfolg eines Unternehmens von entscheidender Bedeutung. Also, ich schätze euch beide, Michael und Richard, dass ihr heute zu mir gekommen seid. Es war wirklich eine Freude und danke auch an unsere Zielgruppe, dass Sie uns bei Beyond the Edge begleiten. Wir sehen uns in der nächsten Folge.
