In der Cybersicherheitsbranche hat es in letzter Zeit einige sehr begrüßenswerte Entwicklungen gegeben. Es scheint, dass sich die Stimmung in vielen Unternehmen dahingehend verbessert, dass der Sicherheit bei der Softwareentwicklung so früh wie möglich Priorität eingeräumt wird. In Verbindung mit offiziellen Maßnahmen wie Bidens Executive Order zur Cybersicherheit hat dies überdeutlich gemacht, dass jeder seinen Teil zur Gewährleistung der Software- und Datensicherheit beitragen muss. Besonders aufregend ist, dass sich die Diskussion über die Rolle des Entwicklers bei der Aufrechterhaltung sicherer Codierungsstandards weiterentwickelt, sogar auf Regierungsebene.

Es gibt jedoch etwas, das in diesem Gespräch fehlt. Die Executive Order legt nahe, dass Entwickler überprüfte Sicherheitskompetenzen benötigen, doch gibt es derzeit keine solche offizielle Zertifizierung. Viele Unternehmen orientieren sich in ihrem Streben nach Konformität und höheren Standards für die Softwaresicherheit nach wie vor am NIST (das als Reaktion auf die EO aktualisierte Richtlinien vorgelegt hat). Wenn wir jedoch an Strategien denken, mit denen sich Schwachstellen deutlich reduzieren lassen, während gleichzeitig die richtigen Tools eingesetzt und die Geschwindigkeit der Veröffentlichung beibehalten wird, sind die meisten einfach zu allgemein, um das gewünschte Ergebnis zu erzielen. An diesem Punkt scheitern viele Unternehmen, da sie auf einer eingeschränkten Entwicklerschulung beharren oder nicht auf allgemeinen Grundlagen aufbauen, um ihnen praktische, praxisnahe Fähigkeiten zu vermitteln.

Sicherheitsbewusste Entwickler wachsen nicht auf Bäumen, aber sie können mit den richtigen Werkzeugen viel schneller gefördert und weiterentwickelt werden. Zu diesem Zweck freuen wir uns, unseren eigenen Kurs für die NIST-Konformität anzukündigen, der nach den Richtlinien der Executive Order der US-Regierung strukturiert ist.

Sinnvolle Unterstützung auf Code-Ebene für Entwickler

Auf der Grundlage der NIST-Richtlinien für EO-kritische Software haben wir den Kurs so strukturiert, dass die fünf wichtigsten Ziele erreicht werden, die letztlich die Sicherheit wichtiger Software verbessern, die auf höchster Regierungsebene eingesetzt wird, und die im Idealfall als Maßstab für eine qualitativ hochwertige Entwicklung von Grund auf dienen sollten.

Damit sich eine Entwicklungsgruppe wirklich durchsetzen kann, muss jede Weiterbildung über die Theorie hinausgehen und so umgesetzt werden, dass nicht ständig zwischen Arbeit und Schulung hin- und hergewechselt werden muss, um Antworten zu finden und agil zu bleiben. Sorgfältige Sicherheitspraktiken (ganz zu schweigen vom Sicherheitsteam) werden als Hindernis für termingerechte Entwicklungssprints angesehen und schränken den Stil des durchschnittlichen, auf Funktionen fokussierten Ingenieurs erheblich ein. 

Kurze Mikro-Lerneinheiten, die auf die Bedürfnisse von Entwicklern zugeschnitten sind, werden weit weniger frostig aufgenommen und führen zu einem einprägsamen, praktischen Kompetenzerwerb. 

Schauen Sie sich an, wie wir dies für unseren NIST-Kurs strukturiert haben:

Ziel 1: Schutz von EO-kritischer Software und EO-kritischen Softwareplattformen vor unbefugtem Zugriff und unbefugter Nutzung.

Falsche Sicherheitskonfigurationen und unsachgemäße Authentifizierungsverfahren werden von Angreifern genutzt, um erfolgreich in Systeme einzudringen, Konten zu übernehmen und Daten zu stehlen. Sie sind ein weit verbreiteter Fehler, der bei erfolgreicher Ausnutzung zu großen Problemen führen kann.

Auf der Website Secure Code Warrior Learning Platformkönnen Entwickler Herausforderungen spielen, die auf realen Codeschnipseln basieren, die genau widerspiegeln, wie diese Fehler in ihrer täglichen Arbeit auftreten würden, und sie dazu bringen, eine genaue Lösung zu finden, um sie zu sichern. Für DevOps-Ingenieure erfordert die Sicherung der Infrastruktur eine sorgfältige Konfiguration der Zugriffskontrolle, und es gibt spezielle Herausforderungen, um diese Anforderung in Infrastructure as Code (IaC)-Sprachen wie Terraform, CloudFormation und Ansible sowie in dem in Docker und Kubernetes verwendeten Code zu erfüllen.

Ziel 2: Schutz der Vertraulichkeit, Integrität und Verfügbarkeit von Daten, die von EO-kritischer Software und EO-kritischen Softwareplattformen verwendet werden.

Für dieses Ziel führen alle Wege zur Zugriffskontrolle. Eine fehlerhafte Zugriffskontrolle hat kürzlich Injektionsfehler als Spitzenreiter der OWASP Top 10 2021 entthront, und es handelt sich um einen schwerwiegenden Fehler, der die Fähigkeiten sicherheitsbewusster Entwickler erfordert, um ihn so früh wie möglich zu finden und zu beheben.

Der Kurs befasst sich mit Konzepten wie den geringsten Rechten auf Code-Ebene und hilft dabei, den Zugriff auf Benutzerkonten auf die notwendigen Bereiche zu beschränken.

Ziel 3: Identifizierung und Pflege von EO-kritischen Softwareplattformen und der auf diesen Plattformen eingesetzten Software, um die EO-kritische Software vor Ausbeutung zu schützen.

Eine der größten Herausforderungen in großen Unternehmen ist die Aufrechterhaltung der Sicherheitsaufsicht über all die verschiedenen Software, Systeme und Komponenten, die derzeit im Einsatz sind. Wenn es um Risikomanagement und Patching geht, müssen diese Elemente in jedem Sicherheitsprogramm Priorität haben, wobei die Entwickler bei der Sicherheitswartung in höchster Alarmbereitschaft sein müssen. 

Auf der Website Secure Code Warrior Learning Platform können Entwickler Herausforderungen spielen, die ihnen dabei helfen, verwundbare Komponenten zu identifizieren und zu beheben, sowie auf Berechtigungen basierende Sicherheitsfehlkonfigurationen.

Ziel 4: Rasche Erkennung von, Reaktion auf und Wiederherstellung nach Bedrohungen und Zwischenfällen, die EO-kritische Software und EO-kritische Softwareplattformen betreffen.

Es ist bedauerlich (und eine Zeit- und Geldverschwendung), dass sich viele Unternehmen bei der Behandlung von Cybersicherheitsproblemen immer noch auf die Reaktion auf Vorfälle konzentrieren - im Gegensatz zur Prävention. Das ist eine Kultur, die wir ändern wollen, und die Entwickler sind in der Lage, präventive Maßnahmen zu ergreifen, wenn sie in bewährten Sicherheitsverfahren geschult sind. 

Ziel 4 verlangt von den Entwicklern im Rahmen ihrer Rolle eine kontinuierliche Überwachung der Sicherheit in ihren Umgebungen und Endpunkten sowohl auf Software- als auch auf Netzwerkebene. Eine unzureichende Protokollierung und Überwachung ist ein weiterer häufiger, heimtückischer Fehler, und es ist von entscheidender Bedeutung, dass Ingenieure in der Lage sind, dies bei ihren täglichen Aufgaben erfolgreich zu bewältigen.

Auf der Website Secure Code Warrior Learning Platform können Entwickler Herausforderungen spielen, um diese Fähigkeiten zu verbessern, egal ob sie mit Web-, API- oder Cloud-Sprachen arbeiten.

Sicherheitsbewusstsein mit Nachhaltigkeit.

Ziel 5: Verbesserung des Verständnisses und der Leistung menschlicher Handlungen, die die Sicherheit von EO-kritischer Software und EO-kritischen Softwareplattformen fördern.

Dieses Ziel ist recht allgemein gehalten, aber es ist das wichtigste, das es zu erreichen gilt... und man kann es nicht erreichen, ohne die ersten vier Ziele zu meistern. Diese Leitlinie verlangt, dass häufige Aktivitäten zur Sensibilisierung für die Sicherheit durchgeführt werden und dass alle "menschlichen Handlungen" an EO-kritischer Software von Personen ausgeführt werden, die im Rahmen ihrer Aufgaben und Verantwortlichkeiten angemessen geschult sind.

Entwickler gehören zu denjenigen, die neben Sicherheitskonfigurationen und Zugangskontrolle am meisten mit Code zu tun haben. Ihre Sicherheitskompetenzen müssen gefördert werden, und um die hohen Standards des NIST zu erreichen, könnte eine praxisorientierte Kursstruktur genau der richtige Weg sein, insbesondere bei großen Entwicklungsgruppen. 

Fangen Sie noch heutean, die Erfahrungspunkte und den Sicherheits-IQ Ihres Entwicklungsteams zu erhöhen.

Dieser Artikel erschien ursprünglich in Sicherheits-Boulevard. Er wurde aktualisiert und hier syndiziert.

‍

Es ist in unserer kollektiven Psyche fast schon tief verwurzelt, dass mehr von einer guten Sache eine noch bessere Sache ist. Wenn man eines von etwas hat, das man wirklich mag, dann ist es nicht verkehrt, zwei oder drei oder sogar mehr zu haben. Schließlich kann man nicht zu viel von einer guten Sache haben, oder?

Leider funktioniert diese Logik zwar für einige Dinge, aber bei größeren Mengen bricht sie manchmal schnell zusammen. In manchen Fällen beginnt der Nutzen zu schwinden. Wie viel zusätzlichen Wert oder Freude wird Ihnen das 13. Stück Schokoladenkuchen wirklich bringen? Und dann gibt es andere Zeiten, in denen ein Zuviel des Guten zu einem erheblichen Risikoprofil für Sie oder Ihr Unternehmen werden kann.

Zu viele Tools für die Cybersicherheit

Ein kritischer Bereich, in dem zu viel des Guten schnell zum Schlechten wird, sind die Tools für die Cybersicherheit, die in den letzten Jahren in den meisten Unternehmen außer Kontrolle geraten sind. Eine Studie in Dark Reading ergab, dass sich die meisten Chief Information Security Officers auf durchschnittlich 55 bis 75 verschiedene Sicherheitsprodukte oder -anwendungen verlassen, um ihre Netzwerke zu schützen. Und dennoch kommen die Angriffe immer noch durch. Laut dem Verizon 2023 Data Breach Investigations Report sind erfolgreiche Angriffe auf dem Vormarsch, und es dauert länger als je zuvor, die komplexesten von ihnen zu entdecken.

Wie können Angreifer den scheinbar unüberwindbaren Spießrutenlauf von 75 oder mehr Cybersicherheitswerkzeugen umgehen? Tatsache ist, dass sie oft Alarme auslösen, aber die menschlichen Verteidiger sind zu sehr damit beschäftigt, ihre Verteidigungswerkzeuge zu warten oder auf Tausende von täglichen Warnungen zu reagieren, um dies zu bemerken. Eine Vielzahl von Sicherheitstools kann Angreifern die nötige Deckung bieten, um unentdeckt zu bleiben.

Ein kürzlich in TechRadar veröffentlichter Bericht hat die negativen Folgen einer zu großen Anzahl von Cybersicherheits-Tools aufgezeigt. Von den befragten Unternehmen waren 71 % der Meinung, dass sie mehr Tools besitzen, als ihre Cybersicherheitsteams jemals erfolgreich verwalten könnten. Dies führte sogar dazu, dass sich die Sicherheitslage verschlechterte, je mehr Tools hinzugefügt wurden. Entgegen der Annahme, dass mehr Tools gleichbedeutend mit mehr Sicherheit sind, gab die überwältigende Mehrheit der Befragten an, dass sie sich aufgrund der vielen in ihrer Umgebung installierten Cybersicherheits-Tools weniger sicher fühlen.

Die Situation hat sich mit der massiven Verlagerung in die Cloud bei den meisten Unternehmen nur noch verschlimmert. Einer der Gründe für die Beliebtheit des Einbaus zahlreicher Cybersicherheits-Tools in ein Netzwerk, um alle möglichen Angriffsmöglichkeiten abzudecken, war, dass diese Strategie in einer Zeit, in der fast alle Ressourcen vor Ort vorhanden waren, irgendwie funktionierte. Zumindest stießen die Unternehmen nicht so schnell auf abnehmende Erträge und negative Konsequenzen. In Cloud-Umgebungen jedoch entstehen mit der Anzahl der hinzugefügten Tools auch mehr Komplexität und Schwachstellen.

Neben der Arbeit, die mit der Wartung sich überschneidender Tools verbunden ist, besteht das andere große Problem bei einem toolzentrierten Ansatz in der Flut von Fehlalarmen, die mit Sicherheit auftreten werden, wenn mehr Tools online gehen. Die Verfolgung von Fehlalarmen kann dem Sicherheitspersonal viel Zeit rauben, ohne dass das Unternehmen davon wirklich profitiert. Und in der Zwischenzeit kann sich unter all den Fehlalarmen leicht ein echter Angriff verbergen. Cybersicherheitsexperten finden echte Bedrohungen möglicherweise erst, wenn es schon viel zu spät ist.

Ein besserer Weg

Es wäre katastrophal, alle Sicherheitstools aus Ihrer Umgebung zu entfernen. Aber Sie wollen auch nicht so viele haben, dass die wichtigsten Tools, die wirklich helfen könnten, nicht genug Aufmerksamkeit bekommen. Es ist wichtig, die richtige Auswahl an Tools zu treffen und dafür zu sorgen, dass nicht zu viele davon Ihre Zeit und Ressourcen in Anspruch nehmen.

Der Schlüssel zu einer funktionierenden Tool-Konsolidierung liegt in der gleichzeitigen Investition in einen von Menschen geführten Sicherheitsansatz. Dabei sollte auch eine Ressource genutzt werden, die traditionell nicht in dieser Rolle eingesetzt wird: Entwicklerteams, die genau die Anwendungen und Software programmieren, die von Angreifern ins Visier genommen werden.

Obwohl Entwickler traditionell nicht mit der Sicherheit betraut waren, ändert sich dies nun. Tatsächlich ist die Ermutigung von Entwicklern, sich auf die Sicherheit zu konzentrieren, ein wichtiger Aspekt der DevSecOps-Bewegung, bei der jeder eine gewisse Verantwortung für die Bereitstellung sicherer Anwendungen übernimmt. Niemand erwartet, dass Entwickler plötzlich zu Sicherheitsexperten werden oder die Hauptverantwortung für die Sicherheit in ihrem Unternehmen tragen, aber wenn man ihnen beibringt, wie man sicheren Code schreibt, und sie für eine gut gemachte Arbeit belohnt, kann man die Voraussetzungen für die Abschaffung all dieser sich überschneidenden Sicherheitstools schaffen.

Wenn man mit gutem, sicherem Code anfängt, kann man leicht damit beginnen, einige der Hunderte von Cybersicherheits-Tools zu eliminieren, die für die Suche nach gängigen Angriffen und Schwachstellen entwickelt wurden. Schließlich werden Sie eine Umgebung fördern, in der die Entwickler sicheren Code erstellen, und einige ausgewählte Cybersicherheits-Tools können als zusätzliche Kontrolle dienen, die für die Sicherheitsteams leicht zu überwachen und zu pflegen ist, ohne dass sie durch zu viel von einer vermeintlich guten Sache überlastet werden.

Cyberangriffe sind zweifelsohne auf dem Vormarsch. Laut dem Verizon 2021 Data Breach Investigations Report ist die Bedrohungslandschaft heute gefährlicher als je zuvor. Unternehmen aller Größenordnungen sehen sich mit einem höheren Volumen an Angriffen und einer höheren Raffinesse der Bedrohungsakteure konfrontiert, die es auf sie abgesehen haben. Und auch die Erfolgsquoten der Angreifer steigen rapide an.

Die Analyse der jüngsten Angriffe hilft dabei, einige der häufigsten Schwachstellen und Techniken aufzudecken, die von Hackern während dieses beispiellosen Angriffs auf die Cyberabwehr genutzt werden. Einige der beliebtesten Angriffe, die es in die Top 10 der Sicherheitsrisiken und Schwachstellen für 2021 des Open Web Application Security Project (OWASP) geschafft haben, beinhalten den Diebstahl oder die Kompromittierung von Anmeldedaten. Und laut einer von Akamai durchgeführten Sicherheitsstudie zielte die überwältigende Mehrheit, fast 75 %, direkt auf die von APIs gespeicherten Anmeldeinformationen ab.

Der Aufstieg und mögliche Untergang von APIs

Es ist kein Wunder, dass Anwendungsprogrammierschnittstellen, meist einfach APIs genannt, in den Netzwerken fast aller Unternehmen auf dem Vormarsch sind. Sie sind ein entscheidender Bestandteil der meisten Cloud-basierten Dienste, die in den meisten Unternehmen, Organisationen und Behörden die Funktionen von On-Premise-Ressourcen rasch übernehmen. Heutzutage ist fast kein Geschäft und keine Aufgabe mehr ohne die Cloud möglich, vor allem wenn es sich um öffentliche Dienste handelt. Und das bedeutet, dass APIs mit Sicherheit der Klebstoff sein werden, der eine ganze Reihe von Diensten in jedem Netzwerk zusammenhält.

Das Erstaunliche an APIs ist, dass sie meist klein und unauffällig sind, was die Zuweisung von Netzwerkressourcen angeht. Und sie sind völlig flexibel, so dass sie mit fast jeder Aufgabe betraut werden können. Im Kern sind APIs individuelle Softwareteile, die auf die Steuerung oder Verwaltung eines bestimmten Programms zugeschnitten sind. Sie können zur Ausführung sehr spezifischer Funktionen verwendet werden, z. B. für den Zugriff auf Daten von einem Host-Betriebssystem, einer Anwendung oder einem Dienst.

Leider ist es genau diese Flexibilität und die Tatsache, dass sie oft klein sind und von Sicherheitsteams übersehen werden, die APIs zu attraktiven Zielen machen. Die meisten APIs werden von den Entwicklern so konzipiert, dass sie völlig flexibel sind, damit sie beispielsweise auch dann noch funktionieren, wenn das Kernprogramm, das sie verwalten, modifiziert oder geändert wird. Und es gibt nur wenige Standards. Fast wie Schneeflocken sind viele APIs insofern einzigartig, als sie für eine bestimmte Funktion mit einem einzigen Programm in einem bestimmten Netzwerk erstellt werden. Wenn sie von Entwicklern programmiert werden, die nicht sehr sicherheitsbewusst sind oder sich nicht speziell auf die Sicherheit konzentrieren, können und werden sie wahrscheinlich jede Menge Schwachstellen aufweisen, die Angreifer finden und ausnutzen können.

Leider gerät das Problem immer mehr außer Kontrolle. Laut Gartner werden Schwachstellen, die APIs betreffen, bis 2022 der häufigste Angriffsvektor in allen Cybersicherheitskategorien sein.

Der Hauptgrund, warum Angreifer APIs kompromittieren wollen, ist nicht, dass sie eine bestimmte Funktion der API übernehmen können, sondern dass sie die damit verbundenen Anmeldedaten stehlen wollen. Eines der größten Probleme mit APIs ist nicht nur, dass sie voller Schwachstellen sind, sondern auch, dass sie in Bezug auf ihre Kernfunktionen oft viel zu viele Berechtigungen haben. Der Einfachheit halber kann man sagen, dass die meisten APIs in einem Netzwerk nahezu auf Administratorenebene zugänglich sind. Wenn ein Angreifer die Kontrolle über eine API erlangt, kann er deren Berechtigungen häufig nutzen, um tiefer und umfassender in ein Netzwerk einzudringen. Und da die API die Berechtigung hat, die Aufgaben auszuführen, auf die der Angreifer sie umleitet, können ihre Aktionen oft die herkömmliche Überwachung der Cybersicherheit umgehen, da die API dank ihres VIP-Backstage-Passes für den Zugang zu allen Bereichen keine Regeln bricht.

Wenn Unternehmen nicht aufpassen, kann die zunehmende Verbreitung von APIs in ihren Netzwerken und Clouds auch zu großen Problemen führen, wenn sie von Angreifern ins Visier genommen werden.

Verteidigung der APIs

So gefährlich die Situation mit APIs auch wird, sie ist keineswegs hoffnungslos. Durch Bewegungen wie DevSecOps werden große Anstrengungen unternommen, um das Sicherheitsbewusstsein der Entwickler zu schärfen und Sicherheit und bewährte Verfahren in alle Aspekte der Softwareerstellung - von der Entwicklung über das Testen bis zur Bereitstellung - einzubringen. Die Einbeziehung der API-Sicherheit als Teil dieser Schulung wird für jede Organisation, die dem Trend der API-Ausbeutung bis 2022 und darüber hinaus entgegenwirken möchte, von entscheidender Bedeutung sein.

Dennoch gibt es einige wirklich gute Best Practices, die im Hinblick auf die API-Sicherheit bereits jetzt implementiert werden können.

Der erste Punkt ist eine strenge Identitätskontrolle für alle APIs. Sie sollten sie bei der Zuweisung von Berechtigungen fast wie menschliche Benutzer betrachten. Nur weil eine API nur für eine bestimmte Funktion ausgelegt ist, müssen Sie darüber nachdenken, was passieren könnte, wenn ein Angreifer in der Lage ist, sie zu kompromittieren. Erwägen Sie die Verwendung einer rollenbasierten Zugriffskontrolle. Idealerweise sollten Sie letztendlich die Prinzipien des Nullvertrauens auf Ihre APIs und Benutzer anwenden, aber das ist oft ein langer Weg. Ein gutes Identitätsmanagement ist ein guter Anfang. Achten Sie nur darauf, dass Sie APIs als Teil dieses Programms einbeziehen.

Außerdem sollten Sie die verschiedenen Aufrufe, die von Ihren APIs getätigt werden, so weit wie möglich genau kontrollieren. Wenn Sie diese Aufrufe auf sehr kontextbezogene Anfragen beschränken, wird es für einen Angreifer viel schwieriger sein, sie für schändliche Zwecke zu verändern. Sie können Ihre APIs sogar schichten, wobei eine erste API einen sehr kontextbezogenen Aufruf an eine andere API macht, die genau weiß, wonach sie suchen und was sie ignorieren muss. Dies kann eine wirksame Methode sein, um die Funktionalität einzuschränken, die einem Angreifer zur Verfügung steht, selbst wenn er in der Lage ist, eine API innerhalb dieser Kette auszunutzen und zu kompromittieren.

Die Bedrohungen, die sich gegen APIs richten, können sicherlich überwältigend erscheinen. Aber durch die Implementierung von Best Practices und die Unterstützung und Belohnung von Entwicklern, die sich für die Sicherheit einsetzen, kann die Situation viel weniger hoffnungslos erscheinen. Mit guter Ausbildung und Praxis können Sie ein robustes Sicherheitsprogramm aufbauen, das Angreifern wenig Spielraum lässt, selbst wenn sie eines Ihrer kleinen, aber wichtigen API-Arbeitspferde kompromittieren sollten.

Wann haben Sie das letzte Mal einen Roadtrip gemacht? Je nachdem, wo auf der Welt Sie sich befinden, ist es vielleicht erst kürzlich wieder auf die Tagesordnung gekommen, aber es gibt wirklich nichts Schöneres als die offene Straße und einen Tapetenwechsel. 

Es sei denn, Sie sind eine Software-Schwachstelle, natürlich.

Wir haben ausführlich über die Gefahren gesprochen, die von laxen Cybersicherheitsmaßnahmen in der Automobilindustrie ausgehen. Unternehmen wie Tesla und Jeep arbeiten bereits mit Sicherheitsforschern zusammen und haben ausnutzbare Fehler gefunden, die zu ernsthaften Sicherheitsproblemen hätten führen können, wenn sie nicht frühzeitig entdeckt und behoben worden wären. Wir haben auch darüber gesprochen, dass sich die Softwaresicherheit im Allgemeinen noch im Wilden Westen befindet. Software ist allgegenwärtig, und für viele vernetzte Geräte, Fahrzeuge und deren Peripheriegeräte gehen die erforderlichen Sicherheitsmaßnahmen weit über die Aufklärung und Wachsamkeit der Endnutzer hinaus.

API-Schwachstellen werden besonders heimtückisch, da der bösartige API-Verkehr allein in den letzten sechs Monaten um mehr als 300 % zugenommen hat. Dies ist ziemlich besorgniserregend, da moderne Fahrzeuge im Wesentlichen APIs auf Rädern sind. Sie sind mit anderen Anwendungen verbunden und können als einer von vielen anfälligen Endpunkten in gezielte Angriffe verwickelt werden. 

Wenn Ihr EV-Ladegerät zu viel sagt

Vernetzte Fahrzeuge sind hinsichtlich ihrer Softwaresicherheit unter die Lupe genommen worden, aber was ist mit ihrem Zubehör? Das geniale Team von Pen Test Partners hat mehrere Schwachstellen auf Code-Ebene in sechs Marken für das Aufladen von Elektrofahrzeugen zu Hause sowie in einem weit verbreiteten öffentlichen EV-Ladenetz aufgedeckt.

Wer interessiert sich für ein Ladegerät? Was könnte ein Angreifer davon haben? Leider ist eine der Kehrseiten von leistungsstarker, tiefgreifender Technologie, die Überstunden für uns macht, dass diese Geräte im Allgemeinen einen schweren Fall von TMI haben. EV-Ladegeräte kommunizieren über eine API in einer cloudbasierten Umgebung mit den zugehörigen mobilen Anwendungen, und all das kann ausgenutzt werden, wenn es nicht sicher kodiert und konfiguriert ist. APIs sind so konzipiert, dass sie der Kommunikation zwischen Apps Tür und Tor öffnen, und wenn diese Endpunkte nicht sorgfältig konfiguriert sind, könnte zu viel geteilt werden - oder schlimmer noch - es könnte über eine anfällige App-Hintertür zugegriffen werden.

Pen Test Partners entdeckte extrem gefährliche Schwachstellen, die dazu hätten führen können, dass Millionen von Ladestationen gekapert worden wären, mehrere Fälle von API-Autorisierungsproblemen, die die Übernahme von Konten und die Fernsteuerung/den Fernzugriff auf ein Konto ermöglicht hätten, und sogar die Möglichkeit, das Stromnetz durch die synchronisierte Steuerung mehrerer Elektrogeräte zu unterbrechen. Diese Probleme wurden zwar alle behoben, aber die Tatsache, dass nur einige wenige Codezeilen zwischen den Angreifern und einer vollständigen Unterbrechung der Kernfunktionen und der Serviceinfrastruktur standen, ist äußerst besorgniserregend. 

Es ist auch nicht so, dass es sich um ein Superhirn handelt. Wallbox zum Beispiel hatte zwei unsichere direkte Objektreferenzen (IDOR) in ihrer API, die bei Ausnutzung eine Kontoübernahme ermöglicht hätten. IDOR fällt unter unsichere Authentifizierung, die auf Platz zwei der OWASP Top 10 API-Schwachstellen steht. Diese Schwachstelle ist weit verbreitet, was auf ein Versagen beim Erlernen und Implementieren von Qualitätscode hinweist. Wir können nicht weiterhin sensible Geräte und Anwendungen über eine Vielzahl fehlerhafter Kommunikationswege miteinander verbinden, und schlecht konfigurierte APIs sind genau das. 

Sicheres Arbeiten mit Automobil-APIs erfordert Ausbildung und Geduld

Das Frustrierende an der API-Sicherheit ist, dass sie als eine neue Welle von Cybersecurity-Katastrophen angepriesen wird, die es zu entschärfen gilt, obwohl sie in Wirklichkeit nur ein neuer Rahmen für die gleichen alten Probleme ist, die wir seit Jahrzehnten in der Webentwicklung beobachten. Cross-Site-Scripting, Injektion, Fehlkonfiguration: Kommt Ihnen das bekannt vor?

Jüngste Indikatoren von Organisationen wie NIST sind vielversprechend und zeigen, dass die Softwaresicherheit immer stärker reguliert und standardisiert wird. Allerdings verfügen wir immer noch nicht über die erforderlichen Experten, um die Flut von Code, die täglich geschrieben wird, auch nur annähernd zu schützen. Die Entwickler müssen in ihren Sicherheitskenntnissen und ihrer Verantwortung gestärkt werden, und es ist nicht an ihnen, die Initiative zu ergreifen. Wenn Sie ein Team haben, das an eingebetteten Systemen in Haushaltsgeräten oder an APIs arbeitet, die ein Auto in ein ferngesteuertes Spielzeug verwandeln könnten, dann müssen Sie sicherstellen, dass sie mit dem nötigen Wissen ausgestattet sind, um die Einführung allgemeiner Schwachstellen zu verhindern. 

Die Unterschiede zwischen einer sicheren API und einer durch XSS anfälligen API sind beispielsweise minimal, aber den Entwicklern müssen die Nuancen aufgezeigt werden, die ein schlechtes Codierungsmuster von einem guten unterscheiden. Hinzu kommt, dass faule Entwicklungsprozesse bei API-Konfigurationen oft zur Tagesordnung gehören, da viele von ihnen über die Mindestanforderungen hinausgehende Berechtigungen erhalten, um ihre Aufgaben zu erfüllen, was eine große zusätzliche Angriffsfläche und potenziellen Datendiebstahl eröffnet. Diese Faktoren müssen bei der Erstellung berücksichtigt werden, aber wenn sie nicht in akzeptablen Entwicklungspraktiken verankert sind, wird der Prozess auch weiterhin ein Risikofaktor sein.

Die neue Spielwiese der Bedrohungsakteure meiden

Die drastische Zunahme von APIs als Ziel von Bedrohungsakteuren zeigt, dass die Aufmerksamkeit auf eine vermeintlich niedrig hängende Frucht gerichtet ist... und in diesem Fall ist es eine, die eine Pipeline zu einer bedeutenden Beute sein könnte, zusätzlich zu den potenziellen Bedrohungen für das Leben in Form einer potenziellen Fahrzeugübernahme. 

Die API-Sicherheit dem Zufall zu überlassen, ist ein todsicherer Weg, um später Probleme zu verursachen, die schlimmstenfalls verheerende Folgen haben können und bestenfalls zu frustrierender Nacharbeit und geringer Leistung führen. Sie sollte als Teil des Kommunikations-Ökosystems von Software eine wichtige Rolle spielen und ganz oben auf der Liste eines erstklassigen Sicherheitsprogramms stehen. Der Schlüssel dazu ist, jede API wie einen Menschen zu behandeln und zu beurteilen, welchen Zugriff sie haben sollte. Sollte Jim aus der Buchhaltung Zugriff auf alle sensiblen Rechtsdokumente für das gesamte Unternehmen haben? Wahrscheinlich nicht, und im Allgemeinen wird die Zugriffskontrolle im Falle von echten Mitarbeitern korrekt festgelegt. Das Gleiche gilt für APIs, und es ist wichtig, daran zu denken, dass sie mächtige Plaudertaschen sind, die jedem Ihre Geheimnisse verraten, wenn sie nicht mit den gleichen Null-Vertrauens-Methoden wie alles andere konfiguriert werden.

Das Unternehmen muss in höchster Alarmbereitschaft sein, und die Entwickler sind die Augen, die vor Ort gebraucht werden, um Qualitätscode zu erstellen, der frei von diesen anfälligen Portalen der Verzweiflung ist. Es ist an der Zeit, ihnen die Möglichkeit zu geben, als sicherheitsbewusste Ingenieure zu wachsen und zu gedeihen, mit der richtigen Einstellung zu diesem Ziel und den praktischen Fähigkeiten, um in kritischen Phasen der Entwicklung die richtigen Entscheidungen zu treffen.

Eine Version dieses Artikels erschien als Beitrag für den Forbes Technologie-Rat. Er wurde aktualisiert und hier syndiziert.

‍

Es gibt nichts Schöneres, als auf der falschen Seite einer Datenschutzverletzung zu stehen. Zuerst gibt es vielleicht Leugnung, dann Panik. Nachdem alle Schimpfwörter ausgesprochen wurden und der CISO um 2 Uhr morgens eine Telefonkonferenz mit der Öffentlichkeitsarbeit abhalten musste, ist es an der Zeit, die Ärmel hochzukrempeln und sich an die Arbeit zu machen, um Endpunkte und Systeme zu sichern und potenzielle Angriffsvektoren schnell zu eliminieren. Das ist, gelinde gesagt, kein Zuckerschlecken. 

Und doch ist dies eine Realität, mit der viele Unternehmen in Zukunft konfrontiert werden und auf die sie sich unbedingt mit einem umfassenden Plan zur Reaktion auf Cyberangriffe vorbereiten müssen. Das Problem ist jedoch, dass ein Großteil der Zeit, der Ressourcen und des Aufwands in diese reaktive Strategie gesteckt wird, anstatt daran zu arbeiten, den potenziellen Schweregrad von Cyberangriffen im Vorfeld zu verhindern oder zu verringern. Es ist ein bisschen so, als würde man bei einem vermuteten Herzinfarkt einen Krankenwagen rufen; die Ergebnisse sind oft weit weniger positiv - ganz zu schweigen von mehr Schaden - als wenn man präventive Gesundheitsmaßnahmen ergriffen hätte, bevor es zu spät war. 

Wie sieht also ein Präventionsplan aus? Lassen Sie uns herausfinden, wie Sicherheitsexperten alle ihnen zur Verfügung stehenden Werkzeuge einsetzen können, um die ständig steigenden Cyberrisiken zu minimieren - jeden Tag:

Verstehen des Umfangs der anfallenden Arbeiten 

Es scheint offensichtlich zu sein, aber der "richtige" Plan zur Minderung von Cyber-Risiken ist von Branche zu Branche unterschiedlich, und es ist wichtig zu verstehen, was im Vorfeld erforderlich ist, um das gewünschte Ergebnis zu erreichen.

Welche Sicherheitsprobleme gibt es derzeit? Wie viel Zeit und Ressourcen nehmen sie in Anspruch? Wie viele davon sind wiederkehrende Probleme? Dies sind wichtige Faktoren, die Ihnen eine gute Ausgangsbasis bieten. Überlegen Sie, welche Rollen neu besetzt werden müssen, welche Lücken in den Werkzeugen bestehen und was aus der Sicht des Fachwissens und der Werkzeuge erforderlich ist, um die Endpunkte zu sichern und die Angriffsfläche zu verringern und gleichzeitig anderen Bereichen mit potenziellen Risiken vorzubeugen.

Ein kürzlich veröffentlichter Bericht zeigt, dass in elf Branchen im vergangenen Jahr jeden Tag eine schwerwiegende Sicherheitslücke in mindestens der Hälfte der Anwendungen auftrat. Insbesondere die Versorgungsunternehmen, die öffentliche Verwaltung und die freien Berufe benötigten im Durchschnitt 288 Tage, um bekannte Schwachstellen zu beheben. Das ist unglaublich langsam und gibt einem Angreifer mehr als genug Zeit, ernsthaften Schaden anzurichten, wenn diese Schwachstellen entdeckt werden, bevor ein Patch eingespielt werden kann. Dies und die Tatsache, dass die Wahrscheinlichkeit, dass ein Unternehmen von einer Datenpanne betroffen ist, bei fast 30 % liegt, ist eine ernüchternde Mahnung, dass es nicht ausreicht, auf einen Vorfall zu reagieren, und dass zu viel auf dem Spiel steht, um sich auf die Auswirkungen eines groß angelegten Cyberangriffs einzustellen und auf das Beste zu hoffen.

Vorbereitung auf die Akzeptanz des kulturellen Wandels

Das Aufrütteln des Status quo sorgt zwar für Kopfschütteln, aber die Wahrheit ist, dass Sicherheitsprogramme ständig verbessert werden sollten. Jede Komponente sollte relevant bleiben, und neue Entwicklungen sollten bewertet und berücksichtigt werden. 

Die Betonung eines präventiven - im Gegensatz zu einem reaktiven - Ansatz wird außerhalb des Sicherheitsteams möglicherweise nicht allgemein verstanden, vor allem, wenn noch kein großer, schlimmer Sicherheitsvorfall stattgefunden hat. Es könnte als etwas angesehen werden, das nicht kaputt ist und nicht repariert werden muss. In diesem Fall ist es von entscheidender Bedeutung, die Zustimmung der Führungskräfte zu erhalten. Einige der wichtigsten Punkte, die sie berücksichtigen sollten, sind:

• Zeit- und Kostenersparnis durch Präventivmaßnahmen, wie z. B. rollenbasierte Schulungen und entsprechende Tools, im Vergleich zu den potenziellen Kosten eines kritischen Zwischenfalls 
• Wie das Auffinden und Beheben von Schwachstellen jetzt dafür sorgt, dass die Veröffentlichungen pünktlich erfolgen und das Sicherheitsteam nicht mehr so viele Hindernisse in den Weg legt
• Warum die Vorbereitung auf und die Vorbeugung von potenziellen Sicherheitsrisiken, vom Entwicklungsteam bis hin zur Veröffentlichung, insgesamt mehr Zeit (ganz zu schweigen von erheblichem Geld) spart. Um es in die richtige Perspektive zu rücken: Späte Schwachstellen, die in der Testphase - oder schlimmer noch, nach der Produktion - aufgedeckt werden, können die Kosten im Durchschnitt um bis zu 3000 % erhöhen.
  

Es ist von entscheidender Bedeutung, dass die vorgeschlagenen kulturellen Veränderungen mit den Unternehmenszielen in Einklang gebracht werden, auch wenn sie zunächst unbequem erscheinen. 

Sicherheitsbewusstsein ist etwas, Sicherheitskompetenz ist alles

In der Branche wird häufig über die Bedeutung des Sicherheitsbewusstseins gesprochen, das für jeden Mitarbeiter in einem Unternehmen eine immer wichtigere Rolle spielt. Es reicht jedoch nicht aus, sich mit Lippenbekenntnissen und passiven Schulungen zu begnügen, vor allem nicht für Mitarbeiter in technischen Positionen.

Einfach ausgedrückt: Jeder, der mit Code in Berührung kommt, stellt ein potenzielles Sicherheitsrisiko dar, wenn er nicht über die nötigen Fähigkeiten für eine sichere Programmierung verfügt. Ein allgemeines Bewusstsein für grundlegende Sicherheitsparameter ist ein guter Anfang, aber ohne kontextbezogenes Wissen über gute, sichere Codierungsmuster herrschen schlechte Gewohnheiten vor, und es ist dieser Mangel an qualitativ hochwertigen Entwicklungsfähigkeiten, auf den sich Angreifer verlassen, um ihre schmutzige Arbeit zu erledigen. 

Schreiben Sie Ihre Entwickler nicht ab.

Obwohl sich die Einstellung ändert, sind viele Unternehmen so strukturiert, dass Entwickler in den Plänen zur Eindämmung der Sicherheitsrisiken kaum eine Rolle spielen. Einige Branchen - wie das Bank- und Finanzwesen - haben strenge Compliance- und Regulierungsanforderungen, die zu verstärkten Sicherheitspraktiken und Schulungen für alle Mitarbeiter führen. Und obwohl sie anderen Branchen sicherlich voraus sind, könnte fast jedes Unternehmen auf der Welt von einem internen Heer sicherheitsbewusster Entwickler profitieren, die in der Lage sind, gängige Sicherheitslücken zu erkennen, bevor sie begangen werden. Die meisten sind noch weit davon entfernt, dieses wichtige Teil des Sicherheitsprogramms zu erreichen - und es ist notwendig, wenn wir jemals die Hoffnung haben wollen, die Flut von Code zu sichern, die von Jahr zu Jahr ansteigt.

Vorbeugende Sicherheit sollte in dem Moment beginnen, in dem die Finger die Tastatur berühren, um Software zu erstellen. Sie brauchen die richtigen Werkzeuge und kontextbezogene Anleitungen, um einen höheren Standard der Codequalität zu erreichen. Die besten Ergebnisse werden immer dann erzielt, wenn dies Teil ihrer täglichen Arbeit ist und nicht ein nachträglicher Gedanke, der sporadisch eingeführt wird, wenn die jährlichen Compliance-Anforderungen kommen.

Eine Version dieses Artikels erschien in TechCrunch .. Er wurde aktualisiert und hier syndiziert.

‍

Als ob wir im Jahr ohne Namen nicht schon genug Störungen gehabt hätten, begann das Jahr 2021 für die US-Regierung mit einem ohrenbetäubenden Knall, und zwar in Form einer der schlimmsten Datenschutzverletzungen aller Zeiten. Der Vorfall bei SolarWinds war ein verheerender, ausgeklügelter Angriff eines nationalen Staates, der mehrere Regierungsbehörden und große Organisationen in Panik versetzte und sie dazu veranlasste, ihre Endpunkte zu sichern. Praktisch jeder Endnutzer der SolarWinds-Software wurde kompromittiert, und der Vorfall machte überdeutlich, wie wichtig Cybersicherheit und Schutz in Software-Lieferketten sind.

Es liegt auf der Hand, dass Cybersicherheit wichtig ist, aber was bedeutet sie eigentlich im Zusammenhang mit Lieferketten?

Der Stand der Cybersicherheit in einem durchschnittlichen Entwicklungsteam

Jeden Tag wird eine enorme Menge an Software erstellt, was Milliarden von Codezeilen pro Jahr entspricht, und diese Zahl steigt mit der Nachfrage, die durch unseren zunehmend digitalen Lebensstil entsteht, weiter an. Die Zahl der Entwickler weltweit wird bis 2024 auf fast 29 Millionen anschwellen, und derzeit gibt es keine formale Zertifizierung, die ihre Fähigkeit zur sicheren Programmierung bewertet und bescheinigt. Das soll nicht heißen, dass jeder Entwickler unsicheren Code produziert oder wiederverwendet, aber es besteht zweifellos ein anhaltendes Risiko, dass grundlegende Sicherheitsschwächen in die Software eingeschleust werden, der wir unsere Daten anvertrauen.

Entwickler werden danach beurteilt, ob sie in der Lage sind, Funktionen zu erstellen und Code so schnell wie möglich zu liefern. Sicherheit war in den meisten Unternehmen kein Maßstab für ihren Erfolg, aber das ändert sich allmählich, da immer mehr Unternehmen das Potenzial erkennen, das sie haben, um häufige Sicherheitsfehler in der frühesten Phase der Softwareentwicklung zu verhindern. Erkenntnis und Umsetzung sind jedoch zwei verschiedene Dinge, und da in den meisten tertiären Entwicklungsprogrammen courses jeglicher Kontext zu sicheren Kodierungspraktiken fehlt, liegt es oft am Arbeitsplatz des Entwicklers, das Defizit auszugleichen. Wenn der Aufbau von Fähigkeiten und die Weitergabe von Wissen selten oder irrelevant sind, dann wird dies wahrscheinlich unwirksam sein. Und so bleibt der Kreislauf der wiederkehrenden Schwachstellen aufgrund mangelnder Kompetenzentwicklung ungebrochen. 

Natürlich ist es nicht die Aufgabe des durchschnittlichen Softwareentwicklers, die Cybersecurity-Probleme der Welt zu lösen; schließlich stellen Unternehmen nicht ohne Grund diese sehr teuren Sicherheitsexperten ein. Sicherheitsgurus sind jedoch Mangelware, und Entwickler können sicherlich eine Rolle dabei spielen, die Belastung zu verringern. 

Doch was bedeutet das für uns - und für die Anbieter, die Software für kritische Infrastrukturen und sensible Organisationen entwickeln - im Hinblick auf die Verhinderung eines verheerenden Cyberangriffs? Es wird zumindest eine Änderung des Status quo bei der Softwarebeschaffung erforderlich sein.

Die Fallstricke, die einer sicheren Software-Lieferkette im Wege stehen

Das alte Sprichwort, dass eine Kette nur so stark ist wie ihr schwächstes Glied, trifft leider auch auf die Softwareversorgung zu. Es spielt wirklich keine Rolle, ob Ihr Unternehmen mit verstärkten Best Practices für die Sicherheit, Investitionen in die Weiterbildung von Entwicklern und dem Übergang zu einer funktionalen DevSecOps-Umgebung (d. h. jeder ist mitverantwortlich dafür, dass die Software so sicher wie möglich hergestellt wird) an den Start gegangen ist; wenn Sie Software von einem Anbieter verwenden, der Sicherheitsprobleme hat, werden Sie diese in Ihr Ökosystem übernehmen und die Konsequenzen tragen.

Sicherlich sollte das Sicherheitsteam dazu beitragen, die Sicherheit von Drittanbieter-Ergänzungen zum Tech-Stack zu bewerten, aber Entscheidungen können auf der Grundlage eines geschäftlichen Bedarfs getroffen werden, wobei die Auswahl an Lösungen gering ist. An diesem Punkt kann es sich um eine Vertrauensfrage handeln. Ist dem Anbieter die Sicherheit genauso wichtig wie Ihrem Unternehmen? Und kann der Anbieter die Risiken tatsächlich so einschätzen, wie nur Sie sie verstehen können, sowie die Werte, die Sie schützen müssen?

Transparenz ist ein wichtiger Faktor bei der Beurteilung der Sicherheit von Software-Ergänzungen des Anbieters. Sind die Anbieter offen mit ihren eigenen Sicherheitspraktiken umgegangen? Sie sollten stolz auf ihren Ansatz sein, Daten sicher zu halten, und dies sollte oberste Priorität haben. Wenn die Sicherheitspraktiken nirgendwo veröffentlicht werden oder keine Informationen verfügbar sind, ist die Wahrscheinlichkeit groß, dass die Sicherheit nicht im Vordergrund steht. Der Anbieter sollte in der Lage sein, technische Fragen zu beantworten, und unabhängige Zertifizierungen wie ISO27001 und SOC2 können ebenfalls nicht schaden. Wenn Sie nicht in der Lage sind, "unter die Haube" zu schauen und im Rahmen Ihrer eigenen internen Sorgfaltspflicht und Sicherheitspraktiken nach Schwachstellen zu suchen, sollten Sie die Sache vergessen.

Da die Nachfrage eine derartig schnelle Umsetzung von Softwareanforderungen vorantreibt, insbesondere wenn der Code des Anbieters in bestehende Systeme eingefügt wird, um Aktionen in einem neuen Kontext auszuführen, müssen sowohl der Anbieter als auch der Abnehmer auf der Höhe der Zeit sein, und beide sollten ihre Entwickler vor Ort haben, um häufige Sicherheitsfehler und Schwachstellen zu finden, bevor sie ausgeliefert werden. Es könnten Hunderte - oder Tausende - von Abhängigkeiten gefährdet sein, wenn ein neuer Zusatz zum bestehenden Spinnennetz der technischen Lösungen hinzugefügt wird, und ein kleiner Fehler könnte zu einem katastrophalen Untergang führen.

Was ist also die Lösung? Alles intern von Grund auf neu programmieren? Wenn wir uns im Jahr 1998 befänden, würde das vielleicht Sinn machen. Aber so wie wir heute nicht mehr "Jeeves" fragen, wo die nächste Autowaschanlage ist, müssen wir realistische Sicherheitsvorkehrungen treffen, die im heutigen Kontext funktionieren.

Es gibt immer noch kein Patentrezept, aber es gibt Lösungen

Für Käufer sollte die Sicherheit assessment der Anbietersoftware und der Entwicklungspraktiken eine Priorität des gesamten Sicherheitsprogramms und des Risikominderungsplans sein. Stellen Sie Fragen zu den Zertifizierungen, Praktiken und der Sicherheitsreputation der Entwickler.

Anbieter (und in der Tat alle Unternehmen, die Software entwickeln) müssen darauf vorbereitet sein zu zeigen, dass die Sicherheit an erster Stelle steht, und sollten sich auf die Weiterbildung von Mitarbeitern konzentrieren. Sicherheitskompetente Entwickler sind sehr gefragt, und mit den richtigen Werkzeugen und der richtigen Unterstützung können sie aus Ihrem bestehenden Team aufgebaut und in die Lage versetzt werden, Angriffe auf gängige Schwachstellen abzuwehren. Aber geben Sie ihnen nicht einfach irgendeine Schulung. Geben Sie ihnen Zeit, sich mit Sicherheitswerkzeugen zurechtzufinden, die ihre bestehenden Arbeitsabläufe ergänzen. Machen Sie es ihnen so einfach wie möglich, und beobachten Sie, wie sich die lästigen Bugs im Code, der das Unternehmen antreibt, langsam ausdünnen.

Die Quintessenz ist, dass jedes Softwarerisiko sich sofort verschlimmert, wenn es Teil der Lieferkette ist und alle Benutzer und alle Systeme betrifft, in denen anfällige Komponenten verwendet wurden. Wenn die Anbieter die Sicherheit nicht so ernst nehmen wie die Unternehmen, die ihre Software implementieren - oder wenn es sowohl dem Anbieter als auch dem Unternehmen an Sicherheitsprogrammen mangelt -, dann werden verheerende, weitreichende Angriffe auf die Lieferkette wie SolarWinds unweigerlich zur Norm werden - und das ist ein kritisches Problem für alle.

Auch wenn es für jemanden, der nicht in der Softwareentwicklung tätig ist, kontraintuitiv erscheinen mag, haben viele der Fachleute, die im Laufe der Jahre im Bereich der Anwendungssicherheit beschäftigt waren, in diesen kritischen Positionen mit wenig oder gar keiner Programmiererfahrung gearbeitet. Diese AppSec-Fachleute sind Teil des Teams, das dafür verantwortlich ist, dass sich keine Schwachstellen in die Anwendungen einschleichen, die zum Lebenselixier vieler Branchen und Unternehmen geworden sind, und dennoch können nur wenige von ihnen den Code selbst direkt bewerten oder beheben. 

Viele Sicherheitsexperten kommen nicht aus dem Bereich der Programmierung, sondern nähern sich ihren Aufgaben aus der Perspektive des Schlüsselwissens über Angriffsvektoren, Bedrohungen, Exploits und Geschäftsrisiken; sie haben eine begrenzte Sicht auf den Code. Zwar verfügt nicht jeder AppSec-Guru über die gleichen Fähigkeiten, aber ein typischer Arbeitstag für viele besteht darin, mit Code-Reviewern und Scanning-Tools zu arbeiten, um sicherzustellen, dass Programme und Systeme gemäß den Unternehmensstandards oder den relevanten Branchen- und Regierungsrahmen gesichert sind. Anschließend verfassen sie Berichte über ihre Ergebnisse und senden Informationen über den Angriffsvektor zurück, der den Code aufbrechen könnte. Es ist dann Sache der Entwickler, die notwendigen Korrekturen vorzunehmen, egal wie sehr dies die laufende Arbeit beeinträchtigt.

Der Grund dafür, dass sich die Situation so entwickelt hat, liegt darin, dass die vorherrschende Logik über die Jahre hinweg war, dass die Aufgabe des Schutzes von Netzwerken und Anwendungen so umfangreich ist, dass es nicht sinnvoll ist, von jedem, der im Bereich der Cybersicherheit arbeitet, zu erwarten, dass er alle Aufgaben erfüllt. Tiefgreifende Programmierkenntnisse wurden den Entwicklern überlassen, und es wurde wenig Wert auf die Fähigkeit gelegt, Code zu schreiben oder zu bearbeiten, der sich weiter unten in der Entwicklungspipeline befindet.

Diese Einstellung ändert sich schnell, und das bietet Entwicklern die einmalige Gelegenheit, den lukrativen Sprung und Karrieresprung in den Bereich AppSec zu wagen. Nicht jeder Entwickler wird sich auf die so genannte dunkle Seite begeben wollen, und viele Entwickler stehen AppSec-Teams nicht besonders positiv gegenüber. Aber für diejenigen, die es tun, gab es noch nie einen besseren Zeitpunkt, um nach dem immer verlockender werdenden Messingring zu greifen.

DevSecOps treibt fast jede Branche an

Einer der größten Faktoren, der den Wert sicherheitsbewusster Programmierer und Entwickler in jedem Unternehmen erhöht, ist der fast durchgängige Übergang zu agileren Entwicklungspraktiken wie DevSecOps. Wenn Entwicklung, Sicherheit und Betrieb kombiniert werden, wird Cybersicherheit zu einer gemeinsamen Verantwortung, die in die Entwicklung neuer Software von Anfang bis Ende integriert ist. In dieser Umgebung wird die Fähigkeit zu programmieren zunehmend als wertvolles Gut angesehen, und dies gilt insbesondere für Ingenieure, die von Natur aus auch etwas von Sicherheit verstehen.

Ein AppSec-Experte, der nicht nur die Cybersicherheit auf hohem Niveau versteht, sondern auch den Code, mit dem alles funktioniert, ist für jedes Unternehmen wertvoller als jemand, dessen Wissen sich auf die Theorie konzentriert. Die Fähigkeit, im Code gefundene Schwachstellen schnell zu entdecken und zu bewerten und diese Probleme dann zu entschärfen, ist der Kern dessen, warum DevSecOps so beliebt ist.

Entwickler, die im Bereich AppSec arbeiten, haben einen weiteren großen Vorteil für jedes Unternehmen, das sie beschäftigt. Da sie aus der Entwicklungsabteilung kommen, ist es für sie einfach, mit den Entwicklern über Sicherheit und Schwachstellen zu sprechen. Es ist auch viel einfacher, Coaches für die Entwicklungsteams zu werden und ihnen zu helfen, bessere Programmierer zu werden. Mit der Zeit können sie vielleicht sogar das Stigma der "dunklen Seite" von AppSec beseitigen und dazu beitragen, die Teams innerhalb der Softwareentwicklung in einem Unternehmen zu vereinen.

Der Fachkräftemangel im Bereich Cybersicherheit wird immer größer

Shakespeare meinte, dass es ein schlechter Wind ist, der niemandem etwas Gutes bläst. Was er damit meinte, war, dass selbst die düsterste Situation wahrscheinlich jemandem nützt. Der Fachkräftemangel im Bereich der Cybersicherheit ist ein gutes Beispiel dafür.

Der Personalmangel ist fast überall akut zu spüren. In einer kürzlich vom Center for Strategic and International Studies durchgeführten Umfrage gaben 82 % der IT-Entscheidungsträger an, dass ihre Unternehmen unter einem Mangel an Cybersicherheitskompetenzen leiden, und 71 % erklärten, dass der Mangel zu einem direkten und messbaren Schaden für ihre Unternehmen geführt hat. Um diese Krise in eine noch bessere Perspektive zu rücken, wies der Bericht darauf hin, dass allein in den Vereinigten Staaten im Jahr 2020 mehr als 520.000 Stellen im Bereich der Cybersicherheit unbesetzt sein werden, obwohl nur etwa 940.000 Menschen in diesem Bereich beschäftigt sind.

Der Personalmangel im Bereich der Cybersicherheit ist eine schlechte Nachricht für Unternehmen, die versuchen, ihre Infrastruktur, ihr Geschäft und ihre Daten vor einer zunehmend gefährlichen Bedrohungslandschaft zu schützen. Für Entwickler, die im Bereich AppSec und Sicherheit arbeiten möchten, ist dies jedoch eine gute Gelegenheit. Die Chancen stehen gut, dass Stellen im Bereich Cybersicherheit und AppSec fast überall verfügbar sind. Und da die Besetzung von Stellen im Bereich Cybersicherheit heutzutage durchschnittlich 21 % mehr Zeit in Anspruch nimmt, steigen die Gehälter auf breiter Front.

Der Sprung zu AppSec

Für Entwickler könnte es nie einen besseren Zeitpunkt geben, um den lukrativen Sprung auf die sonnige Sicherheitsseite des Lebens zu wagen. Sicherheitsbewusste Entwickler werden nicht mehr nur als Teil einer provisorischen Sicherheitsmethode gesehen, sondern füllen stattdessen eine vollwertige und respektierte Rolle als Verteidiger der Cybersicherheit aus. Dies gilt insbesondere für Unternehmen, die DevSecOps und andere agilere Entwicklungsmethoden eingeführt haben. Und der Mangel an Cybersecurity-Talenten bedeutet, dass Positionen in fast jedem Unternehmen, jeder Behörde oder Organisation verfügbar sind. Wer über die richtigen Fähigkeiten verfügt, kann sich aussuchen, wo er arbeiten möchte.

Der Umstieg auf AppSec ist vielleicht nicht für jeden geeignet, und natürlich werden sich die meisten Entwickler weiterhin auf die Entwicklung erstaunlicher Funktionen konzentrieren. Aber für diejenigen, die den Sprung in Erwägung ziehen, kann die Investition in eine Sicherheitsschulung, die ihre vorhandenen Programmierkenntnisse ergänzt, viele Türen öffnen. Die besten AppSec-Mitarbeiter kommen aus der Technik, weil sie ein tiefes Verständnis für die Technik und Einfühlungsvermögen für die Notlage ihrer Entwicklerkollegen haben. DevSecOps bedeutet, dass jetzt ohnehin jeder für die Sicherheit verantwortlich ist. Warum also nicht den aktuellen Mangel an kritischen Fähigkeiten nutzen, um Ihre Karriere in Richtung Anwendungssicherheit voranzutreiben? Es gab noch nie einen besseren Zeitpunkt, um einen positiven Schritt für sich selbst, Ihre Familie und Ihre Karriere zu machen.

In der Popkultur gibt es viele Anspielungen auf schurkische KI und Roboter sowie auf Geräte, die sich gegen ihre menschlichen Herren wenden. Es ist stark von Science-Fiction-Spaß und Fantasie durchdrungen, aber mit der zunehmenden Verbreitung von IoT und vernetzten Geräten in unseren Haushalten sollte auch das Gespräch über Cybersecurity und Sicherheit geführt werden. Software ist allgegenwärtig, und man vergisst leicht, wie sehr wir uns auf Codezeilen verlassen, um all die cleveren Dinge zu tun, die uns so viel Innovation und Komfort bieten. Ähnlich wie bei webbasierter Software, APIs und mobilen Geräten kann anfälliger Code in eingebetteten Systemen ausgenutzt werden, wenn er von einem Angreifer in freier Wildbahn entdeckt wird. 

Es ist zwar unwahrscheinlich, dass eine Armee von Mikrowellen kommt, um die Menschheit zu versklaven (obwohl der Tesla-Bot etwas beunruhigend ist), aber bösartige Cyberangriffe sind dennoch möglich. Einige unserer Autos, Flugzeuge und medizinischen Geräte sind auf komplizierte eingebettete Systemcodes angewiesen, um wichtige Aufgaben zu erfüllen, und die Aussicht, dass diese Objekte kompromittiert werden könnten, ist nicht nur alarmierend, sondern potenziell lebensbedrohlich.

Wie bei jeder anderen Software auch, gehören die Entwickler zu den ersten, die den Code gleich zu Beginn der Erstellungsphase anfassen. Und wie bei jeder anderen Software kann dies der Nährboden für heimtückische, allgemeine Schwachstellen sein, die unentdeckt bleiben könnten, bevor das Produkt in Betrieb geht. 

Entwickler sind keine Sicherheitsexperten, und kein Unternehmen sollte von ihnen erwarten, dass sie diese Rolle übernehmen, aber sie können mit einem weitaus stärkeren Arsenal ausgestattet werden, um die Art von Bedrohungen zu bekämpfen, die für sie relevant sind. Eingebettete Systeme, die in der Regel in C und C++ geschrieben sind, werden immer häufiger zum Einsatz kommen, da sich unsere technischen Anforderungen ständig weiterentwickeln, und eine spezielle Sicherheitsschulung der Entwickler für die Tools in dieser Umgebung ist unerlässlich. 

Explodierende Fritteusen, bösartige Fahrzeuge... Sind wir leichte Beute?

Es gibt zwar einige Standards und Vorschriften für die sichere Entwicklung, um uns zu schützen, aber wir müssen weitaus präzisere und sinnvollere Schritte in Richtung aller Arten von Softwaresicherheit unternehmen. Es mag weit hergeholt erscheinen, an ein Problem zu denken, das dadurch verursacht wird, dass sich jemand in eine Fritteuse hackt, aber es ist in Form eines Angriffs zur Remote-Code-Ausführung (der es dem Bedrohungsakteur ermöglicht, die Temperatur auf ein gefährliches Niveau zu erhöhen) bereits geschehen, ebenso wie Schwachstellen, die zu Fahrzeugübernahmen führen.

Vor allem Fahrzeuge sind besonders komplex, da sie mehrere eingebettete Systeme an Bord haben, die sich jeweils um Mikrofunktionen kümmern - von automatischen Scheibenwischern bis hin zu Motor- und Bremsfunktionen. In Verbindung mit einer ständig wachsenden Anzahl von Kommunikationstechnologien wie WLAN, Bluetooth und GPS stellt das vernetzte Fahrzeug eine komplexe digitale Infrastruktur dar, die zahlreichen Angriffsmöglichkeiten ausgesetzt ist. Und bei 76,3 Millionen vernetzten Fahrzeugen, die bis 2023 weltweit auf den Straßen unterwegs sein sollen, stellt dies einen Monolithen an Verteidigungsgrundlagen dar, die für echte Sicherheit gelegt werden müssen.

MISRA ist eine der wichtigsten Organisationen im Kampf gegen die Bedrohungen eingebetteter Systeme. Sie hat Richtlinien entwickelt, die die Codesicherheit, die Sicherheit, die Portabilität und die Zuverlässigkeit im Zusammenhang mit eingebetteten Systemen erleichtern. Diese Richtlinien sind der Nordstern unter den Standards, die jedes Unternehmen bei seinen Projekten für eingebettete Systeme anstreben muss.

Um jedoch Code zu erstellen und auszuführen, der diesem Goldstandard entspricht, sind Ingenieure für eingebettete Systeme erforderlich, die mit den Werkzeugen vertraut sind - ganz zu schweigen vom Sicherheitsbewusstsein -. 

Warum ist die Weiterbildung im Bereich der Sicherheit eingebetteter Systeme so spezifisch?

Die Programmiersprachen C und C++ sind nach heutigen Maßstäben betagt, werden aber nach wie vor häufig verwendet. Sie bilden den funktionierenden Kern der Codebasis für eingebettete Systeme, und Embedded C/C++ genießt ein glänzendes, modernes Leben als Teil der Welt der vernetzten Geräte.

Obwohl diese Sprachen recht alte Wurzeln haben - und ein ähnliches Verhalten gegenüber Schwachstellen in Bezug auf häufige Probleme wie Injektionsfehler und Pufferüberläufe aufweisen - müssen Entwickler, um wirklich erfolgreich Sicherheitslücken in eingebetteten Systemen zu entschärfen, praktische Erfahrungen mit Code sammeln, der die Umgebungen nachahmt, in denen sie arbeiten. Eine generische C-Schulung in allgemeinen Sicherheitspraktiken ist einfach nicht so wirkungsvoll und einprägsam, wie wenn zusätzliche Zeit und Sorgfalt in die Arbeit in einem Embedded C-Kontext investiert wird.

Da ein modernes Fahrzeug zwischen einem Dutzend und mehr als hundert eingebettete Systeme enthält, ist es unerlässlich, dass die Entwickler genau wissen, worauf sie achten müssen und wie sie die Probleme beheben können, und zwar direkt in der IDE.

Der Schutz eingebetteter Systeme von Grund auf liegt in der Verantwortung aller

Der Status quo in vielen Unternehmen ist, dass die Entwicklungsgeschwindigkeit die Sicherheit übertrumpft, zumindest wenn es um die Verantwortung der Entwickler geht. Sie werden selten nach ihrer Fähigkeit beurteilt, sicheren Code zu produzieren, aber die schnelle Entwicklung toller Funktionen ist der goldene Standard. Die Nachfrage nach Software wird nur noch steigen, aber diese Kultur hat uns auf einen aussichtslosen Kampf gegen Schwachstellen und die daraus resultierenden Cyberangriffe eingestellt. 

Wenn Entwickler nicht geschult sind, ist das nicht ihre Schuld, und es ist eine Lücke, die jemand im AppSec-Team füllen helfen muss, indem er die richtigen, zugänglichen (ganz zu schweigen von bewertbaren) Weiterbildungsprogramme für die gesamte Entwicklergemeinschaft empfiehlt. Gleich zu Beginn eines Softwareentwicklungsprojekts muss das Thema Sicherheit ganz oben auf der Agenda stehen, und jeder - vor allem die Entwickler - muss das bekommen, was er braucht, um seine Rolle zu spielen. 

Praktische Erfahrungen mit Sicherheitsproblemen bei eingebetteten Systemen

Pufferüberläufe, Injektionsfehler und Fehler in der Geschäftslogik sind häufige Fallstricke bei der Entwicklung eingebetteter Systeme. Wenn sie tief in einem Labyrinth von Mikrocontrollern in einem einzigen Fahrzeug oder Gerät verborgen sind, kann dies aus der Sicherheitsperspektive eine Katastrophe bedeuten.

Pufferüberlauf ist besonders häufig, und wenn Sie einen tiefen Einblick in die Kompromittierung der Fritteuse, über die wir zuvor gesprochen haben, erhalten möchten (und die Remotecodeausführung ermöglicht), lesen Sie diesen Bericht über CVE-2020-28592.

Jetzt ist es an der Zeit, sich mit einer Pufferüberlaufschwachstelle in echtem eingebettetem C/C++-Code auseinanderzusetzen. Spielen Sie diese Herausforderung, um zu sehen, ob Sie die schlechten Codierungsmuster, die zu diesem heimtückischen Fehler führen, lokalisieren, identifizieren und beheben können:

Wie haben Sie abgeschnitten? Besuchen Sie www.securecodewarrior.com für präzise und effektive Schulungen zur Sicherheit eingebetteter Systeme.

Als Experte für Anwendungssicherheit ist es Ihre Aufgabe, die Cybersicherheit der Anwendungen Ihres Unternehmens zu gewährleisten. Sie sind jedoch nicht für das Schreiben des Codes verantwortlich, auf dem die Anwendung läuft. Das sind die Ingenieure im Entwicklungsteam. Wie können Sie also sicherstellen, dass sie diese Systeme unter Berücksichtigung der Sicherheit entwickeln? 

Höchstwahrscheinlich tun Sie einige oder sogar alle der folgenden Dinge: 

• Überprüfung des gesamten Codes auf Sicherheitsmängel und Rückmeldung an das Entwicklungsteam zur Behebung dieser Mängel. 
• Durchsetzung eines strengen Peer-Review-Prozesses während des gesamten Lebenszyklus Ihrer sicheren Entwicklung. 
• Regelmäßige Durchführung von Anwendungs assessment/ Penetrationstests durch interne oder externe Sicherheitsteams.
• Implementierung von Scan-Tools zum Aufspüren von Schwachstellen.
  

Das sind tolle bewährte Verfahren, aber sie sind auch teuer und ähneln der Einnahme von Antibiotika bei jeder Krankheit. Das ist nicht nur mit hohen Kosten verbunden, sondern verliert auch an Wirksamkeit und kann mit der Zeit Ihr Immunsystem schwächen. 

Wie können Sie sicherstellen, dass der Code, den die Entwickler ausliefern, überhaupt sicher geschrieben ist? 

Abgesehen von der sicheren Kodierung sollten Sie zunächst einmal darüber nachdenken, wie Menschen lernen. Die meisten von uns sind visuelle Lerner und lernen durch Handeln. Und doch wird die Schulung für sicheren Code oft als eine "Abhak-Aktivität" angeboten und ist für die tägliche Arbeit eines Entwicklers nicht relevant. Sie dienen dazu, den Nachweis zu erbringen, dass die Entwickler an einer Sicherheitsschulung teilgenommen haben, die häufig den Industriestandards entspricht, und nicht dazu, dass die Entwickler das Wissen tatsächlich behalten, geschweige denn Spaß am Lernprozess haben. 

Eine andere Art und Weise, wie der Mensch lernt, ist die, dass er aus Fehlern lernt, so wie es auch unser Immunsystem tut. T-Zellen erinnern sich daran, welche Art von Krankheitserregern sie in der Vergangenheit angetroffen und erfolgreich ausgerottet haben, so dass sie sich in Zukunft vor ihnen schützen können. Dies ist genau die Rolle, die die Entwickler in Ihrem sicheren SDLC spielen sollten.

Es ist unrealistisch, von ihnen zu erwarten, dass sie keine Fehler machen, aber Sie können sie so vorbereiten, dass sie in der Lage sind, Codierungsmuster zu erkennen, die in der Zukunft zu Sicherheitslücken führen werden. 

Dies ist auch der Grund, warum ein robuster Peer-Review-Prozess so wirkungsvoll ist. Nur weil ein Entwickler eine Sicherheitslücke nicht bemerkt, heißt das nicht, dass ein anderer dies auch nicht tut. Und je besser das Entwicklungsteam als Ganzes geschult ist, desto wahrscheinlicher ist es, dass Schwachstellen aufgespürt werden und es nie in die Produktion schaffen. 

Software-Schwachstellen sind wie Krankheitserreger

Software-Schwachstellen sind wie Krankheitserreger in dem Sinne, dass man sich an sie erinnern muss, um sie bekämpfen zu können. Bei Krankheitserregern muss unser Immunsystem oft mehrmals mit ihnen konfrontiert werden, bevor es sich daran erinnert, wie es sie bekämpfen kann, um eine schwere Krankheit oder Schlimmeres zu vermeiden. 

Ein erfolgreicher Cyberangriff durch anfällige Software kann ein Unternehmen ernsthaft lähmen oder zerstören. Wenn Entwickler jedoch zunächst in einer kontrollierten Umgebung mit Software-Schwachstellen konfrontiert werden, können sie sich gegen diese Bedrohungen immunisieren, indem sie ihr Wissen und ihre Fähigkeiten im Bereich der sicheren Programmierung erweitern und regelmäßig üben. 

Entwickler in einer kontrollierten Umgebung mit Sicherheitslücken konfrontieren

Wir können uns nie ganz davor schützen, krank zu werden, aber wir können einiges tun, um unser Immunsystem zu stärken und so gesund wie möglich zu bleiben. Regelmäßige Bewegung, gesunde Ernährung und viel Schlaf gehören zu den Lebensgewohnheiten, die gemeinhin mit einem starken Immunsystem in Verbindung gebracht werden. Aber all diese Dinge erfordern ein wenig Anstrengung und müssen kontinuierlich durchgeführt werden. Wenn Sie eine Woche lang jeden Tag joggen gehen oder einen Monat lang auf Alkohol verzichten, wird sich das kaum auf Ihre allgemeine Gesundheit auswirken. Es ist auch nicht ratsam, am ersten Tag, an dem wir mit dem Laufen beginnen, gleich 10 km zu laufen. Wir müssen unser Herz und unsere Muskeln erst an die Bewegung gewöhnen. Wir wissen auch, dass wir ein wenig experimentieren müssen, bis wir ein gutes Gleichgewicht für unseren Körper und gesunde Lebensmittel und Übungen finden, die wir lieben.

Bei der sicheren Softwareentwicklung ist das nicht viel anders. Man lernt im Laufe der Zeit und mit der Praxis, und die Entwickler brauchen die gleiche fortlaufende Schulung, um ihre Fähigkeiten zur sicheren Programmierung regelmäßig zu verbessern. Ganz zu schweigen davon, dass sich die Softwareentwicklung ständig weiterentwickelt und anpasst, was bedeutet, dass sich auch die Schwachstellen ändern. Aus diesem Grund reicht ein einfacher Schulungskurs nicht aus. Die Entwickler müssen sich regelmäßig weiterbilden, um mit den potenziellen Bedrohungen vertraut zu sein und sich angemessen gegen sie zu schützen. 

Herdenimmunität innerhalb des Entwicklungsteams anstreben

Eine einzelne Person kann nicht alle Sicherheitsprobleme verhindern. Es ist großartig, Sicherheitsbeauftragte im Team zu haben, aber um den besten Schutz zu erhalten, hat Ihr Unternehmen umso bessere Chancen, je mehr Leute sich mit Sicherheitslücken und deren Vermeidung auskennen. Auch hier ist es nicht viel anders, als wenn das Immunsystem verschiedene Arten von T-Zellen für verschiedene Zwecke hat. Jeder einzelne Entwickler ist Teil eines Teams, das für Sicherheit sorgt. Wenn sie in die Lage versetzt werden, Verantwortung zu übernehmen, es gut zu machen und sogar Spaß daran zu haben, dann können Sie innerhalb des Entwicklungsteams eine Herdenimmunität gegen Cyber-Bedrohungen schaffen.

Sicherheit durch wiederholte Exposition in den Vordergrund rücken

Unser Gehirn lernt auf eine ähnliche Weise wie unser Immunsystem. Der deutsche Psychologe Hermann Ebbinghaus war ein Pionier auf dem Gebiet des Gedächtnisses und des Lernens. Er kam zu dem Schluss, dass Lernen im Laufe der Zeit und in mehreren Lernsitzungen erfolgen muss. In der Schule wird von uns nie erwartet, dass wir neues Wissen nach der ersten Einführung behalten. Zuerst werden uns die Informationen präsentiert, dann üben wir sie unter Anleitung, und dann üben wir sie selbständig. Und selbst wenn wir es gut genug gelernt haben, um eine Prüfung zu bestehen, werden die Informationen in der Regel nach kurzer Zeit wieder vergessen, wenn wir das Wissen, für das wir Zeit und Mühe aufgewendet haben, nicht regelmäßig anwenden. Wie viele von uns können von sich behaupten, dass sie sich an ihr Schulfranzösisch erinnern?

Wie können wir also glauben, dass ein einziger Tag, an dem wir uns Folien ansehen und jemandem zuhören, der über Sicherheit spricht, tatsächlich dazu führt, dass die anwesenden Entwickler sicherer programmieren?

Die immer wiederkehrenden Schwachstellen zeigen uns, dass dies einfach nicht funktioniert. 

Wie erreichen Sie eine sichere Entwicklungsimmunität?

Die Antwort liegt in unserer Natur. Unser Körper und unser Geist funktionieren auf die gleiche Weise und bieten wunderbare Lösungen für Probleme, solange wir mit ihnen und nicht gegen sie arbeiten. 

Um zu gewährleisten, dass Ihre Anwendungen sicher sind, müssen Sie zunächst die Entwickler darin schulen, sicheren Code zu schreiben. Andernfalls werden die AppSec-Mitarbeiter weiterhin ihre gesamte Zeit damit verbringen, den gesamten Code auf Sicherheitsmängel zu überprüfen und die immer gleichen Schwachstellen an die Entwickler zu melden, die dann schnell behoben werden, ohne dass sie etwas daraus lernen. Bei der nächsten Version wird das Ganze dann wieder von vorne losgehen.

Lassen Sie uns also noch einmal wiederholen.

Wenn Sie mit Ihren Entwicklungsmanagern zusammenarbeiten, um dies zu erreichen, implementieren Sie nicht nur einen sicheren SDLC und erfüllen die Anforderungen an Sicherheitsschulungen für die Einhaltung der Vorschriften, sondern Sie haben auch einen echten Einfluss auf den Entwicklungsprozess. Als Krönung des Ganzen wird AppSec nicht mehr auf wiederkehrende Schwachstellen stoßen und diese an die Entwicklungsteams zurückmelden, und die Entwickler werden weniger Zeit mit deren Behebung verbringen. Das bedeutet, dass sie mehr Zeit für die Entwicklung und Verbesserung der großartigen Software aufwenden können, die unsere Welt besser macht. 

Sind Sie bereit, Ihr Entwicklungsteam weiterzubilden? Dann buchen Sie jetzt eine Demo bei uns.