DE102019215858A1 - Cybersicherheits-penetrations-testplattform - Google Patents

Cybersicherheits-penetrations-testplattform Download PDF

Info

Publication number
DE102019215858A1
DE102019215858A1 DE102019215858.7A DE102019215858A DE102019215858A1 DE 102019215858 A1 DE102019215858 A1 DE 102019215858A1 DE 102019215858 A DE102019215858 A DE 102019215858A DE 102019215858 A1 DE102019215858 A1 DE 102019215858A1
Authority
DE
Germany
Prior art keywords
attack
processor
circuit
memory
open surfaces
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE102019215858.7A
Other languages
English (en)
Inventor
Michael Metzger
Thomas Leifert
Stephen Lee McGregory
Dean Lee
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Keysight Technologies Inc
Original Assignee
Keysight Technologies Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Keysight Technologies Inc filed Critical Keysight Technologies Inc
Publication of DE102019215858A1 publication Critical patent/DE102019215858A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/14Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1433Vulnerability analysis
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/22Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
    • G06F11/2205Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing using arrangements specific to the hardware being tested
    • G06F11/221Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing using arrangements specific to the hardware being tested to test buses, lines or interfaces, e.g. stuck-at or open line faults
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/22Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
    • G06F11/26Functional testing
    • G06F11/267Reconfiguring circuits for testing, e.g. LSSD, partitioning
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/14Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1408Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
    • H04L63/1416Event detection, e.g. attack signature detection
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/14Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441Countermeasures against malicious traffic
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/20Network architectures or network communication protocols for network security for managing network security; network security policies in general

Abstract

Ein Verfahren, ein System und ein nichtflüchtiges computerlesbares Medium sind offenbart, die zum Testen einer Mehrzahl von Schaltungen zur Bestimmung offener Oberflächen verwendet werden. Das Verfahren beinhaltet: Empfangen einer oder mehrerer Angriffstechniken und bekannter offener Oberflächen; Ausführen von Angriffen auf eine Schaltung zur Bestimmung empfindlicher Oberflächen der Schaltung; Bestimmen, wenn neue offene Oberflächen in der Schaltung vorliegen; Aktualisieren eines Angriffsplans basierend auf den neuen offenen Oberflächen; Ausführen des Angriffsplans; Erzeugen eines Berichts über die offenen und empfindlichen Oberflächen; und Aktualisieren eines Depots, um neue Angriffstechniken gegen neu entdeckte offene Oberflächen der Schaltung zu beinhalten.

Description

  • Viele moderne Ausrüstungen sind dafür ausgebildet, mit dem Internet und der umgebenden Infrastruktur verbunden zu sein. Beispielsweise beinhalten moderne Automobile, Züge, Flugzeuge, landwirtschaftliche Geräte und Drohnen ein rollendes („Rolling“-) Computer-Cluster mit einer Vielzahl verdrahteter und drahtloser Schnittstellen, die die Funktion vieler unterschiedlicher Systeme aktivieren.
  • Jedes dieser Systeme besitzt eine oder mehrere Schnittstellen zu dem Internet oder anderen Netzen und ist so potenziell empfindlich gegenüber Angriffen auf die offenen Oberflächen. Dies macht derartige Ausrüstung wesentlich für Cyberangriffe, was zu gestohlenen Daten von den verschiedenen Komponenten der Ausrüstung sowie Fehlfunktionen von Systemen in der Ausrüstung führen kann.
  • Lediglich beispielhaft ist es, obwohl die Automobilindustrie versucht, Komponenten (zum Beispiel elektronische Steuereinheiten (ECUs; ECU = Electronic Control Unit) und telematische Steuereinheiten (TCUs)) vor Cyberangriffen zu schützen, nötig zu bestätigen, dass diese Techniken effektiv zur Vermeidung von Cyberangriffen sind. Automobilhersteller müssen beispielsweise bestätigen können, dass ihre Implementierung verschiedener Komponenten, die Hardware, Firmware und Software beinhalten, in den verschiedenen ECUs und TCUs vor Cyberangriffen sicher sind.
  • Die Aufgabe der vorliegenden Erfindung besteht darin, ein verbessertes System zum Testen von Komponenten bereitzustellen, die empfindlich gegenüber Ausnutzung und Angriffen sind.
  • Diese Aufgabe wird gelöst durch ein System zum Testen einer Mehrzahl von Komponenten gemäß Anspruch 1.
  • Bevorzugte Ausführungsbeispiele der vorliegenden Erfindung werden nachfolgend Bezug nehmend auf die beigefügten Zeichnungen näher beschrieben. Es wird darauf hingewiesen, dass die verschiedenen Merkmale nicht notwendigerweise maßstabsgetreu sind, wobei tatsächlich die Abmessungen zur Klarheit der Erläuterung beliebig vergrößert oder verkleinert sein könnten. Außerdem beziehen sich, wo immer dies zutreffend und praktisch ist, gleiche Bezugszeichen auf gleiche Elemente. Es zeigen:
    • 1 ein vereinfachtes Blockdiagramm, das ein Automobil und seine Quellen einer Verbindbarkeit mit verschiedenen Typen von Kommunikationssystemen zeigt;
    • 2 ein vereinfachtes Blockdiagramm, das ein Testsystem, das ausgebildet ist, um offene Oberflächen in Komponenten in einem Automobil zu identifizieren, gemäß einem repräsentativen Ausführungsbeispiel zeigt;
    • 3 ein vereinfachtes Blockdiagramm einer Testautomatisierungsplattform gemäß einem repräsentativen Ausführungsbeispiel;
    • 4 ein vereinfachtes Blockdiagramm verschiedener Aspekte des Testsystems aus 2 gemäß einem repräsentativen Ausführungsbeispiel; und
    • 5 ein vereinfachtes Flussdiagramm eines Verfahrens zum Testen von Ausrüstung zur Identifizierung offener Oberflächen in Komponenten in einem Automobil gemäß einem repräsentativen Ausführungsbeispiel.
  • In der nachfolgenden ausführlichen Beschreibung sind zu Zwecken der Erläuterung und nicht der Einschränkung repräsentative Ausführungsbeispiele aufgeführt, die spezifische Einzelheiten offenbaren, um ein gründliches Verständnis eines Ausführungsbeispiels gemäß den vorliegenden Lehren zu ermöglichen. Beschreibungen bekannter Systeme, Vorrichtungen, Materialien, Betriebsverfahren und Herstellungsverfahren können ausgelassen werden, um eine Verschleierung der Beschreibung der repräsentativen Ausführungsbeispiele zu vermeiden. Nichtsdestotrotz befinden sich Systeme, Vorrichtungen, Materialien und Verfahren, die im Bereich eines Durchschnittsfachmanns auf dem Gebiet liegen, innerhalb des Schutzbereichs der vorliegenden Lehren und können gemäß den repräsentativen Ausführungsbeispielen verwendet werden. Es versteht sich, dass die hierin verwendete Terminologie lediglich zur Beschreibung bestimmter Ausführungsbeispiele dient und nicht als Einschränkung gedacht ist. Die definierten Begriffe sind zusätzlich zu den technischen und wissenschaftlichen Bedeutungen der definierten Begriffe, wie sie in dem technischen Gebiet der vorliegenden Lehren allgemein verstanden und akzeptiert werden.
  • Es versteht sich, dass, obwohl die Begriffe „erster/e/es“, „zweiter/e/es“, „dritter/e/es“ usw. hierin zur Beschreibung verschiedener Elemente oder Komponenten verwendet werden können, diese Elemente oder Komponenten nicht durch diese Begriffe eingeschränkt werden sollten. Diese Begriffe werden lediglich verwendet, um ein Element oder eine Komponente von einem anderen Element oder einer anderen Komponente zu unterscheiden. So könnte ein erstes Element oder eine erste Komponente, das bzw. die weiter unten erörtert wird, als zweites Element oder zweite Komponente bezeichnet werden, ohne von der Lehre der vorliegenden Offenbarung abzuweichen.
  • Die hierin verwendete Terminologie dient lediglich der Beschreibung bestimmter Ausführungsbeispiele und ist nicht als Einschränkung gedacht. Die Singularformen der Begriffe „ein/eine“ und „der/die/das“, wie dieselben in der Beschreibung und den beigefügten Ansprüchen verwendet werden, sollen sowohl Singular- als auch Pluralformen umfassen, sofern der Kontext nicht deutlich anderes festlegt. Zusätzlich legen die Begriffe „aufweist“ und/oder „aufweisen“ und/oder ähnliche Begriffe, wenn dieselben in dieser Beschreibung verwendet werden, das Vorhandensein von angegebenen Merkmalen, Elementen und/oder Komponenten fest, schließen jedoch nicht das Vorhandensein oder Hinzufügen eines oder mehrerer anderer Merkmale, Elemente, Komponenten und/oder Gruppen derselben aus. Der Begriff „und/oder“, wie derselbe hierin verwendet wird, umfasst sämtliche Kombinationen eines oder mehrerer der zugehörigen aufgeführten Punkte.
  • Sofern nicht anders angegeben, versteht es sich, dass, wenn ein Element oder eine Komponente als „verbunden mit“, „gekoppelt mit“ einem anderen Element oder einer anderen Komponente bezeichnet wird, das Element oder die Komponente direkt mit dem anderen Element oder der anderen Komponente verbunden oder gekoppelt sein kann oder dazwischenliegende Elemente oder Komponenten vorhanden sein können. Das heißt, diese und ähnliche Begriffe umfassen Fälle, in denen ein oder mehrere Zwischenelemente oder -komponenten verwendet werden können, um zwei Elemente oder Komponenten zu verbinden. Wenn jedoch ein Element oder eine Komponente als „direkt verbunden“ mit einem anderen Element oder einer anderen Komponente bezeichnet wird, umfasst dies lediglich Fälle, in denen die beiden Elemente oder Komponenten ohne Zwischenelemente bzw. -komponenten oder zwischengeschaltete Elemente bzw. Komponenten miteinander verbunden sind.
  • In Anbetracht des zuvor Genannten zielt die vorliegende Offenbarung durch eines oder mehrere ihrer verschiedenen Aspekte, Ausführungsbeispiele und/oder spezifischen Merkmale oder Teilkomponenten darauf ab, einen oder mehrere der Vorteile herauszustellen, wie weiter unten besonders erwähnt. Zur Erläuterung und nicht zur Einschränkung werden exemplarische Ausführungsbeispiele dargelegt, die spezifische Details offenbaren, um ein gründliches Verständnis eines Ausführungsbeispiels gemäß der vorliegenden Lehren zu ermöglichen. Andere mit der vorliegenden Offenbarung übereinstimmende Ausführungsbeispiele, die von den hierin offenbarten spezifischen Details abweichen, bleiben jedoch innerhalb des Schutzbereichs der beigefügten Ansprüche. Darüber hinaus können Beschreibungen bekannter Vorrichtungen und Verfahren ausgelassen werden, um die Beschreibung der exemplarischen Ausführungsbeispiele nicht zu verschleiern. Solche Verfahren und Vorrichtungen liegen innerhalb des Schutzbereichs der vorliegenden Offenbarung.
  • Der Begriff „offene Oberfläche“, wie er hierin verwendet wird, ist ein Punkt, an dem ein nicht autorisierter Benutzer (der „Angreifer“) versuchen kann, Daten in eine Umgebung einzugeben oder Daten aus derselben zu extrahieren. Eine offene Oberfläche wird, wie hierin noch vollständiger beschrieben wird, nach einem Entdeckungs- oder Erkundungs-(bzw. Reconnaissance-) Vorgang identifiziert.
  • Der Begriff „Angriffsoberfläche“, wie er hierin verwendet wird, ist eine Summe aller offenen Oberflächen.
  • Der Begriff „empfindliche Oberflächen“, wie er hierin verwendet wird, ist eine offene Oberfläche, die durch das System und Verfahren der vorliegenden Lehren durchbrochen wurde.
  • Verschiedene Ausführungsbeispiele der vorliegenden Offenbarung stellen Systeme, Verfahren und Vorrichtungen zum Ausführen eines Cybersicherheits-Penetrations- bzw. -Eindring-Testens zur Bestimmung dessen bereit, ob Komponenten eines Systems offene Oberflächen besitzen, die empfindlich gegenüber Cyberangriffen sind. Durch die vorliegenden Lehren wird eine Komponente zuerst einem Angriffsplan unterzogen, um zu bestimmen, ob sie empfindlich gegenüber einem neuen Angriff ist (das heißt, ob offene Oberflächen vorliegen). Abhängig von den Ergebnissen des Angriffsplans kann der Angriffsplan so aktualisiert werden, dass er neu entdeckte offene Oberflächen beinhaltet. Nachdem der Angriffsplan abgeschlossen wurde, wird ein Angriff auf die Komponente ausgeführt und wird aufgrund der Aktualisierung des Angriffsplans ein Regressionstest ausgeführt. Ein Bericht mit Erkenntnissen des Angriffs wird erstellt. Basierend auf dem Bericht können Maßnahmen getroffen werden, um die empfindlichen Oberflächen der Komponente zu beseitigen. Insbesondere wird basierend auf dem Bericht eine Datenbank so aktualisiert, dass sie empfindliche Oberflächen oder offene Oberflächen in der Komponente beinhaltet. Diese Datenbank wird kontinuierlich aktualisiert, so dass weitere Angriffe das aktuellste Wissen über Schwachstellen und Ausnutzung beinhalten.
  • Gemäß einem repräsentativen Ausführungsbeispiel ist ein Verfahren zum Testen einer Mehrzahl von Schaltungen zur Bestimmung offener Oberflächen offenbart. Das Verfahren weist Folgendes auf: Empfangen einer oder mehrerer Angriffstechniken und bekannter offener Oberflächen; Ausführen von Angriffen auf eine Schaltung zur Bestimmung empfindlicher Oberflächen der Schaltung; Bestimmen, wenn neue offene Oberflächen in der Schaltung vorliegen; Aktualisieren eines Angriffsplans basierend auf den neuen offenen Oberflächen; Ausführen des Angriffsplans; Erzeugen eines Berichts über die offenen und empfindlichen Oberflächen; und Aktualisieren eines Depots, um neue Angriffstechniken gegen neu entdeckte offene Oberflächen der Schaltung zu beinhalten.
  • Gemäß einem weiteren repräsentativen Ausführungsbeispiel ist ein System zum Testen einer Mehrzahl von Komponenten zur Bestimmung offener Oberflächen offenbart. Das System weist Folgendes auf: eine Testautomatisierungsplattform mit: einem Speicher, der ausführbare Befehle speichert; und einem Prozessor, der ausgebildet ist, um die von dem Speicher abgerufenen Befehle auszuführen. Bei Ausführung durch den Prozessor bewirken die Befehle, dass der Prozessor: eine oder mehr Angriffstechniken und bekannte offene Oberflächen empfängt; Angriffe auf eine Schaltung ausführt, um empfindliche Oberflächen der Schaltung zu bestimmen; bestimmt, wenn neue offene Oberflächen in der Schaltung vorliegen; einen Angriffsplan basierend auf den neuen offenen Oberflächen aktualisiert; den Angriffsplan ausführt; einen Bericht über die offenen und empfindlichen Oberflächen erzeugt; und ein Depot aktualisiert, um neue Angriffstechniken gegen die neu entdeckten offenen Oberflächen für die Schaltung zu beinhalten.
  • Ein nichtflüchtiges computerlesbares Speichermedium, das maschinenausführbare Befehle speichert, die auf einem Prozessor ausführbar sind, die bei Ausführung durch den Prozessor bewirken, dass der Prozessor ein Verfahren durchführt, dass Folgendes aufweist: Empfangen einer oder mehr Angriffstechniken und bekannter offener Oberflächen; Ausführen von Angriffen auf eine Schaltung zur Bestimmung empfindlicher Oberflächen der Schaltung; Bestimmen, wenn neue offene Oberflächen in der Schaltung vorliegen; Aktualisieren eines Angriffsplans basierend auf den neuen offenen Oberflächen; Ausführen des Angriffsplans; Erzeugen eines Berichts über die offenen und anfälligen Oberflächen; und Aktualisieren eines Depots, um neue Angriffstechniken gegen neu entdeckte offene Oberflächen der Schaltung zu beinhalten.
  • 1 zeigt ein vereinfachtes Blockdiagramm, das ein Kommunikationssystem 100 zeigt, das ein Automobil 101 und dessen Quellen einer Verbindbarkeit mit verschiedenen Typen von Kommunikationssystemen beinhaltet. Lediglich zur Veranschaulichung wird angemerkt, dass das Automobil über eine drahtlose Verbindung 102 mit einer Basisstation 103 verbunden sein kann. Die drahtlose Verbindung ist zur Veranschaulichung eine Long Term Evolution(LTE)-4G-Verbindung, obwohl auch andere Kommunikationsprotokolle infrage kommen. Die Basisstation ist mit einem Dienstanbieter 104 verbunden, der wiederum mit dem Internet 105 verbunden ist. Ein Automobil-OEM-Backend-(bzw. -Ausgangsseite-)System 106, das ein Datenzentrum des Automobilherstellers aufweist. Das OEM-Backend-System sammelt Telematik und hat Wechselwirkungen mit dem Automobil von dem Datenzentrum.
  • Innerhalb des Kommunikationssystems befindet sich das Automobil 101. Es wird darauf hingewiesen, dass das Testen der verschiedenen Komponenten des Automobils 101 lediglich veranschaulichend ist und dass andere Ausrüstung zum Testen gemäß den vorliegenden Lehren infrage kommt. Im Allgemeinen betrachten die vorliegenden Lehren viele Typen von Vorrichtungen, die Komponenten beinhalten, die entweder durch Angriffsoberflächen oder offene Oberflächen anfällig für einen Cyberangriff sind, wie unten erläutert wird. Lediglich zur Veranschaulichung und nicht einschränkend kann das Kommunikationssystem 100 anstelle des oder zusätzlich zu dem Automobil 101 ein Flugzeug, einen Zug, einen Bus, ein Boot oder ein Schiff aufweisen. Noch allgemeiner sind die vorliegenden Lehren auf Komponenten des sogenannten „Internets der Dinge“ (loT; Internet of Things) anpassbar. Diese und andere ähnliche Vorrichtungen und Ausrüstung können jeweils viele Komponenten aufweisen, die durch entweder Angriffsoberflächen oder offene Oberflächen anfällig für Cyberangriffe sind. Durch die vorliegenden Lehren kann ein Testen durch einen kontinuierlich aktualisierten Angriffsplan ausgeführt werden, um die Ergreifung geeigneter Maßnahmen zu ermöglichen, bevor ein Angriff gestartet wird.
  • Insbesondere können Verbindungen innerhalb des Automobils 101 oder zu dem Automobil 101 unter Verwendung verdrahteter Protokolle erstellt werden. Eine nicht einschränkende Liste dieser Typen verdrahteter Verbindungen und deren zugeordneter Protokolle ist in 1 gezeigt.
  • Wie zu erkennen sein wird, können Cyberangriffe, mit offenen Oberflächen verschiedener Komponenten des Automobils, ob nun durch eine drahtlose Verbindung oder eine verdrahtete Verbindung zu dem Automobil 101, erzeugt werden, wobei neue Angriffe mit alarmierender Häufigkeit auftreten.
  • Wie in 1 gezeigt ist, beinhaltet das Automobil 101 eine Mehrzahl von Komponenten, die alle anfällig für Cyberangriffe sind. Diese Komponenten beinhalten Hardware, Software, Firmware und/oder Kombinationen derselben und werden hierin allgemein Komponenten oder Schaltungen genannt. Wie in 1 gezeigt ist, kann das Automobil 101 eine Anzahl von ECUs und TCUs beinhalten. Jede ECU und TCU weist einen Mikroprozessor und einen Speicher auf, der Code/Befehle aufweist, der/die durch den Mikroprozessor ausführbar ist/sind, sowie gespeicherte Daten.
  • Das Automobil 101 kann Komponenten/Schaltungen, wie beispielsweise eine autointerne Luft-4G/LTE-Verbindbarkeitskomponente (OTA; over the air), eine Fahrzeugsicherheitskomponente (SEC), eine kopfseitige Einheit, mit der ein ECU-Bus verbunden ist (HEU), einen Global-Positionierungs-Empfänger (GPS), eine Wi-Fi-Komponente (Wireless Fidelity) unter IEEE 802.11 x, eine Verbindungskomponente mit Bluetooth/Bluetooth-Niedrigenergie (BT/BTLE) unter IEEE 802.15x, eine Nahfeldkommunikationskomponente (NFC) und eine zweckgebundene Kurzstreckenkommunikationskomponente (DSRC; DSRC = Dedicated Short Range Communication), aufweisen. Jede dieser Komponenten kann einen Speicher (nicht gezeigt) mit einem oder mehr Modulen aufweisen, wobei jedes derselben eine Menge entsprechender prozessorausführbarer Befehle aufweist, die einer bestimmten Funktion der Komponenten entsprechen.
  • Wie zu erkennen sein wird, ist jede dieser Komponenten des Automobils 101 aufgrund des Vorliegens offener Oberflächen anfällig für Cyberangriffe. Das Verfahren, das System und das nichtflüchtige computerlesbare Medium der vorliegenden Lehren ermöglichen die Bestimmung derartiger Schwachstellen in den Komponenten des Automobils 101, um zu ermöglichen, dass eine Handlung unternommen wird, um einen Cyberangriff an einer Angriffsoberfläche zu verhindern, oder Datenmanipulation oder Datendiebstahl an einer offenen Oberfläche. Vorteilhafterweise werden gemäß verschiedenen repräsentativen Ausführungsbeispielen die Angriffspläne kontinuierlich aktualisiert, was ein neues zusätzliches Testen der Komponenten in hierin beschriebenen Weisen ermöglicht. Insbesondere ziehen die vorliegenden Lehren auch einen Regressionstest in Betracht, der eine Wiederholung eines vorherigen Tests ist. Die aktualisierten Angriffspläne beinhalten neu entdeckte Angriffstechniken, die eine zusätzliche aufgebaute, größere sind, wobei diese, nachdem sie einmal gelaufen sind, später für einen Regressionstest verwendet werden.
  • 2 ist ein vereinfachtes Blockdiagramm, das ein Testsystem 200, das ausgebildet ist, um offene Oberflächen in Komponenten in einem Automobil zu identifizieren, gemäß einem repräsentativen Ausführungsbeispiel zeigt. Gewisse Aspekte des Kommunikationssystems 100, die in Verbindung mit 1 beschrieben sind, können auch Aspekten des Testsystems 200 entsprechen und werden nicht notwendigerweise wiederholt.
  • Das Testsystem 200 weist eine Unternehmensplattform 201 auf, die einen Speicher für Testberichte 202 aufweist. Im Allgemeinen koordiniert die Unternehmensplattform 201 das nachfolgende Testen durch das Testsystem 200 zu testender Komponenten.
  • Das Testsystem weist ferner eine Testautomatisierungsplattform (TAP) 203 auf. Die TAP 203 weist eine Regressionstestfolge 204 auf, die in deren Speicher gespeichert ist. Wie unten eingehender beschrieben ist, weist die TAP 203 einen Prozessor (in 2 nicht gezeigt) und einen Speicher auf, der Computercode/Befehle aufweist, der/die bei Ausführung durch den Prozessor die gesamte Verbindbarkeit zwischen verschiedenen Hardwarekomponenten des Testsystems 200 ausführt/ausführen. Diese Codes beinhalten protokollspezifische Bibliotheken, die die Verbindung unterschiedlicher Schichten des Testsystems 200 ermöglichen, sind jedoch nicht darauf eingeschränkt.
  • Bei einem veranschaulichenden Ausführungsbeispiel weist die Unternehmensplattform Code/Befehle auf, der/die in einem Speicher gespeichert ist/sind, der auf einem Prozessor in der Unternehmensplattform laufen kann, oder auf dem Prozessor für die TAP 203. Bei einem großen Unternehmen kann es eine Mehrzahl von TAPs (nicht gezeigt) geben, die zum Komponententesten verwendet werden, da es unterschiedliche Quellen zu testender Komponenten gibt. Beispielsweise, bei repräsentativen Ausführungsbeispielen, die auf ein Testen eines Automobils gerichtet sind, ECU-Testen unter Verwendung der Mehrzahl von TAPs, da ECUs für unterschiedliche Funktionen des Automobils entwickelt werden (zum Beispiel Motorsteuerung, unterstütztes Fahren, Körper und Chassis usw.) und eine Unternehmensplattform, die Testergebnisse für jede TAP festigt. Diese Unternehmensplattform visualisiert den Entwurf (Netz) aller ECUs eines Autos und visualisiert die Ergebnisse des individuellen ECU-Testens. So greift die Unternehmensplattform auf die Ergebnisse der einzelnen Ergebnisse für jede ECU (die durch eine der Mehrzahl von TAPs ausgeführt wurde) durch Verbinden mit den einzelnen TAP-Datenbanken über die Netzstruktur des Kunden zu.
  • Das Testsystem 200 weist außerdem einen IP/Mobilfunknetz-Emulator (Netzemulator) 206 und einen WiFi-Bluetooth-Station-Emulator (Stationsemulator) 207 auf. Wie im Folgenden eingehender beschrieben ist, weisen der Emulator 206 und der Stationsemulator Hardware und Software auf, die Kommunikationen mit den zu testenden Komponenten ermöglichen. Der Emulator 206 weist Hardwarekomponenten (zum Beispiel einen Netzemulator, einen WiFi-Bluetooth-Station-Emulator) auf, die protokollspezifische Verbindbarkeits-Übergänge bzw. -Gateways sind. Diese Komponenten liefern die Hardware-HW-Schnittstelle, die eine Verbindung zu den spezifischen Schnittstellen in dem zu testenden Objekt (DUT; DUT = Device under Test) herstellt. So ist ein Ende des Gateways protokollspezifisch (Verbindung in Richtung des DUT) und das andere ist generisch (zum Beispiel eine TCP/IP-Schnittstelle unter Verwendung eines RJ45-Verbinders), das eine Verbindung zu dem Computer herstellt, der die Angriffe ausführt.
  • Das Testsystem 200 weist außerdem Sicherheits-Werkzeug bzw. ein -Toolkit 208 auf. Das Sicherheits-Werkzeug 208 kann ein oder mehrere maschinenlesbare nichtflüchtige Speichermedien, wie zum Beispiel Nur-Lese-Speicher (ROM), Direktzugriffsspeicher (RAM), Magnetplattenspeichermedien, optische Speichermedien, Flash-Speichermedien oder ähnliche Speichermedien, aufweisen. Bei verschiedenen Ausführungsbeispielen speichert das Sicherheits-Werkzeug 208 Code/Befehle in dem Speicher zur Ausführung durch den Prozessor der TAP 203. Das Sicherheits-Werkzeug 208 ist eine Ausführungsmaschine, die durch den Prozessor der TAP 203 laufengelassen wird und die verschiedene Angriffe basierend auf Code/Befehlen ausführt, der/die in einer Sicherheits-Testfolge (Testfolge) 209 gespeichert ist/sind, und eine Anwendungs- und Bedrohungsanalyse-Datenbank 210.
  • Die Anwendungs- und Bedrohungsanalyse-Datenbank 210 ist ein Sicherheitsanalyse-Datenbank-Dienst, der ein Depot bekannter Signaturen/Details über Schadprogramme und Schwachstellen beinhaltet, so dass das Sicherheits-Werkzeug 208 Angriffe zur Bestimmung offener Oberflächen der zu testenden Komponenten ausführen kann. Die Anwendungs- und Bedrohungsanalyse-Datenbank beinhaltet die Definitionen derartiger Schwachstellen (auf Metadatenebene, Beschreibung der Schwachstellen auf hoher Ebene). Andererseits weist die Sicherheitstestfolge 209 Code/Befehle auf, der/die durch das Sicherheits-Werkzeug 208 auf dem Prozessor ausgeführt wird/werden. Allgemeiner weist die Testfolge Angriffspläne auf, die unten eingehender erläutert werden, die spezifisch für die zu testende/n Komponente/n sind.
  • Da die Tests auf durch das Testsystem 200 zu testenden Komponenten laufen, werden Signaturen/Details von Schadprogrammen und Schwachstellen, die in der Anwendungs- und Bedrohungsanalyse-Datenbank 210 und der Sicherheitstestfolge 209 gespeichert sind, durch das Sicherheits-Werkzeug 208 ausgeführt, um offene Oberflächen auf der zu testenden Komponente zu entdecken. Außerdem werden für neu entdeckte offene Oberflächen neue Testfälle zu der Regressions-Testfolge hinzugefügt und gegenüber den offenen Oberflächen ausgeführt, und zwar während einer Ausführung des Testsystems 200. Insbesondere wird ein Testfall auf einem DUT (zum Beispiel ECU, TCU) ausgeführt und endet mit einem Ergebnis. Ein Angriff ist ein Typ eines Testfalls; wobei es auch Scan- oder Erkundungstyp-Testfälle gibt.
  • Außerdem werden die neuen Testfälle ausgeführt und auf die Entdeckung eines neuen Angriffs oder neuer Oberflächen während einer Ausführung des Testsystems 200 hin zu der Regressionstestfolge 204 hinzugefügt.
  • Zur Veranschaulichung kann die Anwendungs- und Bedrohungsanalyse-Datenbank 210 ein oder mehrere maschinenlesbare nichtflüchtige Speichermedien, wie beispielsweise Nur-Lese-Speicher (ROM), Direktzugriffsspeicher (RAM), Magnetplatten-Speichermedien, optische Speichermedien, Flash-Speichervorrichtungen oder ähnliche Speichermedien, aufweisen. Bei verschiedenen Ausführungsbeispielen kann die Anwendungs- und Bedrohungsanalyse-Datenbank 210 Befehle zur Ausführung durch den Prozessor, der in der TAP 203 vorgesehen ist, oder Daten speichern, mit denen der Prozessor arbeiten kann (alleine oder in Verbindung mit dem Sicherheits-Werkzeug 208 und der Sicherheits-Testfolge 209).
  • Wie in 2 gezeigt ist, weist das Testsystem 200 eine Hardware in der Schleife (HIL; Hardware in the Loop) 219 auf. Die HIL 219 ist ein kommerzielles System, das es ermöglicht, dass die ECUs und TCUs außerhalb eines Fahrzeugs arbeiten können. Das System der HIL 219 kann durch die TAP 203 ausgebildet und gesteuert werden und ermöglicht es so dem Benutzer, den Vorgang des Laufenlassens von Angriffen gegen die jeweiligen DUTs zu automatisieren.
  • Das Testsystem 200 ist ausgebildet, um Angriffe durch eine TCU 213 und ein Gateway 215 auf eine Test-ECU 216 eines fahrzeuginternen Netzes 221 zu starten. Dieses Testsystem 200 ist außerdem ausgebildet, um Angriffe durch den Stationsemulator 207 über eine Netzzugriffsvorrichtung (NAD; Network Access Device) zu starten.
  • Das fahrzeuginterne Netz 221 ist ein Netz von Komponenten (zum Beispiel ECUs), die in einem Fahrzeug am Ort der Herstellung zu finden sind. Durch Ausführen der Angriffe auf das fahrzeuginterne Netz 221 werden offene Oberflächen der Test-ECU (oder einer anderen Komponente) identifiziert und können heilende Maßnahmen unternommen werden.
  • Wie in 2 gezeigt ist, kommt das Testsystem 200 der vorliegenden Lehren zur Verwendung mit einem Automobil 220 nach Fertigstellung der Produktion oder während routinemäßiger Wartung in Betracht. So können durch die vorliegenden Lehren Fahrzeugnetzschnittstellen vor einer Verwendung in dem Automobil 220 und nachdem das Automobil in Dienst genommen wurde, getestet werden. Wie oben angemerkt wurde und im Folgenden eingehender beschrieben ist, ist das Testsystem der vorliegenden Lehren ausgebildet, um kontinuierlich mit den neuesten Signaturen/Details von Schadprogrammen und einer Schwachstelle aktualisiert zu werden, so dass Angriffe, die durch das Testsystem 200 auf die zu testenden Komponenten durchgeführt werden, regelmäßig aktualisiert werden können, um offene Oberflächen auf den Komponenten zu identifizieren und zu entdecken, so dass heilende Schritte unternommen werden können.
  • 3 ist ein vereinfachtes Blockdiagramm einer Testautomatisierungsplattform (TAP) 300 gemäß einem repräsentativen Ausführungsbeispiel. Die Testautomatisierungsplattform 300 kann als die TAP 203 in dem Testsystem 200 implementiert sein, das oben in Verbindung mit 2 beschrieben wurde. Bestimmte Aspekte der TAP 300, die in Verbindung mit den 1 und 2 beschrieben wurden, können auch Aspekten der TAP 300 entsprechen und werden nicht notwendigerweise wiederholt.
  • Die TAP 300 weist einen Prozessor 301, einen Speicher 302, der einen Angriff speichert, der momentan abläuft, und eine Regressionstestfolge 303 auf. Der Prozessor 301 ist angepasst, um Code/Instruktionen, der/die in einer Datenbank 304 gespeichert ist/sind, über Protokollschichten 305, sowie eine Benutzerschnittstelle auszuführen. Die Testautomatisierungsplattform 300 kommuniziert mit verschiedenen Komponenten unter Verwendung eines Kommunikationsbus 307.
  • Gemäß einem repräsentativen Ausführungsbeispiel weist die Datenbank 304 das Sicherheits-Werkzeug 208, die Sicherheitstestfolge 209, die Anwendungs- und Bedrohungsanalyse-Datenbank 210, die Kundenbedrohungsbibliothek 211 und eine Kundenbedrohungsdatenbank 212 auf. Wie oben erwähnt wurde, laufen Tests an durch das Testsystem 200 zu testenden Komponenten und Signaturen/Details von Schadprogrammen und Schwachstellen, die in der Datenbank 304 gespeichert sind (zum Beispiel der Anwendungs- und Bedrohungsanalyse-Datenbank 210 und der Sicherheitstestfolge 209), werden durch den Prozessor 301 unter Verwendung der Software des Sicherheits-Werkzeugs 208 ausgeführt, um offene Oberflächen an der zu testenden Komponente zu entdecken.
  • Der Prozessor 301 kann eine beliebige Hardwarevorrichtung sein, die in der Lage ist, Befehle, die in dem Speicher 302 und der Datenbank 304 gespeichert sind, auszuführen und Rohdaten anderweitig zu verarbeiten. Der Prozessor 301 kann die Befehle zur Implementierung eines Teils von oder aller hierin beschriebener Verfahren ausführen. Zusätzlich kann der Prozessor 301 unter mehreren Vorrichtungen verteilt sein, zum Beispiel zur Unterbringung von Verfahren, die notwendigerweise in einer verteilten Weise implementiert sind, die mehrere Sätze von Speicher/Prozessor-Kömbinationen erforderlich macht.
  • Der Prozessor 301 ist greifbar und nichtflüchtig und ist repräsentativ für einen oder mehrere Prozessoren. Der Begriff „nichtflüchtig“, wie er hierin verwendet wird, soll nicht als ewige Charakteristik eines Zustands interpretiert werden, sondern als eine Charakteristik eines Zustands, die für einen Zeitraum andauert. Der Begriff „nichtflüchtig“ erkennt spezifisch fliehende Charakteristika, wie beispielsweise Charakteristika einer Trägerwelle oder eines Signals oder anderer Formen, die nur vorübergehend an einem bestimmten Ort zu einer bestimmten Zeit vorkommen, nicht an. Ein Prozessor ist ein Herstellungsgegenstand und/oder eine Maschinenkomponente. Der Prozessor 301 der TAP 300 ist ausgebildet, um Softwarebefehle auszuführen, um Funktionen, die in den verschiedenen Ausführungsbeispielen hierin beschrieben sind, durchzuführen. Der Prozessor 301 kann ein Universalprozessor sein oder kann Teil einer anwendungsspezifischen integrierten Schaltung (ASIC) sein. Der Prozessor 301 kann auch ein Mikroprozessor, ein Mikrocomputer, ein Prozessorchip, eine Steuerung, eine Mikrosteuerung, ein Digitalsignalprozessor (DSP), eine Zustandsmaschine oder ein programmierbares Logikbauelement sein (oder beinhalten). Der Prozessor 301 kann auch eine logische Schaltung, einschließlich eines programmierbaren Gate-Arrays (PGA), wie zum Beispiel ein frei programmierbares Gate-Array (FPGA), oder ein anderer Typ von Schaltung, die diskrete Gate- und/oder Transistor-Logik beinhaltet, sein (oder beinhalten). Der Prozessor 301 kann eine zentrale Verarbeitungseinheit (CPU), eine Grafikverarbeitungseinheit (GPU) oder beides sein. Zusätzlich kann ein hierin beschriebener Prozessor mehrere Prozessoren, parallele Prozessoren oder beides beinhalten. Mehrere Prozessoren können in einer einzelnen Vorrichtung oder mehreren Vorrichtungen beinhaltet oder mit dieser/diesen gekoppelt sein.
  • Der Speicher 302 und die Datenbank 304 können verschiedene Speicher beinhalten, wie beispielsweise einen Cache- oder Systemspeicher. So können der Speicher 302, die Regressions-Testfolge 303 und die Datenbank 304 jeweils statischen Direktzugriffspeicher (SRAM), dynamischen RAM (DRAM), Flash-Speicher, Nur-Lese-Speicher (ROM) oder andere ähnliche Speichervorrichtungen beinhalten, wie unten mit oben in Verbindung mit dem Testsystem 200 und unten erläutert ist. Es ist zu erkennen, dass bei Ausführungsbeispielen, bei denen der Prozessor eine oder mehrere ASICs (oder andere Verarbeitungsvorrichtungen) beinhaltet, die eine oder mehrere der hierin beschriebenen Funktionen in Hardware implementieren, die Software, die bei anderen Ausführungsbeispielen als dieser Funktionalität entsprechend beschrieben ist, weggelassen werden kann. Dies bedeutet, dass der Speicher 302, die Regression-Testfolge 303 und die Datenbank 304 jeweils Befehle zur Ausführung durch den Prozessor 301 und/oder Daten, an denen der Prozessor 301 arbeiten kann, speichern kann.
  • Der Speicher 302 kann verschiedene Module beinhalten, die jeweils einen Satz verwandter prozessorausführbarer Befehle aufweisen, die einer bestimmten Funktion der TAP 300 entsprechen.
  • Die Datenbank 304 kann ein oder mehrere maschinenlesbare nichtflüchtige Speichermedien, wie beispielsweise Nur-Lese-Speicher (ROM), Direktzugriffspeicher (RAM), Magnetplatten-Speichermedien, optische Speichermedien, Flash-Speichervorrichtungen oder ähnliche Speichermedien, beinhalten. Bei verschiedenen Ausführungsbeispielen kann die Datenbank 304 Befehle zur Ausführung durch den Prozessor 301 oder Daten speichern, an denen der Prozessor 301 arbeiten kann (alleine oder in Verbindung mit dem Speicher 302 und der Regressionstestfolge 303).
  • Die Benutzerschnittstelle 306 kann eine oder mehrere Vorrichtungen zum Ermöglichen einer Kommunikation mit einem Benutzer aufweisen. Die Benutzerschnittstelle 306 weist eine grafische Benutzerschnittstelle (GUI; Graphical User Interface) und eine Anwendungsprogrammierschnittstelle (API; Application Programming Interface) auf. Die GUI ermöglicht es Benutzern, über grafische Darstellung einer Systemkonfiguration und -einstellung mit der TAP 300 in Wechselwirkung zu stehen. Die API ermöglicht es einem Benutzer, über einen Satz programmierbarer Anweisungen mit der TAP 300 in Wechselwirkung zu stehen. So liefert die API eine Programmierschnittstelle, um es Benutzern zu ermöglichen, die Lösung in ihre eigene Umgebung zu integrieren, und um außerdem die Integration kundenspezifischer Angriffs- und Bedrohungsbibliotheken zu ermöglichen. Die Schnittstelle kann außerdem verwendet werden, um das System für zukünftige Protokolle, sowohl verdrahtet als auch drahtlos, zu erweitern.
  • Die Protokollschichten 305 sind in dem IP/Mobilfunknetz-Emulator (Netzemulator) 206 und dem Wi-Fi-Bluetooth-Station-Emulator (Stationsemulator) 207 angeordnet. Es wird angemerkt, dass diese Protokolle lediglich veranschaulichend sind und andere Kommunikationsprotokolle im Bereich des durchschnittlichen Fachmanns in Betracht kommen. Wie hierin eingehender beschrieben ist, weisen die Protokollschichten 305 des Emulators 206 und des Stationsemulators 207 Hardware und Software auf, die Kommunikationen mit den zu testenden Komponenten ermöglichen und Kommunikationen zwischen der TAP 203, der Datenbank 304 und den zu testenden Komponenten ermöglichen.
  • 4 ist ein vereinfachtes Blockdiagramm eines Testsystems 400 gemäß einem repräsentativen Ausführungsbeispiel. Bestimmte Aspekte des Testsystems 400, die in Verbindung mit den 1-3 beschrieben sind, können Aspekten des Testsystems 400 entsprechen und werden nicht notwendigerweise wiederholt.
  • Das Testsystem 400 weist einen Verwaltungsserver 401, der veranschaulichend eine TAP aufweist, und eine optionale Unternehmensplattform auf, wie gezeigt ist. Die verschiedenen Funktionen des Verwaltungsservers 401 sind in einer Unternehmens- und Penetrations-Testplattform 402 gezeigt und sind unten erläutert. Das Testsystem weist außerdem einen Erkundungs- und Fuzzing(RF)-Server 403 auf. Die verschiedenen Funktionen des RF-Servers 403 sind in einer kommunikationsprotokollspezifischen Bibliothek 404 gezeigt und sind unten erläutert.
  • Das Testsystem weist ferner ein Hardware-Gateway zur Verbindung mit zu testenden Komponenten auf, wie in den 1 und 2 gezeigt ist. Das Hardware-Gateway beinhaltet veranschaulichend eine zellulare Schnittstelle 405, eine Wi-Fi-BT-Schnittstelle 406, eine Ethernet-Port-Schnittstelle 407, eine Zigbee-Schnittstelle 408, eine Universal-Seriell-Bus-Schnittstelle 409, ein Steuerungsbereichsnetz 410 und eine Automobil-Ethernet-Schnittstelle 411. Es wird hervorgehoben, dass die verschiedenen Schnittstellen der Hardware lediglich veranschaulichend sind und mehr oder weniger Schnittstellen in Betracht kommen. Allgemeiner sind die betrachteten Schnittstellen aufgabenspezifisch, wobei jede Schnittstelle vorgesehen ist, um Kommunikationen unter Verwendung eines erwünschten Protokolls auszuführen.
  • Die Unternehmens- und Penetrations(PEN)-Testplattform (PEN = 402 ist eine veranschaulichende Darstellung der verschiedenen Komponenten des Verwaltungsservers 401. Diese Komponenten beinhalten die TAP, wie oben in Verbindung mit den 2 und 3 beschrieben ist, sind jedoch nicht darauf eingeschränkt. Insbesondere beinhaltet die Unternehmens- und Penetrations-Testplattform 402 den oben in Verbindung mit 3 beschriebenen Prozessor. Unter anderen Funktionen führt die TAP eine Verbindbarkeit zwischen verschiedenen Komponenten aus und führt Code//Befehle aus, der/die im oben erläuterten Sicherheits-Werkzeug gespeichert ist/sind. Allgemeiner liefert die Unternehmens- und Penetrations-Testplattform 402 des Verwaltungsservers 401 den gesamten und offenen Verwaltungsrahmen und führt eine Verbindbarkeit, Erkundung (hierin auch als „Entdeckung“ bezeichnet), Fuzzing, Testplanerzeugung, Testplanausführung und - berichterstattung aus.
  • Die kommunikationsprotokollspezifische Bibliothek 404 ist eine veranschaulichende Darstellung der verschiedenen Komponenten des RF-Servers 403. Die kommunikationsprotokollspezifische Bibliothek 404 weist verschiedenen protokollspezifische Bibliotheken auf und beinhaltet beispielsweise das Sicherheits-Werkzeug, die Sicherheits-Testfolge, die Anwendungs- und Bedrohungsanalyse-Datenbank und kann die Kundenbedrohungsbibliothek und die Kundenbedrohungsdatenbank, die oben in Verbindung mit den repräsentativen Ausführungsbeispielen aus 2 erläutert sind, beinhalten. Die kommunikationsprotokollspezifische Bibliothek 404 stellt ein Scannen bzw. Abtasten, Fuzzing und Angriffe bereit, die durch den Prozessor der TAP ausgeführt werden. Diese Funktionen werden durch die verschiedenen Hardware-Gateway-Vorrichtungen ausgeführt, die zur Verbindung mit zu testenden Komponenten verwendet werden.
  • Die PEN-Testplattform 402 automatisiert den Vorgang des Auskundschaftens von Schwachstellen durch die unterschiedlichen Angriffsoberflächen des DUT zu einem maximalen Ausmaß. Naturgemäß bleiben einige Elemente des Ausnutzungsvorgangs ein manueller Vorgang (wie zum Beispiel Einrichten einer Verbindbarkeit), während der Großteil arbeitsintensiver Vorgänge in automatisierter Weise ausgeführt wird (zum Beispiel Ausnutzung). Ergebnisse dieser Aktivitäten werden durch automatisiertes Berichten bereitgestellt.
  • 5 ist ein Flussdiagramm, das einen Vorgang 500 zum Durchführen eines Tests an einer Komponente gemäß einem repräsentativen Ausführungsbeispiel zeigt. Bestimmte Aspekte des Vorgangs 500 entsprechen denjenigen, die bei den repräsentativen Ausführungsbeispielen beschrieben wurden, die in Verbindung mit den 1-4 beschrieben wurden. Viele gemeinsame Aspekte des Vorgangs 500 werden nicht notwendigerweise wiederholt.
  • Eine Anwendungs- und Bedrohungsanalyse-Automobil-Angriff-Datenbank 501 ist für den Vorgang 500 vorgesehen. Die Anwendungs- und Bedrohungsanalyse-Automobil-Angriff-Datenbank weist beispielsweise die Sicherheitstestfolge und die Anwendungs- und Bedrohungsanalyse-Datenbank auf, die oben beschrieben wurden. Insbesondere wird die Anwendungs- und Bedrohungsanalyse-Automobil-Angriff-Datenbank 501 durch Berichte aktualisiert, die durch den Vorgang 500 bereitgestellt werden, sowie durch den Abruf von Signaturen/Details von Schadprogrammen und Schwachstellen von externen Quellen (nicht gezeigt).
  • Wahlweise ist eine Kundenangriffsdatenbank 502 für den Vorgang 500 vorgesehen. Die Kundenangriffsdatenbank 502 weist beispielsweise die Kundenbedrohungsbibliothek und die Kundenbedrohungsdatenbank auf, die oben beschrieben wurden. Insbesondere kann die Kundenangriffsdatenbank 502 durch den Kunden durch den Abruf von Signaturen/Details von Schadprogrammen und Schwachstellen von verschiedenen Quellen (nicht gezeigt) aktualisiert werden. Insbesondere können Benutzer die Kundenangriffsdatenbank 502 über Verfassen und Automatisierung eines Skripts erzeugen und aktualisieren.
  • Daten und Code/Befehle von der Anwendungs- und Bedrohungsanalyse-Automobil-Angriff-Datenbank 501 und wahlweise von der Kundenangriffsdatenbank 502 bilden einen Angriffsplan 503. Im Allgemeinen wird der Angriffsplan 503 durch das Sicherheits-Werkzeug ausgeführt, wie oben beschrieben wurde. Der Vorgang 500 stellt außerdem eine Entdeckungssequenz 504 bereit. Die Entdeckungssequenz 504 führt ein Anfangstesten an der zu testenden Komponente durch, um zu bestimmen, ob Angriffsoberflächen, oder offene Oberflächen oder beides vorliegen, die nicht in dem Angriffsplan 503 aufgelistet sind.
  • Die Entdeckungssequenz 504 (auch Erkundung genannt) verwendet Verfahren, die durch jedes der Verbindbarkeitsbrückenprotokolle bereitgestellt werden, die Informationen über offenen Oberflächen offenbaren. Diese offenen Oberflächen werden abgefragt und, falls angesprochen wird, untersucht, um zu bestimmen, wenn der Dienst an einem offenen Port bekannt ist. Ein Dienst ist üblicherweise ein Vorgang mit einem Zweck der Unterstützung des Systems, wie ein Web-Dienst, der Webseiten liefert. Lediglich beispielhaft ist ein IP-Port-Scannen ein veranschaulichendes Verfahren zum Abfragen möglicher offener Ports des Systems. Wenn ein offener Port identifiziert wird, werden Ausnutzungsdienste gemäß den vorliegenden Lehren und spezifischen Details zu diesem Port ausgeführt.
  • Wenn keine neuen Angriffsoberflächen oder offene Oberflächen in der Entdeckungssequenz 504 entdeckt werden, fährt der Vorgang 500 mit dem Angriff 505 fort, der die Ausführung der Sicherheitstestfolge durch das Werkzeug aufweist, wie oben beschrieben wurde. Nach Abschluss des Angriffs 505 werden Berichterkenntnisse 506 erzeugt und die Technik spricht bei Schritt 507 an, um mögliche Angriffsoberflächen oder offene Oberflächen, die während des Angriffs 505 gefunden werden, zu heilen.
  • Wenn neue Angriffsoberflächen oder offene Oberflächen in der Entdeckungssequenz 504 entdeckt werden, fährt der Vorgang 500 damit fort, den Angriffsplan zu aktualisieren. Nach Abschluss des Angriffs 505 werden Berichterkenntnisse 506 erzeugt und die Technik spricht bei Schritt 507 an, um mögliche Angriffsoberflächen oder offene Oberflächen, die während des Angriffs 505 gefunden werden, zu heilen. Insbesondere wird der Bericht, der die neu entdeckten Angriffsoberflächen oder offenen Oberflächen oder beides beinhaltet, an die Anwendungs- und Bedrohungsanalyse-Automobil-Angriff-Datenbank 501 geliefert, und dann zurück zu dem Angriffsplan 503. Die neuen aufgedeckten Angriffe werden in der Regressionstestfolge gespeichert, die oben beschrieben wurde.
  • Schließlich fährt der Vorgang mit einem Neuaufbau 508 einer Komponente (zum Beispiel ECU oder Automobil mit vielen Komponenten) zum Testen fort.
  • Gemäß verschiedenen Ausführungsbeispielen der vorliegenden Offenbarung können die hierin beschriebenen Verfahren unter Verwendung eines Hardware-Computersystems implementiert sein, das Softwareprogramme ausführt. Außerdem können bei einem exemplarischen nicht eingeschränkten Ausführungsbeispiel Implementierungen verteilte Verarbeitung, verteilte Komponenten/Objekt-Verarbeitung und Parallel-Verarbeitung beinhalten. Eine virtuelle Computersystemverarbeitung kann aufgebaut sein, um ein oder mehrere der Verfahren oder Funktionalitäten, die hierin beschrieben sind, zu implementieren, und ein hierin beschriebener Prozessor kann verwendet werden, um eine virtuelle Verarbeitungsumgebung zu unterstützen.
  • Wie oben beschrieben wurde, soll die vorliegende Offenbarung nicht im Hinblick auf die bestimmten Ausführungsbeispiele, die in dieser Anmeldung beschrieben sind, eingeschränkt sein, die als Veranschaulichungen verschiedener Aspekte gedacht sind. Viele Modifizierungen und Abänderungen können durchgeführt werden, ohne von dem Schutzbereich und der Wesensart abzuweichen, wie zu erkennen sein wird. Funktionell gleichwertige Verfahren und Vorrichtungen innerhalb des Schutzbereichs der Offenbarung zusätzlich zu denjenigen, die hierin aufgezählt sind, können aus den vorstehenden repräsentativen Beschreibungen ersichtlich werden. Derartige Modifizierungen und Abänderungen sollen in den Schutzbereich der beigefügten repräsentativen Ansprüche fallen. Die vorliegende Offenbarung soll lediglich durch die Begriffe der beigefügten repräsentativen Ansprüche zusammen mit dem vollen Schutzbereich von Entsprechungen eingeschränkt sein, zu denen diese repräsentativen Ansprüche berechtigen. Es wird außerdem darauf hingewiesen, dass die hierin verwendete Terminologie lediglich dem Zweck der Beschreibung bestimmter Ausführungsbeispiele dient und nicht einschränkend sein soll.
  • Im Hinblick auf die Verwendung im Wesentlichen aller Plural- und/oder Singular-Ausdrücke hierin können Fachleute auf diesem Gebiet den Plural in den Singular und/oder den Singular in den Plural übersetzen, wie dies für den Kontext und/oder die Anwendung geeignet ist. Die verschiedenen Singular/Plural-Permutationen können hierin ausdrücklich aus Gründen der Klarheit dargelegt sein.
  • Es ist für Fachleute auf diesem Gebiet zu erkennen, dass die hierin verwendeten Ausdrücke, insbesondere in den beigefügten Ansprüchen (zum Beispiel Körper der beigefügten Ansprüche) im Allgemeinen als „offene“ Ausdrücke gedacht sind (beispielsweise soll der Ausdruck „beinhalten“ als „beinhalten, jedoch nicht eingeschränkt sein auf“ interpretiert werden, der Ausdruck „haben“ soll als „zumindest ... haben“ interpretiert werden, der Ausdruck „aufweisen“ soll als „aufweisen jedoch nicht eingeschränkt sein auf“ interpretiert werden, usw). Außerdem wird für Fachleute auf diesem Gebiet zu erkennen sein, dass, wenn eine spezifische Zahl einer eingeführten Anspruchsnennung beabsichtigt ist, eine derartige Absicht ausdrücklich in dem Anspruch genannt sein kann, wobei ohne eine derartige Nennung keine derartige Absicht besteht.
  • Die vorstehende Beschreibung wurde zusammen mit ihren zugeordneten Ausführungsbeispielen lediglich zur Veranschaulichungszwecken vorgelegt. Sie ist weder ausschließlich noch schränkt sie die hierin offenbarten Konzepte auf ihre genaue offenbarte Form ein. Fachleute auf diesem Gebiet können aus der vorstehenden Beschreibung ersehen, dass Modifizierungen und Abänderungen angesichts der obigen Lehren möglich sind oder aus einer Praktizierung der offenbarten Ausführungsbeispiele erhalten werden können. Beispielsweise müssen die beschriebenen Schritte nicht in der gleichen erläuterten Reihenfolge oder mit dem gleichen Maß an Trennung durchgeführt werden. Ähnlich können verschiedene Schritte wie nötig weggelassen, wiederholt oder kombiniert werden, um die gleichen oder ähnliche Ziele zu erreichen. Entsprechend ist die vorliegende Offenbarung nicht auf die oben beschriebenen Ausführungsbeispiele eingeschränkt, sondern ist stattdessen durch die beigefügten Ansprüche angesichts ihres vollständigen Bereichs an Entsprechungen definiert.
  • Vorstehend wurden verschiedene repräsentative Ausführungsbeispiele unter Bezugnahme auf die beigefügten Zeichnungen beschrieben. Es ist jedoch deutlich, dass verschiedene Modifizierungen und Änderungen an denselben vorgenommen werden können und zusätzliche Ausführungsbeispiele implementiert werden können, ohne von dem breiteren Schutzbereich der erfindungsgemäßen Konzepte abzuweichen, die wie in den folgenden Ansprüchen dargelegt hierin offenbart sind. Die Beschreibung und die Zeichnungen sollen entsprechend in einem veranschaulichenden, und nicht einschränkenden Sinn aufgefasst werden.
  • Obwohl ein System und ein Verfahren zum Testen einer Mehrzahl von Schaltungen zur Bestimmung offener Oberflächen und Angriffsoberflächen unter Bezugnahme auf eine Anzahl veranschaulichender Ausführungsbeispiele beschrieben wurden, wird darauf hingewiesen, dass die verwendeten Worte Worte der Beschreibung und Veranschaulichung, und nicht Worte der Einschränkung sind. Änderungen können innerhalb des Bereichs der beigefügten Ansprüche durchgeführt werden, wie sie vorliegend genannt und auch abgeändert sind, ohne von dem Schutzbereich und der Wesensart des Systems und Verfahrens zur optimalen Sensorplatzierung in deren Aspekten abzuweichen. Obwohl das System und das Verfahren zur optimalen Sensorplatzierung Bezug nehmend auf bestimmte Einrichtungen, Materialien und Ausführungsbeispiele beschrieben wurden, sollen das System und das Verfahren zur optimalen Sensorplatzierung nicht auf die offenbarten bestimmten Details eingeschränkt sein; vielmehr erstrecken sich das System und das Verfahren zum Auswerten eines Gegenstands oder einer Person unter Verwendung eines tragbaren Sensors auf alle funktionsmäßig gleichwertigen Strukturen, Verfahren und Verwendungen, wie sie innerhalb des Schutzbereichs der beigefügten Ansprüche liegen.
  • Die Darstellungen der hierin beschriebenen Ausführungsbeispiele sind dazu bestimmt, zum allgemeinen Verständnis der Struktur der verschiedenen Ausführungsbeispiele beizutragen. Die Darstellungen sollen nicht als vollständige Beschreibung aller Elemente und Merkmale der hierin beschriebenen Offenbarung dienen. Zahlreiche andere Ausführungsbeispiele können für Fachleute auf dem Gebiet bei Durchsicht der Offenbarung offensichtlich sein. Andere Ausführungsbeispiele können genutzt und von der Offenbarung derart abgeleitet werden, dass strukturelle und logische Ersetzungen und Änderungen vorgenommen werden können, ohne von dem Schutzbereich der Offenbarung abzuweichen. Außerdem sind die Darstellungen lediglich repräsentativ und unter Umständen nicht maßstabsgetreu gezeichnet. Bestimmte Proportionen innerhalb der Darstellungen können übertrieben sein, während andere Proportionen minimiert sein können. Dementsprechend sind die Offenbarung und die Figuren als veranschaulichend und nicht als einschränkend zu betrachten.
  • Ein oder mehrere Ausführungsbeispiele der Offenbarung können hierin lediglich aus Gründen der Zweckmäßigkeit und ohne die Absicht, den Schutzbereich dieser Anmeldung aus freiem Willen auf eine bestimmte Erfindung oder ein erfindungsgemäßes Konzept zu beschränken, individuell und/oder kollektiv mit dem Begriff „Erfindung“ bezeichnet werden. Darüber hinaus sei, obwohl spezifische Ausführungsbeispiele hierin veranschaulicht und beschrieben wurden, darauf hingewiesen, dass jede nachfolgende Anordnung mit dem Ziel, denselben oder einen ähnlichen Zweck zu erfüllen, anstelle der gezeigten spezifischen Ausführungsbeispiele eingesetzt werden kann. Diese Offenbarung ist dazu bestimmt, sämtliche nachfolgenden Anpassungen oder Variationen verschiedener Ausführungsbeispiele abzudecken. Kombinationen der obigen Ausführungsbeispiele und anderer Ausführungsbeispiele, die hierin nicht ausdrücklich beschrieben sind, werden für Fachleute auf dem Gebiet bei Durchsicht der Beschreibung offensichtlich sein.
  • Die Zusammenfassung der Offenbarung ist gemäß 37 C.F.R. §1.72(b) vorgesehen und wird mit dem Wissen vorgelegt, dass dieselbe nicht zur Auslegung oder Beschränkung des Schutzbereichs oder der Bedeutung der Ansprüche verwendet wird. Darüber hinaus können in der vorstehenden ausführlichen Beschreibung verschiedene Merkmale in einem einzelnen Ausführungsbeispiel zusammengefasst oder beschrieben werden, um die Offenbarung zu verschlanken. Diese Offenbarung ist nicht als Ausdruck einer Absicht auszulegen, dass die beanspruchten Ausführungsbeispiele mehr Merkmale erfordern, als in jedem Anspruch ausdrücklich erwähnt sind. Vielmehr kann, wie die folgenden Ansprüche zeigen, ein erfindungsgemäßer Gegenstand auf weniger als alle Merkmale eines der offenbarten Ausführungsbeispiele gerichtet sein. Somit sind die folgenden Ansprüche in die ausführliche Beschreibung aufgenommen, wobei jeder Anspruch für sich allein steht und den separat beanspruchten Gegenstand definiert.
  • Die vorhergehende Beschreibung der offenbarten Ausführungsbeispiele wird bereitgestellt, um es einem Fachmann auf dem Gebiet zu ermöglichen, die in der vorliegenden Offenbarung beschriebenen Konzepte zu praktizieren. Als solcher ist der obige offenbarte Gegenstand als veranschaulichend und nicht als einschränkend zu betrachten, und die beigefügten Ansprüche zielen darauf ab, alle derartigen Modifikationen, Verbesserungen und sonstigen Ausführungsbeispiele abzudecken, die der wahren Wesensart und dem Schutzbereich der vorliegenden Offenbarung entsprechen. Daher soll der Schutzbereich der vorliegenden Offenbarung, soweit gesetzlich zulässig, durch die weitestgehende zulässige Auslegung der folgenden Ansprüche und ihrer Äquivalente bestimm sein und soll durch die vorstehende ausführliche Beschreibung nicht eingeschränkt oder begrenzt werden.

Claims (10)

  1. System zum Testen einer Mehrzahl von Komponenten zum Bestimmen einer Schwachstelle und offener Oberflächen, wobei das System folgende Merkmale aufweist: eine Testautomatisierungsplattform (300) mit: einem Speicher (302), der ausführbare Befehle speichert; und einem Prozessor (301), der ausgebildet ist, um die von dem Speicher (302) abgerufenen Befehle auszuführen, wobei die Befehle bei Ausführung durch den Prozessor (301) bewirken, dass der Prozessor (301): eine oder mehrere Angriffstechniken (505) und bekannte offene Oberflächen empfängt; Angriffe auf eine Schaltung ausführt, um empfindliche Oberflächen der Schaltung zu bestimmen; bestimmt, wenn neue offene Oberflächen in der Schaltung vorliegen; einen Angriffsplan (503) basierend auf den neuen offenen Oberflächen aktualisiert; den Angriffsplan (503) ausführt; einen Bericht über die offenen und empfindlichen Oberflächen erzeugt; und ein Depot aktualisiert, um neue Angriffstechniken (505) gegen entdeckte neue offene Oberflächen für die Schaltung zu beinhalten.
  2. System gemäß Anspruch 1, bei dem der Speicher (302), der ausführbare Befehle speichert, ferner Befehle aufweist, die bei Ausführung außerdem bewirken, dass der Prozessor (301): bestimmt, wenn keine neuen offenen Oberflächen in der Schaltung vorliegen, und den Angriffsplan (503) nicht aktualisiert; und die Ausführung des Angriffsplans (503) durchführt.
  3. System gemäß Anspruch 1 oder 2, bei dem der Speicher (302), der ausführbare Befehle speichert, ferner Befehle aufweist, die bei Ausführung bewirken, dass der Prozessor (301): nach der Durchführung der Ausführung des Angriffsplans (503) einen Bericht über die bestimmten offenen Oberflächen für die Schaltung erzeugt.
  4. System gemäß einem der Ansprüche 1 bis 3, bei dem der Speicher (302) ferner Folgendes aufweist: Sicherheits-Werkzeug; eine Testfolge; eine Datenbank (304) für Angriffe (505).
  5. System gemäß Anspruch 4, bei dem die Testfolge und die Datenbank (304) für Angriffe (505) zumindest einen Teil der Befehle aufweisen.
  6. System gemäß Anspruch 4 oder 5, bei dem das Sicherheits-Werkzeug die Befehle aufweist, die den Angriffsplan (503) ausführen.
  7. System gemäß einem der Ansprüche 4 bis 6, das ferner einen Emulator (206) aufweist, der Folgendes aufweist: eine Mehrzahl von Kommunikationsschichten, wobei jede der Kommunikationsschichten angepasst ist, um den Angriffsplan (503) basierend auf einem für die Schaltungen spezifischen Protokoll an die Schaltung zu übertragen.
  8. System gemäß Anspruch 7, bei dem der Prozessor (301) ein erster Prozessor (301) ist, die Schaltung eine erste Schaltung ist und das System ferner eine Unternehmensplattform (201) aufweist, die Folgendes aufweist: einen zweiten Prozessor (301), der ausgebildet ist, um die von dem Speicher (302) abgerufenen Befehle auszuführen, wobei die Befehle bei Ausführung bewirken, dass der erste Prozessor (301) ein Testen einer zweiten Schaltung ausführt.
  9. System gemäß einem der Ansprüche 4 bis 8, bei dem der Speicher (302) eine Sicherheitstestfolge (209) und eine Datenbank (304) für Angriffe (505) aufweist.
  10. System gemäß einem der Ansprüche 4 bis 9, bei dem der Speicher (302) ferner eine Kundenbedrohungsbibliothek (211) und eine Kundenbedrohungsdatenbank (212) aufweist.
DE102019215858.7A 2019-06-28 2019-10-15 Cybersicherheits-penetrations-testplattform Pending DE102019215858A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US16/455,987 2019-06-28
US16/455,987 US11252173B2 (en) 2019-06-28 2019-06-28 Cybersecurity penetration test platform

Publications (1)

Publication Number Publication Date
DE102019215858A1 true DE102019215858A1 (de) 2020-12-31

Family

ID=73747225

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102019215858.7A Pending DE102019215858A1 (de) 2019-06-28 2019-10-15 Cybersicherheits-penetrations-testplattform

Country Status (4)

Country Link
US (1) US11252173B2 (de)
JP (1) JP2021009660A (de)
CN (1) CN112148539A (de)
DE (1) DE102019215858A1 (de)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220024423A1 (en) * 2020-07-22 2022-01-27 Toyota Motor North America, Inc. Authorizing functionality of a transport component
WO2023066663A1 (de) * 2021-10-18 2023-04-27 Siemens Aktiengesellschaft Verfahren zum testen eines geräts und testeinrichtung
EP4167521A1 (de) * 2021-10-18 2023-04-19 Siemens Aktiengesellschaft Verfahren zum testen eines geräts und testeinrichtung

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7577424B2 (en) * 2005-12-19 2009-08-18 Airdefense, Inc. Systems and methods for wireless vulnerability analysis
JP2015114833A (ja) 2013-12-11 2015-06-22 三菱電機株式会社 検査システム、機器情報取得装置、検査指示装置、検査実行装置、機器検査方法及びプログラム
US9571517B2 (en) * 2014-11-11 2017-02-14 Goldman, Sachs & Co. Synthetic cyber-risk model for vulnerability determination
US9712553B2 (en) * 2015-03-27 2017-07-18 The Boeing Company System and method for developing a cyber-attack scenario
US10362048B2 (en) * 2016-05-12 2019-07-23 Keysight Technologies Singapore (Sales) Pte. Ltd. Distributed online wireless security test system
WO2018084808A1 (en) * 2016-11-04 2018-05-11 Singapore University Of Technology And Design Computer-implemented method and data processing system for testing device security
WO2018138608A2 (en) * 2017-01-30 2018-08-02 XM Ltd. Penetration testing of a networked system
CN107426227B (zh) 2017-08-02 2019-09-10 中通服咨询设计研究院有限公司 一种自动化安全渗透测试方法
US10764319B2 (en) * 2017-10-05 2020-09-01 Honeywell International Inc. Intelligent automated security vulnerability detection and analysis for industrial internet of things (IIOT) devices
US10873594B2 (en) * 2018-08-02 2020-12-22 Rohde & Schwarz Gmbh & Co. Kg Test system and method for identifying security vulnerabilities of a device under test
CN109145579A (zh) 2018-08-18 2019-01-04 北京航空航天大学 智能网联汽车信息安全认证测试方法和系统
WO2020089698A1 (en) * 2018-11-04 2020-05-07 Xm Cyber Ltd. Using information about exportable data in penetration testing

Non-Patent Citations (10)

* Cited by examiner, † Cited by third party
Title
CHECKOWAY, Stephen et al.: Comprehensive experimental analyses of automotive attack surfaces. In: USENIX Security Symposium, 2011. S. 447–462. URL: https://www.usenix.org/legacy/event/sec11/tech/full_papers/Checkoway.pdf [abgerufen am 2. März 2020] *
CHECKOWAY, Stephen et al.: Comprehensive experimental analyses of automotive attack surfaces. In: USENIX Security Symposium, 2011. S. 447–462. URL: https://www.usenix.org/legacy/event/sec11/tech/full_papers/Checkoway.pdf [abgerufen am 2. März 2020]
FELDERER, Michael et al.: Security Testing: A Survey. Advances in Computers, Vol. 101, 2016, S. 1–51. DOI: 10.1016/bs.adcom.2015.11.003 *
FELDERER, Michael et al.: Security Testing: A Survey. Advances in Computers, Vol. 101, 2016, S. 1–51. DOI: 10.1016/bs.adcom.2015.11.003
JAKS, Liis: Security evaluation of the electronic control unit software update process. Stockholm (Sweden) : KTH Royal Institute of Technology in Stockholm, School of Information and Communication Technology. Masterarbeit, 2014. URL: http://www.diva-portal.org/smash/get/diva2:934083/FULLTEXT01.pdf [abgerufen am 2. März 2020] *
JAKS, Liis: Security evaluation of the electronic control unit software update process. Stockholm (Sweden) : KTH Royal Institute of Technology in Stockholm, School of Information and Communication Technology. Masterarbeit, 2014. URL: http://www.diva-portal.org/smash/get/diva2:934083/FULLTEXT01.pdf [abgerufen am 2. März 2020]
MAHMOODI, Yasamin et al.: Attack Surface Modeling and Assessment for Penetration Testing of IoT System Designs. In: 2018 21st Euromicro Conference on Digital System Design (DSD). IEEE, 2018. S. 177–181. DOI: 10.1109/DSD.2018.00043 *
MAHMOODI, Yasamin et al.: Attack Surface Modeling and Assessment for Penetration Testing of IoT System Designs. In: 2018 21st Euromicro Conference on Digital System Design (DSD). IEEE, 2018. S. 177–181. DOI: 10.1109/DSD.2018.00043
RAY, Sandip et al.: System-on-chip platform security assurance: Architecture and validation. Proceedings of the IEEE, Vol. 106, 2017, Nr. 1, S. 21–37. DOI: 10.1109/JPROC.2017.2714641 *
RAY, Sandip et al.: System-on-chip platform security assurance: Architecture and validation. Proceedings of the IEEE, Vol. 106, 2017, Nr. 1, S. 21–37. DOI: 10.1109/JPROC.2017.2714641

Also Published As

Publication number Publication date
CN112148539A (zh) 2020-12-29
US20200412759A1 (en) 2020-12-31
US11252173B2 (en) 2022-02-15
JP2021009660A (ja) 2021-01-28

Similar Documents

Publication Publication Date Title
DE102012102770B4 (de) System und Verfahren zur Fehlereingrenzung und Fehlerabschwächung basierend auf einer Netzwerkmodellierung
DE102011017590B4 (de) Verfahren zur Fahrzeugdatenaufzeichnung für Fahrzeugservice
DE102019215858A1 (de) Cybersicherheits-penetrations-testplattform
DE102019109672A1 (de) Rückgängigmachung nach einem teilausfall in mehreren elektronischen steuergeräten mittels over-the-air-updates
DE102011079875A1 (de) Bereitstellung von daten an ein fahrzeug-infotainment-datenverarbeitungssystem
DE102014204222A1 (de) Verfahren und vorrichtung für die umprogrammierung mehrerer fahrzeugsoftwaremodule
DE102017102970A1 (de) Kompatilitätsmodul zur Unterstützung eines Kraftfahrzeugsystemupgrades
DE112016006544T5 (de) Programmaktualisierungssystem, Programmaktualisierungsverfahren und Computerprogramm
DE102013216055A1 (de) Verfahren und Vorrichtungen für Fahrzeugrechensystem-Softwareaktualisierungen
DE102018103209A1 (de) Verfahren und vorrichtung zur handhabung der übereinstimmung von mehrzyklischen fahrzeugsoftwareaktualisierungen
DE112012005016T5 (de) Zielgerichtete Sicherheitsprüfung
DE112014004313T5 (de) Überschreiboperation-Erkennungssystem, Überschreiboperation-Erkennungseinrichtung und Informationsverarbeitungseinrichtung
EP2056201A2 (de) Verfahren, Rechnersystem und Computerprogrammprodukt
DE112013000485T5 (de) Automatische Synthese von Einheitentests für Sicherheitstests
DE112012004247T5 (de) Passives Überwachen virtueller Systeme unter Verwendung einer erweiterbaren Indexierung
DE102012218699A1 (de) Passives überwachen virtueller systeme mittels agentenlosem offline-indexieren
DE102018215636A1 (de) Verfahren, Computerprogramme und Vorrichtungen für eine Netzwerkkomponente und für ein Endgerät, Netzwerkkomponente, Endgerät, System
DE102021130897A1 (de) Elektronische steuerungseinheit, softwareaktualisierungsverfahren, softwareaktualisierungsprogramm und elektronisches steuerungssystem
DE102021124445A1 (de) Metamerkmal-trainingsmodelle für maschinenlernalgorithmen
DE102017100749A1 (de) Verfahren und vorrichtung für zyklischen dateienaustauschbei abgeschaltetem fahrzeug
DE112020005622B4 (de) Informationsverarbeitungsvorrichtung, Informationsverarbeitungsverfahren und Computerprogramm
DE102018206762A1 (de) Feature-Development-Framework und Feature-Integration-Framework zum Implementieren physikalischer Funktionsfeatures in einem Zielgerät
DE112013007507T5 (de) Verfahren und Vorrichtung zur Brunnenauflassung
DE102014221977A1 (de) Verfahren und Vorrichtung zum Speichern von Daten in einem Kraftfahrzeug
EP3705993B1 (de) System und verfahren zum auffinden und identifizieren von rechenknoten in einem netzwerk

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R016 Response to examination communication