Risiken und Kontrollen der Software-Lieferkette – 2025

1. Einführung: Hallo. Hallo, alle zusammen. Willkommen zu meinem neuen Kurs , der Supply Chain Security and Master Class. Mein Name ist Pamurg Law und ich werde für die Dauer dieses Kurses, in dem es natürlich um die Sicherheit der Software-Lieferkette geht, Dozent sein für die Dauer dieses Kurses, in dem es natürlich um die Sicherheit der Software-Lieferkette geht, Sicherheit der Software-Lieferkette geht Nun, der Zweck dieses Kurses ist sehr, sehr einfach. Ich möchte Ihnen die Grundlagen der Software-Lieferkettensicherheit erklären , die Grundlagen für Fortgeschrittene festigen und Sie werden ein sehr umfassendes Verständnis der Software-Lieferkette erlangen ein sehr umfassendes Verständnis der Software-Lieferkette Was sind ihre Komponenten, was sind die Beteiligten und die verschiedenen Arten von Risiken und Sicherheitsproblemen, die die Integrität und Sicherheit Ihrer Software gefährden können Integrität und Sicherheit Ihrer Software gefährden Sie werden also alle damit verbundenen Risiken verstehen und ich gebe Ihnen das Wissen, das Sie benötigen, um ein geeignetes Sicherheitsprogramm für die Lieferkette zu implementieren . Und sehr, sehr wichtig. Ich sagte ein Sicherheitsprogramm. Ich meinte nicht, dass ich kein Sicherheitsprodukt gesagt habe , denn das ist leider oft der Grund, warum die Leute verwirrt sind. Sie glauben, dass es bei der Sicherheit der Software-Lieferkette darum geht , eine Software zu implementieren oder sich zertifizieren zu lassen, und das ist nicht weiter von der Wahrheit entfernt. Sicherheit der Software-Lieferkette ist sozusagen eine komplette Nische in der Cybersicherheit, die Sie benötigen, um die verschiedenen Risiken zu verstehen und zu verstehen, wie sie gemindert werden können Nische in der Cybersicherheit, die Sie benötigen, um die verschiedenen Risiken zu verstehen und zu verstehen, wie sie gemindert Wir werden uns einige Fallstudien auch innerhalb der Branche ansehen , wie sie entstanden sind und wie Sie sie verstehen können, um sich weiter davor zu schützen , denselben Problemen zum Opfer zu fallen , die es gibt Also, wer bin ich? Mein Name ist Kamchal und ich bin ein mehrfach ausgezeichneter Experte für Cybersicherheit Ich habe geschrieben: Okay, ich nenne mich selbst eine Führungskraft Ich bin seit über 21 Jahren in einer Branche im Bereich Cybersicherheit Ich war Redner und Dozent. Ich bin auch Karriere-Coach. Ich helfe Menschen, sich mit Cybersicherheit vertraut zu machen. Ich habe einen YouTube-Kanal namens The Cloud Security Guy, auf dem ich über Cloud-Sicherheit und KI spreche. Ich bin auch Bestseller-Autor und Kursersteller, wie ich bereits erwähnt habe Nur um Ihnen die Gewissheit zu geben, dass ich ein bisschen darüber weiß, wovon ich spreche, sind dies einige meiner Bücher, die über KI-Governance und Cybersicherheit geschrieben wurden Ich habe viele Kurse auf dieser Plattform. Zu diesem Thema. Ich habe auch Bücher über Zero Trust und Comtea, Cybersicherheitszertifizierungen viele andere Themen Ich bin dort auf Substack. Ich habe dort einen kostenlosen Newsletter. Ich bin auch auf LinkedIn dort. Cloud heißt wie mein YouTube-Kanal The Cloud Security Guy, und ich bin auf Twitter dort, also zögern Sie nicht, mich dort zu kontaktieren. Ich freue mich immer, von Leuten zu hören, die meine Kurse besucht haben. Machen wir jetzt einen Schritt vorwärts, rückwärts, tut mir leid. Lassen Sie uns über die Lieferkette sprechen , wenn wir über die Lieferkette sprechen Sie wissen es vielleicht nicht, aber die Lieferkette ist für unser Leben von entscheidender Bedeutung. Und was ist eine Lieferkette? Es ist ein Netzwerk von Einzelpersonen und Unternehmen, die an der Entwicklung eines Produkts und dessen Lieferung an den Kunden beteiligt sind , oder? Und wenn Sie etwas kaufen, wissen Sie, Beispiel aus dem Internet oder ein Produkt, und die meisten Menschen wissen es nicht. Normalerweise ist es ein sehr langer Weg von der ursprünglichen Idee bis zum Zeitpunkt der Lieferung. Und es sind eine Menge Leute involviert, vom Lager über das Unternehmen bis hin zum Transport, bis man es bekommt, oder? Und es sind viele, viele , so nennen Sie, Interessenvertreter daran beteiligt. Und was Sie nicht wissen ist, dass es viele, viele Möglichkeiten gibt, auch dass etwas passiert, wenn das Produkt diesen Weg einschlägt, die Waren, die sich weiterentwickeln, oder? All das sind Probleme. Sicherheitsprobleme treten an jedem Punkt der Lieferkette auf. Und die meisten Menschen sind sich dessen nicht bewusst, aber die Sicherheit der Lieferkette war Teil unserer Existenz. Tausende und Abertausende von Jahren, zum Beispiel als Gewürze von Ost nach West transportiert wurden oder als Schiffe Waren zwischen Kontinenten transportierten, oder? Oder wenn Militärtruppen während Kriegen Nahrungsmittel und Waffen transportieren, sind die Menschen in all diesen Situationen Angriffe vorbereitet und verteidigen ihre Vorräte. Der Artikel könnte es also bis zum vorgesehenen Ziel schaffen. Und das Gleiche gilt auch für Software. Stellen Sie sich vor, Sie bauen ein Auto. Stimmt? Sie würden die Teile nicht von Grund auf neu herstellen, oder? Stattdessen würden Sie die verschiedenen Komponenten, die Reifen, den Motor, die Elektronik von verschiedenen Lieferanten in einer Fabrik beziehen und sie dann zusammenbauen. Und das ist der gleiche Weg. Das gleiche Prinzip gilt auch für Software. Und hier kommt die Software-Lieferkette ins Spiel. Es bezieht sich auf die Abfolge von Prozessen, die bei der Entwicklung, Bereitstellung und Wartung von Softwareanwendungen erforderlich sind, also im Grunde alles , was zur Erstellung einer Software erforderlich ist , von Bereitstellung des Quellcodes bis zur Produktion, oder? In den heutigen Umgebungen ist es sehr, sehr selten, dass Unternehmen Software komplett von Grund auf neu erstellen. Stattdessen verlassen sie sich auf eine Reihe von Bausteinen wie Open-Source-Bibliotheken, wie Open-Source-Bibliotheken, Entwicklertools und Cloud-basierte Bereitstellungen, wissen Sie Und jede dieser Komponenten ist Teil einer langen Lieferkette von der einer langen Lieferkette von IT-Infrastruktur bis zum Quellcode, richtig? Und die Software-Lieferkette bezieht sich auf die Abfolge von Prozessen, die erforderlich sind, um Ihnen diese Software zu beschaffen. Das kann also der Quellcode sein, die beteiligten Bibliotheken von Drittanbietern, die Bau- und Paketierungssysteme, die Vertriebskanäle, die Bereitstellungsinfrastrukturen, all das, sie entstehen hier. Und so sieht es also von den verschiedenen Ebenen aus, oder? Zum Beispiel werden sich Entwickler beim Schreiben darauf verlassen, dass sie sich bei der Softwareentwicklung auf zahlreiche externe Komponenten verlassen werden. Dies kann eine Open-Source-Bibliothek, ein Drittanbieter, eine API oder ein Cloud-Dienst sein. Sie verwenden es in ihrer Umgebung und senden es dann an ein Bit-System, das quasi ein Softwareartefakt erzeugt und ein Repository verschoben wird, wo es dann bereitgestellt wird Machen Sie sich keine Sorgen, wenn Sie mit diesen Begriffen nicht vertraut sind. Wir werden uns eingehend mit jedem dieser Themen befassen, Software Ich versuche nur, Ihnen verständlich zu machen , dass Software normalerweise von mehreren Personen entwickelt wird , die möglicherweise Teil mehrerer verschiedener Organisationen sind. Und im Laufe der Zeit haben möglicherweise Tausende von Menschen zu einer bestimmten Software beigetragen. Sie müssen also sicherstellen , dass Sie es verstehen. Wo die Sicherheitsprobleme ins Spiel kommen könnten, oder? Und hier kommt die Sicherheit der Software-Lieferkette ins Spiel. Dadurch wird die Integrität, Sicherheit und Zuverlässigkeit der Komponenten und Prozesse gewährleistet, die an der Entwicklung, dem Vertrieb und der Wartung von Software beteiligt sind . Sie möchten sicherstellen, dass Ihre Software zu keinem Zeitpunkt des Lebenszyklus manipuliert und gefährdet Und bei der Lieferkette geht es nicht nur um den Code, sondern auch um Bibliotheken, Tools und Dienste von Drittanbietern Das hängt von der Infrastruktur ab. Die Sicherheit der Software-Lieferkette umfasst also alles. Sicherheit der Software-Lieferkette ist keine Zertifizierung, die Sie erhalten Es ist kein Produkt, das Sie kaufen. Es umfasst all diese Prozesse. Okay? Und warum ist es so wichtig? Nun, einfach ausgedrückt, das kann ein großer blinder Fleck sein. Richtig? Die meisten Unternehmen konzentrieren sich darauf, ihre eigenen Umgebungen und ihren eigenen Code zu schützen , sie führen Schulungen durch und stellen sicher, dass alles sicher ist. Und sie haben die Bibliotheken von Drittanbietern, die Komponenten von Drittanbietern, die es gibt , völlig vergessen Bibliotheken von Drittanbietern, die Komponenten von Drittanbietern, die es gibt , völlig vergessen . Und Angreifer sind nicht dämlich. Dessen sind sie sich auch bewusst. Warum sollten sie direkt angreifen wollen wenn sie wissen, dass sich das Unternehmen selbst schützt, wenn sie sich einfach durch eine Komponente eines Drittanbieters, durch eine Drittanbieter-Bibliothek oder durch eine andere Art von Hintertür einschleichen können Komponente eines Drittanbieters, durch eine Drittanbieter-Bibliothek , von der das Unternehmen nichts weiß Und leider mangelt es, genau wie mir , an Bewusstsein und Kontrolle in dieser Hinsicht. Die meisten Unternehmen denken, dass sie ein Produkt kaufen und ihre Lieferkette sicher ist, oder sie erstellen eine Checkliste, überprüfen ihren Lieferanten und jetzt sind wir sicher, oder sie stellen MFA in Rechnung All diese Dinge sind wichtig. Ich sage übrigens nicht, dass diese Dinge nicht wichtig sind, aber die Sicherheit der Software-Lieferkette ist viel, viel mehr als das. Und es gibt einen allgemeinen Mangel an Bewusstsein, weshalb ich diesen Kurs hier gemacht habe. Und warum sollte es dich interessieren? Ich meine, ich kann das nicht genug betonen , als vor ein paar Jahren Solargewinne gefährdet waren, oder? Es hat das Bewusstsein für die Sicherheit der Software-Lieferkette geschärft. Und ich werde im Detail über Solargewinne sprechen , aber zusammenfassend lässt sich sagen, dass sie im Oktober 2019 begannen und bis Dezember 2020 unentdeckt bleiben Und bis dahin waren 18.000 Kunden einem Risiko ausgesetzt , Microsoft bestätigte, dass so viele Unternehmen, darunter sogar US-Regierungen, regiert wurden , oder? Und Solarenergie gewinnt, sie mussten sich, glaube ich, mit einer Klage in Höhe von 26.000.000$ mit ihren Investoren zufrieden geben, einer Klage in Höhe von 26.000.000$ mit wegen all der finanziellen Verluste, die daraus entstanden Und dabei waren die Millionen nicht enthalten, die Solar Winds und seine Kunden für die Reaktion auf Zwischenfälle, Bedrohungsuntersuchungen, Ausfallzeiten, Abhilfemaßnahmen und Umsatzverluste ausgegeben Solar Winds und seine Kunden für die Reaktion auf Zwischenfälle, Bedrohungsuntersuchungen, Ausfallzeiten, Abhilfemaßnahmen Sie können also verstehen, wie mächtig dieser Angriff war, und in ähnlicher Weise, Log for J, falls Sie es wissen, wenn Sie im Dezember 2021 irgendwo auf dem Gebiet der Cybersicherheit waren, ich bin sicher, dass Sie wissen, wie die Feiertage vieler Menschen durch dieses beliebte Labor gefährdet wurden, es wurde kompromittiert, und es war in Millionen und Abermillionen von Umgebungen präsent, und alle mussten ein Risiko eingehen , um sicherzustellen, dass sie Die Sicherheit der Software-Lieferkette ist also kein Witz. Sie kann zu verheerenden Cyberangriffen führen wenn Sie sie nicht ordnungsgemäß sichern. Also für wen ist dieser Kurs? Dieser Kurs richtet sich natürlich an Cybersicherheitsfachleute, die sich ein gutes Bild machen wollen sich ein gutes Bild Ich habe mein gesamtes Wissen über die Sicherheit der Software-Lieferkette genutzt und es in diesen Kurs eingebracht. Es richtet sich auch an Entwickler , die den breiteren Kontext des Codes und dessen Sicherheit verstehen möchten . Diese Experten, wenn Sie Ihr Risikowissen verfeinern und auch Suffa-Lieferkettenrisiken einbeziehen Und natürlich freuen sich Sicherheitsverantwortliche wie CIOs, CTOs, Chief Information Security Officers und alle, die daran interessiert mehr über die Sicherheit der Software-Lieferkette zu erfahren, CTOs, Chief Information Security Officers und alle, die daran interessiert sind, mehr über die Sicherheit der Software-Lieferkette zu erfahren, dass Sie an diesem Und wie Sie diesen Kurs nutzen können, müssen Sie die Strategien, die ich skizzieren werde , verstehen und umsetzen und Ihre Software-Lieferkette mit diesen Praktiken abgleichen . Nehmen Sie nicht einfach an diesem Kurs teil und vergessen Sie ihn dann. Bitte wenden Sie das Wissen an, von dem ich spreche. Wissen, das Sie nicht anwenden, Sie werden es vergessen und dann ein geeignetes Sicherheitsprogramm für die Software-Lieferkette erstellen . Das wird Ihr Projekt für diesen Kurs sein. Ich möchte, dass Sie die Führung übernehmen, die Konzepte anwenden, die ich Ihnen beibringe , und sie in Ihrem Unternehmen anwenden und eine Lücke schließen. Das ist es, worüber wir sprechen. Nun, Software, wir fangen jetzt an. Denken Sie daran, Software ist überall. Billionen von Quellcodezeilen sind überall vorhanden, und eine einzige Sicherheitslücke in der Software kann ganze Unternehmen daran hindern , Geschäfte zu machen, und Schäden in Milliardenhöhe anrichten. Mehr denn je müssen Sie sich Software-Lieferkette und der Sicherheit auskennen Ich hoffe, das gibt Ihnen ein gutes Verständnis und es hat Sie motiviert, sich wirklich mit diesem Thema zu befassen. Lass uns anfangen. Ich hoffe, du freust dich genauso wie ich und wir sehen uns in der nächsten Lektion. Ich danke dir vielmals. 2. Lieferkette verstehen: Hallo zusammen. Willkommen zu dieser Lektion , in der wir die Software-Lieferkette verstehen werden. Bevor wir uns mit der Sicherung befassen, müssen Sie sich ein Bild davon machen, wie die Software-Lieferkette in der heutigen Welt funktioniert, und dann werden wir uns mit dem Teil der Risiken befassen. Okay? Das ist es also, worüber Sie in dieser Lektion sprechen, die Software-Lieferkette, die wichtigsten Konzepte, die Sie berücksichtigen müssen und die verschiedenen Arten von Umgebungen, die es gibt. Und das ist wie ein Grundkurs , der die Grundlage für den gesamten Kurs bilden wird Wenn Sie also nicht wissen was die Software-Lieferkette ist, Sie unbedingt diese Lektion lernen, und Sie werden nicht glauben , wie viele Sicherheitsexperten ich gesehen habe, die diesen Fehler gemacht Sie gehen sofort das Risiko ein , ohne vorher ein Verständnis oder eine Vorstellung davon zu bekommen ein Verständnis oder eine Vorstellung davon was die Software-Lieferkette ist, was die verschiedenen Umgebungen sind und wie sie funktionieren. Wir haben also schon einmal über diese Definition gesprochen , ein sehr kurzer Überblick. Software-Lieferkette, wie wir bereits erwähnt haben, die Reihenfolge der Prozesse, die bei der Bereitstellung, Entwicklung und Wartung von Softwareanwendungen anfallen. Im Grunde ist alles , was Sie für die Erstellung eines Softwareartefakts benötigen , von Entwicklung des Quellcodes bis zur Bereitstellung in der Produktion , Teil der Software-Lieferkette Wir haben bereits darüber gesprochen, dass Unternehmen es sehr selten vorkommen, dass sie ein von Grund auf neu erstellen. Sie verlassen sich auf Bausteine wie Open-Source-Bibliotheken, Entwicklertools und SAS-Dienste. Sie alle kommen zusammen , um dieses Softwarepaket zu erstellen, oder? Und in allen von ihnen besteht das Potenzial von Sicherheitsrisiken. Wie sieht also eine typische Softwareentwicklungsumgebung heutzutage aus? Eine Softwareumgebung, tut mir leid. So sieht es also aus. Wir gehen Schritt für Schritt vor, wie es geht. Und bevor du auf mich losspringst und anfängst schreien, dass meine Umgebung nicht so ist, ich weiß, dass jede Umgebung anders ist, ich weiß, dass jede Umgebung anders ist, aber das ist am häufigsten, das sind die Eigenschaften, die in praktisch jeder Umgebung vorhanden sein werden die in praktisch jeder Umgebung vorhanden sein Lassen Sie uns also zunächst mit der Entwicklungsumgebung beginnen mit der Entwicklungsumgebung Hier passiert die Magie, oder? Entwickler verwenden diese Umgebung , um Code zu schreiben und zu testen. Sie entwickeln neue Funktionen und experimentieren mit Ideen. Es ist wie ihr Arbeitsbereich, oder? Es ermöglicht ihnen, Code zu schreiben und ihre Visionen zum Leben zu erwecken. Und die Entwicklungsumgebung ist in der Regel mit verschiedenen Tools und Frameworks ausgestattet, die auf anderen Geschäftsrechnern nicht vorhanden sind. Das ist also wie eine besondere Umgebung. Sie haben normalerweise mehr Privilegien. Was machen sie also? Sie verwenden ihre integrierte Entwicklungsumgebung, ihre Workstations, auf denen ihre Codierungssoftware installiert ist Um Code zu schreiben, der in ein Code-Repo übertragen wird. Ein Code-Repo kann wie ein gemeinsam genutzter Server sein, der den Code enthält Von dort, der Build-Plattform, nimmt sie ihren Code und baut ihn zu einem Artefakt ein Jetzt verwenden Entwickler möglicherweise Abhängigkeiten in ihrem Code, oder wenn der Code erstellt wird, Abhängigkeiten abgerufen Abhängigkeiten sind, wie ich schon sagte, diese Bausteine, oder? Du wirst nicht alles von Grund auf neu schreiben, oder? Wenn Sie Python-Code schreiben, verwenden Sie verschiedene Bibliotheken. All diese Abhängigkeiten wird die Build-Plattform also verwenden, um ihre Software zu erstellen, und so funktioniert die Entwicklungsumgebung . Also schreibe ich Code. Es geht in ein Code-Repo, wo die Build-Umgebung diesen Code generiert und kompiliert Es ruft alle Abhängigkeiten ab, die erforderlich sind. Es könnte sich in der Umgebung befinden, es könnte sich um einen öffentlichen Bericht handeln , der im Internet gespeichert ist Aber so sieht die Entwicklungsumgebung typischerweise aus. Danach, was kommt, kommt die Testumgebung. Sobald der Code geschrieben ist, ist es an der Zeit, seine Robustheit und Funktionalität zu bewerten, oder? Die Testumgebung ist wie ein kontrollierter Ort, an dem Sie verschiedene Arten von Tests wie Komponententests, Integrationstests, Systemtests und Qualitätssicherung durchführen von Tests wie Komponententests, Integrationstests, Systemtests und Qualitätssicherung Sie evaluieren diesen Code akribisch, oder? Anhand vordefinierter Testfälle , um herauszufinden, ob Probleme vorliegen Dies kann jetzt in vielen Umgebungen vollständig automatisiert werden. Sie haben DevOps und DFSycoVs. Sie haben also möglicherweise vollständig automatisierte Tests. Oder vielleicht sitzt dort eine Person , die die Tests durchführt , und Sie werden nicht glauben, dass das immer noch passiert Sie haben viele QA - und Testteams , die diese automatisierten Tests durchführen, aber es gibt eine Person, die sich das anschaut. Es gibt also verschiedene Möglichkeiten, dies zu tun. Normalerweise haben Sie jedoch eine Test- und eine UAT-Umgebung, in der der Code getestet wird, um sicherzustellen, dass er frei von Bots ist Okay? Was passiert danach? Danach haben Sie also eine sogenannte Pre-Prod- oder Staging-Umgebung Das ist also wie eine Lücke zwischen der Test- und der Produktionsphase Dies ist normalerweise eine Nachbildung der Produktionsumgebung. Auf diese Weise können Teams überprüfen , ob sich die Software verhält Es funktioniert unter realen Bedingungen einwandfrei , oder? Wie ich schon sagte, es ist sehr nah an der Produktionsumgebung. Es ermöglicht ihnen also, sie einem Stresstest zu unterziehen, und sie können sich verschiedene Möglichkeiten ansehen , wie die Software tatsächlich funktionieren wird, wissen Sie? Weil die UAT-Testumgebung wie eine Testumgebung ist Sie repräsentiert nicht die tatsächliche Welt. Die Preprod- und die Staging-Umgebung, das ist also sehr, sehr ähnlich wie die Produktionsumgebung funktionieren wird Und viele Leute verwenden Preprod und Staging Preprod Es gibt subtile Unterschiede. Aber in der Regel verwenden sie auf der ganzen Linie ziemlich synonym, ehrlich gesagt innerhalb dessen, was ich gesehen habe Und was sind die Vorteile der Nutzung dieser Umgebungen? Wie ich schon sagte, Belastungstests, Leistungstests, Stresstests, die Sie in UAT-Umgebungen nicht durchführen können, oder? Und sie bieten Ihnen mehrere Vorteile, weil sie Ihnen sagen, wie der tatsächliche Kunde die Software betrachten wird, und er macht Fehler bei der Leistung, und Sie werden langsamer, bevor die Software den Endkunden erreicht Es ermöglicht Ihnen, die Leistung zu verfeinern , indem Sie eventuelle Engpässe identifizieren , und es gibt Ihnen eine gute Möglichkeit, zu beurteilen, ob die Benutzerleistung, die Benutzerzufriedenheit und wie sie da sein wird, denn jetzt bekommen Sie eine sehr gute Vorstellung davon, wie der Kunde diese Software betrachten wird, und das ist der Vorteil von die Vorproduktion und die Inszenierung. Und wie ich schon sagte, das ist sehr, sehr nah an der Produktionsumgebung, also haben Sie hier vielleicht tatsächliche Daten, tatsächliche Produktionsdaten werden hier gespeichert Und zu guter Letzt ist da noch die Produktionsumgebung. Dies ist also das ultimative Ziel für Ihre Software, es ist eine Live-Umgebung, in Endbenutzer mit Ihrer Anwendung oder Ihrem System interagieren. Die Software wird hier bereitgestellt und muss in den vorherigen Umgebungen sorgfältig getestet und verfeinert werden, um sicherzustellen, dass die Kunden ein reibungsloses Erlebnis haben Ich habe noch nie von einer Software gehört, die in dieser Produktionsumgebung keine Fehler aufweist, egal wie viele Tests Sie durchführen jedoch die Schritte befolgen, erhalten Sie eine sehr gute Vorstellung und haben die Möglichkeit, eventuell vorhandene Fehler zu beheben. So wird also eine typische Softwareumgebung aussehen. Wie ich schon sagte, bevor Sie ganz verrückt werden und mir vorwerfen, kritische Bereiche verpasst Wie ich schon sagte, ich weiß, dass jede Umgebung anders ist, aber diese Umgebung kommt dieser Umgebung am nächsten In der Regel sind dies die gängigsten Methoden zur Strukturierung von Softwareentwicklungsumgebungen. Ich hoffe, du hast eine gute Idee. Jetzt werden wir uns ansehen einige Konzepte ansehen , die es gibt, nämlich Dev SecOps, CICD-Pipelines , Artefakte, Artefakt-Repos, Paket-Repositorien und Infrastruktur als COD Artefakte, Artefakt-Repos, Paket-Repositorien einige Konzepte ansehen , die es gibt, nämlich Dev SecOps, CICD-Pipelines , Artefakte, Artefakt-Repos, Paket-Repositorien und Infrastruktur als COD. Sie kennen das vielleicht, aber ich habe es bewusst hier nur zur Auffrischung aufgeführt, weil all diese Bereiche ins Spiel kommen werden, wenn wir über die Sicherheitsrisiken in der Software-Lieferkette sprechen über die Sicherheitsrisiken in der Software-Lieferkette , die es gibt. Also habe ich es als Gegenüberarbeitung angegeben. Wenn Sie der Meinung sind, dass Sie in all diesen Konzepten sehr gut sind, können Sie diese Lektion gerne überspringen. Aber ich würde empfehlen, es als schnelle Überarbeitung zu nehmen, damit wir uns in der nächsten Lektion wiedersehen. Danke. 3. Risiken der Lieferkette – 1: Hallo alle zusammen. Willkommen. Willkommen zur nächsten Lektion. Und hier fangen wir wirklich an den Kern des Kurses einzugehen , und jetzt werden wir über das Sicherheitsrisiko sprechen, oder? Die Software-Lieferkette, Sicherheitsrisiko. In der vorherigen Lektion habe ich mit Ihnen darüber gesprochen, wie Softwareentwicklungsumgebungen normalerweise konfiguriert werden, oder? Ich versuche sehr, die gängigsten Softwareentwicklungsumgebungen und ihre Funktionsweise, die verschiedenen Konzepte und die Art und Weise, wie Software sie durchläuft, zu behandeln die gängigsten Softwareentwicklungsumgebungen und ihre Funktionsweise, die verschiedenen Konzepte und die Art und . In dieser Lektion werden wir nun über die Sicherheitsrisiken sprechen, also über die Sicherheitsrisiken in der Sofa-Lieferkette, wie sie entstehen, und wir werden eine Analyse der tatsächlichen Vorfälle durchführen. Zu den beliebtesten gehören Solarereignisse, Cord Cov Bis ich diesen Kurs beendet habe, wahrscheinlich schon ein anderer Angriff auf die Lieferkette passiert Aber ich werde diejenigen behandeln , die verschiedene Szenarien abdecken. Und die Ihnen die tatsächlichen Auswirkungen zeigen können. also nicht nur theoretisch Ich sage Ihnen also nicht nur theoretisch, dass diese Dinge passieren können. Ich werde Ihnen zeigen, wie es tatsächlich passiert ist und welche Auswirkungen es hatte und was Sie tun können um sich selbst zu schützen, richtig, zu verhindern, dass diese Dinge passieren. Wenn Sie sich erinnern, das ist das Diagramm, das wir uns zuvor angesehen haben, oder? Wir hatten die Entwicklerumgebung mit der ID, Code in das Repo pushte, die Bull-Plattform wurde aktiviert, alle Abhängigkeiten eingelesen und weiß, und sie wird es in die Testumgebung pushen und dann die Vorbereitung zur Produktion Das kann komplett manuell sein oder es kann eine CICD-Pipeline sein , weiß, die Ihren Code pusht Von den verschiedenen Umgebungen bis zur Übertragung in die Produktionsumgebung, und genau darüber haben wir gesprochen Lassen Sie uns nun über die Risiken auf hoher Ebene nachdenken. Fangen wir nun mit dem Entwickler an. Nun, Entwickler in den meisten Umgebungen und was nennen Sie Entwickler, haben in der Regel recht mächtige Rechte. Sie sind in der Lage, ihre eigenen Entwicklungsumgebungen zu verwalten , weil sie diese Flexibilität für die Entwicklung neuer Anwendungen und Produkte benötigen Flexibilität für die Entwicklung neuer Anwendungen und . Meiner Erfahrung nach können sie manchmal virtuelle Maschinen wie, Sie wissen schon, Dual-Boat-Betriebssysteme, Linux und Windows einrichten . Und diese Umgebungen sind manchmal für IT-Organisationen oft unsichtbar . Deshalb nennen sie sie Schatten-IT, oder? Und Entwickler glauben, dass sie diese Flexibilität benötigen, oder? Sie müssen in der Lage sein, eine virtuelle Maschine hochzufahren, Anwendungen zu installieren und ihre Umgebungen zu verwalten. Sie wollen nicht, dass ihre Laptops oder Desktops gesperrt werden, und sie wollen Administratorzugriff oder Power-User-Zugriff auf ihre Systeme, denn wenn Sie diese Fähigkeit beenden, haben sie keine Möglichkeit, Fehler zu beheben, um Umgebungen zu erstellen, oder sie müssen Dutzende von Genehmigungen für die Änderung von Umgebungen durchgehen Genehmigungen für die Änderung von Umgebungen Wenn Sie jemals im Bereich Cybersicherheit gearbeitet haben, bin ich mir sicher, dass Sie das gesehen haben müssen, oder? Wir beginnen also damit, dass Sie als Erstes über die sehr mächtigen Privilegien nachdenken müssen , die Entwickler haben, und zu was das führen wird, wir werden sehen. Dann kommt natürlich der sichere Code. Und wir werden sehen, was wenn der Code, den sie schreiben, unsicher ist Sie werden ihn in ein Code-Repo verschieben und dann wird er in den Umgebungen verbreitet, und dieser Code weist schwerwiegende Und wenn Sie ein Dienstanbieter sind, wie bei Solar Winds , wird dieser unsichere Code überall verbreitet Tausende und Abertausende von Menschen, weil Sie es nicht selbst überprüft haben, oder? Und der Code wird so gepusht, dass man so etwas wie ein Code-Repo nennt, oder? Nun, das Code-Repo, Sie können auch hier mehrere Kompromisse eingehen Das Quell-Repository, das Code-Repository, vielleicht ist die Admin-Oberfläche nicht sicher Und der Angreifer kann die Admin-Oberfläche verwenden oder den zugrunde liegenden Server kompromittieren , um den Quellcode direkt anzugreifen und Zugriff darauf zu erhalten, und er beginnt, den Code zu ändern. Oder sie könnten dort etwas Malware platzieren, das sich überall verbreitet. Denken Sie also an das Code-Repo, das da ist. Natürlich haben Sie die fertige Plattform, und sie sind eng in Ihre Artefakt-Repos und Ihre Paket-Repositorys integriert Ihre Artefakt-Repos und Ihre Paket-Repositorys Und oft fangen sie an, Dinge zu erstellen und sie in Ihren Umgebungen zu verbreiten, richtig? und sie in Ihren Umgebungen zu verbreiten, richtig So können Angreifer die Eingaben der Build-Plattform angreifen, z. B. welche Version verwendet werden soll, und sie können sie zu bösartigem Code umleiten, den die Build-Plattform dann verbreitet Und das werden wir beim Angriff der Sonnenwinde sehen. Sie können also jeden Teil der erstellten Plattform angreifen, einschließlich ihrer Dienste oder der zugrunde liegenden Infrastruktur, und sie können ändern, wie das abgerechnet wird, oder? Und das kann weiterführen. Sie können das Artefakt-Repository kompromittieren wie das Paket, über das wir gesprochen haben, und sie können veränderte Artefakte hochladen oder veröffentlichen , weil Sie die Admin-Oberfläche nicht gesichert Und schließlich die Abhängigkeiten, wenn man sich ganz oben anschaut und das ist eines der häufigsten Dinge Und leider denken die Leute, dass das einfach das Einzige an der Software-Lieferkette ist das einfach das Einzige , aber Ihre Abhängigkeiten, weil Sie eine Vielzahl von kommerziellen und Open-Source-Bibliotheken von Drittanbietern verwenden , sind da, und so sind die meisten Umgebungen konfiguriert, oder? Was also passieren wird, ist, dass Sie mehrere haben werden , was passiert, wenn ein Angreifer diese Bibliothek kompromittiert Sie versuchen, bösartiges Verhalten einzuführen indem sie diese Bibliothek kompromittieren, und diese Abhängigkeit wird sich in Ihrem gesamten Code ausbreiten Ihr Code, wir haben eine unsichere Komponente, wie wir über Log for J gesprochen haben, richtig Es wird in Ihrer Umgebung verbreitet, und wenn später eine Sicherheitslücke entdeckt wird, kann ein Angreifer diese nutzen, um wenn später eine Sicherheitslücke entdeckt wird, kann ein Angreifer diese nutzen, sich in Ihre Umgebung einzuschleusen. Das ist also nur die Entwicklerumgebung, oder? Und dann zu den anderen Umgebungen wie der UAT-Testumgebung Wenn Sie die Tests durchführen, machen Unternehmen manchmal nicht einmal Mühe, Sicherheitstests durchzuführen Sie haben keine Ahnung, ob der Code sicher ist. Ob der COO irgendwelche Sicherheitslücken einführt oder nicht, etwas Unabhängiges Sie verlassen sich einfach auf den Entwickler. Sie werden nicht glauben, wie häufig das leider immer noch ist. Sicherheitstests gibt es also nicht. Ich habe viele Unternehmen gesehen, Sicherheitstests durchführen, aber danach passiert nichts mehr. Also machen sie einen Sicherheitstest und sie sind okay, sie haben gerade einen Bericht veröffentlicht. Dies sind die Sicherheitslücken. Niemand schaut sich diese Sicherheitslücken an, oder? dem Sicherheitstest machst du also keine Sicherheitstests nur um der Sicherheitstests willen, oder? Sie führen Sicherheitstests , damit Sicherheitslücken behoben werden. Das ist also ein weiteres Problem. Die Sicherheitstests sind nicht da. Dann geht man natürlich zu den Pre-Proud- und Staging-Umgebungen Und wir haben darüber gesprochen, dass dies eine Nachbildung der Produktion ist. Das ist nicht so sicher wie die Produktion. Das ist eine Replik Also könnte jemand in der Lage sein, es zu kompromittieren und Zugriff auf die Daten zu erhalten, weil Sie Kundendaten haben Vielleicht haben Sie sie nicht maskiert oder anonymisiert, sodass die Leute auf diese Daten zugreifen und sie kompromittieren können diese Daten zugreifen und sie kompromittieren Und zu guter Letzt natürlich die Produktionsumgebung. Die Produktionsumgebung habe ich aus dem Rahmen dieses Kurses herausgenommen, weil das natürlich traditionelle Cybersicherheit ist. Sie werden Patches und all diese anderen Dinge haben. Aber das kann auch gefährdet werden, oder? Weil ich möchte , dass du es aus der Gesamtperspektive betrachtest Das sind alle Angriffe , die passieren können, oder? Und zu guter Letzt, wenn Sie sich die Pfeile ansehen, die diese Umgebungen verbinden, diese, die CICD-Pipeline, wenn Sie eine CSED-Pipeline verwenden, haben wir darüber gesprochen, wie die kontinuierliche Integration sie schnell testet, den Code pusht und die Tests durchführt, und dann die kontinuierliche Bereitstellung oder sie überträgt den Code durch die andere Umgebungen, richtig? Was ist, wenn jemand die CICD-Pipeline kompromittieren kann? Diese Pipeline hat Zugriff auf alle Umgebungen, oder? Sie können also tatsächlich kontrollieren, welcher Code übertragen wird und welche Art von Tests stattfinden Dies ist eine weitere Sache, die Sie beachten müssen. Das ist eine weitere sehr, sehr gefährliche Sache, die passieren kann. Das ist also das große Ganze. Das ist die Art von Angriffen an die Sie denken sollten, wenn Sie über die Sicherheit der Lieferkette nachdenken, richtig? Und ist das meine Meinung? Sie denken vielleicht, und das ist nur Ihre subjektive Meinung. Also nein, ich habe es auf einen Branchen-Benchmark gestützt. Also das ist Salsa. Man sagt, sie sprechen es Salsa aus, was ich mag, aber Supply-Chain-Ebene für Software-Artefakte Das ist ein Branchen-Benchmark. Ich werde den Link in diesen Kurs einfügen. Es ist also ein Sicherheitsframework. Es ist wie eine Checkliste mit bewährten Methoden, um zu verhindern, dass beispielsweise die Sicherheit Ihrer Software-Lieferkette gefährdet wird, oder Und es wird normalerweise in der gesamten Branche verwendet. Es ist ein sehr, sehr gutes unabhängiges Produkt, es ist technologieunabhängig, es ist herstellerunabhängig Und es ist wie eine Reihe von Richtlinien. Sie können sie langsam und langsam übernehmen, und sie werden im Branchenkonsens festgelegt. Und sie sind eingerichtet. Also sollte jeder, der Software entwickelt, sie benutzen, richtig? Jeder, der Software wie Build-Plattformen oder etwas anderes produziert, konsumiert oder anbietet, kann dies nutzen, um mehr Vertrauen in Sicherheit Ihrer Software-Lieferkette zu gewinnen. Es ist wie branchenübergreifende Zusammenarbeit. Wir werden später mehr darüber sprechen. Aber es ist quasi ein völlig herstellerneutraler, was nennen Sie ein Framework zur Sicherung Ihrer Software, ein Plan. Es gibt Ihnen ein allgemeines Vokabular , um über die Sicherheit der Software-Lieferkette zu sprechen. Und darauf habe ich dieses Diagramm aufgebaut. Das ist es also, was wir zeigen wollen. Und das ist ein Branchen-Benchmark. Also werde ich den Link dort platzieren. Du siehst also, es geht nicht nur mir so, du denkst, ich spreche nur aus meiner eigenen Meinung heraus. Das basiert auf einem Branchen-Benchmark , über den ich gesprochen habe, und ich würde definitiv empfehlen, es uns später, wenn wir ein Sicherheitsprogramm für die Software-Lieferkette entwickeln ein Sicherheitsprogramm für die Software-Lieferkette , anzusehen, okay? Jetzt werden wir über das wichtigste Sicherheitsrisiko sprechen. Ich werde in dieser Lektion nicht darüber sprechen, weil ich Ihnen bereits einige Dinge gegeben habe , über die Sie sprechen können. Wir werden in der nächsten Lektion weitermachen. Aber wir werden über das wichtigste Sicherheitsrisiko sprechen. all den Risiken, über die wir im Diagramm gesprochen haben, werden wir uns eingehend mit jedem einzelnen Risiko befassen und darüber nachdenken wie das funktioniert und welche Auswirkungen diese Angriffe haben. Es ist sehr wichtig, diese zu verstehen, weil man sonst nichts sichern kann , wenn man nicht versteht, wie es passiert, oder? Jetzt werden wir uns eingehend mit jedem dieser Risiken befassen, und ich werde Ihnen zeigen, welche Auswirkungen diese Dinge haben. Okay, vielen Dank. Wir sehen uns in der nächsten Lektion. 4. Risiken der Lieferkette – 2: Hallo, alle zusammen. Willkommen zu dieser Lektion. Und jetzt werden wir über die wichtigsten Sicherheitsrisiken sprechen über die wir in der Abbildung gesprochen haben. Und wir gehen eins nach dem anderen durch, damit Sie sich ein besseres Bild von diesen Sicherheitsrisiken machen können. Und später, wenn wir anfangen, sie zu schützen, werden Sie eine viel bessere Vorstellung haben. Und wir werden uns auch einige Fallstudien über Sonnenwinde und Kokov ansehen auch einige Fallstudien über Sonnenwinde und , wie diese Risiken tatsächlich auftreten und wirklich Kompromisse eingehen können Ich werde Schritt für Schritt vorgehen, damit Sie diese Angriffe besser einschätzen Fangen wir also mit der Nummer eins an , nämlich dem unsicheren Code. Nun, unsicherer Code ist nicht, ich meine, ehrlich gesagt, das ist etwas, das in der Branche schon seit Jahrzehnten existiert, und es gibt inzwischen ein großes Bewusstsein dafür Ich meine, im Vergleich zu den anderen Angriffen würde ich sagen, dass unsicherer Code nicht so schwerwiegend ist Ich weiß, dass die meisten Unternehmen damit begonnen haben , Maßnahmen zu ergreifen, aber das ist der Ausgangspunkt Von allen Sicherheitsrisiken in der Software-Lieferkette Ehrlich gesagt, wie gesagt, die Wurzel allen Übels, egal ob es sich um Erstanbieter oder Dritte handelt, müssen Sie sicherstellen , dass Ihr Code sicher ist. Und der Fehler, den ich bei vielen Unternehmen sehe, sie ihren First-Party-Code sichern , der ihr eigener Code ist, aber sie schauen nicht auf Dritte, und Sie müssen den gesamten Code gleich behandeln. Sie müssen sicherstellen, dass Sie die Gewissheit haben , dass dieser Code gesichert wurde. Und Sie fragen sich vielleicht, wie kann ich Code eines Drittanbieters sichern? Ich habe keinen Zugriff darauf? Nun, es gibt Möglichkeiten, das anzugehen. Sie können den Verkäufer fragen. Sie können die Risikomanagementprozesse des Anbieters beurteilen, oder? Es gibt also Möglichkeiten , dies zu überprüfen, und wir werden uns das genauer ansehen. Wo wir über die Erstellung des Sicherheitsrisikomanagementprogramms des Anbieters sprechen. Aber unsicherer Code ist so ziemlich alles, wenn Sie Ihren Code nicht sichern . Alle anderen Kontrollen spielen keine Rolle, da dort die meisten Ihrer Sicherheitsrisiken liegen Das sind also nur Beispiele. Ich habe sie mir früher angesehen, und wenn Sie sich ein bisschen mit Programmieren auskennen, ist das so etwas wie ein Injection-Angriff, bei Sie sich ein bisschen mit Programmieren auskennen, ist das so etwas wie ein Injection-Angriff dem Sie den Code nicht bereinigen, sondern nur Code in Ihre Umgebung aufnehmen und so ziemlich jeder diesen Code einfach umgehen kann, und so ziemlich jeder diesen Code einfach umgehen kann um auf Ihre zugrunde liegenden Datenbanken, Ihr zugrunde liegendes Betriebssystem zuzugreifen Ihr zugrunde liegendes Betriebssystem Das wird als Injection-Angriff bezeichnet. Und Sie werden nicht glauben, dass ich selbst 2024 noch Menschen sehe, die diesen Fehler machen . Es ist also unglaublich. Ich habe mir 2002 das Programmieren angesehen. Es ist jetzt fast 22 Jahre her, und dieses Problem ist immer noch da, was ich sehr lustig fand, dass dieser Fehler trotz aller Fortschritte, die wir gemacht haben, immer trotz aller Fortschritte, die wir gemacht haben noch besteht. Das ist etwas anderes. Das ist wie ein ZIP-Bombenangriff falls Sie damit nicht vertraut sind. Das ist wie ein Archiv, bei dem Sie keine ZIP-Datei oder Archivdatei validieren, Sie extrahieren es einfach, ohne eine Überprüfung durchzuführen Sie können dem Angreifer also tatsächlich einen Denial-of-Service zufügen Sie können den Speicherplatz oder Speicher des Zielsystems erschöpfen , wenn Sie versuchen, es zu extrahieren, Und ehrlich gesagt ist das ZIP-Format das am häufigsten verwendete, aber Sie können es so ziemlich verwenden Es ist, als würde man eine große Datei komprimieren , die aus einem einzigen Zeichen besteht, oder? Und Sie können eine Ein-MB-Datei erstellen , die auf ein GV dekomprimiert wird Und es wird tatsächlich das Betriebssystem durcheinander bringen , weil Sie keine Validierung durchführen Das ist also ein weiterer Angriff , der auf Ihren unsicheren Code zurückzuführen ist Und das ist, ich meine, jeder weiß das. Das ist die älteste und häufigste Sache, nämlich hartcodierte Geheimnisse. Als ob die Leute faul sind. Sie wollen keine sichere Validierung durchführen und niemand schaut sich den Code an. Also geben sie tatsächlich die fest codierten Geheimnisse ein, und das wird in ein öffentliches Code-Repository verschoben. Nehmen wir an, Sie verwenden einen Public-Code-Reaper, jemand greift darauf zu und bumm, er hat Zugriff auf Ihre Umgebung, weil Sie die Benutzer-ID und das Passwort in einen Code-Reaper eingeben die Benutzer-ID und das Passwort in einen Code-Reaper So viele Unternehmen, die ich kenne, haben sehr strenge Passwortrichtlinien, aber sie schauen sich den Code nicht an Welches ist da, und deshalb scannen sie nicht einmal ihren Code. Das kann also tatsächlich dazu führen hartcodierte Benutzer-IDs, Passwörter hartcodierte Zugangsschlüssel in einen Code eingegeben und in den Codebericht übertragen werden. Jeder, der Zugriff auf diesen Code hat, kann Ihre Umgebung jetzt tatsächlich umgehen und gefährden. Das ist also nur, um Ihnen zu zeigen, wie gefährlich diese Angriffe sind. Das war also wie unsicherer Code. Gehen wir zum nächsten über, bei dem es sich unsichere Komponenten von Drittanbietern handelt Und genau hier liegt der größte Fokus, wenn es um Sicherheit in der Lieferkette geht , also im Grunde genommen um anfällige oder böswillige Abhängigkeiten von Drittanbietern Wissen Sie, wir haben bereits darüber gesprochen, dass moderne Software auf Bibliotheken oder Audios von Drittanbietern angewiesen ist Und wenn diese Abhängigkeiten Sicherheitslücken oder vielleicht bösartigen Code enthalten , können sie ein Risiko für Ihre gesamte Umgebung darstellen, oder? Und Software von Drittanbietern, stellen Sie sich vor, Software von Drittanbietern ist nur Erstanbieter-Software , die von jemand anderem geschrieben wurde. So wie die Cloud nur ein Server ist , der von jemand anderem betrieben wird. Softwareabhängigkeiten von Drittanbietern, das können Sie sich vorstellen. Dies sind Ihre Abhängigkeiten, die jedoch von jemand anderem geschrieben wurden. All die Risiken, über die wir beim Kodieren gesprochen haben, werden auch hier übertragen. Und diese Sicherheitslücken können in Ihre Umgebung gelangen. Wenn der Angreifer in der Lage ist, es zu kompromittieren. Abhängigkeit, diese Abhängigkeit wird jetzt genutzt, um Ihre Umgebung zu gefährden, oder? Und das können bekannte Sicherheitslücken sein. Es ist also nicht so, dass sie versteckt ist weil diese Sicherheitslücke schon seit geraumer Zeit bekannt ist, aber Sie können sie nicht beheben, weil dadurch Ihre Anwendung beschädigt wird oder weil der Anbieter kein Update veröffentlicht hat. Sie müssen also darüber nachdenken. Okay, was mache ich jetzt? Oder das können null Tage sein, wie das ursprüngliche Lock für J. Du erinnerst dich an Log for J, oder? Das können null Tage sein. Niemand wusste davon. Plötzlich kommt es rein und es gibt keine Lösung dafür. Und schnell können Angreifer damit beginnen, es zu manipulieren und zu versuchen, Umgebungen damit zu kompromittieren Und das ist so es unmittelbare Sicherheitslücken geben kann, die monatelang, jahrelang oder sogar jahrzehntelang in einer Codebasis schlummern Und als sie endlich entdeckt und bekannt gegeben werden, sind Menschen auf der ganzen Welt dabei, sich Ich möchte herausfinden, ob sie diese Software verwenden oder nicht, um herauszufinden, ob sie diese Abhängigkeit nutzen und wie sie diese Abhängigkeit nutzen und wie sich davor schützen können, ausgenutzt zu Angreifer versuchen auch, sich zu manipulieren. Übrigens versuchen sie herauszufinden, wer diese anfällige Software verwendet, und sie versuchen, Exploits zu entwickeln, um die Umgebung auszunutzen und zu Es ist also wie ein verrückter Schlag, wenn die Leute das herausfinden wollen, oder? Und so sieht es normalerweise aus. Sie haben also einen Angreifer, diese Umgebung kompromittiert. Sie kompromittieren ein Labor eines Drittanbieters und dieses Drittanbieter-Labyrinth macht sich breit. Es wird an Tausende und Abertausende von Unternehmen weitergegeben , richtig, wie Lock for und nehmen Sie das Jemand hat die Umgebung für Sonnenwinde kompromittiert, und diesen Code haben wir dann benutzt, um die Umgebung zu verbreiten Das ist also ein weiteres Beispiel dafür , wie das passiert ist. Und so funktionieren normalerweise unsichere Komponenten von Drittanbietern, oder? Sie müssen es aus dieser Perspektive betrachten. Das waren also die Codierung der ersten Ebene und die Abhängigkeiten von Drittanbietern. Ich werde diese Lektion in mehrere Teile unterteilen, weil ich möchte, dass Sie das, worüber wir gesprochen haben, aufnehmen , bevor ich zum nächsten übergehe. In der nächsten werde ich über die Kompromittierung des Code-Repos sprechen , in dem Sie den Code speichern Denken Sie daran, dass der Entwickler Code früher per Push in ein Code-Repository Lassen Sie uns also über das Code-Repo sprechen und darüber, was passieren kann. Vielen Dank und wir sehen uns in der nächsten Lektion. 5. Risiken der Lieferkette – 3: Hallo, alle zusammen. Willkommen. Willkommen zu dieser Lektion. Und jetzt werden wir über den Code-Repo-Kompromiss sprechen über den Code-Repo-Kompromiss Wie Sie sehen können, bewegen wir uns langsam in der gesamten Software-Lieferkette, wenn Sie sich an das Diagramm erinnern bewegen wir uns langsam in der gesamten Software-Lieferkette, wenn Sie sich an das Und wir haben schon einmal über Code-Repos gesprochen. Basic, stellen Sie sich das als eine zentralisierte Bibliothek oder ein zentrales Repository vor, in dem Ihre Entwickler gemeinsam am Code arbeiten können, oder? Also schreibe ich Code und füge ihn in einen Codebericht ein. Ein anderer Entwickler schreibt ebenfalls Code. Sie drängen auf denselben Bericht. Und der Code, von dem Sie überall auf Github gehört haben. Es stellt also sicher, dass der gesamte Code synchronisiert ist. Und was kann passieren, Angreifer können sich Zugriff auf dieses Repo verschaffen, oder? Vielleicht ist die Software nicht gesichert, oder vielleicht kompromittieren sie den Benutzer, sie haben ihm einen bösartigen Link geschickt, und er hat so seine Benutzer-ID und sein Passwort eingegeben, und sie konnten es bekommen Jetzt können sie den Quellcode in der Foundation manipulieren . Oder sogar viele Leute sind sich dessen nicht bewusst. Das Repo selbst kann für Angriffe auf Kunden verwendet werden Und manchmal sind sich die Leute dessen nicht bewusst. Da ist also die Sicherheit des Repos selbst, um sicherzustellen, dass das Repo nicht gefährdet ist und das Repo selbst als Angriffsvektor verwendet werden kann Und lassen Sie uns ein Beispiel nehmen. Nur für den Fall, dass Sie sich dessen nicht bewusst sind, ich glaube, das ist 2020 passiert, die Octopus-Scanner-Malware Sie sind also tatsächlich Angreifer. Sie hatten quasi eine Reihe von auf Github gehosteten Repositorys, und sie waren ungewollt das Schlüsselwort hier Unbeabsichtigt wurden sie zur Bereitstellung von Schadsoftware verwendet. Und tatsächlich, das Github-Sicherheitsteam hat es untersucht und herausgefunden, dass diese Repos nicht gesichert waren und sie dazu verwendet wurden, Malware auf breiter Front zu verteilen, oder? diese Repos nicht gesichert waren und sie dazu verwendet wurden, Malware auf breiter Front zu verteilen, oder Und die Besitzer der Repos waren sich dessen überhaupt Sie haben sich wie bösartigen Code in die bösartigen Code in Als sie den Code abgerufen haben, haben sie tatsächlich Schadsoftware abgerufen, und sie bieten ein hohes Level, wie nennt man das? Was es gut macht, ist im Grunde, dass es das Repo selbst kompromittiert hat Und Sie können sich vorstellen, wie gefährlich das ist, oder? Denn warum? Weil die Malware die Entwickler-Workstation übertragen wird. Und von dort aus wird sie in den Build übernommen, und jetzt geben Sie dieser Malware die Möglichkeit, sich in Ihrer Umgebung zu bewegen. Und da die Hauptpersonen , die kompromittiert werden, Entwickler sind, und wenn Sie sich erinnern, worüber wir gesprochen , haben Entwickler traditionell mehr Zugriff als normale Leute, oder? Sie haben erhöhte Rechte, Poweruser. Auf diese Weise können sie potenziell auf Produktionsumgebungen zugreifen . Sie könnten möglicherweise Zugriff auf Datenbanken, Passwörter und andere wichtige Ressourcen erhalten , oder? Es besteht ein enormes Eskalationspotenzial für den Angreifer, der eine Rechteerweiterung ist ein zentrales Ziel der meisten Datenkompromittierungen Wenn der Angreifer in eine Umgebung eindringt, möchte er als Erstes Administrator werden, oder? Administrator werden, oder Und das ist nur, um Ihnen zu zeigen, was passieren kann. Die Leute denken, oh, das Code-Depot könnte veröffentlicht werden. Das ist das Schlimmste , was passieren kann. Nein, wenn Sie Ihr Code-Repo nicht gesichert haben, kann der Codebericht selbst kompromittiert und zur Bereitstellung von Malware verwendet werden. Und wir werden später über alle Sicherheitskontrollen sprechen später über alle Sicherheitskontrollen Zunächst möchte ich, dass Sie die Risiken verstehen. Und das hängt stark mit der Entwicklerumgebung zusammen. Wir haben schon einmal darüber gesprochen, oder? Das ist ein Entwickler, sie brauchen Zugriff, weil sie die Möglichkeit haben wollen , sie wollen Sandboxen Sie wollen die Möglichkeit haben, virtuelle Maschinen zu starten, Anwendungen zu installieren und zumindest erweiterten Zugriff Sie wollen keinen Firmen-PC, auf dem sie nichts tun können, weil sie Code ausführen müssen. Sie haben also Elektrowerkzeuge, sie haben IDs mit Plugins. Diese Plugins können kompromittiert werden, oder? Also über all diese Dinge musst du nachdenken. Und natürlich PreProde-Umgebungen. Die Pre-Prod-Umgebung wird Kundendaten enthalten. Wenn also eine Schadsoftware vorhanden ist, kompromittiert sie den Computer des Entwicklers und wird langsam in die Umgebung geschleudert. Der Angreifer kann so lange auf eine Umgebung zugreifen, bis er eine Umgebung erreicht , in der die Malware ihm sagen kann: Schau, ich habe jetzt Zugriff auf Kundendaten Sie werden in der Lage sein, diese Daten zu exfiltrieren. diese Weise können Sie also sehen, wie mehrere Dinge zusammenkommen: Der Entwickler-PC ist nicht sicher, der Quellcode-Sweep ist kompromittiert und Ihre Vorproduktumgebung enthält Auf diese Weise können Sie also sehen, wie mehrere Dinge zusammenkommen: Der Entwickler-PC ist nicht sicher, der Quellcode-Sweep ist kompromittiert und Ihre Vorproduktumgebung enthält vollständig offene Produktionsdaten. All diese Faktoren führen zu einer echten Gefährdung Ihrer Umgebung Das war also eher aus Sicht der Entwickler. Lassen Sie uns nun über Angriffe während der Build-Phase sprechen. Wir haben schon einmal über einen Build-Server gesprochen, oder? Es ist ein wichtiger Teil von CICD, da sie im Grunde den Prozess des Kompilierens von Code, der Ausführung von Tests und der Vorbereitung von Anwendungen für die Bereitstellung automatisieren Ausführung von Tests und der Vorbereitung von Anwendungen für Es ist, als ob der Build-Server alles macht, oder? Und Angriffe während der Build-Phase sind ziemlich gefährlich, denn wenn ein Angreifer in der Lage ist, unbefugten Zugriff auf oder Kontrolle über den Build-Server zu erlangen , können sie in Ihrer Umgebung wirklich Chaos anrichten Warum? Weil gebaute Plattformen normalerweise in Ihre Artefakt-Repos integriert sind, wo sich Ihr Code oder Ihre Paket-Repos befinden, Und sie können Ihren Build modifizieren. Sie können also diese Rechnungsplattformen tatsächlich angreifen. Sie haben viele Parameter, oder? Sie können es also tatsächlich ändern. Sie können damit zu einem kompromittierten Ort weiterleiten kompromittierten Ort weiterleiten Oder sie können die Bill-Plattform selbst nutzen , um ihren eigenen bösartigen Code zu verbreiten, wie den, der bei Sonnenwinden passiert ist über den wir gleich sprechen Oder sie können es tatsächlich verwenden die Artefakte zu kompromittieren, oder? Die entwickelte Plattform ist also ein sehr, sehr wichtiger Teil Ihrer Umgebung. Und eines der besten Beispiele dafür, was passiert, sind Solargewinne. Nach dieser Lektion werden wir uns später einige Lektionen ansehen . Wir werden anhand einer Fallstudie zeigen, was passiert, wenn eine gebaute Plattform kompromittiert wird Die schiere Wirkung des besten Beispiels dafür sind Gewinne aus der Solarenergie Der andere, der in engem Zusammenhang damit steht, ist der Kompromiss mit der CICD-Pipeline Wir haben über die CICD-Pipeline gesprochen. Warum? Das überträgt automatisch Code, stellt ihn bereit und testet ihn Und diese Pipelines sind sehr, sehr attraktive Ziele für Angreifer Warum? Weil sie einen direkten Weg zur Softwareproduktionsumgebung und zum Benutzersystem und zu den Daten bieten. Also ich meine, wie kann es kompromittiert werden? Es gibt mehrere Möglichkeiten. Möglicherweise haben Sie unsichere Anmeldeinformationen. Vielleicht haben Sie die Zugriffskontrollen nicht richtig konfiguriert Zugriffskontrollen nicht richtig Möglicherweise haben Sie anfällige Tools , die kompromittiert werden, oder? Und denken Sie daran, dass es sich bei CSCDPipeline um automatisierte Prozesse handelt , die zum Integrieren, Testen und Bereitstellen von Code verwendet werden , Testen Und diese können zu schwerwiegenden Sicherheitsverletzungen führen. Und das kann dazu führen, dass auch andere Kunden Kompromisse eingehen, worüber wir in einer Fallstudie namens Cod COV sprechen einer Fallstudie namens Cod COV Ich werde dir zeigen, was passiert. Eigentlich, wenn die CICD-Pipeline kompromittiert wird, was das für Auswirkungen Also das sind die beiden. Also einer ist der Build-Server, wir werden eine Fallstudie machen und diese. Wir werden eine Kas-Studie machen. Ich werde Ihnen in Kürze zeigen , was passiert, wenn entweder der Build-Server oder die CICD-Pipeline kompromittiert Aber jetzt möchte ich, dass Sie über die Auswirkungen dessen nachdenken , was passieren kann Das deckt also diesen speziellen Abschnitt ab. Jetzt werden wir über das Paketdepot sprechen, aber wie ich schon sagte, ich möchte Sie nicht mit zu vielen Informationen überhäufen In der nächsten Lektion werden wir über das Paket wept und spezifische Angriffe sprechen , die darauf abzielen können , sowie über einige einzigartige Angriffe wie Abhängigkeiten und Konfusionsangriffe Wie sie passieren und welche Auswirkungen diese Angriffe haben Also vielen Dank, und wir sehen uns im nächsten. 6. Risiken der Lieferkette – 4: Hallo, alle zusammen. Willkommen. Willkommen zu dieser Lektion. Und jetzt werden wir uns auf die Paketruhe konzentrieren. Wenn Sie sich an Ihre Software erinnern , die in einem Paket gebündelt ist, oder? Der gesamte Code und alle Abhängigkeiten werden in einem Paket gebündelt, das Sie in den Kundenumgebungen und in Ihren Produktionsumgebungen bereitstellen können Ihren Produktionsumgebungen Jetzt werden diese Pakete im Paket-Repo aufbewahrt, und der Paketbericht selbst kann kompromittiert werden Vielleicht haben Sie das Paket-Repo nicht gesichert , oder? Wir haben es offen zugänglich gemacht. Sie haben es also falsch konfiguriert. Vielleicht haben Sie eine Verbindung zum Internet hergestellt, vielleicht haben Sie anonymen Zugriff zugelassen Sie verwenden Standardkennwörter und gewähren Benutzern Upload-Rechte, die missbraucht werden können. Und was passieren kann, ist, dass sich ein Angreifer Zugriff auf dieses Paket-Repo verschafft und es vergiftet Das Paket-Repo wird also von böswilligen Akteuren wie Widen verletzt oder manipuliert Das kann also die Integrität und Sicherheit der gesamten Lieferkette, nicht wahr, der Software-Lieferkette beeinträchtigen , weil sie bösartige Pakete verbreiten können, oder Denken Sie daran, dass dies ein zentraler Ort ist, an dem Softwarepakete gespeichert werden. Was kann also passieren? Menschen können Malware verbreiten. Bei der Malware-Injektion kann bösartiger Code zu Paketen im Repository hinzugefügt werden. Also, wenn Leute es herunterladen und diese kompromittierten Pakete integrieren, wird die Malware Teil der Anwendung oder, äh, der Diebstahl von Zugangsdaten, Vielleicht können Angreifer Anmeldeinformationen aus Paketen stehlen und sie dann verwenden um anderen nicht autorisierten Code in die Pipeline zu bringen Sie können sogar legitime Pakete ersetzen lassen. Sie haben also einen Paketnamen. Sie können das durch Ihr eigenes bösartiges Paket ersetzen, und im Nachhinein wird es an Tausende und Abertausende von Leuten weitergegeben. Und zu guter Letzt gibt es noch Angriffe zur Verwirrung bei Abhängigkeiten. Dabei handelt es sich um eine spezielle Art von Angriff bei der Angreifer Pakete veröffentlichen, deren Namen den internen privaten Paketen ähneln , die von Unternehmen verwendet werden. Und wenn das öffentliche Paket eine höhere Versionsnummer hat, könnten die Paketmanager diese anstelle der internen Nummer abrufen, und ich zeige Ihnen, wie das passiert Es ist ein sehr einzigartiger Angriff, aber ein extrem, extrem gefährlicher Aber das ist genau das, was ich dir zeigen wollte. Und das ist kein Witz. Ich meine, das Paket-Repo, nur um dir ein Beispiel zu geben. Das war ein Paket-Repo, das letztes Jahr kompromittiert wurde. Der Angreifer konnte sich Zugriff verschaffen, glaube ich, auf vier inaktive Konten, und er hat über ein Dutzend Pakete mit über 500 Millionen Installationen entführt mit über 500 Millionen Und im Grunde haben sie, glaube ich, die Paketbeschreibung durch ihre eigene Nachricht ersetzt , und das wurde kompromittiert, im Grunde genommen, die Pakete modifiziert, und es wurde immer mehr geschoben Also würden Entwickler, die die Pakete herunterladen, das bösartige Paket bekommen. Und nur um Ihnen zu zeigen, wie gefährlich das ist, Leute, wenn Sie nicht so etwas wie Multifaktor-Authentifizierung verwenden, wenn Sie nur Ihre eigenen Passwörter öffnen, und so ist das passiert Und wissen Sie, das zeigt Ihnen nur, wie gefährlich es ist, dass Benutzer, die völlig offen sind, die keine Zugriffskontrolle haben, sich tatsächlich Malware einfangen können Die Leute denken über Malware nach. Sie denken daran, dass etwas ins Internet oder per E-Mail kommt , oder? Sie wissen nicht, dass Ihre Softwarelieferkette , also Ihre Paketanbieter, Ihre entwickelten Plattformen, die auch dazu verwendet werden können , bösartigen Code in Ihre Umgebung und in die Umgebung Ihrer Kunden zu übertragen, was zu einem massiven Reputationsproblem für Ihr Unternehmen führen kann zu einem massiven Reputationsproblem für Ihr Denken Sie also bitte an all diese Dinge. Und jetzt, worüber ich vorhin sprechen wollte, Verwirrung über Abhängigkeiten, falls Sie sich erinnern. Also das ist wie eine besondere Art von Angriff. Diese nutzen aus, wie Paketmanager Pakete herunterladen und installieren. Ein Angreifer veröffentlicht also ein bösartiges Paket in einem öffentlichen Paket-Repo mit demselben Namen wie ein bekanntes Paket, das intern verwendet wird Und wenn Sie dieses Paket anfordern Ihr Paket-Repo nicht konfiguriert ist , geht es zunächst ins Internet und prüft, ob dort eine höhere Versionsnummer vorhanden ist Nehmen wir also an, Sie verwenden Version eins in Ihrem privaten Repo, wird der Angreifer denselben Namen eingeben und er wird Version zwei installieren Wenn Sie das Paket-Repo also nicht richtig konfiguriert haben , wird es dieses bösartige Paket herunterladen Deshalb wird es als Abhängigkeitsverwirrung bezeichnet , oder? Wir nutzen die Art und Weise aus, wie diese Dinge funktionieren. Denken Sie daran, wir haben öffentliche und private Repos, richtig? Es tut uns leid. Private Repos sind also solche, die intern gehostet werden, aber Sie haben vielleicht einen öffentlichen Node Packet Manager und all das, oder? den öffentlichen Paketen können Angreifer also schnell herausfinden, können Angreifer also schnell was die gängigsten und beliebtesten sind, und sie können schnell viele, viele Pakete, bösartige Pakete mit demselben Namen, pushen bösartige Pakete mit demselben Namen Und das ist sehr, sehr gefährlich, denn wenn Sie es nicht richtig konfiguriert haben , können Angreifer ein bösartiges Paket mit demselben Namen wie ein legitimes Paket erstellen ein bösartiges Paket mit demselben Namen wie und es in diese beliebten Paket-Repos hochladen Wenn also ein Entwickler nach einer legitimen Abhängigkeit fragt, wird der Paketmanager dieses bösartige Paket abholen Und das ist eine großartige Möglichkeit, Malware zu verbreiten. So wird es also aussehen , oder? Sie haben ein öffentliches Paket-Repo. Der Angreifer geht dorthin Er sagt: Okay, das sind die gängigsten Pakete. Ich werde mein eigenes mit dem gleichen Namen veröffentlichen, aber ich werde eine höhere Versionsnummer als die aktuelle angeben. Version drei, Version vier, Version fünf, richtig? Und was passiert? Also geht der Entwickler dorthin. Er sagt, ich möchte das XYZ-Paket in der privaten Registrierung haben. Sie haben diese private Registrierung nicht so konfiguriert , dass sie nur die privaten verwendet. Standardmäßig wird das Verhalten also zuerst in das öffentliche Repo übertragen Es wird sagen und es wird das falsche Paket abrufen Es wird das interne nicht abrufen . Es wird sagen: Hey, ich habe Version eins im Internet, es gibt Version zwei Es wird also die, wie Sie es nennen, neueste Version herausgeben. Aber dieser war bösartig. Dieser wurde vom Angreifer geschubst. Wenn es also erfolgreich ist, können eine Abhängigkeit, eine Verwirrung und ein Angriff schwerwiegende verheerende Folgen haben Es kann alle Kunden infizieren, die das bösartige Paket installieren, und sie können dann ins Visier genommen werden, weil sie durch Malware oder Ransomware kompromittiert wurden . Sie können dieses Problem eindämmen, Sie können indem Sie sicherstellen, dass die Entwickler ihre Pakete überprüfen und verifizieren und ihre Abhängigkeiten auf dem neuesten Stand halten , aber private Es handelt sich also um eine sehr einzigartige Art von Angriff, mit der viele Menschen nicht vertraut sind Und das ist ziemlich gefährlich in der Art und Weise, wie es funktioniert. Damit ist dieser spezielle Bereich, den Sie als Sicherheitsrisiko in der Lieferkette bezeichnen In der nächsten Lektion werde ich über eine Fallstudie sprechen. Denken Sie daran, dass wir über die kompromittierte Build-Plattform und die CICD-Pipeline gesprochen kompromittierte Build-Plattform und die CICD-Pipeline Wir werden über die Sonnenvenen und die Code-CV-Venen sprechen Sonnenvenen und die Code-CV-Venen Aber in dieser Lektion, die ziemlich lang war, haben wir über die Arten von Software, die Risiken in der Lieferkette, die verschiedenen Angriffspunkte und die möglichen Auswirkungen gesprochen über die Arten von Software, Risiken in der Lieferkette, die verschiedenen Angriffspunkte . Was die Auswirkungen angeht, werde ich Ihnen mehr Kontext geben , indem ich mir die tatsächlichen Angriffe und dergleichen anschaue, welche sehr gefährlichen Folgen diese Angriffe hatten sehr gefährlichen Folgen . Also vielen Dank. Nehmen Sie sich Zeit , um diese Lektion noch einmal durchzugehen, falls nötig. Damit du eine gute Grundlage hast und wir sehen uns in der nächsten Lektion. Danke. 7. SolarWinde: Hallo, alle zusammen. Willkommen. Willkommen zu dieser Lektion, der es darum geht, den Angriff von Solowinden zu verstehen. Ich bin mir sicher, dass Sie von dem Angriff auf die Lieferkette durch Solarwinde gehört haben . Es ist einer der verheerendsten Angriffe, die je passiert sind, zumindest innerhalb von 21 Jahren, in denen zumindest innerhalb von 21 Jahren ich im Bereich Cybersicherheit gearbeitet habe, die Auswirkungen und die Anzahl der kompromittierten Unternehmen Solar Wins ist mit Abstand einer der größten Cyberangriffe , die es je gegeben hat Es ist sehr wahrscheinlich, dass Sie meinen Kurs verfolgen, hauptsächlich wegen des Solarwind-Cyberangriffs Ich bin ehrlich, ja. Deshalb wollte ich über Sonnenwinde sprechen. Man kann nicht über Lieferkettensicherheit sprechen ohne über den Solarwind-Cyberangriff und Fallstudien zu sprechen , und wissen Sie, wirklich einen Schritt zurücktreten und einige dieser Themen ansehen, wird das wirklich dazu beitragen, die Sicherheitsrisiken in der Lieferkette, von denen ich gesprochen habe, zu kontextualisieren , denn dann können Sie es aus der Perspektive eines tatsächlichen Vorfalls betrachten der Perspektive eines tatsächlichen ist passiert und nur um eine bessere Vorstellung davon zu bekommen , wie gefährlich diese Dinge sind, richtig? Also lass uns weitermachen. Wenn wir also über Solargewinne sprechen, ist das, wie ich schon sagte, einer der verheerendsten Angriffe auf die Lieferkette aller Zeiten. Es ist wie bekannt, wissen Sie, all die großen Cybersicherheitsvorfälle, und es zeigt wirklich die Schwachstellen , die es in der Sofa-Lieferkette gibt , und die Folgen wie die Auswirkungen. Gewinne im Solarbereich hatten globale Auswirkungen. Es ist auf Regierungen und Organisationen auf der ganzen Welt verteilt, einfach weil die Solarwind-Software so verbreitet ist, oder? Und es sind wirklich so viele CSOs, Tausende und Abertausende von Unternehmen, Tausende und Abertausende von Unternehmen, dass sie ihre Lieferkettensicherheit und ihr Vertrauen in Drittanbieter aus allen Branchen neu bewerten ihr Vertrauen in Drittanbieter aus allen Branchen Und Solar gewinnt, falls Sie nicht wissen, es sich um ein weit verbreitetes Unternehmen für Netzwerkmanagement-Software handelt, das Ziel des hochentwickelten Supply-Chain-Angriffs war des hochentwickelten Supply-Chain-Angriffs Im Grunde waren die Angreifer in der Lage, den Softwareentwicklungs - und Vertriebsprozess von Solarwind zu infiltrieren den Softwareentwicklungs - und Vertriebsprozess von Solarwind - und Vertriebsprozess und bösartigen Code in die Softwareupdates einzufügen bösartigen Code in die Softwareupdates Es handelte sich also nicht nur um einen direkten Angriff auf Solargewinne, sondern auch um einen indirekten Angriff auf Tausende und Abertausende von Unternehmen sondern auch um einen indirekten Angriff auf Tausende und Abertausende von Unternehmen. Dem sie vertrauen. Das bösartige Update wurde also als legitimes Softwareupdate für Solar Wins getarnt , und es wurde an Tausende von Solarwins-Kunden verteilt , und es hat sich heimlich seinen Weg in die Netzwerke so vieler Solarwin-Kunden verschafft die Netzwerke so vieler Solarwin-Kunden Und es ist wirklich eine Erinnerung daran, wie wichtig es ist, die Software-Lieferkette zu sichern die Software-Lieferkette und dass Sie diese Risikobeurteilungen wirklich ständig evaluieren und durchführen müssen diese Risikobeurteilungen wirklich ständig evaluieren und durchführen So sah es also richtig aus. Wie ich Ihnen bereits gesagt habe, gewinnt Solarenergie Angebote wie ID-Leistungsmanagement- und Überwachungssystem Orion, und es wird von Kunden auf der ganzen Welt genutzt Und Orion hat normalerweise Zugriff auf die Systemleistungsprotokolle und -daten der Kunden Und das ist wahrscheinlich der Grund, warum die Angreifer es ins Visier genommen , weil es aus diesem Grund Opfer des Supply-Chain-Angriffs wurde Sie verwendeten also maßgeschneiderte Malware, die für den Bauzyklus von Sonnenwinden entwickelt wurde. Und sie waren in der Lage, die Dateien zu ersetzen. Manche Leute sagen, Millisekunden, und sie waren im Grunde in der Lage, die Dateien durch ihre eigenen bösartigen Updates zu ersetzen Und es gab einen sehr, sehr ausgeklügelten Angriff, so wie sie ihn gemacht haben Er hieß Malway und hieß Sunspot, und er ermöglichte es den Hackern, quasi alles zu überwachen Die Entwicklungsumgebung für Sonnenwinde. Und wann immer sie ihre Rechnungen in die Höhe trieben, ersetzten sie sie durch ihr eigenes bösartiges Update. Im Grunde war es also eine Hintertür. Und diese Hintertür, als die Updates als bösartiges Update veröffentlicht wurden, hatten sie nun Zugriff auf Tausende und Abertausende von Kunden, weil sie sich in andere Kunden einschleichen konnten , weil sie ihr eigenes bösartiges Update in das Solar Wins-Update gesteckt hatten ihr eigenes bösartiges Update in das Solar Wins-Update gesteckt in das Solar Solar Wins hat ihnen also geholfen, diese Malware zu verbreiten, oder? Und Sie können verstehen, warum Slewns ein so vielversprechendes Ziel für diese Art von Supply-Chain-Angriff war ein so vielversprechendes Ziel , oder? Warum sollten sie möglicherweise so sein? Nun, weil ehrlich gesagt, wie gesagt, viele multinationale Unternehmen und Regierungsbehörden die Oon-Software verwenden Alles, was die Hacker brauchten , war , dieses bösartige Update zu installieren, und Solewns würde es verteilen Und weil Unternehmen ihnen vertrauen , würden sie sie installieren Es war also wirklich wunderschön in der Art und Weise, nicht wegen des Schadens, der passiert ist, sondern wirklich wunderschön in der Art, wie es entworfen wurde Man konnte sehen, wie intelligent diese Typen waren, oder? Und was ist danach passiert? Eine Sicherheitsfirma, ich glaube, es war Frey. Sie entdeckten diese Malware , die sich auf die Kunden ausbreitete, und konnten das Sunburst-Aktualisierungspaket identifizieren das Sunburst-Aktualisierungspaket Sie haben in K festgestellt, dass dieses Solvins-Paket kompromittiert wurde Und sobald es entdeckt wurde, veröffentlichten sie sofort dieses Update, und mehrere Kunden konnten feststellen dasselbe Verhalten in ihrem Enami Und so wurde ihnen klar, wie schlimm die Ausbreitung war, oder? Es hatte Tausende und Abertausende von Kunden durch sie infiziert . Und Solns hat schnelle Hotfixes veröffentlicht , um diese Hintertür zu beseitigen Aber wissen Sie, ich meine, ich glaube, etwa 18.000 Kunden von Solar Vines haben das Sunburst-Update installiert, das den Angreifern dann den Fernzugriff auf die Daten ihrer Kunden ermöglichte Fernzugriff Und wissen Sie, ich glaube, das US-Gesundheitsministerium, das US-Finanzministerium und der Staat waren alle infiziert, große Namen, Sie wissen schon, große Technologieunternehmen, alle waren von der Malware betroffen Und der ganze Sinn liegt darin , dass die Art und Weise, wie sie es verbreiten konnten, den blinden Fleck vertrauensvoller Softwareupdates aufgezeigt hat, und das hat wirklich dazu geführt, dass nicht nur Solar Vines, sondern auch andere Unternehmen sich den Wiederaufbauprozess angesehen haben. Wenn Sie ein Unternehmen sind, das Software an andere Unternehmen vertreibt, richtig? Und Sie geben automatisch Updates heraus. Sie müssen wirklich darüber nachdenken, was ist, wenn sich darin Malware befindet? Wie stelle ich sicher, dass mir das nicht passiert? Und genau darum geht es bei der Betrachtung dieser Fallstudie. Und genau das ist danach passiert. Wir hatten also so viele Unternehmen, sich ihre Softwarerechnungen angesehen , zum Beispiel, wie stelle ich sicher haben, zum Beispiel, wie stelle ich sicher, dass sich niemand einschleicht Und hier kam das Konzept der reproduzierbaren Builds zum Vorschein, das wir in Kürze eingehen werden Aber ich wollte dir nur die Wirkung zeigen. Wir hatten, wie die Regierung Biden, eine Exekutivverordnung erlassen, um Cybersicherheit des Landes zu verbessern Sie können das Datum 12. Mai 2021 sehen, und sie hatten spezielle Anforderungen an die Sicherheit der Software-Lieferkette Sie sagten, sie hätten die Tatsache erwähnt, dass diese Art von Software keine Transparenz bietet. Wir wissen nicht, was passiert, wenn Malware eindringt, und wir müssen wirklich Kontrollen einführen, um sicherzustellen, dass die Sicherheit der Software-Lieferkette gewährleistet ist, oder? Und am meisten schockierend war der wegweisende Schritt, die Securities and Exchange Commission, SEC, die den CSO von Solar Wins tatsächlich des Betrugs und der Fehler bei der internen Kontrolle im Zusammenhang mit den Cybersicherheitspraktiken des Unternehmens beschuldigte Fehler bei der internen Kontrolle im Zusammenhang den Cybersicherheitspraktiken des Unternehmens Sie sagten, sie hätten Gebühren gekauft, bei denen Sie falsch angegeben hatten, wie sicher Solargewinne Sie haben sie also tatsächlich gekauft. Sie sagten, er habe Investoren über die Cybersicherheitspraktiken des Unternehmens in die Irre geführt über die Cybersicherheitspraktiken des Unternehmens in die Er hatte die Risiken und die unzureichende Kontrolle nicht offengelegt. Im Grunde hatte er also übertrieben, wie sicher sie waren, und er hatte nicht alle Risiken offengelegt Und das war quasi ein bedeutender Wandel in der Sichtweise der Menschen auf Cybersicherheit Jetzt erkennen zivilgesellschaftliche Organisationen, dass sie tatsächlich, wissen Sie, nicht nur mit Bußgeldern, sondern sogar mit Gefängnisstrafen Und werden bewerten, dass die zivilgesellschaftlichen Organisationen wirklich einen Schritt zurücktreten mussten. Und aus diesem Grund ist die Sicherheit der Software-Lieferkette heutzutage so wichtig geworden Und ich hoffe, ich kann Ihnen erklären, wie wichtig es war, mit Solarenergie zu gewinnen. Und wie schützt man sich? Das ist eine Frage im Wert von 1.000.000$, oder? Wie stellen Sie sicher , dass Ihr Unternehmen nicht zum nächsten, sagen wir, Solarunternehmen Leider können viele bewährte Sicherheitspraktiken dieser Art von Angriffen nicht entgegenwirken. Was sagen die Leute, die nur signierte Versionen installiert haben, wissen Sie, digital signierte Softwareupdates , die von Solaranlagen stammen? Es wird nicht helfen, weil die Software signiert ist. Es kommt von der legitimen Firma. Es ist nicht so, als würde sich ein Angreifer einschleichen. Es kommt von der vertrauenswürdigen Firma, oder? Aktualisieren Sie Ihre Software auf die neueste Version, wie die Leute sagen werden, richtig? Weil die aktualisierte Software bösartig war. Und es war Teil des gültigen Build-Prozesses. Hier begann also das Startproblem ins Spiel zu kommen. Man kann nicht einmal sagen, den Quellcode überprüfen, weil sie den Build-Prozess beeinträchtigt haben, oder? Also ein paar der wichtigsten Dinge, die Sie tun können, neben Ihren guten Sicherheitspraktiken wie Überwachung und Abhärtung, ja, sicherzustellen, dass Sie Kontrollen haben, die das Verhalten überwachen, dass Unternehmen ihren Build-Prozess wirklich gegen diese Art von Angriffen absichern müssen , oder? Und sie müssen sicherstellen, dass die Build-Umgebung nicht kompromittiert werden kann Sie haben dafür gesorgt, dass wir mehr darüber sprechen , wenn wir über die Sicherung der Software-Lieferkette sprechen die Sicherung der Software-Lieferkette Die Build-Umgebung muss jedoch gesichert werden. Sie müssen sicherstellen , dass Benutzer nicht einfach die Umgebung kompromittieren und ihre eigenen bösartigen Updates einfügen können, und Sie müssen das überwachen. Und die beiden wichtigsten Dinge, die Sie tun können, sind verifizierte, reproduzierbare Builds und Software-Stücklisten Ich werde im Detail auf ihre Software-Stücklisten eingehen , aber die stärkste Gegenmaßnahme, die Sie haben können, ist ein reproduzierbarer Build. Dabei handelt es sich um einen Build, immer die gleichen Ausgaben erzeugt , sodass die Build-Ergebnisse , reproduzierbaren Build kann also verifizierten, reproduzierbaren Build kann also eine unabhängige Person des Quellcodes einen Build erstellen und überprüfen, ob die Build-Ergebnisse aus demselben Quellcode stammen, den Ich würde fast sagen, dass 99% der heutigen Software nicht so sind Aber was wäre im Fall von Sonnenwinden passiert? Zum Beispiel, wie würde ein verifizierter, reproduzierbarer Aufbau aussehen? Allein anhand des Namens, den Sie sehen können, können Sie ihn verifizieren und reproduzieren Also, wenn Sie Zugriff sowohl auf den Quellcode als auch auf den Build haben. Was bewirken verifizierte, reproduzierbare Rechnungen? Sie bieten Ihnen im Grunde eine sehr, sehr starke Gegenmaßnahme gegen Angriffe wie Solar-Ins, bei denen Binärdateien nicht mit dem Quellcode übereinstimmen Warum? Weil ein Angreifer bösartigen Code in eine Binärdatei eingefügt hat, oder? Denn im Fall von Sonnenvenen greifen sie die Binärdatei an, nicht den Quellcode. Einer der Vorteile reproduzierbarer Builds besteht also darin, dass diese beiden Builds unabhängig voneinander erstellt werden können und beide nach und nach dasselbe Artefakt erzeugen . Und das gibt Ihnen die Gewissheit, dass keine Malware in dieses System eingeschleust wurde . Und das ist die ganze Motivation hinter diesem Konzept. Und was mit Solaranlagen passiert wäre, wenn Solar Wins reproduzierbare Rechnungen eingeführt hätte , dann hätten sie aus der Quelle eine gute Binärdatei generieren und sie mit der verteilten Binärdatei vergleichen müssen aus der Quelle eine gute Binärdatei generieren und sie mit der verteilten Binärdatei vergleichen Und es würde nicht passen, oder? Diese Diskrepanz wäre also entstanden durch das Einfügen des bösartigen Codes entstanden, und er wäre erkannt worden, weil die und er wäre erkannt worden Binärdatei bei der Verteilung nicht mit dem verifizierten , reproduzierbaren Build übereinstimmt reproduzierbaren Build Und das hätte die Entwickler auf unautorisierte Änderungen aufmerksam machen können, dass, hey, der Build-Prozess Der Binärdatei wurde etwas Zusätzliches hinzugefügt , das vorher nicht da war Ist es zu 100% narrensicher? Absolut nicht Denn denken Sie daran, dass sich die Angreifer bereits in der Umgebung befanden, oder? Sie benötigen also auch andere Sicherheitskontrollen. Aber diese Art von verifiziertem, reproduzierbarem Build gibt Ihnen eine sehr, sehr starke Kontrolle dagegen Ich werde den Link auch auf die gesamte Website setzen, die diese Art von Kontrolle vorgibt Denken Sie jedoch daran, dass, wenn Sie Updates an Tausende von Kunden verteilen an Tausende von Kunden und diese Art von Überprüfung benötigen, der verifizierte, reproduzierbare Gürtel eine sehr, sehr starke Kontrolle Ich hoffe also, das war nützlich für Sie. Wir sind einen Schritt zurückgetreten und haben uns Angriff der Sonnenwinde genau angesehen. Schauen wir uns nun einen weiteren Angriff an und sehen, wie er passiert ist und dass es sich um weiteren Angriff an und sehen, wie er passiert ist und dass eine andere Art von Angriff als Sonnenwinde handelte. Aber nur um Ihnen mehr Informationen darüber zu geben , wie diese Angriffe passieren, danke ich Ihnen. Wir sehen uns in der nächsten Lektion. 8. Codecov: Es ist eher Hallo, alle zusammen. Willkommen zu dieser Lektion. Und jetzt weiter mit dem vorherigen, in dem wir uns Sonnenwinde angesehen haben. Jetzt gehen wir zu einem anderen aktuellen Angriff über, dem Dov Attack Nun, Sonnenwinde, wenn Sie sich erinnern, beeinträchtigen sie den Bauprozess, oder? Die Angreifer waren in der Lage, den Build-Prozess zu kompromittieren und Schadsoftware einzuschleusen In diesem Fall geht es mehr um die CICD-Pipeline. Wenn du Codkov nicht kennst , hoffe ich, dass ich den Namen ausspreche , wenn sie nicht sauer Aber ja, es ist ein Code-Coverage-Tool. Was bedeutet das? Im Grunde genommen, überprüfen Sie, wie viel von Ihrer Anwendung getestet wird, wissen Sie? Wenn Sie zum Beispiel moderne Anwendungen entwickeln wir CICE verwenden, verwenden wir automatisierte Tests, oder? Darüber haben wir schon einmal gesprochen Und wir wollen sicherstellen, dass jede Codezeile getestet wurde, richtig, und jedes FOG, und das erfordert ziemlich viel ausgereiftes Test-Framework. Hier kommt Cod Cov ins Spiel, und es kann Ihnen helfen, zu wissen, welche Codezeilen in Ihrer CI-Umgebung nicht abgedeckt werden Und so gehen sie Kompromisse ein, sie kompromittieren diese, was es ihnen ermöglichte, auch andere Umgebungen zu kompromittieren Nun, wenn Sie sich an Sonnenwind und Solarenergie erinnern, war der Gewinn von Solarenergie zielgerichteter und zielte auf Spionage gegen Regierungsbehörden und große Unternehmen ab, oder? Hatte ein klares geopolitisches Motiv, wie einen Angriff durch einen Nationalstaat Dieser ist eher eine weitreichende Sicherheitsverletzung , von der unterschiedslos eine Vielzahl von Unternehmen betroffen waren Es war ihnen egal, wer kompromittiert wurde. Und sie konzentrierten sich darauf, Informationen aus den Entwicklungsumgebungen von Soffe zu stehlen Informationen aus den Entwicklungsumgebungen von Soffe zu Oh, darüber sprechen wir jetzt. Der Code Cv-Angriff wurde im April 2021 entdeckt , wenn ich mich erinnere. Ja, es war wie ein riesiger Sicherheitsstrand. Und wie gesagt, dies ist ein sehr beliebtes Tool zur Codeabdeckung , das von Softwareentwicklern verwendet wird, um zu beurteilen, wie effektiv ihre Tests sind. Und es lässt sich in verschiedene Virgin-Kontrollsysteme integrieren. Es generiert Berichte, die Sie darüber informieren, wie gut die Softwaretests Ihre Codebasis abdecken, oder? Im Grunde haben sich die Angreifer also unbefugten Zugriff auf Code CoF-Systeme verschafft Wie sie unsere Sicherheitslücke ausgenutzt haben. Ich denke, bei der Erstellung von Docker-Images müssen wir nicht die Besonderheiten von Docker und allem anderen kennen die Besonderheiten von Docker Aber im Grunde haben sie das Bash-Uploader-Skript geändert. Ich werde mir Einzelheiten dazu ansehen. Was sie dazu befähigte, ermöglichte es ihnen, heimlich vertrauliche Informationen von den Kunden von Cod C zu exportieren , oder? Von dort aus, speziell aus den CI-Umgebungen, den Umgebungen für kontinuierliche Integration. Und welche Informationen, Anmeldeinformationen, Benutzer-IDs, Passwörter, Token-Schlüssel und andere Daten könnten sie verwenden, um weiteren und unbefugten Zugriff zu gewähren. Ich glaube, es blieb mehrere Monate lang unentdeckt, vom 31. Januar 2021 bis April 2021 Und jeder, der das kompromittierte Bash-Uploader-Skript heruntergeladen hat, im Grunde unwissentlich seine Informationen preisgegeben Ich glaube, es betraf etwa 29.000 Kunden, große Namen in der Branche, große Namen in der Branche Und wieder wurden, wie üblich, alle mit Angriffen auf die Lieferkette konfrontiert Es tut uns leid, aber alle wurden mit Angriffen auf die Lieferkette konfrontiert und plötzlich wurde ihnen klar, konfrontiert und plötzlich wurde ihnen klar wie wichtig diese Dinge sind. Und Kotov hat die betroffenen Benutzer benachrichtigt und sie haben die Schlüssel zurückgezogen und ausgegeben und sie haben zugestimmt, ihre Umgebung überprüfen zu Aber wenn man sich das anschaut, sah es im Grunde so Konzentrieren wir uns also darauf, ob Sie sich an die CI-Umgebung erinnern, eine kontinuierliche Integrationsumgebung. Wir können hier eine Menge leistungsstarker Automatisierung durchführen, um unsere Anwendung zu testen, oder? Und Sie verlassen sich auch auf viele externe Dinge, oder? Datenbanken, Zahlungssysteme, Cloud-Infrastruktur. Wenn Sie die Tests durchführen und all diese Komponenten von der aus zugegriffen werden muss Pipeline aus zugegriffen werden muss, damit sie die Anwendung erstellen und testen können. Im Grunde muss Ihre CI-Pipeline also Zugriff auf welche Geheimnisse und Anmeldeinformationen haben , damit sie Zugriff erhalten kann. Und normalerweise sollten Sie, wenn Sie eine CI-Umgebung aufbauen, die Staging-Infrastruktur und nicht das Produktions-Byte verwenden , aber nach meiner eigenen Erfahrung ist es sehr üblich, dass Produktionsanmeldedaten verwendet werden, weil die Leute sicherstellen wollen , dass sie die Tests ordnungsgemäß durchführen und dass die Tests so viel wie möglich abdecken Leider können diese Informationen oft vorkommen Es ist also sehr wahrscheinlich, dass die CI-Umgebung Zugriff auf sehr vertrauliche Informationen hat. Also, indem sie Kotkov angegriffen haben und das haben sie getan, richtig? Sie haben die Malware infiziert und Testtool kompromittiert Sie haben Zugriff auf alle Anmeldeinformationen. In der CI-Umgebung für alle Cdf-Kunden. Und wenn Sie sich erinnern, haben sie im Grunde ein Bash-Skript kompromittiert, das nur eine Reihe von Anweisungen für das ist was Sie schreiben würden, wenn Sie jemals Terminal oder Bash gemacht hätten, aber das auf programmierte Weise geschrieben wurde Sie fügten eine einzige Codezeile hinzu, die all ihre Umgebungsvariablen vom CI an den Remote-Server des Angreifers senden sollte vom CI an den Remote-Server des Angreifers Sie verstehen, dass sie diese Daten im Grunde stillschweigend auslesen. Und jetzt können Sie verstehen wenn sie rund 23.000 Kunden haben, jeder, dass, wenn sie rund 23.000 Kunden haben, jeder, der zwischen dem 31. Januar und dem 1. April die kompromittierte Version von Cod Cov verwendet hat, betroffen gewesen zwischen dem 31. Januar und dem 1. April die kompromittierte Version von Cod Cov 31. Januar und Und große Unternehmen waren betroffen, und sie veröffentlichten im Grunde genommen Dokumente für ihre Kunden darüber wie sie sich von diesem Angriff erholen können Und was sie tun, was haben sie getan, nachdem sie es kompromittiert hatten Sie haben sie also nicht direkt angegriffen. Sie hätten von dort aus mehrere Angriffe durchführen können, oder? Aber sie haben tatsächlich die Quellcode-Repos kompromittiert Quellcode-Repos weil sie die Anmeldeinformationen erhalten haben, oder Die Quelle. Und sie konnten dann auf ihre Quellcode-Repos zugreifen dann auf ihre Quellcode-Repos Und sie waren in der Lage , sie zu finden, weil diese Repos möglicherweise tatsächlich über Produktionsanmeldedaten Sie können also sehen, wie sich dieser Angriff kaskadiert, oder? Zuerst haben sie Kotkov kompromittiert. Sie haben die Zugangsdaten für die Quellcode-Repos Sie haben diese Repos kompromittiert. Sie haben Zugang zur Produktion. Und sie waren aufgestanden und hatten sogar bemerkt, dass sie verdächtige Aktivitäten von anderen privaten Repositorys bemerkt hatten verdächtige Aktivitäten von anderen privaten Repositorys Sie wurden an einige nicht autorisierte Benutzer geklont, und das zeigt nur, wie einfach es war, oder? Kompromittiertes KotkVU Verwenden Sie gestohlene Git-Anmeldeinformationen, greifen Sie mit diesen gestohlenen Anmeldeinformationen auf private Repositorys zu, und dann können Sie damit beginnen, und dann können Sie damit beginnen greifen Sie mit diesen gestohlenen Anmeldeinformationen auf private Repositorys zu, und dann können Sie damit beginnen, sie nach vertraulichen Informationen zu durchsuchen. Nur um Ihnen zu zeigen, wie wunderbar einfach dieser Angriff war und wie sie damit so viele Kunden kompromittieren konnten . Wie ich bereits erwähnt habe, hatte er wiederum globale Auswirkungen. Unzählige Kunden wechselten ihre vertraulichen Daten, ihre Quellcode-Depots und Angreifer konnten sich Zugang zu nicht autorisierten Depots verschaffen, und sie enthielten leider internen Quellcode und interne wechselten ihre vertraulichen Daten, ihre Quellcode-Depots und Angreifer konnten sich Zugang zu nicht autorisierten Depots verschaffen, und sie enthielten leider internen Quellcode und interne Zugangsdaten. Auch hier haben Sie jetzt eine bessere Vorstellung davon, was getan werden kann. Natürlich unterscheidet es sich von Sonnenwinden, bei denen die Bauumgebung beeinträchtigt wurde Aber auch hier muss die Sicherheit der Umwelt verbessert Ich kann nicht stressfrei genug sein, Sie müssen dafür sorgen, dass Ihre Umgebung sicher ist Halten Sie Ihre Quellcode-Repos sauber. Legen Sie dort keine Anmeldeinformationen in Ihrer Ruhezone ab. Wenn jemand in der Lage ist, sie zu kompromittieren, kann er sie als Sprungbrett in Ihre Umgebung nutzen , oder? Setzen Sie Datenfilterung und Kontrollen gegen Datenlecks ein. Woher wissen Sie, ob jemand Stillen Daten überall durchsickern lässt Sie können Ihre Quellcode-Repos sogar mithilfe von Multifaktor-Authentifizierung Wenn Sie also wissen, dass Anfragen nur aus einem bestimmten Bereich kommen, können Sie tatsächlich IP-Einschränkungen festlegen, können Sie tatsächlich IP-Einschränkungen festlegen Selbst wenn sie über die Anmeldeinformationen verfügen, können sie nicht darauf zugreifen. Verstärkte Sicherheit der CICD-Pipelines, um sicherzustellen, dass sie nur den Zugriff haben , der benötigt wird Sie möchten ihnen keine Administratoranmeldedaten für die gesamte Umgebung geben , Und natürlich, um hartcodierte Anmeldeinformationen zu vermeiden. Das war also wieder eine weitere wichtige Studie, eine weitere Umgebung, die aufgrund eines Supply-Chain-Angriffs kompromittiert wurde , und ich hoffe, Sie haben jetzt ein anderes Bild gesehen Ich habe mich bewusst für diese Methode entschieden, weil sie sich von der Art und Weise unterscheidet, wie Solaranlagen gefährdet wurden. Jetzt haben Sie also eine gute Idee, und ich hoffe, Sie haben jetzt die Voraussetzungen geschaffen, um zu verstehen , wie wir sie sichern können Sie haben eine gute Vorstellung von den Risiken, und im Kontext der tatsächlichen Angriffe sehen Sie, wie sich diese Risiken materialisieren Jetzt können wir mit der nächsten Lektion fortfahren, in der es darum geht, die Software-Lieferkette tatsächlich abzusichern Jetzt können wir zum guten Teil übergehen, nämlich der eigentlichen Absicherung und Minderung dieser Risiken Vielen Dank und wir sehen uns in der nächsten Lektion 9. Menschenstreik: Hallo, alle zusammen. Willkommen. Willkommen zu dieser neuen Lektion, die ich gerade zum CrowdStrike-Ausfall hochgeladen ich also nicht meine, wenn Sie keine IT oder gar kein System verwenden, hätten Sie vom CrowdStrike-Ausfall gehört , der dieses Jahr im Jahr 2024 passiert ist Cloud Strike ist ein sehr, sehr beliebtes Unternehmen wie ein Unternehmen für Sicherheitslösungen Ich meine, sie geben ihre Produkte ausschließlich an Unternehmen und große Organisationen weiter. Sie sind in der Welt der Cybersicherheit sehr, sehr berühmt. Leider sind sie zu einem bekannten Namen geworden. Jetzt kennt sie jeder wegen dieses Vorfalls. Und im Grunde genommen, obwohl es sich in diesem Sinne nicht um einen Cybersicherheitsvorfall handelt, hat ihn niemand gefährdet, aber er hatte massive Auswirkungen auf die Lieferkette Und das ist sehr wichtig. Ich könnte nicht über die Software-Lieferkette oder die Sicherheitsrisiken in der Lieferkette sprechen die Sicherheitsrisiken in der Lieferkette ohne über Cloud Strike zu sprechen. Falls Sie mit CloudStrike noch nicht vertraut sind: Sie haben im Grunde eine Komponente namens CrowdStrike Sie haben im Grunde eine Komponente namens Falcon. Es ist wie ein Sensor Es nutzt KI, um Kundenumgebungen zu schützen , Sie wissen schon, indem es die neuesten Bedrohungen identifiziert und sich davor schützt. Kurz gesagt, im Grunde genommen wurde 2024 ein neues Update eingeführt, richtig, mit dem der neue Sensor im Grunde nicht umgehen konnte und abgestürzt ist Und angesichts der Nähe des CrowdStrike-Sensors zum Windows-Betriebssystem führte dies zum Absturz aller Systeme und zu einem massiven globalen Ausfall, der sich auf fast alle Branchen auf der ganzen Welt auswirkte Millionen und Abermillionen von Endpunkten waren betroffen, oder? Und das wurde als die größte Störung im Identitätsmanagement aller Zeiten bezeichnet , oder ich denke, es ist die größte, weil es einfach der Natur und der Art und Weise, wie Ich habe bereits mit Ihnen über Rodseg gesprochen, es ist ein sehr, sehr beliebtes Unternehmen für Sicherheitslösungen Millionen von Unternehmen haben es genutzt , und es ist ein gutes Leider wurde der Name aufgrund dieses Vorfalls gewissermaßen durch den Schlamm gezogen Aber zweifellos ist es ein sehr gutes Unternehmen, ein sehr, sehr, sehr ausgereiftes Sicherheitsunternehmen Aber leider das fehlerhafte Software-Update. Ich habe zu dem blauen Bildschirm des Todes geführt. Es ist wie eine Schleife auf Windows-Computern bei der sie wiederholt abstürzen. Und obwohl viele Menschen das Update einführten, waren die Auswirkungen auf der ganzen Welt enorm Und wie ich schon sagte, wortwörtlich, Flughäfen , Häfen, lassen Sie uns ein Beispiel nehmen, was für Dinge passieren Flughäfen waren betroffen. Wenn Sie zu der Zeit gereist sind, haben Sie mein Mitgefühl Sie werden Bilder von, Sie wissen schon, überall sehen, wie Flughäfen überfüllt sind, Flughäfen überfüllt Tausende Flüge verspätet sind, Schiffshäfen betroffen sind, Supermärkte, Krankenhäuser, ich lebe in Großbritannien, und der NHS hat quasi eine Erklärung veröffentlicht, in der es heißt, dass sie derzeit keine Kunden bedienen können derzeit keine Kunden bedienen Patienten wegen der Impact-ID-Firmen, Regierungsbehörden und so weiter nein. Ich meine, auf der ganzen Welt gab es große Schließungen, Verspätungen, Tausende von Flügen wie Seitwärtsflüge Und im Grunde zeigt es den vernetzten Charakter der Software-Lieferkette Und obwohl das Erstaunliche daran ist, handelt es sich nicht um einen Angriff. Es war nur ein Fehler, aber es hat gezeigt, welche Auswirkungen haben können, und das ist nur ein Beispiel. Ich meine, ich bin sicher, du hättest es gesehen, oder? Aber es zeigt nur, wie gefährlich die Abhängigkeiten auf der ganzen Welt in Bezug auf diese Art von Software sind , oder? Also die globalen, wie ich schon sagte, Krankenhäuser, australische Unternehmen, sie sagten, sie hätten eine Schadensrechnung von rund 1 Milliarde, oder? Und Banken, Medien, NHS. Die Auswirkungen auf der ganzen Welt waren also unglaublich. Aber es ist sehr, sehr wichtig die Tatsache von der Übertreibung zu trennen Und ich mag das nicht so , wie es oft formuliert wurde Und wie die Leute anfingen zu sagen , es sei ein Cyberangriff. Es hatte natürlich Auswirkungen auf die Verfügbarkeit im Internet, und es war nicht wie ein Angriff durch einen Kriminellen. Und sie haben einen Ursachenbericht veröffentlicht , den Sie sehen können. Und sie haben erwähnt, wie es passiert ist. Im Grunde der Zensor. Ich glaube, es waren ungefähr 20 Eingabefelder zu erwarten , aber es gab das neueste Update mit 21 Eingabefeldern, und die Diskrepanz bei der Anzahl hat zu einem weltweiten Absturz geführt Und weil der Interpreter 20 Werte erwartete und als er anfing, auf 21st zuzugreifen, gab er eine Anzeige aus, die nicht über den verfügbaren Speicherplatz verfügte. Weißt du, diese Dinge. Und weil es so eng in den Windows-Code integriert ist, hat es beim Absturz das gesamte Betriebssystem heruntergefahren, und der blaue Bildschirm blinkte auf der ganzen Welt, in Supermärkten, Flughäfen, überall, wo Sie sich vorstellen können, es blinkte im Grunde, was darauf hinausläuft, dass es an geeigneten Tests für Sensorupdates mangelte Es umging ihre neuartigen Prozesse. Die Tests waren kein Nachteil. Und viele Leute begannen zu sagen, dass dies jetzt ausgenutzt werden könnte Und ich würde empfehlen, die Blogbeiträge von CrowdStrike zu lesen , in denen sie die Behauptungen über den Sicherheitssensor von Falcons angesprochen und widerlegt haben Sicherheitssensor von Falcons Obwohl es sich um einen Speicherabsturz außerhalb der Grenzen handelte, wurde festgestellt, dass er bis heute nicht für eine vorherige Eskalation oder Remotecodeausführung ausgenutzt werden kann vorherige Eskalation oder Und sie haben eine detaillierte Ursachenanalyse durchgeführt , dass selbst dieser Fehler keine Programmausführung zulässt, und sie haben die anderen Kontrollen erwähnt, die sie hatten, wie Zertifikat-Pinning, Prüfsummenvalidierung, Zugriffskontrolle Manipulationserkennung, richtig? Und sie haben gezeigt, dass ich den Bericht hier verlinken werde, den Blog hier, und ich werde dir auf jeden Fall empfehlen, ihn zu lesen, denn wenn du diese Situationen analysieren willst, achte darauf, dass du ihn richtig analysierst und keine Dinge einfügst , die zu diesem Zeitpunkt nicht existierten. Und CoudStak, sie haben ihr Engagement für Sicherheit bekräftigt und erwähnt, dass sie ihr Bug-Bounty-Programm ebenfalls verbessert haben. Aber die Lehren, die aus diesem Vorfall gezogen werden können , sind Um es ganz klar zu sagen: Angreifer, auch wenn es kein Angriff war, aber die Angreifer werden aus diesem Vorfall lernen. Sie haben gesehen, wie schädlich dieser Angriff war. Sie können sich also ohne Zweifel vorstellen Angreifer Interesse an diesem Angriff gezeigt haben, und sie werden darüber nachdenken, wie sie beim nächsten Mal sogar eine größere Wirkung erzielen und damit etwas Geld verdienen können . Wenn Sie ein Lösungsanbieter sind. Das ist wie bei CrowdStrike, Sie stellen dem Unternehmen einen Agenten , eine Software zur Es ist gut, sich Ihre Testprozesse anzusehen. Denken Sie über diese Art von Resilienz nach. Was passiert, wenn sich Ihr Endpunkt sehr nahe am Windows-Kernel und etwas passiert, richtig Führen Sie eine Phasenbereitstellung durch. Machen Sie keinen Urknall-Ansatz. Ich kann nicht glauben, dass ich das sagen muss, aber es zeigt sich einfach richtig. Sie müssen keine große Implementierung durchführen, diese phasenweise durchführen und Ihren gesamten Prozess unabhängig prüfen lassen. CrowdStrike, ich denke, sie arbeiten mit zwei verschiedenen Unternehmen zusammen, um eine vollständige Bewertung ihrer Softwareentwicklungspraktiken durchzuführen . Die Tests werden nur durchgeführt, um sicherzustellen , dass sie keine blinden Flecken haben Und aus Kundensicht würde ich, wenn Sie eine Software wie RoudStrik verwenden , zunächst empfehlen, die übermäßige Abhängigkeit von wenn Sie eine Software wie RoudStrik verwenden, zunächst empfehlen, die übermäßige Abhängigkeit von einem Anbieter zu beseitigen . Wenn Sie einen Anbieter haben, der alles macht und diesem Anbieter etwas passiert, werden Sie in große Schwierigkeiten geraten, oder? Denken Sie über dieses Szenario und nehmen Sie es in Ihr Disaster Recovery-Playbook auf Aber ich muss mich ganz klar ausdrücken. Ein solches Szenario können nur sehr wenige Menschen vorhersagen. Es war wie ein Black Swan-Vorfall, oder? wie etwas , das alle zwei, drei Jahrzehnte passiert alle zwei, drei Jahrzehnte Aber ich würde empfehlen , über Dinge wie Cloud-Backups oder einen virtuellen Desktop nachzudenken , der ein völlig anderes Image von Ihren normalen Desktops ist , oder? Wenn also etwas passiert, wenn es einen größeren, schwerwiegenden Fall gibt, können Sie Daten auf dem Cloud-Desktop wiederherstellen. Und das ist etwas völlig anderes dass es von Ihrem regulären Netzwerk Es hat nicht dieselben Agenten. Es hat verschiedene Agenten. Es mag mehr kosten, aber dann können Sie bei einem solchen Vorfall ein komplett eigenes Image erstellen, dann können Sie bei einem solchen Vorfall ein komplett eigenes auf dem Ihre Mitarbeiter zumindest in eingeschränktem Umfang ihre Aktivitäten wieder aufnehmen können , da viele Unternehmen völlig abgeschnitten waren. Die Server waren ausgefallen, aber selbst die normalen Desktops sind ausgefallen, weil Cloud Stoke überall lief, oder? Denken Sie also darüber nach, ein anderes Image zu haben , auf dem Sie es bereitstellen und zum Laufen bringen können, das sich von Ihren normalen Images unterscheidet und das nicht von denselben Problemen betroffen Das waren also die Dinge, über die ich mit allen sprechen wollte , nur um es euch zu zeigen, weil CrowdSTK wie ein riesiger Vorfall war Es entwickelt sich immer noch. Es kommen viele Neuigkeiten raus. Aber denken Sie an diese Vorfälle, vor allem, wenn Sie darüber nachdenken, Ihre Software gegen die Anwendungskette abzusichern . Vielen Dank. Ich sehe dich in der nächsten Lektion. 10. Sicherung der Lieferkette – 1: Hallo, alle zusammen. Willkommen. Willkommen zu dieser Lektion, die Teil einer mehrteiligen Lektion ist , in der es um die Sicherung der Software-Lieferkette gehen wird . Ich hoffe, Sie haben inzwischen eine gute Vorstellung davon, was die Software-Lieferkette ist. Sie haben eine gute Vorstellung von den Risiken, die auftreten können. Sie haben tatsächliche Angriffe gesehen und wie sie kompromittiert wurden, oder? Jetzt werden wir uns also mit der Implementierung von Kontrollen innerhalb der Software-Lieferkette befassen Wir werden uns mit Sicherheitskontrollen und -praktiken befassen, einigen der häufigsten Fehler , die Menschen machen, wenn sie ihrer Software-Lieferkette beginnen , also mit der Sicherheit. Und dann werden wir uns auch einige Standards und Frameworks ansehen , die Sie nutzen können, um beim Aufbau eines Supply-Chain-Sicherheitsprogramms den größtmöglichen Nutzen zu erzielen beim Aufbau . Sie müssen also nicht von Grund auf neu aufbauen, . Sie müssen also nicht von Grund auf neu aufbauen sondern können das nutzen, was Sie bereits haben. Wenn Sie also einen Blick darauf werfen, haben wir das bereits besprochen. Erinnerst du dich? Dies war die Umgebung mit dem Risiko, dass Sie eine Entwicklerumgebung haben, die gefährdet werden kann Sie haben unsicheren Code, die Build-Plattform wurde kompromittiert, das Quellcode-Repository, die Abhängigkeiten, Sie konnten keine Sicherheitstests für den Code durchführen Sie haben eine Datenschutzverletzung in der Preprod-Umgebung festgestellt, und sogar Ihre Produktionsumgebung und sogar Ihre Produktionsumgebung Hier kommt also die Sicherheit der Software-Lieferkette ins Spiel, um all diese Risiken grundsätzlich abzusichern Und wenn Sie sich erinnern, als wir zu Beginn des Kurses über Sicherheit in der Software-Lieferkette gesprochen haben, oder? Es geht im Grunde darum , die Integrität, Sicherheit, Verfügbarkeit Zuverlässigkeit aller beteiligten Komponenten und Prozesse sicherzustellen. Bei Ihrer Entwicklung, dem Vertrieb und der Wartung von Software. Sie möchten sicherstellen, dass niemand an Ihrer Software herumspielt, dass niemand sie manipuliert Und sehr, sehr wichtig, wenn wir über eine Lieferkette sprechen, sprechen wir nicht nur über den direkten Quellcode, oder? Wir sprechen auch über Bibliotheken, Tools und Dienste von Drittanbietern und die Infrastruktur, weil ich oft sehe , dass es manchmal nicht Ihre Infrastruktur ist, die Kompromisse eingeht. Es sind die Anbieter oder die Anbieter. Wie können Sie also sicherstellen, dass Ihr Sicherheitsprogramm für die Lieferkette alles abdeckt? Das müssen Sie also beachten. Und was sind leider einige der häufigsten Fehler , die Leute machen und die mir immer wieder Kopfschmerzen bereiten, wenn ich mit Kunden spreche , die Sicherheit der Lieferkette. Was ist es nicht? Es ist kein Werkzeug oder Produkt. Bitte. Jeder, der Ihnen sagt, dass jeder Anbieter, der zu Ihnen kommt und sagt: „ Kaufen Sie mein Produkt und Sie haben Sicherheit in der Software-Lieferkette“, das ist völliger Schwindel. Es wird Ihnen helfen. Zweifellos wird es dir helfen, ist es aber nicht. Es ist Teil der Sicherheit der Software-Lieferkette, nicht das Endziel. Okay? Sie können nicht einfach automatisch werden, dass Ihre Software-Lieferkette nicht sicher wird, weil Sie eine Lösung für Millionen von Dollar gekauft und implementiert haben . Es ist keine Zertifizierung. Jemand sagt, dass Sie diese Checkliste verwenden oder dieses Ding verwenden, und jetzt ist Ihre Lieferkette gesichert Nochmals, so funktioniert das nicht. Es ist auch keine Lieferanten-Checkliste. Manche Leute führen eine Risikobeurteilung des Anbieters durch und denken, dass ihre Software-Lieferkette jetzt sicher ist Und es ist auch keine einmalige Aktivität. Es ist etwas, das Sie kontinuierlich mit einer Risikobewertung durchführen müssen. Und es ist Last One is MyF, das MFA aktiviert. Auch hier ist nichts falsch daran, MFA zu aktivieren. Dies ist ein sehr wichtiger Teil der Sicherheit bei der Softwareversorgung. Aber die Leute denken , dass unsere Umgebung jetzt sicher ist, weil wir MFA aktiviert haben unsere Umgebung jetzt sicher ist, weil wir MFA Ich habe keine Ahnung , wie das zustande kommt, aber bitte machen Sie diesen Fehler nicht, oder? Denken Sie also, wie gesagt, an die Definition, über die ich Ihnen vorhin gesprochen habe, diese, denken Sie daran und lassen Sie sich nicht mit diesen Missverständnissen verwirren Und wenn wir über die Sicherung der Software-Lieferkette sprechen , sprechen wir über mehrere Kontrollen, oder? Und darauf werde ich mich in diesen Lektionen konzentrieren. Wir werden über sichere Programmierpraktiken sprechen, was Sie tun können, Komponenten von Drittanbietern, Abhärtung Ihrer Umgebung, CICD-Pipeline-Sicherheit, tatsächliche Sicherheitstests und -Scans, die Software-Builds von Material, L BOM, falls Sie nicht damit vertraut sind, und natürlich über Vendor West Management All diese Dinge sorgen zusammen für eine effektive Sicherheit der Software-Lieferkette, und dann werden wir uns auch ansehen, wie ein konkretes Programm erstellt All diese Punkte werde ich behandeln. Ich werde Sie nicht mit Informationen bombardieren. Wir werden Schritt für Schritt Ihre Umgebung aufbauen , richtig Am Ende wird Ihre Umgebung also so aussehen. Sie werden Kontrollen auf mehreren Ebenen haben, und dann wird ein ordnungsgemäßes Programm laufen, das sicherstellt, dass all diese Dinge beachtet und Risiken bewertet werden. Also, wie ich schon sagte, wir werden es Schritt für Schritt tun. Wir sehen uns in der nächsten Lektion. Wir werden uns eingehend mit diesen Steuerungen befassen Vielen Dank. Wir sehen uns in der nächsten Lektion. 11. Sicherung der Lieferkette – 2: Hallo zusammen. Willkommen. Willkommen zurück zur Lektion. Und wir setzen unsere vorherige Lektion fort in der wir über die Sicherung der Lieferkette und die Sicherheitskontrollen sprechen die Sicherung der Lieferkette und . Wir können sie umsetzen. Wenn Sie sich erinnern, habe ich Ihnen diese grundlegenden Kontrollen gezeigt diese grundlegenden Kontrollen nämlich sichere Codierungspraktiken, Komponenten von Drittanbietern, Hoarding-Umgebungen, CICD-Pipelines alle, wir werden eins nach dem anderen durchgehen und es uns ansehen Also lass uns weitermachen. Und wenn Sie sich erinnern, ich habe Ihnen das Diagramm auch so gezeigt das Diagramm auch so wenn wir früher die Risiken in diesem Diagramm gesehen haben, aber wenn Sie die Kontrollen einführen, diese Kontrollen, die Sie in dem Diagramm sehen, werden diese Risiken gemindert Fangen wir also mit der allerersten an, nämlich der sicheren Codierung Wenn Sie sich erinnern, haben wir über die Risiken gesprochen, oder? Und ich sagte, dass der unsichere Code die Wurzel allen Übels ist Also sichere Codierung, deshalb müssen wir das zuerst besprechen. Sichere Codierung im Kontext der Lieferkettensicherheit bezieht sich darauf , dass die Entwickler Software so entwickeln , dass Sie sicherstellen, dass Sicherheitslücken der Code zu keinem Zeitpunkt Sicherheitslücken enthält. Okay? Und das erfordert Kontrollen, sowohl Bewusstsein als auch technische Kontrollen, richtig? Denn denken Sie daran, dass es mehrere Möglichkeiten gibt , Sicherheitslücken eingeführt werden können. Wir werden also über Schulungen zu sicherem Code sprechen und darüber, wie Sicherheitsfeedback in die ID selbst integriert werden kann. Dies ist ein wichtiger Teil, Dies ist ein wichtiger Teil, der von vielen Leuten übersehen wird. Wir werden darüber sprechen, wie sichere Codeüberprüfungen stattfinden können. Und natürlich die Sicherheitstests des Codes, der dem SAST und dem Staub vorgelegt wird Wenn Sie im Bereich Cybersicherheit gearbeitet haben, bin ich mir sicher, dass Sie damit vertraut sind Lassen Sie uns also zunächst mit der Schulung zum sicheren Code beginnen. Das Sicherheitsbewusstsein für unsicheren Code ist ein sehr, sehr, sehr guter Anfang Sie müssen Ihre Entwickler über unsicheren Code und die damit verbundenen Gefahren informieren über unsicheren Code und , oder ? Es gibt viele, viele gute Schulungen. Die Top Ten der Betriebssysteme sind der Branchenmaßstab. Ich bin mir sicher, wenn Sie im Bereich Cybersicherheit tätig sind, müssen Sie schon davon gehört haben. Informieren Sie sie also, erzählen Sie ihnen von Schulungen wie diesen, zeigen Sie ihnen, sprechen Sie mit ihnen über die Unsicherheiten, zwar sehr, sehr wichtig sein können Bitte machen Sie es nicht mit PowerPoint zum Tod, was ich meine, wenn Sie ihnen ein 200-seitiges PowerPoint-Dokument geben Glauben Sie mir, niemand wird sich daran erinnern. Zeigen Sie ihnen, zeigen Sie ihnen tatsächlich unsichere Codeteile und zeigen Sie ihnen, wo die Sicherheitslücken liegen Zeigen Sie ihnen, dass Sie Zeit und Mühe sparen, wenn Sie es im Code selbst reparieren Zeit und Mühe , im Gegensatz dazu, dass jemand es später herausfindet und es dann repariert und wie es später herausfindet und es dann repariert viel Zeit verschwendet wird, richtig? Es gibt also viele, viele, sehr gute Schulungen zu unsicherem Code, zu OVA, Dingen wie SQL-Injection , Cross-Site-Scripting und all diesen Dingen. Also sensibilisiere sie. Aber bei einem sehr, sehr wichtigen Punkt, und hier verpassen die Leute etwas, beginnen Sie mit dem Bewusstsein, aber stellen Sie sicher, dass Sie das tun, das ist dieser Punkt Sicherheitsfeedback in die ID integriert. Die ID ist die integrierte Entwicklungsumgebung. Und damit meine ich, die Programmierung, die sie machen, sollten sie in der Lage sein, sofort Feedback zu erhalten. Okay? Du kannst so viele Schulungen geben, wie du willst. Entwickler benötigen eine Möglichkeit, Feedback in Echtzeit zu erhalten. Okay? können sie wissen, dass der Code nicht sicher ist, wenn sie den Code entwickeln Wie können sie wissen, dass der Code nicht sicher ist, wenn sie den Code entwickeln, oder? Welche Probleme gibt es? Und das ist die schmerzloseste und reibungsloseste Art, Code zu sichern Glauben Sie mir, Sie müssen später keine Sicherheitstests durchführen später keine Sicherheitstests wenn der Entwickler es sofort weiß, wenn er einen schnellen Scan durchführt und sieht, schauen Sie, das sind Vielleicht ist mein Code, den ich geschrieben habe nicht sicher, ich muss ihn reparieren Dies ist der einfachste Weg, und wenn Sie das richtig machen, werden Sie einen massiven Anstieg Ihres Sicherheitscodes feststellen. Okay? Wenn Sie also ein Beispiel nehmen, wenn Sie sich erinnern, dass ich Ihnen dieses Beispiel schon früh gezeigt habe, als ob das ein Code ist, der nicht bereinigt, die Eingabe wird genommen, und das kann natürlich zu Dingen wie SQL-Injection führen, kann natürlich zu Dingen wie SQL-Injection führen bei der Leute tatsächlich auf Ihre Backend-Datenbanken, Ihre Betriebssysteme, Ihre Dateien zugreifen können , wenn Sie sie nicht Nun, das ist ein Beispiel für eine IDE, wie Visual Studio-Code , wie Visual Studio-Code Und das ist ein Tool, was Sie Code Whisperer nennen, das ist A. Sie können jedes Tool verwenden. Ich nenne übrigens nicht gern spezielle Tools Aber wenn Sie sich den Screenshot ansehen, also das war der Code, derselbe Code, den ich Ihnen gezeigt habe, wenn ich ihn hier einfüge und sofort einen Sicherheitsscan durchführe , wird er mir sagen, schauen Sie, dass es eine SeQL-Injektion gibt, und es wird mir auch die Zeile sagen Sie sehen, wie mächtig das ist, wenn Sie es richtig machen. Sie können also sofort sagen, der Entwickler wird es wissen, schauen Sie, ich führe eine Sicherheitslücke in den Code ein. Ich muss das beheben, bevor ich es an das Repo schicke. Und dies wird zu einer massiven Steigerung der Qualität Ihres Sicherheitscodes führen der Qualität Ihres Sicherheitscodes Wenn Sie sich noch erinnern, habe ich Ihnen diesen hier gezeigt, den Zip-Bomben-Angriff, bei dem Leute eine Datei versenden , die möglicherweise in riesige Datenmengen von GB entpackt werden kann riesige Datenmengen von GB entpackt , und ein Serverausfall zu einem Denial-of-Service führt Also, wenn Sie das noch einmal tun, werden Sie sofort sehen, es wird Ihnen Feedback geben, uneingeschränktes Hochladen gefährlicher Dateien, tippen Sie unten auf und klicken Sie auf den Link zu den Ressourcen Das ist also ein sehr, sehr mächtiger Weg. Ich habe Ihnen das Beispiel für Code mit Spur gezeigt , aber Sie können viele Tools verwenden, die in die IDE selbst integrieren und dem Entwickler Feedback in Echtzeit geben. Darüber, welche Art von Code sie einreichen und warum er unsicher ist Schauen Sie sich das bitte an. Machen Sie nicht den Fehler , den 90% der Leute machen, nämlich dass sie die Entwickler Sicherheitscode schulen und dann erwarten, dass sie alles finden. Nein, so wird das nicht funktionieren. Geben Sie ihnen Tools, die ihnen Feedback in Echtzeit geben. Danach sprechen wir über Tests. Wenn Sie sich erinnern, wir haben über Tests gesprochen, es geht durch die CSED-Pipeline, es geht zu den Qualitätstests Hier können Sie Ihre verschiedenen Arten von Sicherheitstests für den Code vorstellen von Sicherheitstests für den Code Der erste ist Static Application Securities Testing oder SAS. Dies ist eine Testmethode , die Ihren Quellcode untersucht. Es führt das Programm nicht aus und wird normalerweise in einem frühen Stadium während der Codierungsphase selbst ausgeführt . Es wird Sie darüber informieren, also schaut es sich den Quellcode an und es wird herausfinden, hey, führen Sie irgendwelche Sicherheitslücken ein? Sie können die Tools in die CICD-Pipeline integrieren und sie führt eine sehr gründliche Analyse Ihrer Codebasis Es untersucht den Code, weil er bis zur Codeebene reicht Die zweite Methode ist DAST, bei der es sich um eine Black-Box-Testmethode handelt, was bedeutet, dass der Code keinen Zugriff hat Es schaut sich nicht den Quellcode an, sondern er wird tatsächlich ausgeführt Also während seiner Ausführung läuft das Programm Ich simuliere tatsächlich externe Angriffe wie SQL-Injection, und sie werden später in der CICD-Pipeline ausgeführt Normalerweise, wenn sich Ihre Software in der Preprod- oder Staging-Umgebung befindet , oder Es sieht also aus wie die Webseiten und die APIs, und es versucht, Beide Booster werden also zusammen verwendet. Es gibt keine Leute, die versuchen zu sagen, ich SASPTO sei DAS, B, SAS und DAS ergänzen sich beide DAST identifiziert Verfügbarkeiten aus einer anderen Perspektive, und SAS betrachtet Sie ergänzen sich also gegenseitig. Idealerweise sollten Sie sich beide ansehen. Und wie kommt das zusammen? Wenn Sie also auf die linke Seite schauen, haben Sie die ID, unter der Sie die Entwickler schulen, und Sie geben Feedback in die ID ein. Sie schreiben also sicheren Code. Sobald sie den Code eingereicht haben, geht er in die CI-Pipeline. Es testet, berichtet, erstellt und SAST kommt ins Spiel Es sieht also aus wie der Quellcode. Wenn der Code unsicher ist, geht er zurück an den Entwickler. Bitte repariere das Wenn es erfolgreich ist, also wenn es die ID weitergibt, passiert es die SAS, es geht an die CD-Pipeline, wo Sie das Review Staging Prod haben Innerhalb der Stagingphase finden die Tage statt. Das ist ein sehr vereinfachtes Beispiel dafür, wie man es betrachtet, aber es ist ein sehr, sehr mächtiges Werkzeug Wenn Sie also während Ihres gesamten Lebenszyklus auf verteilte Sicherheit achten, werden Sie definitiv zu einer höheren Codequalität in Ihrer Anwendung führen einer höheren Codequalität in Ihrer Anwendung Das waren also der SAST und der Staub. Ich möchte auf das andere Beispiel zurückkommen , das wiederum eines der wichtigsten Beispiele ist Ich denke, das ist der Punkt , an den die Leute am meisten denken , wenn sie über die Sicherheit der Software-Lieferkette sprechen , also über Komponenten oder Abhängigkeiten von Drittanbietern. Wir haben über die Bibliotheken gesprochen, oder? Die Bibliotheken, weil niemand Anwendungen von Grund auf neu erstellt. Sie werden sich auf Bibliotheken verlassen, Bibliotheken wie Log FoJ, wurden aber kompromittiert, oder All diese Bibliotheken können also Sicherheitslücken und Komponenten von Drittanbietern enthalten, und sie sind ein großer blinder Also, was machst du hier? Sie verwenden etwas, das als Software-Kompositionsanalyse bezeichnet wird. Es untersucht also Ihre Abhängigkeiten. Was sind die Abhängigkeiten? Was sind die Softwarebibliotheken, und sie identifiziert tatsächlich alle vorhandenen Sicherheitsrisiken. So wie SAST wie der Quellcode aussieht. Dieser sieht aus wie Ihre Drittanbieter-Bibliotheken und sagt Entwicklern: Hey, Ihre Komponente ist verwundbar und sie kann sie tatsächlich kontinuierlich verwenden, um herauszufinden, ob eine Sicherheitslücke darauf kontinuierlich verwenden, um herauszufinden, ob eine zurückzuführen ist, dass sie nicht statisch ist, oder? Es ist möglich , dass eine Komponente sicher ist und morgen wird sie unsicher SCS-Softwarekomposition analysiert also vollständig und es sieht so aus, als ob das passiert Das ist ein Beispiel von CISA, sie sind eine Regierungswebsite, und sie haben eine sehr gute Publikation Ich werde sie über die Sicherung der Software-Lieferkette für Entwickler verlinken die Sicherung der Software-Lieferkette für Und sie geben diese Empfehlung. In der Pipeline wählt der Entwickler also vielleicht eine Komponente zum Herunterladen aus, oder? Ich weiß nicht, die Log Four J-Bibliothek. Die Komponente wird also in einem sicheren Zwischenspeicher abgelegt dem Sie die Analyse der Softwarezusammensetzung durchführen. Also wird es gescannt und Sie wissen lassen, dass, okay, das sicher ist. Es gibt keine Probleme und es wird in das sichere Repository verschoben. Und von dort aus kann sich der Entwickler jetzt anmelden, es einchecken und es im Code verwenden. Oder es sei denn, es wird ein Problem gefunden, dann geht es zurück. Das ist also eine sehr gute Art, sich anzusehen, wie die Zusammenstellung und Analyse von Software funktioniert. Und wenn Sie es sich innerhalb der Pipeline, also innerhalb der ID, noch einmal ansehen , haben Sie sicheren Code und Feedback, und Sie können dort auch die Softwarezusammensetzung und RSS einfügen. Wenn der Entwickler also eine Bibliothek eincheckt, wird die Softwarekomposition Ss aktiviert und ihm mitteilen , dass die Software unsicher ist oder ebenfalls Teil der CI-Pipeline Wenn also SAST passiert, kann SAS die Software Composition Analysis integrieren und Sie wissen lassen, schauen Sie, der Code ist sicher, aber Sie verwenden eine unsichere Bibliothek. Und zu guter Letzt DAST Also, wenn Sie DAS verwenden, können Sie auch die vorhandenen Bibliotheken überwachen die vorhandenen Bibliotheken und es kann Sie in der laufenden Software darüber informieren , welche Probleme es gibt Das war also nur ein allgemeiner Überblick über den allerersten Teil, nämlich den unsicheren Code und wie man ihn schützt , dass Sie inzwischen Ich hoffe, dass Sie inzwischen eine viel bessere Vorstellung von den Kontrollen haben , die Sie zur Sicherung Ihres Quellcodes einrichten können zur Sicherung Ihres Quellcodes Okay, als Nächstes werden wir uns die Absicherung der Umgebung ansehen, wie wir die Quellcodeberichte, die Rechnungsserver, die Paketserver absichern, und wir werden uns das auf einer höheren Ebene ansehen und sehen, wie es die Sicherheit des Software-Quellcodes ergänzt Software-Quellcodes Vielen Dank. Ich werde Sie in der nächsten Lektion fragen. 12. Sicherung der Lieferkette – 3: Hallo. Hallo, alle zusammen. Willkommen, willkommen. Wir setzen jetzt unseren Unterricht fort. Wir haben uns mit Codierung befasst, mit weißer sicherer Codierung und warum das wichtig ist und wie man es schützt. Und wir haben auch über Abhängigkeiten von Drittanbietern gesprochen , oder? Also werden wir in diesem Fall weitermachen, und jetzt werden wir über die Umgebungen sprechen. Wenn Sie sich erinnern, haben wir über die Entwickler-Umgebung gesprochen , die Pre-Prod-Umgebung Und wir werden in dieser Lektion über die Komponenten sprechen , die es gibt Zuallererst, Sie wissen schon, praktische Tools zur Verfügung stellen, um sicherzustellen, dass Entwickler tun können, was sie wollen Das ist eine der größten Herausforderungen, wissen Sie, in der Cybersicherheit, denn wenn man ihnen nicht was sie für ihre Arbeit benötigen, sind Entwickler technisch sehr versiert Sie werden unsichere Wege finden, ihre Arbeit zu erledigen. Hier war Cybersicherheit also schon immer eine Herausforderung, oder? Nehmen wir ein Beispiel. Unternehmen und Cybersicherheitsteams wollen in der Regel nicht, dass Mitarbeiter Code auf ihren Workstations oder Laptops ausführen, das aus offensichtlichen Gründen Doch das brauchen Entwickler. Sie müssen in der Lage sein, wichtige Tools zu installieren und ihre Software effektiv zu testen. Hier müssen Sie in der Entwicklerumgebung flexibel sein . Und wie ich schon sagte, Entwickler sind sehr technisch versiert. Wenn Sie ihnen nicht das geben, was sie wollen, werden sie wahrscheinlich Wege finden, Hindernisse zu umgehen , die sie daran hindern, zu arbeiten, und die zu einer unsicheren Umgebung führen Aus diesem Grund müssen Sie darüber nachdenken, Entwicklern die Möglichkeit zu geben, das zu tun, was sie tun müssen Es gibt also viele Möglichkeiten, dies zu tun. Sie können das Entwicklernetzwerk tatsächlich segmentieren . Sie können es also in ein separates Netzwerk stellen, oder? Ich kenne Leute, die ihre Entwicklungsumgebungen komplett in die Cloud gestellt und sie vom Produktionsnetzwerk getrennt sie vom Produktionsnetzwerk Das einzige, was sie kombiniert, ist ein Repo. Aber sie haben alle Rechte, weil sie wissen, dass selbst wenn dort ein Problem auftritt, es in der Cloud ist, es komplett von ihrem Produktionsnetzwerk getrennt Das ist es also, worüber Sie nachdenken müssen. Was passiert, wenn ein Angreifer es kompromittiert? Denn sobald ein Angreifer es kompromittiert hat, kann er potenziell bösartigen Kern einschleusen ausnutzen Es gibt also viele verschiedene Möglichkeiten, dies zu tun. Sie können, wie gesagt, Ihre Geschäftsumgebung und Ihre Entwicklungsumgebung trennen, Ihre Entwickler vom Kerngeschäft isolieren. Stellen Sie also sicher, dass sie keinen Zugriff auf wichtige Geschäftsfunktionen haben keinen Zugriff auf wichtige Geschäftsfunktionen und überlegen Sie Ihre Entwicklungsumgebung schützen können. Sie setzen eine Multifaktor-Authentifizierung ein geben ihnen Dinge wie VDI, wodurch sie eine Es gibt ihnen also die Möglichkeit , das zu tun, was sie wollen, aber sie sind eingeschränkt Sie werden in eine bestimmte Sandbox gesteckt. Das sind also die Dinge, über die Sie wirklich nachdenken müssen , wenn Sie Ihre Umgebungen absichern, oder? So isolieren Sie Ihre Entwickler von Ihren Produktionsumgebungen. Und natürlich haben Sie auch Pre-Prod-Umgebungen . Sie haben Daten Stellen Sie sicher, dass Sie es anonymisieren. Sie desinfizieren es so weit wie möglich. Entgegen der landläufigen Meinung benötigen Sie dort nicht alle Daten Sie benötigen gerade genug, um die gesamte Produktion zu simulieren, aber Sie benötigen möglicherweise nicht alle, z. B. Kuhdaten oder PII-Daten, Sie können sie möglicherweise bereinigen. Denken Sie also über diese Dinge nach. Sie müssen eine Sicherheitsüberwachung haben. Ich habe über Datenanonymisierung gesprochen. Auf diese Weise können Sie also Ihre Entwicklungsumgebung und Ihre P-Produktionsumgebung und Ihre P-Produktionsumgebung Und wir haben über Härtung gesprochen. Eines der wichtigsten Dinge , über die Sie nachdenken sollten, ist die Sicherheit Ihrer Quellcode-Repos, Ihres Build-Servers, Ihres Paketservers All diese Dinge kommen einem in den Sinn, egal ob Sie eine CICD-Pipeline oder DevOps oder einfach nur manuell haben oder DevOps oder einfach nur manuell Gehen wir also Schritt für Schritt vor. Zuallererst ist es dein Code-Repo. Wenn Sie sich erinnern, haben Sie hier Ihren gesamten Code eingegeben, ja. Hier platzieren Ihre Entwickler den Code und sichern den Zugriff auf den Reaper Sie können sich vorstellen, Dinge wie Multifaktor-Authentifizierung einzuführen Prüfen Sie, wer Zugriff auf das Repo hat, und sichern Sie die zugrundeliegende Infrastruktur? Wenn es vor Ort ist und jemand in den Server selbst hacken kann, dann kann man dem Code nicht wirklich vertrauen , der oben drauf sein wird, Und setzen Sie immer das Prinzip der Leasing-Privilegien durch. Sie werden nicht glauben, wie viele Unternehmen, die ich kenne, den Zugriff auf ihre Anwendungen überprüfen, aber die Börsengänge vergessen sie völlig Sie vermissen es völlig. also beim Benutzerzugriff auf Repos darüber nach, wie Sie sich authentifiziert haben Gibt es eine gute Passwortrichtlinie? Setzen Sie Dinge wie die Multifaktor-Authentifizierung durch? Beschränken Sie es auf IP-Adressen? Wie wir über das Cod Cv-Problem gesprochen haben, oder? Das hätte der Fall sein können, wenn die IPs zerstört worden wären, denn selbst wenn sie Ihr Repo kompromittiert hätten, hätten sie nicht darauf zugreifen können Und natürlich eines der gefährlichsten Dinge, bitte scannen Sie es weiter Bewahren Sie Ihre Anmeldeinformationen und Ihren Quellcode immer getrennt auf. Wissen Sie, ob Ihre Entwickler irgendwelche Anmeldeinformationen in Ihrem EPO fest codiert haben, sodass Ihre Anmeldeinformationen logisch vom Quellcode getrennt Und dafür zu sorgen, dass sie gescannt werden. Das ist eines der grundlegendsten Dinge. Bis heute kann ich Ihnen garantieren, dass so viele Unternehmen hartcodierte Anmeldeinformationen in ihren Repos haben hartcodierte Anmeldeinformationen in und sich dessen nicht bewusst sind Also, haben Sie diesen Plan? Haben Sie eine Art Notfallplan, falls Sie das herausfinden, oder? Dies sind all die Dinge, über die Sie nachdenken müssen , wenn Sie über Ihr Code-Repo sprechen Wenn das Code-Depot gesichert gewesen wäre, hätten Angriffe wie Cod COV blockiert werden können Okay, die nächste ist die Build-Pipeline, richtig? Wir haben darüber gesprochen, als der Entwickler etwas in den Code, das Repo, übernommen hat Hier kommt Ihre Build-Pipeline ins Spiel. Dies kann Teil der CSCD-Pipeline sein. Sie müssen dies vor allem sicherstellen, da dies eines der größten Ziele ist Wir haben das schon bei Solargewinnen gesehen, oder? Was macht ein Angreifer? Er infiltriert ein Entwicklungsnetzwerk. Er scannt, um herauszufinden, wo sich der Quellcode befindet, wo die gebauten Systeme sind und wo die Sicherheitslücken liegen . Er geht Kompromisse ein Jetzt ist er in der Lage, den Code zu kompromittieren, der übergeben wird, und Sie können die Binärdateien kompromittieren, richtig Wenn Sie die Integrität Ihres Codes und der Build-Artefakte sicherstellen möchten , sollten Sie sicherstellen, dass Ihr Build gehärtet ist Und denken Sie immer daran, dass die Build-Threads eine der gefährlichsten Bedrohungen darstellen , die es geben kann, wie die Sonnenwindumgebung zeigt Was können wir also tun? Befolgen Sie also zunächst die Richtlinien zur Härtung. Die meisten Build-Tools, die es gibt, verfügen alle über bewährte Methoden zum Härten , die Sie befolgen können. Trennen Sie Ihre Entwicklung, Ihr Engineering-Netzwerk vom Coopit-Netzwerk Wir haben bereits darüber gesprochen. Überwachen Sie Ihre Build-Umgebung? Haben Sie dort Dinge wie eine Multi-Faktor-Authentifizierung Warum? Prüfen Sie, auf welche Konten sie Zugriff haben? Denn denken Sie daran, dass der Build-Server wenn er automatisch Code in verschiedenen Umgebungen bereitstellt Zugriff benötigt, wenn er automatisch Code in verschiedenen Umgebungen bereitstellt. Woher weißt du , dass diese Konten nicht kompromittiert wurden, oder? Stellen Sie sicher, dass Sie alle Zugriffe protokollieren. Und wir haben auch über die verifizierten reproduzierbaren Builds gesprochen , oder? Also Builds, die Sie in verschiedenen Umgebungen erstellen können, und sie werden immer dieselben sein Das gibt Ihnen die Gewissheit, dass niemand an einer Solaranlage herumgepfuscht hat Und stellen Sie sicher, dass Ihre Geheimnisse und Ihre Anmeldeinformationen grundsätzlich sicher sind Dies ist also eine vollständige Checkliste , anhand derer Sie Sicherung Ihrer erstellten Umgebungen beginnen Das sind also die Build-Server. Was ist der Paketserver sonst noch? Wenn Sie sich erinnern, also fügen Sie Dinge in den Quellcode ein, sie gehen zum Build-Server und von dort gehen sie zum Paket. Nun, der Paketserver ist Ort, an dem Ihre Software bereitgestellt wird, oder? Ihre Softwarepakete. Und Kompromisse bei Paket-Repositorys. Das kann eine erhebliche Bedrohung für Ihre Software-Lieferkette darstellen. Wir haben vorhin darüber gesprochen. Wenn Angreifer in der Lage sind, es zu kompromittieren, können sie möglicherweise bösartigen Code dorthin übertragen, oder? Also nochmal: MFA mithilfe kryptografischer Signaturen absichern. Was ist das? Sie möchten sicherstellen, dass die Integrität Ihrer Softwarepakete gewährleistet ist. Auf diese Weise kommt Ihre kryptografische Signatur ins Spiel, wenn dieses Paket manipuliert oder verändert wird Weil das Paket einen einzigartigen digitalen Fußabdruck haben wird , oder? Und wir können verifizieren, dass niemand daran herumgepfuscht hat. Auch hier können Sie sicherstellen, dass Sie sichere Kanäle verwenden und sicherstellen, dass HDDPS, SFTP oder sogar VPNs verwendet werden, SFTP oder sogar VPNs um sicherzustellen, dass die Pakete im Transet verschlüsselt werden, um die Integrität der Softwarepakete vor der Verteilung zu überprüfen vor der dass Sie sichere Kanäle verwenden und sicherstellen, dass HDDPS, SFTP oder sogar VPNs verwendet werden, um sicherzustellen, dass die Pakete im Transet verschlüsselt werden, um die Integrität der Softwarepakete vor der Verteilung zu überprüfen. Sie möchten also die aktuelle Kryptosignatur Ihres Pakets mit der Originalsignatur vergleichen Kryptosignatur Ihres Pakets mit der Originalsignatur vergleichen um sicherzustellen, dass niemand daran manipuliert hat , um sicherzustellen, dass niemand daran manipuliert hat, oder? Und dagegen, es zu unterschreiben Dies sind einige der sehr, sehr wichtigen Kontrollen. Und jetzt möchte ich Ihnen eines der Hauptrisiken, über die wir gesprochen haben, rückgängig machen . Sie erinnern sich an den Angriff zur Konfusion von Abhängigkeiten. Dabei handelte es sich um einen großen, sehr ähnlichen Supply-Chain-Whisk, bei dem ein Angreifer ein bösartiges Paket in einem öffentlichen Paket-Repository veröffentlicht einem öffentlichen Paket-Repository das denselben Namen wie ein bekanntes Paket trägt Ihr Entwickler könnte also nach einem Paket fragen, und was passiert, ist, dass das Paket zuerst zurückkommt, was es tut, es überprüft den öffentlichen Bericht Und dort hat der Angreifer den gleichen Namen eingegeben, aber mit einer höheren Versionsnummer. Sie könnten also Version drei haben, er wird Version fünf hinzufügen. Und das Paket-Repository, so wie es konfiguriert ist, wird es zuerst ins Internet gehen, um es zu überprüfen, und dann wird es das bösartige Paket herunterladen Auf diese Weise wird das Paket in Ihr Entwicklernetzwerk und auf Bingo kopiert Der Angreifer hat Zugriff auf Ihre Softwareentwicklungsumgebung und kann diese kompromittieren. Es ist also nur ein Weg, es ist eine Art von Angriff , der die Funktionsweise von Softwareentwicklungsumgebungen und Paketmanagern ausnutzt , wissen Sie, Dinge wie Node Package Manager, Python Package Index Das ist einfach die Art und Weise, wie es funktioniert. Also nochmal, was können Sie tun, um das zu sichern? Sie können private Repositorys für kritische Abhängigkeiten verwenden , Sie können einfach private Repositorys mit strengen Zugriffskontrollen verwenden , um das Risiko zu verringern, dass Sie versehentlich kompromittierte Pakete konsumieren Sie können das Sperren von Abhängigkeiten verwenden und so sicherstellen, dass Ihre Abhängigkeit das Paket, das der Entwickler auflistet , auf eine bestimmte Version beschränkt ist , die Dadurch wird verhindert, dass diese automatischen Updates von potenziell gefährdeten neueren Versionen In diesem Diagramm können Sie sehen, dass der Angreifer ein öffentliches Paket-Repo kompromittiert hat Und den Entwickler hat er nach einem Paket gefragt. Das Paket wird nicht ins Internet gehen, um es zu überprüfen. Warum? Weil du die Abhängigkeit gesperrt hast. Du hast gesagt, dass das die einzige Version ist, die ich will, die du bereits verifiziert hast, und die ist vor Ort. Es wird also nicht ins Internet gelangen und Sie werden in der Lage sein diesen Angriff vollständig zu umgehen Der Angreifer wird nicht in der Lage sein Ihre Umgebung zu gefährden. Das sind also die Dinge, die Sie im Hinterkopf behalten sollten, nämlich den Schutz vor Konfusionsangriffen, richtig? Das sind die Dinge, die Sie benötigen, um sicherzustellen, dass die Namen aller Pakete, die in Ihrem Projekt verwendet werden , bekannt und vertrauenswürdig sind. Und das können Sie tun, indem Sie die Quelle und den Betreuer jedes Pakets verifizieren Betreuer jedes Pakets bevor Sie es zu Ihren Abhängigkeiten hinzufügen Über das Signieren von Paketen wurde bereits gesprochen. Das Gleiche, als ob Sie eine digitale Signatur haben, oder? Signieren Sie das Paket und verwenden Sie private Paket-Repositorys. Erwägen Sie also, private Paket-Repositorys zu verwenden in denen Sie Ihre internen Abhängigkeiten hosten Dies kann dazu beitragen, die Anzahl der Angreifer zu reduzieren, wie ich im vorherigen Diagramm gezeigt habe Selbst wenn er ein bösartiges Paket einführt, das denselben Namen wie Ihre interne Abhängigkeit hat, wird Ihr Paketmanager nicht darauf zugreifen, da er lokal bleibt und nur das interne Paket verwendet Und natürlich das Überwachen und Scannen Ihrer Pakete, oder? Sie möchten sicherstellen , dass in der Zwischenzeit keine Sicherheitslücken eingeführt wurden. Dies kann also dazu beitragen, schädliche Pakete abzufangen und die Paket-Downloads zu überwachen. Indem Sie also die Downloads Ihres Pakets überwachen, können Sie dazu beitragen, böswillige Aktivitäten zu erkennen. sind also all die Dinge, die Sie tun können , um sicherzustellen, dass Sie vor Angriffen zur Konfusion von Abhängigkeiten geschützt sind. Also haben wir uns jetzt mit den Umgebungen befasst. Jetzt möchte ich über ein sehr wichtiges Thema sprechen, das für die Sicherheit der Software-Lieferkette von entscheidender Bedeutung ist , und das ist die Software Builds of Material, SBOM Danke. Und ich werde das nicht behandeln , weil ich denke, dass Sie in dieser Lektion bereits genug zu verstehen haben. Wir sehen uns in der nächsten Lektion, wir werden mit diesem Thema beginnen. Vielen Dank und wir sehen uns in der nächsten Lektion. 13. SBOM: Hallo, alle zusammen. Willkommen. Willkommen zu dieser Lektion, die sich mit einem sehr, sehr wichtigen Thema der Sicherheit der Software-Lieferkette befasst , nämlich einem Software-Build-of-Material, SBOYM Was ist also ein SBM? Es ist sehr einfach Es ist im Grunde ein verschachteltes Inventar. Es ist eine Zutatenliste. Von allen Softwarekomponenten , die in Ihrer Software vorhanden sind. Und wenn Sie an die Software-Lieferkette denken, richtig, jedes Tool-Framework oder Build, das zum Schreiben, Erstellen und Ausführen von Anwendungen verwendet wird, und hier kommen all die Sicherheitslücken ins Spiel, oder? Und Sie verwenden ständig Code und Softwarepakete wieder , und Drittanbieter verkaufen auch kommerzielle Pakete Die Komplexität der Entwicklung all dieser Software-Apps macht es also sehr, sehr wichtig, ein Inventar aller Komponenten zu haben , die zur Erstellung solcher Anwendungen verwendet werden, einen Katalog, oder? Und dieser Katalog hilft Unternehmen dabei , schnell Sicherheitslücken in der Umgebung zu identifizieren und festzustellen, ob sie Sicherheitslücken haben festzustellen, ob sie Sicherheitslücken haben . An dieser Stelle kommt das SBM ins Spiel. Es ist zu einem Standard für die Sicherheit der Software-Lieferkette Und hier können Sie tatsächlich von Anbietern anfragen und das bekommen. Und wir werden uns das genauer ansehen. Sie können das also tatsächlich selbst tun. Sie können es sogar mit einer Excel tun. Ich würde es überhaupt nicht empfehlen, oder Sie können es automatisch generieren. Es gibt viele, viele Programme die Ihre Umgebung scannen, und dann generieren sie tatsächlich unsere Software-Builds von Materialien Das ist es, was ich empfehle, ein maschinell generiertes Programm zu verwenden. Und es ist sehr, sehr vorteilhaft, warum? Weil es Ihnen hilft, anfällige Komponenten zu identifizieren , und es gibt Ihnen ein umfassendes Wissen darüber, was Sie haben, oder? Was ist, wenn es einen Vorfall gibt dem eine bestimmte Bibliothek kompromittiert wird Wie würden Sie wissen, ob Ihre kritischen Anwendungen dies haben oder nicht Sie können Ihr SBM tatsächlich schnell abfragen, ob es im Computerformat vorliegt, um herauszufinden, ob diese spezielle Version dieser speziellen Bibliothek verwendet wird, oder? Und es hilft Ihnen, auch Anbieter auszuwählen, die schreiben, zum Beispiel, wenn Ihr Anbieter transparent ist und er sagt: Hey, hier ist mein SBM mit der Anwendung Sie wissen, dass dies ein ausgereifter Anbieter ist, oder? Sie haben all diese notwendigen Dinge. Und selbst nachdem ich glaube, dass Solarenergie gewonnen hat, die Anbieter von Softwarelieferketten und die Sicherheitsvorkehrungen aus der Durchführungsverordnung, die zustande gekommen sind, haben sie auch angefangen, vorzuschreiben , dass Sie ein SPOM benötigen Also wie gesagt, Sie können es manuell tun , indem Sie eine Excel verwenden. Ich würde es absolut nicht empfehlen, da Sie Hunderte bis Tausende von Abhängigkeiten haben können. Normalerweise können Sie dies mit maschinell generierten Tools tun, richtig, die es völlig automatisch für Sie erledigen. Also, wie ich schon sagte, was macht es? Es ist wie ein komplett erschöpfendes Inventar, oder? Es beschreibt alle Open-Source-Dateien , Bibliotheken und Codepakete von Drittanbietern, die bei der Entwicklung einer Softwareanwendung verwendet werden , und gibt Ihnen eine gute Vorstellung von der Softwarekomposition, oder? Auf diese Weise wissen Sie, was da ist, was nicht, welche Version Sie verwenden, welche Bibliotheken und Codepakete verwendet werden? Wie sind Komponenten von Drittanbietern, wie ist der PAT-Status? Was sind die Abhängigkeiten zwischen ihnen? Und Sie können jetzt verstehen: Wenn ich wissen möchte, wie der PAT-Status ist, weil ich nicht weiß, ob die jeweilige Software für einen bestimmten Angriff anfällig ist oder nicht, kann die SBOM Ihnen sofort helfen, sie zu identifizieren Und das ist wie ein maschinell generierter . So sieht es aus. Ich meine, ich will nicht, dass du es liest, aber es zeigt nur, dass du sehen kannst , dass es dir zeigt, was das Paket ist. Stimmt? Was ist der Status? Was ist die Version? Was ist der Hashcode? Wer ist der Lieferant? Also kommen all diese Dinge ins Spiel. Und wie hilft es? Ich habe bereits darüber gesprochen, aber wissen Sie, zuallererst haben Sie Transparenz. Es gibt Ihnen also eine vollständige Liste dessen, was Sie haben, oder? Dieses Maß an Transparenz ermöglicht es Unternehmen, genau zu wissen , was in der Software enthalten ist , und erleichtert die Verwaltung und Sicherung. Schwachstellenmanagement mit SBM können Sie schnell erkennen, ob Softwarekomponenten vorhanden sind , die anfällig für Sicherheitslücken sind. So können Sie Probleme proaktiv identifizieren. Einhaltung von Vorschriften: In vielen Branchen gelten regulatorische Anforderungen , die Sicherheitsstandards für Software Wenn Sie dies nicht tun, auch wenn Sie die Software nicht im Haus haben, verwenden Sie möglicherweise eine herstellerbasierte Software. Sie können eine SBOM verwenden. Sie können den Verkäufer nach dem SBM fragen, oder? Und natürlich die Sicherheit der Lieferkette. Der ganze Sinn besteht darin, die Sicherheit Ihrer Lieferkette zu verbessern, und es hilft auch bei der Reaktion auf Vorfälle. Nehmen wir an, SBM ermöglicht Ihnen im Falle einer Reaktion auf einen Vorfall eine SBM ermöglicht Ihnen schnellere und effizientere Reaktion auf Vorfälle Sie können schnell und einfach feststellen , welche Komponenten von einem Angriff betroffen sein könnten Und wieder das Tracking von Abhängigkeiten. Also, wie ich schon sagte, es wird so kompliziert zu verfolgen, was man hat und was nicht. Eine SVM hilft Ihnen also dabei, diese Abhängigkeiten im Laufe der Zeit zu verfolgen. Und heutzutage, im Zeitalter von GNAI und allem, kann man tatsächlich eine KI auf diese Dateien legen sie abfragen und dann Antworten erhalten, die völlig menschenwürdig sind, oder? Also über all diese Dinge kannst du nachdenken. Also wenn ich es aus dieser Perspektive betrachte. Nehmen wir an, Sie haben ein Cybersicherheitsteam, richtig, und Ihr Unternehmen kauft ein Produkt von einem Anbieter Und jetzt will das Cybersicherheitsteam wissen, welche Art von Software es gibt Ist es Open Source? Wie ist es gebaut, oder? Also fragst du den Verkäufer, kannst du mir bitte ein SBM geben? Also das ist es, was der Verkäufer richtig reagiert. Sie geben Ihnen eine SBOM und die Person kann sie jetzt lesen und sich diese Gewissheit holen Okay, was ist da? Was ist nicht da? Nun, keine Software ist immun gegen Sicherheitslücken, oder? Jeder Es gibt keine Software , die zu 100% sicher ist. Sie können das also sogar mit einer SBOM tun. Sie können also den Anbieter fragen, es irgendwelche Sicherheitslücken in Ihren Softwarelabor-Redes gibt? Sie können Ihnen OSB und einen sogenannten Vulnerability Exploitability Exchange anbieten. Was ist das jetzt? Dies ist ein Framework , das darauf ausgelegt ist, die Sicherheitslücken in der Software zu kommunizieren, insbesondere ob die Software anfällig ist oder nicht. VX-Statements bieten Anbietern also eine Möglichkeit zur Kommunikation Ob es eine Sicherheitslücke oder nicht, Sie können ihnen genau sagen. Wenn ich also ein Anbieter bin und ein Kunde mich fragt, kann ich ihm das SBM plus einen VX geben Und ich sage, dass diese Sicherheitslücke kein Problem für unser Produkt darstellt, und Sie können die Bedingungen detailliert beschreiben unter denen es ein Problem sein könnte, aber Sie haben es gemildert Es ist also Teil der SBOM und bietet Ihnen Transparenz Dies ist also wieder ein Standard, der immer beliebter in der Software-Lieferkette Warum, weil Sie keinen Zugriff auf den Outsourcing-Quellcode haben , oder? Aber wenn Sie eine Anwendung kaufen, können Sie das SPM tatsächlich verwenden Sie können den VX verwenden, um diese Sicherheit zu erhalten. Und in der nächsten Lektion werden wir eine konkrete Fallstudie machen , zum Beispiel, wie das passieren würde, wenn ein Kunde eine Software kaufen würde und was wir tun können? Ich denke, das deckt so ziemlich alle Dinge ab, über die wir gesprochen haben, oder? Wir haben es also von der Entwicklerumgebung aus betrachtet: sicheres Codieren, Härten, Scannen von Komponenten, Testen, Abhärten der Umgebung, und jetzt betrachten wir es aus der SBM-Perspektive Ich hoffe, es war nützlich für Sie, um zu verstehen, wie groß diese Welt ist, oder? Jetzt haben Sie eine gute Vorstellung von der Sicherheit der Software-Lieferkette und den Kontrollen in jeder Phase und von den Missverständnissen, die die Leute haben, so dass es sich bei diesem Produkt um ein Produkt handelt , das Sie kaufen, oder dass es sich um eine Zertifizierung handelt, die Sie erhalten Jetzt, wo Sie in einem guten Zustand sind, können wir jetzt sagen, dass Sie vielleicht denken: Okay, es gibt so viele Kontrollen Wie implementiere ich das eigentlich? Wo fange ich an, fange ich mit dem SBM an? Beginne ich mit Secure Code? Beginne ich mit Abhängigkeiten? Was muss ich tun? Darüber werden wir also in der nächsten Lektion sprechen , in der wir über den Aufbau eines Software-Supply-Chain-, Sicherheits- und Risikoprogramms sprechen werden. Wenn Sie zum Beispiel damit beginnen, dies in Ihrem Unternehmen zu tun, wo Sie anfangen sollen und wo all diese verschiedenen Komponenten ins Spiel kommen werden. Okay? Also ich hoffe, das war nützlich für dich. Wir sehen uns in der nächsten Lektion. Ich danke dir. 14. Fazit: Hallo, hallo, alle zusammen. Willkommen. Willkommen zur letzten Lektion. Und das ist gerade zu Ende. Danke. Danke, dass du mir zugehört für Gott weiß wie lange geredet hast. Aber ich hoffe, Sie haben ein gutes Verständnis für die Sicherheit der Software-Lieferkette. Ich hoffe, Sie haben jetzt einen ganzheitlichen Überblick und denken nicht nur darüber nach, ein Produkt zu kaufen oder einfach MFA oder etwas Ähnliches einzuschalten Ich hoffe, ich habe Ihr Wissen über neue Arten von Angriffen erweitert über neue Arten von Angriffen Denken Sie also daran, es ist eine fortwährende Reise. Folgen Sie den besten Praktiken und Trends der Branche , die es gibt, und beginnen Sie. Ich kann nicht, bitte gehören Sie nicht Leuten, die diese Lektion einfach nehmen zu den Leuten, die diese Lektion einfach nehmen und sie dann in der nächsten Woche vergessen. Okay, fangen Sie an, nehmen Sie einige der Lektionen, von denen ich Ihnen erzählt habe , und fangen Sie an, sie in Ihrem Unternehmen umzusetzen. Schauen Sie sich die erstellten Repos und die Paket-Repos an und beginnen Sie, die Paket-Repos an und sie schrittweise zu implementieren Aber das ist so ziemlich, dass wir den Kurs beendet haben. Ich hoffe, es hat dir Spaß gemacht, mir so viele Stunden Babylon zuzuhören mir so viele Stunden Babylon Vielen Dank, dass du dich mit mir abgefunden hast. Denken Sie daran, dass ich Ihnen am Anfang ein Projekt gegeben habe. Sie können dies nutzen und Ihre eigene Software-Lieferkette gegen das Risiko, über das wir gesprochen haben, abwägen und es teilen. Und werfen Sie einen Blick darauf, wie Sie sich befinden wo Sie stehen, in Ihrer Lieferkette, was die Risiken sind und wie Sie sie mindern können, und dokumentieren Sie sie, damit Sie sich ein besseres Bild machen können Denn wenn Sie dieses Wissen nicht anwenden, kann ich garantieren, dass Sie es vergessen werden Sie werden Ihre Zeit und Ihr Geld verschwendet haben, wenn Sie das Wissen, über das ich gesprochen habe, nicht anwenden . Das ist also so ziemlich alles. Bitte zögern Sie nicht , mich zu kontaktieren. Ich bin dort auf Substack, LinkedIn und habe auch einen kleinen YouTube-Kanal Ich verlinke alles in den Kommentaren. Es tut mir leid, innerhalb der Lektion können Sie darauf klicken und mich kontaktieren, und mich wenn Sie denken, dass dies eine gute Lektion war. Bitte hinterlassen Sie eine Nachricht, wenn Sie denken, dass dies der schlechteste Kurs ist, den Sie je besucht haben, lassen Sie es mich bitte auch wissen. sich überhaupt keine Sorgen. Ich freue mich über Feedback. Also vielen Dank. Damit ist dieser Kurs abgeschlossen. Ich hoffe, Sie hatten eine gute Zeit und wir sehen uns im nächsten Kurs, den ich unterrichte Vielen Dank und auf Wiedersehen.