Auf Secure Code Warrior sind wir stets bestrebt, unser Schulungsangebot zu erweitern. Um Entwicklern und Sicherheitsverantwortlichen die Möglichkeit zu geben, sichere eingebettete Systeme zu entwickeln, haben wir uns in die Welt der Sicherheit eingebetteter Systeme eingearbeitet. In diesem Beitrag stellen wir die wichtigsten Dinge vor, die Entwickler und Architekten über die Entwicklung sicherer eingebetteter Systeme wissen sollten. 

Ein eingebettetes Gerät ist eine unabhängige Recheneinheit mit eigener mikroprozessorbasierter Hardware und Software. Sie werden in der Regel zur Ausführung spezieller Funktionen verwendet, entweder unabhängig oder als Teil größerer Systeme.

Was ist ein eingebettetes Gerät und System?

Eingebettete Geräte sind zweckgebundene Computersysteme mit minimalistischer Hardware und Software, die für die Ausführung bestimmter Funktionen programmiert sind. Je nach ihrem Zweck können eingebettete Geräte unterschiedlich komplex sein. 

Wenn ein eingebettetes System komplizierte, ressourcenintensive Operationen durchführen muss, kann seine Hardware aus mehreren Prozessoren mit verschiedenen miteinander verbundenen Peripheriegeräten bestehen. Wenn es jedoch für eine einfache Aufgabe konzipiert ist, kann es auch nur einen einzigen Mikrocontroller enthalten. 

Einige eingebettete Systeme sind Blackboxes ohne Benutzeroberfläche, während andere detaillierte grafische Benutzeroberflächen haben können.

Beispiele für eingebettete Geräte

Eingebettete Geräte finden in zahlreichen Branchen Anwendung, von der Luft- und Raumfahrt bis zur Computerbranche und von Haushaltsgeräten bis zum Gesundheitswesen. Hier sind ein paar Beispiele:

• Ein Thermostat in einem Klimagerät. 
• Ein Fitness-Tracker mit kleinen elektrischen Bauteilen, auf denen ein winziges Betriebssystem läuft, das nicht mehr kann als Ihre Gesundheitsdaten aufzuzeichnen und zu synchronisieren.
• Digitale Klimakontrollsysteme.
• Navigationssysteme in Flugzeugen.
• Digitale Uhren.
• GPS-Geräte.
• Wi-Fi-Komponenten in Mikrowellenherden und anderer Unterhaltungselektronik.
• Blutdruck- und Herzschlagmessgeräte.
• Vernetzungskomponente in einem MRT-Gerät, die Daten an die Cloud sendet.

Ist ein Laptop ein eingebettetes Gerät?

Kurze Antwort: Nein. Lange Antwort:

Per Definition umfasst ein eingebettetes Gerät die gesamte Software und Hardware, die es zur Ausführung seiner Funktionen benötigt. Ein Laptop verpackt in der Tat verschiedene Hardwarekomponenten in ein Metallgehäuse und umfasst die gesamte Software, die zur Bereitstellung seiner Funktionen erforderlich ist.

Im Gegensatz zu typischen eingebetteten Systemen, die einen vordefinierten, minimalen Funktionsumfang haben, ist ein Laptop jedoch universeller einsetzbar und kann für eine Vielzahl von Aktivitäten verwendet werden.

Eingebettete Geräte im Internet der Dinge

Eingebettete Systeme sind das Herzstück des IoT. Ihr intelligenter Kühlschrank kann dank eines eingebetteten Geräts über Ihr Mobilgerät gesteuert werden. Es ist ein eingebettetes Gerät in Ihrem Sicherheitssystem, mit dem Sie CCTV-Aufnahmen aus tausend Meilen Entfernung ansehen können. Und wenn Sie einen Knopf drücken, um Ihr Auto auf Autopilot zu stellen, ist es ein eingebettetes Gerät, das hinter den Kulissen die ganze Magie bewirkt.

Lebenszyklus der Entwicklung eingebetteter Software

Der typische Lebenszyklus der Softwareentwicklung eines eingebetteten Geräts umfasst die folgenden Schritte:

Schritt 1: Zweck und Anforderungen

Ein eingebettetes Gerät hat einen bestimmten und präzisen Funktionsumfang. Deshalb ist es sehr wichtig, seinen Zweck und seine Anforderungen vor Beginn der Entwicklung explizit zu formulieren. Es wird empfohlen, ein detailliertes Entwurfsdokument für das System zu erstellen. Beantworten Sie Fragen wie:

• Welche Funktionen wird das Gerät erfüllen?
• Wird sie ein Teil einer anderen Maschine sein, oder wird sie eigenständig funktionieren?
• Soll das Gerät über eine Benutzeroberfläche verfügen? Wenn ja, reicht eine Befehlszeile aus, oder ist eine grafische Benutzeroberfläche erforderlich?
• Welche Größen-, Kosten- oder Stromverbrauchsgrenzen muss das Gerät einhalten?
• Gibt es Leistungsmaßstäbe? Wird z. B. erwartet, dass das Gerät in Echtzeit oder innerhalb bestimmter Schwellenwerte reagiert?

Schritt 2: Systemarchitektur

Sobald wir die einzigartigen Systemanforderungen ermittelt haben, können wir die Systemarchitektur entwerfen. Beantworten Sie Fragen wie:

• Welche Hardwarekomponenten werden für die Entwicklung des Geräts benötigt? Dazu gehört die Identifizierung der Schaltkreise, Prozessorchips und Mikrocontroller sowie aller erforderlichen internen und externen Peripheriegeräte. 
• Wie viel Strom werden die Komponenten benötigen? 
• Wird das Gerät mit dem Internet verbunden sein?
• Welche Schnittstellen müssen hinzugefügt/entwickelt werden, damit das Gerät mit anderen Geräten oder der größeren Maschine verbunden werden kann?
• Wie werden Sie die Verschlüsselung umsetzen? (denken Sie an Algorithmen, Schlüsselspeicherung usw.)
• Wie werden Sie potenzielle Schwachstellen, Sicherheitslücken und Malware erkennen und vermeiden?

Schritt 3: Auswahl des Betriebssystems

Die Wahl des Betriebssystems entscheidet oft über die Effizienz Ihrer eingebetteten Anwendungen, also wählen Sie mit Bedacht. Windows für IoT kann bei der Grafik punkten, bietet aber keine Hardware-Unterstützung. Embedded Linux und Android sind kostenlos, während für VxWorks und Windows für IoT Lizenzkosten anfallen. 

Bei Open-Source-Systemen wie Linux und Android haben die Entwickler mehr Kontrolle über den Kernel; bei proprietären Systemen hingegen können Sie nur mit den Standardfunktionen des Kernels arbeiten. 

Es ist auch wichtig, bei der Auswahl eines Betriebssystems die Sicherheitsaspekte zu berücksichtigen. Werden Sicherheits-Patches schnell veröffentlicht, falls Sicherheitslücken entdeckt werden? Gibt es einen eingebauten Schutz gegen die häufigsten Angriffe auf die Cybersicherheit?

Schritt 4: Die Entwicklungswerkzeuge

Verschiedene Programmiersprachen und Frameworks haben verschiedene Vor- und Nachteile. Je nach Ihren Anforderungen an Funktionen, Geschwindigkeit und Zuverlässigkeit können Sie eine Sprache/ein Framework der anderen vorziehen. 

Wenn Ihre Anwendung webbasiert ist und Sie eine hohe Leistung wünschen, wählen Sie Java.
Wenn Sie jedoch den schnellsten Durchsatz wünschen, wählen Sie C/C++. Wenn Sie die beste Unterstützung für Bibliotheken von Drittanbietern wünschen, sollten Sie sich für Python entscheiden.

Schritt 5: Programmieren, überarbeiten, testen, weiterprogrammieren

Sobald Sie sich für eine Entwicklungsplattform entschieden haben, können Sie mit dem Programmieren beginnen. Denken Sie daran, dass eingebettete Systeme empfindliche Geräte mit begrenzten Hardware- und Softwareressourcen sind. Daher ist es von entscheidender Bedeutung, die besten Praktiken in Bezug auf Anwendungssicherheit und Leistung zu beachten.

Code-Reviews helfen bei der Optimierung des Codes und bei der Identifizierung potenzieller Bugs. Außerdem müssen Sie so rigoros wie möglich testen. Stellen Sie sicher, dass Sie eine erschöpfende Liste aller Testfälle zusammenstellen, auf die das Gerät beim Einsatz in der Produktion stoßen könnte.

Schritt 6: Wartung und Unterstützung

Wie bei jeder anderen Anwendung/jedem anderen Gerät endet der Lebenszyklus nicht, wenn das eingebettete Gerät ausgeliefert und installiert wurde. Während das Gerät in der Produktion eingesetzt wird, werden neue Anwendungsfälle identifiziert, die das Hinzufügen neuer Funktionen erfordern. Gemeldete Fehler können auch die Veröffentlichung neuer Firmware-Updates erforderlich machen.

Die wichtigsten eingebetteten Programmiersprachen

Es gibt viele seriöse Organisationen wie IEEE und TIOBE, die eine Rangliste der Programmiersprachen nach Beliebtheit und Verwendung erstellen. Unabhängig davon, ob Sie sich den TIOBE-Index oder das IEEE Spectrum ansehen, werden Sie jedoch ein gemeinsames Thema feststellen.

Die Top 3 Sprachen sind immer C, Python und Java. Im TIOBE-Index für Juli 2021 steht C auf Platz 1, Java auf Platz 2 und Python auf Platz 3. Laut IEEE Spectrum's Ranking für eingebettete Programmiersprachen lautet die Reihenfolge: Python, Java, und dann C.

Wie unterscheidet sich in Java, C oder Python geschriebene Firmware?

Verschiedene Sprachen verwalten den Speicher, die Interaktion mit dem Betriebssystem und die Laufzeit auf unterschiedliche Weise. Java-Anwendungen werden z. B. in einer speziellen Laufzeitumgebung ausgeführt, die als Java Virtual Machine (JVM) bekannt ist. 

Die Speicherverwaltung in C/C++ erfolgt manuell, während Sie sich in Java oder Python nicht selbst um die Speicherverwaltung kümmern müssen; die Sprache erledigt das für Sie. Hinzu kommt, dass Sie in C Ihren Müll selbst einsammeln müssen, d. h. wenn Sie einen Speicherbereich dynamisch zuweisen, müssen Sie ihn auch explizit wieder freigeben. Wenn Sie das nicht tun, führt das zu einem Speicherleck. In Java oder Python wird die Garbage Collection automatisch durchgeführt. Allerdings ist C von Natur aus viel schneller als Java oder Python.

Eine Sache, die C und Java (aber insbesondere C) im Vergleich zu Python fehlt, ist die Verfügbarkeit von Bibliotheken von Drittanbietern. Python verfügt über eine reichhaltigere Datenbank von Bibliotheken, die es Entwicklern viel einfacher macht, bestimmte Funktionen hinzuzufügen.

Insgesamt sollten Sie C wählen, wenn:

• Sie wollen eine Low-Level-Schnittstelle mit dem Betriebssystem und der Hardware.
• Sie wollen die bestmögliche Leistung.
• Ihre Entwickler sind in C/C++ bewandert.
• Sie brauchen nicht allzu viel Unterstützung von außen/von Dritten.

Verwenden Sie Python, wenn:

• Sie möchten datenwissenschaftliche oder maschinelle Lernalgorithmen implementieren.
• Sie möchten umfangreiche Unterstützung für Bibliotheken von Drittanbietern.
• Sie sind damit einverstanden, Geschwindigkeit gegen Benutzerfreundlichkeit einzutauschen.
• Sie haben nur begrenzte Erfahrung in der Embedded-Entwicklung.
• Sie brauchen keine Low-Level-Schnittstelle mit dem Betriebssystem oder der Hardware.

Verwenden Sie Java, wenn:

• Sie erstellen Webanwendungen.
• Sie wollen eine einfachere Entwicklung als in C, aber dennoch mehr Leistung als in Python.
• Sie brauchen nicht allzu viel Unterstützung von außen/von Dritten.

Wird C langsam aufhören, die erste Wahl für die Embedded-Entwicklung zu sein?

Hochsprachen erleichtern die Programmierung, indem sie die Komplexität, die sich in C einfach nicht vermeiden lässt, abstrahieren. Dennoch ist C trotz der Einführung neuer Sprachen und Frameworks seit Jahrzehnten die erste Wahl bei der Embedded-Entwicklung. 

Der Grund dafür ist, dass die Geschwindigkeit, Leistung und Zuverlässigkeit, die sie bietet, immer noch unerreicht sind. Die Tatsache, dass Python und große Teile des Java-Ökosystems (einschließlich der Laufzeitumgebung, der Sprache und des Compilers) in C geschrieben sind, spricht Bände über die Effizienz und Beständigkeit der Sprache.

Allerdings ist C für neue Entwickler, die die Einfachheit von Sprachen wie Python bevorzugen, unbestreitbar schwieriger zu erlernen. Dies führt zu einem spürbaren Rückgang der C-Entwicklergemeinde. Auch die zunehmende Entwicklung von KI- und ML-Anwendungen führt dazu, dass die Menschen Python gegenüber C bevorzugen, einfach weil es eine größere Bibliotheksunterstützung bietet.

Es ist wichtig, daran zu denken, dass Python erst seit kurzem Teil der Debatte um die wichtigste Programmiersprache für Embedded-Systeme ist. Ja, seine Akzeptanz wird in den kommenden Jahren weiter steigen, aber wir erwarten nicht, dass C jemals aufhören wird, die erste Wahl für die Embedded-Entwicklung zu sein.

Warum sichere Kodierung in C/C++ wichtig ist

Beim Schreiben von Code in C/C++ kann eine Menge schief gehen. Der Zugriff auf eine Speicheradresse, die nicht mehr auf gültige Daten verweist, oder die falsche gemeinsame Nutzung von Daten zwischen Threads kann zum Absturz Ihrer gesamten Anwendung führen. 

Bei eingebetteten Geräten sind diese Auswirkungen weitaus bedeutender, da ein Absturz in diesen Geräten dazu führen kann, dass eine viel größere Maschine nicht mehr funktioniert. Wenn z. B. das Autopilot-Modul in einem Auto ausfällt, kann das Auto Hindernissen nicht mehr ausweichen.

Hier sind weitere Gründe, warum die sichere Kodierung von C/C++-Anwendungen so wichtig ist:

• Unsichere Speicherbehandlung (Nullzeiger, Speicherverfälschung, Stapelüberläufe, Puffer- und Heap-Überläufe) führen zum Absturz der gesamten Anwendung.
• Zeiger sind ein fester Bestandteil von C und C++. Der Umgang mit ihnen erfordert äußerste Sorgfalt und tiefgreifende Kenntnisse der zugrunde liegenden Konzepte.
• Die Speicherbereinigung erfolgt manuell. Daher müssen Programmierer jeden dynamisch zugewiesenen Speicher explizit löschen. Nicht freigegebener oder nicht korrekt freigegebener Speicher kann zu Speicherlecks oder -beschädigung führen.
• Es fehlt an standardisierten APIs für fortgeschrittene Datenstrukturen (z. B. Hashtabellen, Mengen usw.), so dass die Entwickler gezwungen sind, das Rad neu zu erfinden.

Es ist absolut wichtig, dass Entwickler in der sicheren Programmierung von C/C++-Anwendungen geschult werden. Secure Code Warrior bietet eine personalisierte learning platform mit interaktiven Herausforderungen, courses und Bewertungen, die es Entwicklern ermöglichen, sicheren C/C++-Code zu schreiben. Hier geht es um sprachen- und rahmenspezifische Inhalte, nicht nur um eine Verbesserung der allgemeinen konzeptionellen Schulung.

Erfahren Sie, wie wir die Automobil- und Transportbranche unterstützen. Oder probieren Sie noch heute eine Embed-Focus-Coding-Challenge aus, um zu erfahren, wie wir Entwickler in die Lage versetzen, sichere Embedded-Anwendungen zu schreiben!

Auf Secure Code Warrior sind wir stets bestrebt, unser Schulungsangebot zu erweitern. Um Entwicklern und Sicherheitsverantwortlichen die Möglichkeit zu geben, sichere eingebettete Systeme zu entwickeln, befassen wir uns mit der Welt der Sicherheit eingebetteter Systeme. In diesem Beitrag werden wir über den MISRA C 2012-Standard sprechen und darüber, warum seine Einhaltung für die Entwicklung sicherer eingebetteter Systeme notwendig ist.

Beim Schreiben von Code in C ist es sehr einfach, Dinge zu implementieren, die scheinbar richtig aussehen, aber von Grund auf falsch sind. Ihr Code lässt sich vielleicht gut kompilieren und läuft sogar eine gewisse Zeit lang gut. Aber derselbe Code kann abstürzen oder ein undefiniertes Verhalten zeigen, wenn die Eingabegröße und/oder der Speicher wächst. So kann beispielsweise eine bestimmte Eingabezahl einen Überlauf einer Ganzzahl verursachen oder eine bestimmte Zeichenfolge ein Array aus dem Rahmen fallen lassen.

Hier kann der MISRA C-Codierungsstandard helfen. Die Regeln, Richtlinien und Best Practices des Standards ermöglichen es Entwicklern, sicheren und zuverlässigen C-Code für die Embedded-Entwicklung zu schreiben. 

MISRA C 2012, die neueste Version des Standards, fügt neue Regeln hinzu, verbessert die bestehenden und beseitigt einige Unstimmigkeiten. Wenn Sie noch eine ältere Version verwenden, wäre jetzt ein guter Zeitpunkt für einen Wechsel. 

Was ist der MISRA C-Codierungsstandard?

Der MISRA C-Standard enthält Richtlinien für Codesicherheit, Portabilität und Zuverlässigkeit für die Programmiersprache C. Der erste Satz von Richtlinien wurde 1998 veröffentlicht, der sich speziell auf die Sprache C bezog. 

Seitdem entwickelt das MISRA-Konsortium jedoch auch Codierungsstandards für C++. Jedes MISRA-C-Dokument enthält eine Reihe von Regeln, nicht konforme Beispiele und ausführliche Abschnitte über die Hintergrundinformationen, die zur Entwicklung dieser Regeln beigetragen haben.

C und C++ sind die am häufigsten verwendeten Sprachen für die Entwicklung eingebetteter Software. Einer der Hauptgründe dafür ist, dass sie schnell sind, da sie nur 1 oder 2 Abstraktionsebenen über der Maschinensprache haben. Das bedeutet aber auch, dass das Schreiben von sicherem Code, insbesondere in C, schwierig und fehleranfällig ist. In den meisten Hochsprachen wie Java und C# muss man sich zum Beispiel keine Gedanken über triviale Dinge wie Garbage Collection oder dynamische Typisierung machen. 

In C gibt es jedoch keine vordefinierte Möglichkeit, Speicherplatz zu sammeln, d. h. wenn Sie einen Speicherbereich für eine Datenstruktur zuweisen, müssen Sie ihn manuell freigeben, sobald Sie ihn nicht mehr benötigen. Wenn Sie das nicht tun, gibt C im Gegensatz zu anderen Sprachen den Speicher nicht frei, was zu einem Speicherleck führen würde.

MISRA C 2004 (C2) vs. MISRA C 2012 (C3) - Was hat sich geändert?

MISRA C: 2012, auch bekannt als C3, wurde erstmals im April 2013 veröffentlicht. Mit dem Wissen aus der Arbeit von Tausenden von Menschen und Organisationen fügt C3 neue Regeln hinzu, verbessert die Erläuterungen und Hintergründe einiger bestehender Regeln und schließt einige Schlupflöcher.

C3 unterstützt die C99-Version der Sprache, behält aber auch Regeln für die ältere ISO C90 bei. Das Hauptaugenmerk von C3 lag darauf, die üblichen Kosten für die Durchsetzung von Regeln zu senken und gleichzeitig die Verwendung der Sprache C in kritischen Systemen sicherer zu machen. Daher ist es ratsam, auf die neue Norm umzusteigen, falls Sie dies noch nicht getan haben.

Im Folgenden finden Sie eine Liste der wichtigsten Änderungen:

• Behebung von Problemen, die in der Version von 2004 gefunden wurden.
• Erhebliche Erhöhung der Anzahl der entscheidbaren Regeln. Eine Regel ist entscheidbar, wenn ein Analysewerkzeug dabei helfen kann, die Konformität mit ihr festzustellen.
• Regeln werden als "erforderlich", "beratend" oder "verbindlich" eingestuft. Obligatorische Regeln dürfen unter keinen Umständen gebrochen werden. Erforderliche und beratende Regeln können in besonderen Fällen verletzt werden, sofern die Verletzung gerechtfertigt ist.
• Es wurde eine Anleitung hinzugefügt, wie Regeln auf automatisch generierten Code anzuwenden sind. Dies ist sehr wichtig, da für von Menschen geschriebenen Code nicht immer dieselben Richtlinien gelten wie für den von einem Tool generierten Code.
• Beseitigung der übermäßig verallgemeinerten Regeln, die ein vernünftiges Benutzerverhalten verbieten. Früher wurde z.B. empfohlen, überhaupt keine Makros zu verwenden, da sie zu verschiedenen Schwierigkeiten und Verwirrungen führen können (Makros können nicht debuggt werden, Makros haben keine Namespaces usw.). Dies verhinderte die Verwendung von Makros, selbst in Situationen, in denen sie eine elegante, sichere und bequeme Lösung darstellen könnten. In MISRA C: 2012 wurden neue Regeln für Makros eingeführt, die es ermöglichen, sie vorsichtig zu verwenden, wann immer dies möglich ist. Der folgende Auszug aus einem MISRA C-Dokument empfiehlt die Verwendung eines Makros anstelle einer Funktion.

MISRA C-Regeln in Aktion

Genug geredet, jetzt ist es an der Zeit, einige MISRA C-Regeln in die Praxis umzusetzen, mit Beispielen, wie sie angewendet werden.

Verwendung kompatibler Typen als Zeigerargumente für memcpy, memmove und memcmp

Die Standardbibliotheksfunktionen memcpy, memmove und memcmp führen byteweise Verschiebungen oder Vergleiche der angegebenen Anzahl von Bytes durch. Die Regel 21.15 des MISRA C 2012-Standards schreibt vor, dass die beiden Funktionsparameter Zeiger desselben Typs sein müssen. Ein Funktionsaufruf mit inkompatiblen Zeigertypen könnte auf einen Fehler hindeuten. 

Betrachten Sie die folgende Abbildung aus dem offiziellen MISRA-Konformitätsdokument. Die Regel ist erforderlich, entscheidbar und gilt sowohl für C90 als auch für C99.

Ein Beispiel folgt der Regelbeschreibung.

Da die Objekte von unterschiedlichem Typ sind (uint8_t und uint16_t), ist dies eine nicht konforme Lösung, wie Sie sehen können.

Funktionen zur Behandlung von Zeichenketten, die keine Länge als Eingabe benötigen, dürfen nicht zu einem Out-of-Bound-Zugriff führen

String handling functions from <string.h> that don’t take the length as an input, shouldn’t result in out-of-bound access. The relevant functions are: strcat, strchr, strcmp, strcoll, strcpy, strcspn, strlen, strpbrk, strrchr, strspn, strrstr, and strtok. The rule is mandatory, meaning it can never be breached, under any circumstances. It applies to both C90 and C99, and is undecidable.

Das entsprechende Beispiel lautet:

Wie Sie sehen können, kopiert strcpy in der Funktion f1 über die Länge der Zeichenkette hinaus, die nur 5 Zeichen enthalten kann. Wir haben auch eine konforme und sichere Verwendung von strcpy, bei der die Zeichenkette nur kopiert wird, wenn der Inhalt von "str" passt.

Extern empfangene Daten validieren

Dir 4.14 empfiehlt, die Gültigkeit der von "externen" Quellen empfangenen Daten zu überprüfen. Externer Input kann sein:

• Lesen aus einer Datei.
• Lesen aus einer Umgebungsvariablen.
• Jede Benutzereingabe.
• Alles, was über einen Kommunikationskanal empfangen wird. Z. B. über eine TCP-Verbindung oder HTTP-API usw.

Diese Richtlinie fällt in die Kategorie " erforderlich" und gilt sowohl für C90 als auch für C99. Der Grund dafür ist, dass ein Programm keine Kontrolle über die von externen Quellen empfangenen Daten hat, was bedeutet, dass diese Daten ungültig oder bösartig sein können. Ein Programm erwartet z. B., dass der Benutzer eine Zahl eingibt, aber der Benutzer gibt eine Zeichenkette ein. Bevor das Programm die Eingabe verarbeitet, muss es überprüfen, ob es sich tatsächlich um eine Zahl handelt.

Wie man zu MISRA C 2012 wechselt

Die Umstellung auf MISRA C 2012 erfordert eine Aktualisierung Ihres Kodierrichtlinien-Dokuments. Wenn Sie kein solches Dokument verwenden und sich stattdessen auf ein statisches Analysetool verlassen (was die empfohlene Wahl ist), müssen Sie sich möglicherweise eine neuere Version des Tools besorgen. Hier sind drei Tools, die die Einhaltung von MISRA C 2012 überprüfen:

1. Cppcheck ist ein Open-Source-Tool, das auf MISRA-Regeln prüfen und auch verschiedene Arten von Fehlern aufspüren kann.
2. PC-lint Plus ist ein kostenpflichtiges Tool, das eine 30-tägige Testphase beinhaltet. Es prüft nicht nur die Einhaltung von MISRA C, sondern kann auch dabei helfen, potenzielle Bugs und Schwachstellen zu erkennen.
3. CodeSonar ist ein weiteres Tool, das sowohl die MISRA C- als auch die C++-Konformität überprüft.

Es gibt auch einige Compiler, die auf die Einhaltung von MISRA testen können. Falls eine Regelverletzung festgestellt wird, werden entsprechende Warnungen oder Ausnahmen ausgegeben. Green Hills Software bietet z. B. Compiler mit Unterstützung für alle MISRA-Standards, sowohl für 32-Bit- als auch für 64-Bit-Architekturen.

Verwendung von Secure Code Warrior für die Weiterbildung von Entwicklern in MISRA C

Das Vorzeigeprodukt vonSecure Code Warrior- learning platform - bietet zahlreiche interaktive Herausforderungen, courses, und Bewertungen, die Entwicklern helfen können, sicheren C/C++-Code zu schreiben. Der Inhalt der Plattform ist rahmenspezifisch und sehr ansprechend. Unsere C/C++:Embed-Codieraufgaben wurden sowohl von MISRA C, AUTOSAR C++ (MISRA C++) als auch von IEC inspiriert.

Entwickler können sich auf eine persönliche Lernreise begeben, auf der sie C/C++-spezifische Schwachstellen erkennen und - was noch wichtiger ist - lernen, diese Fehler zu beheben. In diesem Prozess können die Entwickler ihre Fortschritte verfolgen, um ihre Schwachstellen zu erkennen, und sogar einen freundschaftlichen Programmierwettbewerb mit Gleichgesinnten austragen. Erfahren Sie mehr darüber, wie wir die Automobil- und Transportbranche mit unseren Lösungen unterstützen.

Möchten Sie herausfinden, wie interaktiv und einbettungsorientiert unsere Challenges sind? Probieren Sie noch heute einige C/C++:Embed-Herausforderungen auf learning platform aus!

Eingebettete Systeme tragen zu einem Großteil der modernen Technologie bei. Vom adaptiven Geschwindigkeitsregler in Ihrem Auto bis hin zum Wifi in Ihrem intelligenten Kühlschrank. Mit der Zunahme von Cyberangriffen ist die Sicherung dieser Systeme von entscheidender Bedeutung geworden.

Eingebettete Geräte sind ein ideales Ziel für Hacker, denn ein erfolgreicher Angriff kann Eindringlingen Zugang zu den von ihnen erzeugten, empfangenen und verarbeiteten Daten verschaffen. Dies kann oft schwerwiegende Folgen für das größere System haben, das von dem eingebetteten Gerät betrieben wird. So kann z. B. die Abschaltung eines eingebetteten Geräts in einem F-15-Kampfjet, das Daten von verschiedenen Kameras und Sensoren sammelt, die Verteidigung des Jets erheblich beeinträchtigen.

In diesem Artikel finden Sie alles, was Sie für die Entwicklung sicherer eingebetteter Systeme benötigen. Hier finden Sie, was enthalten ist: 

• Was ist eingebettete Sicherheit?
• Herausforderungen bei der Implementierung eingebetteter Sicherheit.
• Was macht ein eingebettetes System "sicher"?
• Warum End-to-End-Sicherheit in einem eingebetteten Ökosystem wichtig ist.
• Einige eingebettete Sicherheitstools.
• Was fehlt den typischen eingebetteten Lösungen?
• Die Zukunft der eingebetteten Sicherheit.

Was ist eingebettete Sicherheit?

Embedded Security bietet die Tools, Prozesse und Best Practices zur Sicherung der Software und Hardware von Embedded-Geräten. 

Da die Hardware-Module eingebetteter Systeme klein sind, unterliegen sie verschiedenen Beschränkungen in Bezug auf den Speicher und die Speicherung. Die Integration von Sicherheitsmaßnahmen in diese Systeme ist daher eine große Herausforderung für das Design. Doch so schwierig dies auch sein mag, es ist ein Gebot der Stunde.

Viele der von eingebetteten Geräten betriebenen Gadgets und Maschinen sind auch mit dem Internet verbunden. Das bedeutet, dass Hacker unbefugten Zugang zu ihnen erhalten und bösartigen Code ausführen können. 

Ein Hack in einem eingebetteten Gerät kann sich oft auf andere angeschlossene Komponenten ausbreiten und/oder das gesamte System lahmlegen. Nehmen wir zum Beispiel an, dass ein Angreifer die Kontrolle über ein eingebettetes Gerät erlangt, mit dem der Fahrer sein Auto auf Autopilot schalten kann. Der Hacker kann das Auto dann von der Straße weg oder in den Verkehr hinein steuern und so möglicherweise großen Schaden anrichten.

Kritische Herausforderungen für die Sicherheit eingebetteter Systeme

Die Sicherheit eingebetteter Systeme erhält nicht die Aufmerksamkeit, die sie verdient. Hier sind ein paar Gründe dafür:

1. Mangelndes Bewusstsein der Entwickler:

Die Entwickler kennen in der Regel nicht die besten Verfahren für die Entwicklung sicherer eingebetteter Geräte. Das liegt zum einen an Punkt 2 und zum anderen daran, dass eingebettete Anwendungen weitaus komplizierter sind als herkömmliche Softwareanwendungen. Es kann eine Herausforderung sein, die Auswirkungen auf die Sicherheit zu verstehen und sicheren, leistungsfähigen Code für alle Anwendungsfälle zu schreiben, und das auch noch in einer eingeschränkten Mikrocomputerumgebung. 

2. Mangelnde Standardisierung:

Es fehlt an Cybersicherheitsstandards für eingebettete Systeme. Auch wenn die Autoindustrie langsam versucht, dies zu ändern. In den letzten Jahren haben Forscher eine ganze Reihe von Publikationen veröffentlicht, die sich mit der Cybersicherheit von intelligenten Fahrzeugen befassen. Einige davon sind SAE J3061, "Cybersecurity Guidebook for Cyber-Physical Vehicle Systems", und UNECE WP.29 Regulation on Cyber Security and Software Update Processes.

3. Verwendung von Komponenten Dritter

Viele eingebettete Geräte benötigen Hardware- und Softwarekomponenten von Drittanbietern, um zu funktionieren. Oft werden diese Komponenten verwendet, ohne dass sie auf Sicherheitsmängel und Schwachstellen getestet wurden. 

4. Veraltete Software

Eine veraltete Firmware ist in der Regel mit Fehlern und potenziell ausnutzbaren Schwachstellen behaftet. Auch wenn es besonders schwierig sein kann, die Firmware eines kleinen, eingebetteten Geräts regelmäßig zu aktualisieren, kann dies nicht ignoriert werden.

5. Direkte Internetverbindung

Viele eingebettete Systeme und Geräte sind direkt mit dem Internet verbunden. Dies bedeutet, dass sie nicht über den Schutz von Unternehmensfirewalls verfügen, die Netzwerkangriffe erkennen und verhindern können. Da die Ressourcen knapp sind, ist es sehr schwierig, in einer derart eingeschränkten Umgebung strenge Sicherheitsstandards zu implementieren.

6. Angriff in großem Maßstab

Eingebettete Geräte werden in der Regel in großem Maßstab hergestellt. Das bedeutet, dass eine einzige Schwachstelle oder ein Fehler Millionen von Geräten betreffen kann, manchmal sogar weltweit. Die Eindämmung der Auswirkungen eines Angriffs auf eingebettete Systeme kann daher eine große Herausforderung darstellen.

Was macht ein eingebettetes System sicher?

In den folgenden Abschnitten werden wir einige Software- und Hardware-Merkmale sicherer eingebetteter Systeme betrachten.

Bewährte Hardware-Sicherheitspraktiken

Ein sicheres eingebettetes System hat:

• Eine vertrauenswürdige Ausführungsumgebung

Eine vertrauenswürdige Ausführungsumgebung (TEE) ermöglicht die Isolierung sicherheitskritischer Vorgänge auf Hardwareebene. So kann beispielsweise die Benutzerauthentifizierung in einem separaten Bereich ausgeführt werden, was einen besseren Schutz sensibler Informationen ermöglicht.

• Angemessen partitionierte Hardwareressourcen

Verschiedene Hardwarekomponenten wie Prozessor(en), Cache, Speicher, Netzwerkschnittstellen usw. sollten angemessen getrennt sein und ihre Funktionen so unabhängig wie möglich ausführen. Dadurch wird verhindert, dass sich ein Fehler in einer Komponente auf andere Komponenten ausbreitet.

• Schutz des ausführbaren Speicherplatzes (ESP)

Der Schutz des ausführbaren Speichers (Executable Space Protection, ESP) besteht darin, bestimmte Speicherbereiche als nicht ausführbar zu markieren. Wenn jemand versucht, Code innerhalb dieser markierten Bereiche auszuführen, wird eine Ausnahme ausgelöst.

Bewährte Software-Sicherheitspraktiken

Bei der Entwicklung von eingebetteter Software sollten die folgenden bewährten Verfahren beachtet werden:

• Sicheres Booten verwenden:

Wenn ein eingebettetes Gerät hochfährt, wird das Boot-Image mithilfe kryptografischer Algorithmen überprüft. Dadurch wird sichergestellt, dass die Boot-Sequenz korrekt ist und dass die Software (Firmware und andere relevante Daten) nicht manipuliert wurde. 

• Verwendung eines Mikrokernel-Betriebssystems

Ein Mikrokernel-Betriebssystem ist viel kleiner als ein herkömmliches Betriebssystem und enthält nur eine Teilmenge seiner Funktionen. Der Kernelbereich ist winzig, und viele Benutzerdienste (wie die Dateisystemverwaltung usw.) werden in einem separaten Bereich, dem so genannten Benutzerbereich , gehalten . Da im Kernelbereich weniger Code und Operationen ausgeführt werden, ist die Angriffsfläche deutlich geringer.

• ordnungsgemäß verpackte Softwareanwendungen verwenden

Jede Softwareanwendung sollte in sich geschlossen und ordnungsgemäß verpackt sein. Wenn eine Anwendung z. B. eine Abhängigkeit von einem Drittanbieter erfordert, sollte diese nicht global auf dem Betriebssystem installiert werden. Vielmehr sollte sie Teil des Anwendungspakets/Containers sein.

• Alle Eingaben validieren

Alle von externen und/oder nicht vertrauenswürdigen Quellen empfangenen Daten sollten ordnungsgemäß bereinigt und validiert werden, bevor sie an kritische Software- und/oder Hardwarekomponenten weitergeleitet werden. 

Wenn eine Anwendung Daten von einer externen API-Integration abruft und darauf basierend eine Einstellung umschaltet, sollten die empfangenen Daten streng validiert werden, bevor die Einstellung geändert wird.

• Schutz der Daten im Ruhezustand:

Die gesamte sensible Software, Daten, Konfigurationsdateien, sichere Schlüssel und Passwörter usw., die auf einem eingebetteten Gerät gespeichert sind, sollten geschützt werden. Dies geschieht in der Regel durch Verschlüsselung. Die privaten Schlüssel, die zur Verschlüsselung der Daten verwendet werden, müssen in spezieller, eigens dafür entwickelter Sicherheitshardware gespeichert werden.

Die Sicherheitspyramide - End-to-End-Sicherheit für eingebettete Systeme

Vorbei sind die Zeiten, in denen Sicherheit ein nachträglicher Gedanke war. Eine nicht-funktionale Anforderung. Heute muss die Sicherheit inhärent sein. Die Geräte müssen von vornherein sicher sein. Zu diesem Zweck ist es unerlässlich, in einer eingebetteten Umgebung durchgängige Sicherheitsanforderungen zu implementieren. Das bedeutet: Denken Sie bei der Auswahl der Hardware, bei der Definition der Systemarchitektur, beim Entwurf des Systems und natürlich beim Schreiben des Codes an die Sicherheit.

Beginnen Sie bei der Hardware

Wie robust Ihre Software auch sein mag, wenn Ihre Hardware nicht ausreichend geschützt ist, sind Sie anfällig für Angriffe. On-Chip-Sicherheitstechniken können einen sicheren Start und eine effiziente Verwaltung von kryptografischen Funktionen und Geheimnissen ermöglichen. Einige Hardwarekomponenten ermöglichen es dem Betriebssystem auch, verschiedene Sicherheitsfunktionen wie die Erkennung von Systemanomalien bei Systemaufrufen, die Verschlüsselung des Dateisystems und Zugriffskontrollrichtlinien anzubieten.

Ein fehlertolerantes System

Es gibt zahlreiche Gründe, ein fehlertolerantes System zu entwickeln, und die Vermeidung von Angriffen durch differenzielle Fehleranalyse ist nur einer davon. Bei einem solchen Angriff kann ein potenzieller Hacker mithilfe von Fehlerinjektionstechniken versuchen, Fehler in einem eingebetteten Gerät zu erzeugen. Es gibt jedoch mehrere Möglichkeiten, solche Fehler zu erkennen und sich dagegen zu schützen:

• Replizieren Sie die kritischsten Vorgänge, so dass die verschiedenen Ausgaben jederzeit verglichen werden können, um das Auftreten eines Fehlers zu erkennen.
• Standardmäßig fehlschlagen: Bei der Behandlung mehrerer Bedingungen (innerhalb einer If-Bedingung oder eines Switch-Blocks) immer im Standardfall fehlschlagen, d.h. wenn nichts anderes passt.
• Führen Sie ein zufälliges Verhalten ein: Durch das Hinzufügen kleiner, zufälliger Verzögerungen vor wichtigen Operationen wird sichergestellt, dass deren Zeitablauf niemals vorhersehbar ist. Dies ist für die Erkennung von Eindringlingen von entscheidender Bedeutung, da es für Hacker sehr schwierig ist, Betriebsmuster zu ermitteln und Zeitangriffe durchzuführen.
• Schutzabdeckungen: Die Hersteller sollten die wichtigsten Komponenten mit Abdeckungen versehen, um sie vor Manipulationen von außen zu schützen.
• Erkennen Sie abnormale Schwankungen: Erkennen Sie abnormale Schwankungen bei Spannung, Strom oder anderen Werten und lösen Sie entsprechende Ausnahmen aus.

Sichern Sie Ihre Anwendung... und Ihr Betriebssystem

Der Aufbau des Schutzes Ihres Geräts auf der Anwendungsebene beinhaltet:

• Auswahl geprüfter, seriöser Software- und Hardwarekomponenten von Drittanbietern, die regelmäßig aktualisiert werden können.
• Weiterbildung von Entwicklern in den besten Praktiken für die Sicherheit eingebetteter Systeme.
• Verwenden Sie ein Mikrokernel-Betriebssystem, um sicherzustellen, dass nur eine minimale Anzahl von Operationen im Kernelbereich ausgeführt wird.
• Überwachung und Schutz vor Software-Angriffen, einschließlich Viren, Trojanern und Malware.
• Entfernen Sie alle unnötigen Dienste. Ihre Firmware sollte nur das enthalten, was Sie unbedingt benötigen. Wenn Sie z. B. keine Dateien übertragen oder Pakete aufzeichnen müssen, können Sie Dateiübertragungsprotokolle und Netzwerkpakete wie Telnet deaktivieren.
• Verwenden Sie sichere Protokolle wie SFTP, IPsec, SSL, TLS, SSH und DNSSEC.

Tools für die Sicherheit eingebetteter Systeme

Im Folgenden finden Sie eine nicht erschöpfende Liste von Tools, die bei der Sicherung eingebetteter Systeme helfen können:

• Bus-Blaster: Eine Hochgeschwindigkeits-Debugging-Plattform, die mit Hardware-Debug-Ports interagieren kann.
• Salae: Dekodieren Sie verschiedene Protokolle wie Seriell, SPI und I2C usw. Sie können von der Community erstellte Protokollanalysatoren verwenden oder Ihre eigenen erstellen.
• Hydrabus: Open-Source-Multi-Tool-Hardware, die für Debugging, Hacking und/oder Penetrationstests von eingebetteter Hardware verwendet werden kann.
• Ausnutzen: Ein Open-Source-Framework zum Testen und Ausnutzen der Sicherheit des Internets der Dinge (IoT).
• FACT (The Firmware Analysis and Comparison Tool): Framework zur Automatisierung der Sicherheitsanalyse von Firmware.
• Routersploit: Ein Open-Source-Exploit-Framework für eingebettete Geräte.
• Firmadyne: Open-Source-System zur Emulation und dynamischen Analyse von Linux-basierter Embedded-Firmware.

Woran mangelt es bei modernen eingebetteten Sicherheitslösungen?

Obwohl verschiedene Lösungen zum Debuggen, Ausnutzen und Testen von eingebetteten Lösungen zur Verfügung stehen, werden sie nicht ohne weiteres eingesetzt. Ein großer Schwerpunkt liegt nach wie vor auf der physischen Absicherung des Geräts, aber es wird nicht genug für den Schutz vor softwarebezogenen Angriffen getan. Selbst die einfachsten und leicht vermeidbaren Sicherheitsrisiken und Schwachstellen von Anwendungen sind bei modernen eingebetteten Geräten immer noch weit verbreitet.  

Ein wichtiger Grund dafür ist das mangelnde Bewusstsein der Entwickler für eingebettete Sicherheit. Laut einer von Tripwire durchgeführten Umfrage glauben 68 % der IT-Fachleute, dass ihre Mitarbeiter nicht ausreichend über potenzielle Sicherheitslücken informiert sind.

Die Entwickler wissen nicht, welche Sicherheitsprotokolle zu wählen sind, welche Frameworks zu vermeiden sind, welche Hardwarekomponenten abgetrennt werden müssen, wie mit sensiblen Daten umzugehen ist und welcher Verschlüsselungsalgorithmus der sicherste ist. Dieser allgemeine Mangel an Wissen und die Missachtung bewährter Verfahren machen Anwendungen, die auf eingebetteten Geräten laufen, anfällig für Kompromisse.

Die Zukunft der eingebetteten Sicherheit

Auf dem Markt für eingebettete Sicherheit wird viel gearbeitet. Experten gehen davon aus, dass die durchschnittliche jährliche Wachstumsrate (CAGR) des Marktes im Zeitraum von 2021 bis 2026 einen Wert von 5,5 % erreichen kann . Da immer mehr IoT-Geräte auf den Markt kommen, ist zu erwarten, dass sich neue eingebettete Sicherheitsstandards etablieren werden.

Die zunehmende Verbreitung von tragbaren medizinischen Geräten wird auch die Nachfrage nach zuverlässigen eingebetteten Sicherheitslösungen erhöhen. Damit die Geräte sensible medizinische Daten enthalten und verarbeiten können, müssen sie bestimmte Sicherheitschecklisten erfüllen, und wir hoffen, dass Anbieter und Ingenieure sich deshalb stärker auf die Sicherheit konzentrieren werden.

In Zukunft werden wir vielleicht auch Lösungen haben, die eine Fernsicht, -überwachung und -steuerung der wichtigsten Software- und Hardwarekomponenten in eingebetteten Geräten ermöglichen. Dies wird die Welt der Sicherheit eingebetteter Systeme grundlegend verändern.

Digitale Signaturen, die Verschlüsselung von Daten, das Hinzufügen von Firewalls, die Implementierung von Zugriffskontrollen und die Zufallsgenerierung von Operationen reichen letztendlich nur bis zu einem gewissen Punkt. Um wirklich sichere Geräte zu bauen, müssen die Entwickler darin geschult werden, sicheren Code zu schreiben. Die Identifizierung potenzieller Sicherheitsrisiken und deren Abschwächung in der Phase des Anwendungsentwurfs trägt wesentlich dazu bei, dass Systeme von sich aus sicher sind.

Wie Secure Code Warrior helfen kann

Das Vorzeigeprodukt vonSecure Code Warrior- learning platform - bietet zahlreiche interaktive Herausforderungen, courses, und Bewertungen, die Entwicklern helfen können, sicheren C/C++-Code zu schreiben. Der Inhalt der Plattform ist rahmenspezifisch und sehr ansprechend. Unsere C/C++:Embed-Codieraufgaben wurden sowohl von MISRA C, AUTOSAR C++ (MISRA C++) als auch von IEC inspiriert.

Entwickler können sich auf eine persönliche Lernreise begeben, auf der sie C/C++-spezifische Schwachstellen erkennen und - was noch wichtiger ist - lernen, diese Fehler zu beheben. In diesem Prozess können die Entwickler ihre Fortschritte verfolgen, um ihre Schwachstellen zu erkennen, und sogar einen freundschaftlichen Programmierwettbewerb mit Gleichgesinnten austragen. Erfahren Sie mehr darüber, wie wir die Automobil- und Transportbranche mit unseren Lösungen unterstützen.

Möchten Sie herausfinden, wie interaktiv und einbettungsorientiert unsere Challenges sind? Probieren Sie noch heute einige C/C++:Embed-Herausforderungen auf learning platform aus!

Wir haben uns mit Larry Maccherone von Contrast Security zusammengesetzt, dem führenden Anbieter von modernisierter Anwendungssicherheit, der Code-Analyse und Angriffsprävention direkt in Software einbettet. Wir haben darüber gesprochen, wie kontextuelles Lernen erfolgreich funktioniert, um Entwickler in sicherem Coding zu schulen.

Die Entwickler von heute sind zunehmend damit betraut, die Cybersecurity-Verletzungen von morgen zu stoppen. Zwar gibt es Schulungen zu Code-Schwachstellen, aber diese werden oft in wenig ansprechenden Formaten angeboten, die für die tägliche Arbeit der Entwickler nicht relevant sind. Entwickler müssen schnell Code schreiben, um Kundenwünsche zu erfüllen, wodurch Geschäftsziele wie Schulungen zurückgestellt werden. Und wenn dieses Training ohne Kontext und in Form von langen Präsentationen oder Studienhandbüchern angeboten wird, wird es noch entmutigender, was es schwer macht, den Nutzen des zusätzlichen Aufwands zu erkennen. 

Wie können Unternehmen Entwicklern wichtige Sicherheitsschulungen anbieten, ohne ihre täglichen Aufgaben zu unterbrechen oder sie von ihren bevorzugten Tools und Arbeitsabläufen fernzuhalten? 

Die Antwort ist einfach. Durch kontextbezogenes Lernen und die Bereitstellung von Schulungen direkt an den Fingerspitzen der Entwickler. Larry erklärt im folgenden Video, warum dies für Entwickler so leistungsstark ist.

‍
Durch die Integration von Schulungsangeboten zur gleichen Zeit, in der die Entwickler Code-Probleme überprüfen, erhalten sie sofort die Informationen, die für das identifizierte Problem oder die Schwachstelle am relevantesten sind. Da die Schulungen in kleineren und leichter verdaulichen Einheiten durchgeführt werden, ist es zudem wahrscheinlicher, dass die Entwickler die Informationen behalten und die Verwendung von anfälligem Code in Zukunft verhindern. Wie Larry es ausdrückt: "Feedback ist der Schlüssel zum Lernen".

Die Quintessenz ist, dass Entwickler in kürzerer Zeit mehr leisten und sicheren, hochwertigen Code liefern müssen. Durch das Einflechten von Schulungen, die kontextbezogen und spezifisch für die Code-Schwachstelle sind, werden die Arbeitsabläufe und Erfahrungen der Entwickler optimiert und ihre Behaltensquote erhöht. Hören Sie von Larry, wie Sie diese 40 Stunden Training einsparen können!

‍
Secure Code Warrior bietet technische Integrationen, die Ihren Entwicklungs- und Sicherheitsteams kontextbezogenes und hochrelevantes Lernen ermöglichen.

Interessiert an einer Demo? Buchen Sie eine unten. 

‍

Im Leben ist Kommunikation im Allgemeinen eine großartige Sache. Es gibt keinen schnelleren Weg, um zu einem Verständnis zu kommen, etwas Neues zu lernen oder eine Beziehung aufzubauen. In der Softwarebranche dienen APIs einem kommunikativen Zweck, der es Anwendungen ermöglicht, miteinander zu kommunizieren und so Funktionen und Benutzerfreundlichkeit zu verbessern. Diese Konnektivität führt oft zu einem reichhaltigeren Erlebnis, das die Endbenutzer lieben und zunehmend von der Software in ihrem täglichen Leben erwarten. 

Doch wie im richtigen Leben ist es ein großes Problem, wenn sie zu viel reden. Experian hat dies vor kurzem auf die harte Tour erfahren, als eine ihrer APIs - die von einem Drittpartner verwendet wird - potenziell die Kreditwürdigkeit von... nun ja, so ziemlich jedem amerikanischen Bürger preisgab.

Das Problem wurde schnell gepatcht, aber es bleibt die Frage, ob diese Sicherheitslücke wirklich gestoppt wurde. Wenn ein Anbieter betroffen war, stehen die Chancen gut, dass auch andere betroffen waren, und es besteht die Möglichkeit, dass es sich um einen systemischen Fehler handelt, der jeden betrifft, der diese unsichere API verwendet.

API-Sicherheit ist ein Thema, das den meisten Sicherheitsexperten nicht aus dem Kopf geht, und es ist etwas, für das wir uns mit dem Wissen ausstatten müssen, um es zu bekämpfen. 

Jeder verwegene Geek kann die schlechte API-Authentifizierung umgehen

Ein Merkmal vieler Datenlecks, Sicherheitsverletzungen und Sicherheitsvorfälle ist, dass sie selten von einem Superhirn ausgeführt werden. Komplexe, heimtückische und schädliche Angriffe, wie wir sie bei SolarWinds gesehen haben, erfordern Teams von cyberkriminellen Genies, um sie auszuführen, und sie sind eher die Ausnahme als die Regel. 

Wenn eine API mit schwacher Authentifizierung gebaut wird, ist es ziemlich einfach für sie, ausgenutzt zu werden. Bill Demirkapi, der Sicherheitsforscher, der Experians API-Bug entdeckte, stellte fest, dass auf diese ohne jegliche Authentifizierung zugegriffen werden konnte. Durch die Eingabe von 00/00/0000 in das Feld für das Geburtsdatum konnte er auf die Kreditwürdigkeit einer Person zugreifen, indem er nur öffentlich zugängliche Informationen wie den Namen und die dazugehörige Postanschrift verwendete. Dies wurde zwar nicht gemeldet, aber das Potenzial, dass diese Datensätze als kreditbezogener Datendump abgegriffen und kontextualisiert werden (und somit wertvoll sind), ist sicherlich vorhanden.

Saubere und funktionale Authentifizierungsprozesse sollten vorhanden sein, egal wie klein der Anwendungsfall ist; eine Chatterbox-API, die nicht ordnungsgemäß abgesichert ist und potenziell den Zugriff auf mehrere Systeme ermöglicht, ist eine Gefahr.

Broken Authentication ist die Nummer zwei auf der OWASP Top 10 API-Schwachstellenliste. Lesen Sie hier mehr darüber, wie Sie diesen Fehler vermeiden können, und testen Sie Ihre Fähigkeiten auf unserer Plattform, sobald Sie Ihr Gehirn gefüttert haben.

Schlechte API-Sicherheitskontrollen sind ein weit verbreitetes Problem, das einen kulturellen Wandel erfordert

Es ist nicht fair, mit dem Finger nur auf Unternehmen wie Experian zu zeigen, aber der Mangel an Nuancen und Sorgfalt bei der Sicherheitskontrolle, der in dieser speziellen API-Enthüllung gezeigt wurde, lässt nichts Gutes für die vielen Unternehmen da draußen erahnen, die APIs als Teil ihrer IT-Systeme und Endpunkte nutzen. 

Generell müssen wir noch viel mehr tun, um API-Schwachstellen nicht nur zu finden und zu beheben, sondern sie als Teil der Angriffsfläche zu verstehen, die wir schützen sollen. Die Sichtbarkeit von APIs - und wie sie erstellt wurden - ist ein großes Anliegen und sollte als Teil der Best Practices für Sicherheit gefordert werden. Selbst ein Unternehmen mit den strengsten Sicherheitsmaßnahmen kann durch eine API, die veröffentlicht wird und außerhalb der Sicherheitskontrollen des Unternehmens arbeitet, in Gefahr geraten. Es ist wichtiger denn je, sich zu fragen, woher eine API kommt, wer sie letztendlich verwaltet (ist es ein Drittanbieter? Wie streng sind seine Sicherheitsmaßnahmen?) und auf welche Informationen sie zugreift. 

Injection-Schwachstellen bleiben für jeden CISO ein Dorn im Auge.

API-Sicherheit scheint ein relativ neues Modul zu sein, das in ein Sicherheitsprogramm aufgenommen werden sollte, aber es kann mit einigen (sehr) alten Tricks ausgenutzt werden, die wir von gewöhnlicher Web-Software kennen.

Ein kürzlich bekannt gewordener Angriff auf Accellion zeigte, dass verkettete SQL-Injection- und OS-Befehlsausführungs-Angriffe es den Bedrohungsakteuren ermöglichten, APIs zu manipulieren und eine beträchtliche Menge sensibler Daten zu extrahieren, einschließlich Sozialversicherungsnummern. Es wurde festgestellt, dass die Angreifer umfangreiche Kenntnisse über die FTA-Software von Accellion haben mussten, um den Raub durchzuführen, was durch umfangreiches Reverse Engineering möglich gewesen wäre.

Da der Einbruch im Dezember 2020 und Januar 2021 stattfand, hatten die Diebe genügend Zeit, um Schaden anzurichten. Weitere Entdeckungen im Februar 2021 deckten eine gespeicherte XSS-Schwachstelle auf, wobei die forensische Analyse ergab, dass nur ein API-Endpunkt mit nicht ordnungsgemäß bereinigten Benutzereingaben es ermöglichte, ein Argument beim Aufruf des Skripts admin.pl zu injizieren.

Bei über 3000 Kunden, darunter viele renommierte Bildungseinrichtungen, könnte dieser Verstoß weitreichende Folgen haben. Leider wurden diese Angriffe durch die Ausnutzung allgemeiner Schwachstellen ermöglicht, von denen viele von sicherheitsbewussten Entwicklern bereits auf Code-Ebene und vor der Produktion hätten behoben werden können. Wie wir immer wieder sehen, braucht es nur ein kleines offen gelassenes Fenster, um große Probleme zu verursachen. Und eine Kultur der von Menschen geführten Cyber-Verteidigung muss Teil der Strategie sein, um ein sehr menschliches Problem zu lösen.

Möchten Sie jetzt Ihre API-Sicherheitskenntnisse testen in Java Spring API, Kotlin Spring API, C# (.NET) Web API und mehr? Probieren Sie einige API-Herausforderungen auf unserer Learning Platform aus (prüfen Sie alle Sprachen:Frameworks über das Dropdown):

‍

Die Begriffe "Champion" und "Coach" gewinnen auch außerhalb des Sports zunehmend an Bedeutung und haben in den meisten Kontexten eine starke Präsenz. Es gibt Life-Coaches, Wellness-Coaches, Empathie-Coaches und "Champions", die in vielen Organisationen gekrönt werden, Titel wie "Safety Champion" oder "Vibe Champion" werden immer mehr zum Mainstream und in den Geist und die Kultur des Unternehmens integriert. Wer möchte nicht einen Coach oder einen Champion an seiner Seite haben, wenn es hart auf hart kommt? 

Institutionen in der Cybersicherheitsbranche setzen seit langem Champions ein, um das Thema Sicherheit auf der Entwicklungsebene zu verbreiten und höhere Standards für die Softwaresicherheit aufrechtzuerhalten. BSIMM nennt sie die Satellite-Gruppe, während OpenSAMM und Axway zu den Pioniergruppen gehören, die Sicherheits-Champions als Konzept und formalisiertes Programm unterstützen. Diese Initiativen überschneiden sich mit einem der Hauptziele der DevSecOps-Bewegung, nämlich der Verpflichtung, die Verantwortung für die Sicherheit über alle Teams und Funktionen hinweg zu teilen, und zwar von Beginn des Softwareentwicklungsprozesses an.

Viele Unternehmen, die mit ihrem Cybersicherheitskonzept hohe Ziele verfolgen, haben ein offizielles Security-Champion-Programm eingeführt, das Personen, die für diese Aufgabe geeignet sind und sich dafür begeistern können, mit wichtigen Sicherheitsaufgaben betraut - von der Zusammenarbeit zwischen Teams über allgemeine Unterstützung bis hin zur Überwachung bewährter Verfahren. 

Es hat sich jedoch gezeigt, dass sich die Rolle des "Sicherheitschampions" verändert und dass ein zukunftsorientiertes Unternehmen mit einem erweiterten Team, in dem die wichtigsten Mitarbeiter unterschiedliche, aber gleichermaßen wichtige Funktionen wahrnehmen, neue Dimensionen skalierbarer Best Practices im Bereich der Sicherheit erreichen kann. 

Wir definieren den Sicherheitschampion neu und vervielfältigen ihn, um in einem zukunftssicheren Sicherheitsprogramm wirklich etwas bewirken zu können. Sind Sie bereit, Ihr nächstes Dream Team zusammenzustellen?

Jede großartige Mannschaft steht hinter einem inspirierenden Trainer.

Wenn man an Lionel Messi, Michael Jordan oder Serena Williams denkt, können in der Regel nur die eingefleischtesten Fans Fakten über ihre Trainer aufzählen, aber es ist diese enge Unterstützung, die ihre natürlichen Fähigkeiten, ihr Talent und ihre Zielstrebigkeit fördert, die den immensen Erfolg hervorbringt, den wir im Rampenlicht sehen. 

Niemand erwartet von Entwicklern, dass sie einen Grand Slam gewinnen oder ein Tor für Argentinien schießen, und niemand sollte auch nur erwarten, dass Entwickler Sicherheitsexperten sind (schließlich haben sie sich verpflichtet, coole Funktionen zu entwickeln, und nicht, sich tief in die Sicherheit zu vertiefen), aber ein großartiger Sicherheits-"Coach" ist ihr wahrer Champion im Team.

Ein entwicklerseitiger Sicherheits-Champion entspricht viel mehr dem, was wir als die Grundlagen eines Coaches bezeichnen würden. Sie engagieren sich leidenschaftlich für die Sicherheit, kennen sich aus und sind ein wichtiger Ansprechpartner, wenn ein Entwickler ein Sicherheitsproblem zu lösen hat. Sie verfügen über das praktische Know-how, um das Problem zu beheben und aus den Fehlern zu lernen, und stellen gleichzeitig sicher, dass das Team die grundlegenden bewährten Sicherheitsverfahren und -werte befolgt. 

Würde der AppSec-Champion bitte aufstehen?

Ein AppSec-Champion ist ein oft vermisstes Puzzlestück im Sicherheitsprogramm. Sie sind für den Erfolg eines Entwicklungsteams absolut unverzichtbar. Als Brücke zwischen der Führungsebene und den Entwicklern können sie sich aktiv für diese einsetzen und ihnen die Tools an die Hand geben, die sie benötigen, um einen positiven Einfluss auf die Verringerung von Schwachstellen, die Softwaresicherheit und das Vertrauen und die Zufriedenheit der Kunden zu haben. 

Ein großartiger AppSec-Champion ist innerhalb des Unternehmens als Sicherheitsführer anerkannt und sollte eine wichtige Rolle bei der direkten Schulung der Sicherheitstrainer spielen, um bessere Ergebnisse und Beziehungen zwischen den Teams zu erzielen, die alle ein gemeinsames Ziel verfolgen: erstklassigen, wasserdichten sicheren Code. 

Rufen Sie Ihren Supercoach.

Champions und großartige Coaches gehen Hand in Hand, und zusammen schaffen sie Magie. Bestehende Security-Champion-Programme konzentrieren sich in der Regel auf den Entwickler, aber wie wir festgestellt haben, sollte die wirkliche Förderung auf der AppSec-Seite stattfinden, so dass die leidenschaftlichsten, sicherheitsbewussten Entwickler dabei helfen können, unter der Haube sichere Codierung zu erreichen und den Rest des Teams zu fördern. 

Die Suche nach dem idealen Coach ist ein ähnlicher Prozess wie beim traditionellen Champion: Der beste Coach ist nicht einfach die Person, die im Bereich Sicherheit "am besten" ist. Die Person, die zufälligerweise erstaunlich gut im sicheren Programmieren ist und qualitativ hochwertigen, abgesicherten Code produziert, hat vielleicht kein Interesse daran, eine außerschulische Rolle zu übernehmen, oder sie ist trotz ihrer Begabung nicht besonders von Sicherheit begeistert. 

Stattdessen könnte Ihr Coach aufgedeckt werden, wenn Sie sich jemanden suchen, der:

• großes Interesse an der Cybersicherheit, von der praktischen Programmierung bis hin zur ständigen Information über die neuesten Vorfälle, Tools und coolen Entwicklungen
• Sie verfügen über gute zwischenmenschliche Fähigkeiten; sie helfen anderen gerne, fühlen sich als Ansprechpartner (oder Experte) und sind ansprechbare Teamplayer
• Sie wissen, was benötigt wird, um dem Team zu helfen, und können mit ihrem AppSec-Verbindungsmann (ihrem Champion) zusammenarbeiten, um die Bedürfnisse zu erfüllen, so dass gemeinsame Sicherheitsergebnisse erzielt werden können.

Setzen Sie Anreize für die Trainertätigkeit; wer auch immer Sie auswählen , wird mehr Verantwortung übernehmen müssen, und sein Arbeitspensum muss entsprechend bewertet werden. Auch wenn persönliches Interesse und berufliches Fortkommen bei der Motivation eines potenziellen Coaches eine Rolle spielen, ist es sinnvoll zu prüfen, wo er sonst noch für das Erreichen von Zielen belohnt werden kann. Können sie zu einer großartigen Konferenz geschickt werden? Können sie zusätzlichen Urlaub bekommen? Können courses und Zertifizierungen für sie finanziert werden? Zeit und Geld, die jetzt in die Sicherung des SDLC von Anfang an investiert werden, sparen später im Zyklus viel mehr - oder schlimmer noch, wenn eine Schwachstelle live entdeckt wird - und ein guter Coach wird das Bewusstsein hoch halten. Finden Sie einen Weg, um sinnvolle Belohnungen anzubieten.

Ihr Sicherheits-Champion-Programm der nächsten Stufe.

Letztendlich müssen wir als Industrie mehr tun, um Entwickler zu unterstützen und sie für die dunkle Seite der Sicherheit zu gewinnen, indem wir sie motivieren, zu erkennen, dass Qualitätscode sicherer Code ist. Es ist schwierig, sich für etwas zu interessieren, wenn die Zeit und der Aufwand für die Ausbildung und die Ermöglichung des Erfolgs ausbleiben, und leider ist das bei der Ausbildung in sicherer Programmierung oft der Fall. Relevante, praxisnahe Fortbildung in Verbindung mit einem Peer-Coach und einem AppSec-Befürworter ist wirklich der Triple-Hit, der nötig ist, um das Entwicklungsteam zu unterstützen und seine Verteidigungskraft zu entfalten.

Eine Version dieses Artikels erschien in Hilfe zur Netzsicherheit. Er wurde aktualisiert und hier syndiziert.

‍

Ich habe meine berufliche Laufbahn damit verbracht, Software-Schwachstellen zu finden, zu beheben, zu diskutieren und zu beseitigen, so oder so. Ich weiß, dass einige verbreitete Sicherheitslücken, obwohl sie schon seit den 90er Jahren bekannt sind, unsere Software weiterhin plagen und große Probleme verursachen, obwohl die (oft einfache) Lösung schon fast genauso lange bekannt ist. Es fühlt sich wirklich an wie der Murmeltiertag, an dem wir als Branche immer wieder das Gleiche tun und ein anderes Ergebnis erwarten. 

Es gibt jedoch noch ein weiteres kleines Problem. Wir erhalten weder realistische Ratschläge noch die schnellsten Lösungen zur Bekämpfung des unaufhörlichen Ansturms, der die moderne Cybersicherheit ausmacht. Natürlich ist jede Sicherheitsverletzung auf ihre eigene Art und Weise anders, und es gibt zahlreiche Angriffsvektoren, die in anfälliger Software ausgenutzt werden können. Allgemein gültige Ratschläge werden nur begrenzt möglich sein, aber der Best-Practice-Ansatz wird von Stunde zu Stunde unzulänglicher. 

In diesem Zusammenhang muss ich mich fragen, warum in so vielen Kommentaren und Analysen zum Thema Cybersicherheit Lösungen ausgelassen werden, die die eigentliche Ursache für so viele Schwachstellen angehen: den Menschen. Der jüngste Hype Cycle for Application Security von Gartner und The State of Application Security 2021 von Forrester, beides Bibeln für Sicherheitsexperten, die zweifellos dazu beitragen, ihr Programm und die potenzielle Produktakzeptanz zu gestalten, sind fast ausschließlich auf Tools fokussiert. Ein Bericht von Aberdeen aus dem Jahr 2017 zeigte, wie unkontrolliert der durchschnittliche Security-Tech-Stack geworden war, mit CISOs, die Hunderte von Produkten als Teil ihrer Sicherheitsstrategien verwalten; vier Jahre später haben wir es mit mehr Risiken, mehr Schwachstellen und mehr Ergänzungen zu wachsenden Tech-Stack-Bestien zu tun.

Sicherheitstools sind ein Muss, aber wir müssen weiter blicken und die menschliche Komponente der Sicherheitsabwehr wieder ins Gleichgewicht bringen.    

Der Automatisierung gehört die Zukunft. Warum sollten wir uns um das menschliche Element der Cybersicherheit kümmern?

Praktisch alles in unserem Leben wird von Software angetrieben, und es ist wahr, dass die Automatisierung die menschlichen Elemente ersetzt, die einst in so vielen Branchen vorhanden waren. Das ist ein Zeichen des Fortschritts in einer Welt, die sich in rasantem Tempo digitalisiert. KI und maschinelles Lernen sind aktuelle Themen, die viele Unternehmen zukunftsorientiert machen. 

Warum also sollte ein auf den Menschen ausgerichteter Ansatz für die Cybersicherheit etwas anderes sein als eine antiquierte Lösung für ein technologisch fortschreitendes Problem? Die Tatsache, dass im vergangenen Jahr bei Sicherheitsverletzungen Milliarden von Datensätzen gestohlen wurden, darunter die jüngste Facebook-Verletzung , die mehr als eine halbe Milliarde Konten betraf, sollte ein Hinweis darauf sein, dass wir nicht genug tun (oder nicht den richtigen Ansatz wählen), um den Bedrohungsakteuren ernsthaft entgegenzutreten. 

Tools für die Cybersicherheit sind eine dringend benötigte Komponente der Cyberabwehr, und Tools werden immer einen Platz haben. Analysten haben die neuesten Tools zur Risikominderung für Unternehmen absolut richtig empfohlen, und das wird sich auch nicht ändern. Da jedoch die Codequalität (und damit auch die Sicherheit) bei dem Umfang der Codeproduktion nur schwer zu handhaben ist, können Tools die Aufgabe nicht allein bewältigen. Bislang gibt es kein einziges Tool, das dies kann:

• Suche nach jeder Schwachstelle, in jeder Sprache: Framework
• Scannen mit Geschwindigkeit
• Minimierung der durch falsch-positive und -negative Ergebnisse verursachten Doppelarbeit

Werkzeuge können langsam, umständlich und unhandlich sein. Vor allem aber finden sie nur Probleme - sie beheben sie nicht und empfehlen auch keine Lösungen. Letzteres erfordert Sicherheitsexperten, die dünn gesät und überlastet sind und sich durch den Müll wühlen, um in endlosen Pentest- und Scan-Ergebnissen einen Schatz zu finden.

Tatsache ist, dass laut dem IBM Cyber Security Intelligence Index Report bei 95 % aller erfolgreichen Datenschutzverletzungen menschliches Versagen eine Rolle spielt. Fast die Hälfte davon steht in direktem Zusammenhang mit Software-Schwachstellen, von denen viele vermieden werden könnten, wenn in den frühen Phasen des SDLC mehr Wert auf eine sichere Kodierung und ein entsprechendes Bewusstsein gelegt würde. Um dies zu erreichen, ist eine stärkere und relevantere Fokussierung auf die Ausbildung von Entwicklern - neben der Einbindung in ihren Arbeitsablauf - der Schlüssel. 

Ob es uns gefällt oder nicht, der Mensch ist tief in den Softwareentwicklungsprozess eingebunden, und die Cybersicherheit ist in erster Linie ein menschliches Problem. Tools sind kein Allheilmittel, um einen grundlegenden Fehler in unserem Ansatz zu korrigieren, aber sie können eine wichtige unterstützende Rolle bei der Umgestaltung menschlicher Lösungen spielen. 

Was wäre, wenn wir einfach bessere Werkzeuge (und zwar viele davon) bauen würden?

Die Sicherheitstools werden ständig verbessert. SAST/DAST/IAST-Tools haben einen langen Weg zurückgelegt, sind schneller und intelligenter geworden, und RASP sollte in vielen Anwendungsumgebungen eine ernsthafte Verteidigungsmaßnahme sein. Firewalls, Secrets Manager, Cloud- und Netzwerksicherheitsanwendungen: alles unumstößlich. 

Der Mensch kann sich immer bemühen, bessere Werkzeuge zu entwickeln, aber die Innovation hält nicht mit den Sicherheits- und Datenschutzanforderungen der digitalen Welt, in der wir leben, Schritt. Tools werden größtenteils mit Robotern im Hinterkopf entwickelt. Sie können Entwickler und das Sicherheitsteam beim Scannen, Überwachen oder Schützen von Code unterstützen, aber die Interaktion ist sehr begrenzt, und nur sehr wenige Lösungen zielen darauf ab, das Sicherheitsbewusstsein zu erhöhen oder Kernkompetenzen zu verbessern, die zu besseren Sicherheitsergebnissen führen können.

Tatsächlich weiß mehr als die Hälfte der Unternehmen nicht einmal, ob die Tools für sie funktionieren, noch sind sie zuversichtlich, dass sie eine verheerende Datenpanne vermeiden können. Das ist ein sehr schlechtes Gefühl und führt in einer tool-besessenen Branche, der es an Unterstützung für einen anderen Ansatz mangelt, eher zu einer Verfestigung des Status quo und der darin enthaltenen Probleme. 

Wie kann ein Unternehmen einen von Menschen geleiteten Ansatz für die Sicherheit nutzen?

Es steht außer Frage, dass es von Vorteil ist, den Trends in der Anwendungssicherheitstechnologie voraus zu sein, und dass es sogar dabei helfen kann, Upgrades oder Konsolidierungen in einem aufgeblähten Tech-Stack zu priorisieren, aber wenn wir darauf verzichten, die Hauptursache für anfällige Software anzugehen - nämlich uns Menschen -, werden wir an der Cybersecurity-Schlachtfront immer auf der Verliererseite stehen.

Wenn wir die Zahl der Sicherheitslücken auf Code-Ebene ernsthaft verringern wollen, dann müssen die Entwickler die Grundlagen für eine erfolgreiche Mitverantwortung für die Sicherheit erhalten. Sie brauchen eine relevante, praxisnahe Ausbildung und Weiterbildung sowie funktionale Werkzeuge, die ihren Arbeitsablauf nicht stören oder die Entwicklung von Sicherheitslösungen zu einer lästigen Pflicht machen. Idealerweise wären einige Tools auf die Entwickler ausgerichtet und würden deren Benutzererfahrung in den Vordergrund stellen. 

Bis heute gibt es kein offizielles Sicherheitszertifizierungsprogramm für Entwickler, aber jedes Unternehmen kann von einem Benchmarking und der Entwicklung sicherer Programmierfähigkeiten profitieren, indem es häufige Schwachstellen frühzeitig und häufig beseitigt, bevor der große Tech-Stack in Aktion tritt und alles verlangsamt. 

Ein Team von sicherheitsbewussten Entwicklern ist ein verborgener Schatz für jedes Unternehmen, aber wie alles, was wertvoll ist, braucht es Zeit und Mühe, um ein effektives Dreamteam zu bilden. Um Entwickler dafür zu gewinnen, sich für Sicherheit zu interessieren und sichere Kodierung als Grundlage für die Codequalität zu betrachten, bedarf es einer unternehmensweiten Verpflichtung, Sicherheit an die erste Stelle zu setzen. Und wenn ganze Teams auf den positiven Einfluss aufmerksam gemacht werden, den sie bei der Beseitigung allgemeiner Schwachstellen beim Schreiben von Code spielen können, gibt es kein Tool auf der Welt, das da mithalten kann.

Wir waren kürzlich sehr erfreut, als der erste Forbes Technology Council-Beitrag unseres Vorsitzenden und CEO Pieter Danhieux online ging. Der Beitrag beschreibt, wie die Weiterbildung von Entwicklern zur Erstellung von sichererem Code ein Schlüssel zur Verhinderung von Cyberangriffen und Datenschutzverletzungen ist. Darüber hinaus wird aufgezeigt, wie dieselben sicherheitsbewussten Entwickler dabei helfen können, besseren und sichereren Code zu liefern, und zwar schneller, als es vielen IT-Abteilungen bewusst ist. Die Notwendigkeit für diesen Ansatz ist sicherlich zwingend. Eine kürzlich durchgeführte Studie hat ergeben, dass heute alle 39 Sekunden ein Cyberangriff stattfindet, und wir alle haben die Störung gesehen, die durch einen einzigen erfolgreichen Ransomware-Angriff auf die Colonial Pipeline verursacht wurde, der im Großen und Ganzen nicht so zerstörerisch war wie der SolarWinds-Hack. 

‍

Viele verbreitete Schwachstellen existieren weiterhin, weil sich niemand die Mühe gemacht hat, den Entwicklern zu zeigen, wie man schlechte Codierungsmuster durch einen besseren Weg ersetzt, um die gleichen Funktionen auf eine sicherere Art und Weise zu erreichen. Und die Auswirkungen der Korrektur von Software in einem späten Entwicklungsstadium sind extrem kostspielig, sowohl in Bezug auf die aufgewendeten Stunden als auch auf die Verzögerungen bei der Bereitstellung. Die Korrektur des Codes nach der Bereitstellung, insbesondere nachdem ein Angreifer eine zuvor unentdeckte Schwachstelle ausgenutzt hat, kann manchmal Millionen von Dollar kosten. Und dabei ist der Schaden für den Ruf eines Unternehmens nach einer großen Sicherheitslücke noch gar nicht berücksichtigt.

Sicherheitsgeschulte Entwickler werden natürlich zu besseren Programmierern. Sicherlich sollten CISOs ihre Sicherheitstools nicht so bald fallen lassen, aber indem sie einen umfassenden, präventiven Sicherheitsansatz von oben anführen, können CISOs die größte Ressource ihres Unternehmens nutzen, den Faktor Mensch, insbesondere wenn es um sichere Codierung von Beginn des Softwareentwicklungszyklus an geht.

Um dies zu tun, sind hier die drei wichtigsten Strategien, die Sie im Auge behalten sollten.

1. Seien Sie proaktiv, nicht reaktiv

Unternehmen tappen oft in die Falle, reaktiv zu sein, z. B. auf das zu reagieren, was die Konkurrenz tut, anstatt eine eigene Vision zu entwickeln und zu verfolgen. Viele verfallen auch in diesen Ansatz, wenn es um Sicherheitsschwachstellen im Code geht, und nehmen Cybersicherheit erst dann ernst, wenn sie durch einen erfolgreichen Einbruch dazu gezwungen werden. Leider ist der Schaden dann schon angerichtet, denn Geldstrafen, Wiederherstellungskosten, Kundenverluste und die Wiederherstellung der Marke schlagen zu Buche. Eine andere Form des Reagierens statt Agierens ist das Verlassen auf automatisches oder manuelles Code-Scanning, um Schwachstellen im bestehenden Code zu finden, anstatt sich von vornherein auf die Erstellung sicheren Codes zu konzentrieren. Leider ist das Scannen von Code keine perfekte Lösung, d. h. je mehr Schwachstellen im Code vorhanden sind, desto größer ist die Chance, dass einige davon durchschlüpfen. 

Nur wenn Sie proaktiv vorgehen und mit den Entwicklern zusammenarbeiten, um sie von Anfang an bei der Erstellung von sicherem Code zu unterstützen, können Sie einen Softwareentwicklungs-Lebenszyklus etablieren, der die Wahrscheinlichkeit, dass Schwachstellen im Code an die Benutzer weitergegeben werden, deutlich reduziert.

2. Upskill, nicht Overkill

Wenn Sie sich entschieden haben, Entwicklern das Wissen zu vermitteln, das sie zur Erstellung von sicherem Code benötigen, wählen Sie Ihren Ansatz mit Bedacht. Interne Schulungsworkshops, die die Codierung zum Stillstand bringen, frustrieren Entwickler und Manager gleichermaßen. Offsite-Schulungen courses , die eine Teilnahme am Abend oder am Wochenende erfordern, sind noch weniger beliebt. Die beste Herangehensweise ist der schrittweise Aufbau von Programmierkenntnissen, indem relevante Informationen Schritt für Schritt während des Programmierprozesses vermittelt werden - im Wesentlichen ein Upskilling, ohne die Entwickler wesentlich abzulenken oder den Entwicklungsprozess zu verlangsamen. 

3. Anreize schaffen, nicht voraussetzen

Entwickler sollten Sicherheits-Upskilling nicht als Bestrafung oder als totale Plackerei sehen. Manager müssen die Entwickler inspirieren, indem sie ihnen die wichtige Rolle vermitteln, die sicherer Code für den Erfolg des Unternehmens spielt. Es ist auch wichtig, zu vermitteln, dass sichere Programmierer wertvoller für das Unternehmen sind und in Zukunft erweiterte Karrieremöglichkeiten genießen werden.

Die von der Biden-Administration begrüßte Durchführungsverordnung hat den Fokus auf Cybersicherheit und die Notwendigkeit verstärkt, "Kriterien zur Bewertung der Sicherheitspraktiken der Entwickler und Zulieferer selbst einzubeziehen und innovative Werkzeuge oder Methoden zum Nachweis der Konformität mit sicheren Praktiken zu identifizieren." Aber obwohl Werkzeuge wichtig sind, reichen sie nicht aus. Kein Tool wird jemals vollständig ausschließen können, dass ein Einzelner die eingerichteten Systeme und Tools irgendwie ignoriert, missversteht, missbraucht oder anderweitig umgeht. Um die Sicherheit ihrer Unternehmen zu maximieren, müssen CISOs den menschlichen Faktor ausnutzen und Entwickler dazu ermutigen, bereitwillige Sicherheitsbefürworter und -praktiker zu werden.

Die jüngste Cybersecurity Executive Order der Biden-Administration hat die Sicherheitsbranche sicherlich ins Gerede gebracht, insbesondere diejenigen, die Entwickler für die Bedeutung der Anwendung von Best Practices für sichere Codierung bei ihrer täglichen Arbeit gewinnen wollen. Zum ersten Mal müssen Entwickler, die an Software arbeiten, die von der Bundesregierung eingesetzt wird, über nachgewiesene Sicherheitskompetenzen verfügen und sich an neue, weiterentwickelte Richtlinien halten.

Dies stellt eine positive Veränderung des Status quo in der Cyberverteidigung dar und macht endlich die adäquate Weiterbildung von Entwicklern zum Bestandteil des Gesprächs. Obwohl diese Richtlinien auf die US-Regierung ausgerichtet sind, bieten sie eine globale Gelegenheit für Organisationen, sich mit den aktuellen Sicherheitsstandards zu befassen und diese zu verbessern - von Entwicklern bis hin zur Sicherheitsanalyse von Software-Lieferketten. 

Das NIST hat kürzlich die Öffentlichkeit um Kommentare gebeten, um die nächsten Aktualisierungen der HIPAA-Gesetzgebung zu informieren, und dies war eine unübersehbare Gelegenheit für uns, unsere Firmenexpertise in Positionspapieren zu bündeln, die dazu beitragen können, einen sichereren und effektiveren, von Menschen geleiteten Ansatz für die Cybersicherheit zu entwickeln, der Organisationen dabei hilft, ihre Teams für bessere Ergebnisse einzusetzen. 

Als expertengetriebene Organisation haben wir das Glück, dass einige der engagiertesten und versiertesten Cybersecurity-Experten mit uns zusammenarbeiten, darunter der Doktorand Pieter de Cremer und Dr. Brian Chess, der Teil unseres Technical Advisory Board ist. Wir drei haben unsere Köpfe zusammengesteckt, um formell Positionspapiere bei NIST einzureichen, in denen wir Wege aufzeigen, wie unser Ansatz für die Fortbildung von Entwicklern und präventive Sicherheit in der Softwareerstellungsphase die zukünftigen Cybersicherheitsstandards positiv beeinflussen könnte. 

Ein sicherer Entwicklungspfad, geebnet für Entwickler

Tools zum Scannen von Schwachstellen, Monitoring und andere Formen der Sicherheitsautomatisierung werden immer häufiger eingesetzt, und sie sind sowohl in der neuen Executive Order als auch in den NIST-Richtlinien enthalten. Sie sind ein immer wichtigerer Bestandteil eines modernen Sicherheitsprogramms, aber die Geschichte und die Gegenwart zeigen, dass insbesondere Scanning-Tools zwar mit immer größerer Effizienz Schwachstellen in Software finden, dies allein aber keinen Effekt auf deren Reduzierung oder gar eine Verbesserung der Sicherheit von Anfang an hat. 

Ein schwerfälliger Tech-Stack, der ablenkt und den Arbeitsablauf von Entwicklern verlangsamt, ist einer der Hauptgründe dafür, dass sich Entwickler nicht mit Sicherheit beschäftigen und sie in einem negativen Licht sehen. Hätten Entwickler jedoch einen geebneten Weg zur sicheren Entwicklung, der nicht nur an die Technologie, sondern auch an Sprachen, Frameworks und projektspezifische Entwicklungsziele angepasst ist, dann wäre die Einbettung von Sicherheit in den Entwicklungsprozess von Anfang an - mit so wenig Unterbrechung ihrer Produktivität wie möglich - ein Ideal, das im Laufe der Zeit zu einer signifikanten Verringerung der gängigen Schwachstellen führen würde. 

Um unser NIST-Positionspapier vollständig zu lesen, laden Sie es jetzt herunter:

Zertifizierungsrahmen für sichere Entwicklungspraktiken: Das (derzeit) fehlende Glied

Bis heute gibt es keine formale Zertifizierung zur Verifizierung von sicheren Codierungsfähigkeiten und Best Practices. Dies ist seit langem ein Versäumnis der Branche, und wir sind der Meinung, dass dies für die Zukunft einer verbesserten Cyberabwehr und sicheren Entwicklung unerlässlich ist. 

Wir wissen, dass es viele Formen von Sicherheitstrainings gibt, die auf Entwickler abzielen, aber wenn die Menge an groß angelegten Datenschutzverletzungen, Cyberangriffen und minderwertigem Code, die es da draußen gibt, irgendein Anzeichen dafür ist, dann werden keine sicherheitsbewussten Entwickler geschaffen und sie werden nicht mit dem Wissen ausgestattet, um eine Delle in ein Problem zu machen, das nur noch schlimmer wird. 

Die Weiterbildung von Entwicklern erfordert Tools und Schulungen, die für die tägliche Arbeit relevant, kontextbezogen und mundgerecht (aber dennoch häufig) sind und es ihnen ermöglichen, auf dem vorhandenen Wissen in den Sprachen und Frameworks aufzubauen, die sie tatsächlich verwenden. Allgemeine Schulungen reichen nicht aus, und dies muss in der Gesetzgebung und in Branchengremien wie dem NIST deutlich gemacht werden. 

Das NICE-Framework ist mehr als geeignet, um umfassende Zertifizierungsrichtlinien zu erstellen, die aktiv Methoden verwenden, die funktionieren und die für Entwickler und ihre Arbeit von größtem Interesse und Relevanz sind. Die Ausrichtung an diesem anerkannten institutionellen Rahmen hilft dabei, Praktiken zu standardisieren, die wirklich einen Unterschied machen, und bietet konkretere Wege für Organisationen, denen sie folgen können.

Um unser zweites NIST-Positionspapier vollständig zu lesen, laden Sie es jetzt herunter:

Der Faktor Mensch wird bei der Cybersicherheit oft vergessen, und es ist an der Zeit, dass wir auf menschliche Lösungen für menschliche Probleme wie wiederkehrende allgemeine Sicherheitslücken hinarbeiten. Jahrzehnte alte Bugs sollten uns nicht mehr in die Quere kommen, aber es braucht die Unterstützung von globalen Regierungen, um den Status quo zu ändern und messbare, positive Auswirkungen zu erzielen.

Sind Sie bereit, Ihre Entwickler zu zertifizieren? Dann sind Sie bei uns genau richtig. Schauen Sie sich unser Learning Platform heute.