DE102019220164A1

DE102019220164A1 - Verfahren zur Sicherheitsüberprüfung, Sicherheitsüberprüfungsvorrichtung, Informationssystem, Kraftfahrzeug

Info

Publication number: DE102019220164A1
Application number: DE102019220164.4A
Authority: DE
Inventors: Rafiee Hosnieh
Original assignee: Volkswagen AG
Current assignee: Volkswagen AG
Priority date: 2019-12-19
Filing date: 2019-12-19
Publication date: 2021-06-24

Abstract

Die vorliegende Erfindung betrifft ein Verfahren (1; 10) für eine Sicherheitsüberprüfung eines Informationssystems eines Kraftfahrzeugs, umfassend:Festlegen (2; 11) einer Sequenz von Sicherheitsprotokollen aus einem Satz von Sicherheitsprotokollen einer Programmierrahmenstruktur, welche durch ein Hinzufügen eines Sicherheitsprotokolls zu dem Satz von Sicherheitsprotokollen erweiterbar ist, wobei das Festlegen der Sequenz von Sicherheitsprotokollen auf wenigstens einem vorbestimmten Kriterium für eine Sicherheitsüberprüfung basiert; undAusführen (3; 12) der Sequenz von Sicherheitsprotokollen zum Identifizieren wenigstens einer Sicherheitslücke des Informationssystems des Kraftfahrzeugs.

Description

Die Erfindung betrifft ein Verfahren für eine Sicherheitsüberprüfung eines Informationssystems eines Kraftfahrzeug, eine Sicherheitsüberprüfungsvorrichtung, ein Informationssystem, und ein Kraftfahrzeug.
Mit steigender Anzahl an Software in einem Kraftfahrzeug und steigender Vernetzung von Kraftfahrzeugen, steigt möglicherweise auch eine Fläche für potentielle Angriffe auf das Kraftfahrzeug bzw. auf Teile der Software des Kraftfahrzeugs.
Solche Angriffe (bspw. durch Cyber-Kriminalität) können ein Sicherheitsrisiko für den Straßenverkehr und/oder für Fahrzeuginsassen, Fußgänger, und dergleichen sein.
Generell sind Verfahren bekannt, um eine Sicherheitsüberprüfung an einem Kraftfahrzeug bereitzustellen.
Beispielsweise ist aus der Offenlegungsschrift EP 2 415 242 A1 eine Methode bekannt, um Softwarekomponenten in einem Fahrzeug zu kombinieren. Jedoch kann hier ohne ein Softwareupdate keine Softwarekomponente hinzugefügt werden.
Des Weiteren ist aus der Patentschrift US 7,269,482 B1 ein Framework bekannt, welches Software aus verschiedenen Quellen kombiniert. Jedoch wird hier keine Sicherheitsüberprüfung durchgeführt. Darüber hinaus ist es nicht modular.
Die Offenlegungsschrift WO 2014/061021 A1 beschreibt ein Gerät, um eine Attacke auf ein Fahrzeug zu erkennen und zu verhindern. Jedoch können hier ohne ein vollständiges Softwareupdate keine neuen Attacken erkannt und/oder verhindert werden.
Aufgabe der vorliegenden Erfindung ist es, ein Verfahren zur Sicherheitsüberprüfung, eine Sicherheitsüberprüfungsvorrichtung, ein Informationssystem für ein Kraftfahrzeug, und ein Kraftfahrzeug bereitzustellen, welche die oben genannten Nachteile wenigstens teilweise überwinden.
Diese Aufgabe wird durch das erfindungsgemäße Verfahren zur Sicherheitsüberprüfung nach Anspruch 1, die erfindungsgemäße Sicherheitsüberprüfungsvorrichtung nach Anspruch 13, das erfindungsgemäße Informationssystem nach Anspruch 14, und das erfindungsgemäße Kraftfahrzeug nach Anspruch 15 gelöst.
Nach einem ersten Aspekt der vorliegenden Erfindung umfasst ein Verfahren für eine Sicherheitsüberprüfung eines Informationssystems eines Kraftfahrzeugs:

Festlegen einer Sequenz von Sicherheitsprotokollen aus einem Satz von Sicherheitsprotokollen einer Programmierrahmenstruktur, welche durch ein Hinzufügen eines Sicherheitsprotokolls zu dem Satz von Sicherheitsprotokollen erweiterbar ist, wobei das Festlegen der Sequenz von Sicherheitsprotokollen auf wenigstens einem vorbestimmten Kriterium für eine Sicherheitsüberprüfung basiert; und
Ausführen der Sequenz von Sicherheitsprotokollen zum Identifizieren wenigstens einer Sicherheitslücke des Informationssystems des Kraftfahrzeugs.

Nach einem zweiten Aspekt der vorliegenden Erfindung ist eine Sicherheitsüberprüfungsvorrichtung dazu eingerichtet, das Verfahren nach dem ersten Aspekt auszuführen.
Nach einem dritten Aspekt der vorliegenden Erfindung ist ein Informationssystem für ein Kraftfahrzeug mit einer Sicherheitsüberprüfungsvorrichtung nach dem zweiten Aspekt überprüfbar.
Nach einem vierten Aspekt der vorliegenden Erfindung weist ein Kraftfahrzeug ein Informationssystem nach dem dritten Aspekt auf.
Weitere vorteilhafte Ausgestaltungen der Erfindung ergeben sich aus den Unteransprüchen und der folgenden Beschreibung bevorzugter Ausführungsbeispiele der vorliegenden Erfindung.
Wie bereits diskutiert sind bekannte Systeme und Verfahren für eine Sicherheitsüberprüfung einer Kraftfahrzeugsoftware nur erweiterbar, indem ein vollständiges Softwareupdate durchgeführt wird.
Es wurde jedoch erkannt, dass dies zu einem hohen Zeitaufwand führt, wobei es generell wünschenswert ist, dass der Zeitaufwand reduziert wird.
Des Weiteren wurde erkannt, dass eine Flexibilität einer Sicherheitsüberprüfung dadurch eingeschränkt ist, nämlich beispielsweise, weil ein vollständiges Softwareupdate langsamer entwickelt werden kann als neue Angriffe auf die Kraftfahrzeugsoftware entstehen, sodass möglicherweise manche Angriffe erfolgreich sind.
Darum ist es wünschenswert, dass die Anzahl an erkannter und verhinderter Angriffe maximiert wird.
Darüber hinaus können bekannte Systeme und Verfahren eine limitierte Funktionalität aufweisen, sodass, wenn die Funktionalität erweitert werden soll, möglicherweise softwareseitig starke Veränderungen durchgeführt werden müssen, was einen hohen Zeitaufwand erforderlich machen kann, und wodurch auch Kosten entstehen können.
Deshalb wurde erkannt, dass es wünschenswert ist, eine Funktionalität einer Sicherheitsüberprüfung schnell bereitzustellen, wodurch ein Sicherheitssystem eines Kraftfahrzeugs überprüft werden kann.
Außerdem wurde erkannt, dass es wünschenswert ist, ein Framework bereitzustellen, wodurch ein Kraftfahrzeug überprüft werden kann bspw. von einem externen Interface, und welches modular ist, da bekannte Frameworks typischerweise nur für einen Zweck, wie bspw. eine Netzwerküberprüfung, eine Sicherheitslücke (bspw. Vulnerability Scan) einer Software, eines Netzwerks, eines Protokolls, und dergleichen, ausgelegt sind, sodass innerhalb bekannter Frameworks nur die dafür vorgesehene Funktion ausgeführt werden kann.
Um eine neue Funktionalität von bekannten Frameworks hinzuzufügen, muss ein vollständiges Softwareupdate durchgeführt werden, sodass es typischerweise mit großem Aufwand verbunden ist, wenn eine neue Funktionalität für ein bekanntes Framework bereitgestellt werden soll.
Deshalb ist es wünschenswert, ein Framework (Programmierrahmenstruktur) bereitzustellen, durch welches beliebige Werkzeuge für eine Sicherheitsüberprüfung (Sicherheitsprotokolle) ausgeführt werden können, ohne dass dafür ein Softwareupdate erforderlich ist.
Für ein solches Framework kann es wünschenswert sein, dass eine schnelle, effiziente, reproduzierbare, und dergleichen, Sicherheitsüberprüfung durchführbar ist, welche ein Informationssystem flexibel bzgl. einer (neu entdeckten) Sicherheitslücke testen kann.
Deshalb betreffen manche Ausführungsbeispiele ein Verfahren für eine Sicherheitsüberprüfung eines Informationssystems eines Kraftfahrzeugs, umfassend: Festlegen einer Sequenz von Sicherheitsprotokollen aus einem Satz von Sicherheitsprotokollen einer Programmierrahmenstruktur, welche durch ein Hinzufügen eines Sicherheitsprotokolls zu dem Satz von Sicherheitsprotokollen erweiterbar ist, wobei das Festlegen der Sequenz von Sicherheitsprotokollen auf wenigstens einem vorbestimmten Kriterium für eine Sicherheitsüberprüfung basiert; und Ausführen der Sequenz von Sicherheitsprotokollen zum Identifizieren wenigstens einer Sicherheitslücke des Informationssystems des Kraftfahrzeugs.
Sicherheit (engl. Security) kann in diesem Kontext eine Betriebssicherheit bezeichnen bzw. ein Schutz von Komponenten des Kraftfahrzeugs vor einem externen An- bzw. Zugriff.
Darüber hinaus kann die Sicherheit auch ein Risiko bezeichnen, zu welchem das Kraftfahrzeug vor einem (Fern-)Angreifer geschützt ist. Durch solch einen Angriff kann beispielsweise ein wirtschaftlichen bzw. finanziellen Schaden, ein Personenschaden, ein (teilweiser) Funktionalitätsverlust einer Kraftfahrzeugkomponente, und dergleichen entstehen.
Die Sicherheitsüberprüfung (engl.: security check) kann eine Überprüfung einer kraftfahrzeuginternen Programmierung, Steuerung, und dergleichen sein, wobei die Sicherheitsüberprüfung dazu dienen kann, einen Angriff auf ein Informationssystem (Sicherheitssystem, interne Programmierung, Kraftfahrzeugsoftware, und dergleichen) zu validieren bzw. zu überprüfen.
Die Sicherheitsüberprüfung kann eine Sicherheit eines Kraftfahrzeugs überprüfen, einschätzen und dergleichen, wobei die Sicherheit durch ein Risiko (bspw. anhand einer Wahrscheinlichkeit), dass das Kraftfahrzeug durch einen physischen Angriff oder durch einen Fernangriff (bspw. Hacking) angegriffen wird, bemessen werden kann, sodass abgeschätzt werden kann, ob ein finanzieller Schaden für einen Halter des Kraftfahrzeugs entstehen kann, ob eine Gesetzesübertretung stattfinden kann, ob ein Verletzungsrisiko einer Person (bspw. Fahrer, Halter, Insasse des Kraftfahrzeugs) entstehen kann, ob eine Kraftfahrzeugfunktionalität gestört werden kann, und dergleichen.
Die Sicherheitsüberprüfung kann auf einer Programmierrahmenstruktur basieren.
Generell sind Programmierrahmenstrukturen (Frameworks) bekannt. Ein Framework kann dazu eingerichtet sein, ein Grundgerüst für eine Programmierung bereitzustellen, beispielsweise in einer objektorientierten Programmierung und/oder bei komponentenbasierten Entwicklungsansätzen, wobei ein Nutzer des Frameworks (beispielsweise ein Programmierer) eine Anwendung erstellen kann.
Ein erfindungsgemäßes Framework kann einen Satz von Sicherheitsprotokollen (mindestens eins) aufweisen. Des Weiteren kann ein erfindungsgemäßes Framework durch ein Hinzufügen eines Sicherheitsprotokolls zu einem Satz von Sicherheitsprotokollen erweiterbar sein.
Darüber hinaus kann das Framework dazu eingerichtet sein, eine Sicherheitsüberprüfung auszuführen.
Ein Sicherheitsprotokoll kann eine Programmroutine, einen Ablauf, ein Skript, ein Makro, ein Programm, ein Fuzzy Tool, eine Programmschicht, eine Anwendung, einen Code, ein Modul, eine (Open-Source-)Software, ein Template, und dergleichen umfassen, welches eine Komponente oder mehrere Komponenten des Informationssystems überprüft, bspw. um eine Sicherheitslücke in dem Informationssystem zu finden, zu identifizieren, und dergleichen.
Die Sicherheitsüberprüfung kann dazu eingerichtet sein, eine Sicherheitslücke zu finden.
Beispielsweise kann ein Problem in einem TCP Stack in einem Linux-Betriebssystem erkannt worden sein, welches derart gestaltet sein kann, dass wenn eine Nachricht mit einer vorbestimmten Größe an ein Steuergerät eines Kraftfahrzeugs gesendet wird, ein Buffer-Überlauf erfolgen kann.
Ein Sicherheitsprotokoll kann in Reaktion darauf entwickelt worden sein, welches jedoch noch nicht in der Programmierrahmenstruktur verfügbar ist.
Um das Sicherheitsprotokoll verfügbar zu machen, kann die Programmierrahmenstruktur bspw. durch Drag and Drop des Sicherheitsprotokolls erweitert werden, ohne die vorliegende Erfindung darauf zu beschränken, da eine Erweiterung der Programmierrahmenstruktur nicht notwendigerweise durch einen Benutzer stattfinden muss, sondern auch automatisiert stattfinden kann.
In manchen Ausführungsbeispielen kann ein Fuzzy Tool durch ein Hinzufügen eines Sicherheitsprotokolls ebenfalls erweitert werden (bspw. als eine neue Programmschicht), sodass ein Fuzzy-Test basierend auf dem hinzugefügten Sicherheitsprotokoll möglich ist.
In manchen Ausführungsbeispielen kann ein Sicherheitsprotokoll ein Skript und/oder eine (Open-Source-)Software umfassen, welche ein bestehendes Protokoll (bspw. ein Kommunikationsprotokoll wie TCP/IP, und dergleichen) manipulieren kann.
Generell soll ein erfindungsgemäßes Sicherheitsprotokoll nicht als ein Kommunikationsprotokoll, oder dergleichen, ausgelegt werden, da, wie hierin diskutiert, ein erfindungsgemäßes Sicherheitsprotokoll generell einen Ablauf darstellen kann, um eine Sicherheitslücke zu identifizieren.
Das Framework kann des Weiteren dazu eingerichtet, durch ein Hinzufügen eines Sicherheitsprotokolls zu dem Satz von Sicherheitsprotokollen erweitert zu werden.
Beispielsweise kann ein weiteres Sicherheitsprotokoll an den Satz von Sicherheitsprotokollen angehängt werden, sodass eine Erweiterung des Frameworks stattfinden kann, ohne dass eine Aktualisierung des Frameworks selbst stattfindet (d. h. dass kein Softwareupdate des Frameworks durchgeführt werden muss).
Aus dem Satz von Sicherheitsprotokollen kann ein Teilsatz (oder eine Teilmenge) von Sicherheitsprotokollen ausgewählt werden.
Der Teilsatz kann wenigstens ein Sicherheitsprotokoll (oder mehr) umfassen, sodass eine oder mehrere vorbestimmte (bekannte oder unbekannte) Sicherheitslücken mit diesem bestimmt werden können, wenn die Sicherheitsprotokolle in einer bestimmte Reihenfolge (Sequenz) ausgeführt werden, wobei eine erfindungsgemäße Sequenz von Sicherheitsprotokollen auch umfassen kann, dass wenigstens zwei Sicherheitsprotokolle des Teilsatzes von Sicherheitsprotokollen gleichzeitig ausgeführt werden.
Es wurde erkannt, dass eine Standardisierung zu einer erhöhten Sicherheit beitragen kann.
Basierend auf vorbestimmten Kriterien (oder gemeinsamen Kriterien, CC (common criteria)) oder basierend auf Bedingungen oder Standards, welche gestellt werden (bspw. extern von einer Behörde, wie z. B. UNECE) kann das Framework, in manchen Ausführungsbeispielen, eine Sicherheitsstufe eines Kraftfahrzeugs oder einer Komponente eines Kraftfahrzeugs bestimmen und ein Sicherheitszertifikat erstellen, wodurch vorteilhafterweise eine Automatisierung stattfinden kann, was Zeit spart und einen Fehler durch eine menschliche Komponente minimiert.
In manchen Ausführungsbeispielen basiert die Sicherheitsüberprüfung daher auf vorbestimmten (gemeinsamen) Kriterien zur Sicherheitsüberprüfung.
Ein vorbestimmtes Kriterium kann allgemein so definiert sein, dass ein Angriff (von einem entfernten Angreifer, einem nahen Angreifer, einem Angreifer mit physischem Zugang, und dergleichen) auf das Informationssystem klassifiziert werden kann.
Hierfür umfasst in manchen Ausführungsbeispielen das wenigstens eine vorbestimmte Kriterium wenigstens eines von einer Zeit, einer Schwere, einem Ort, und einer weiteren Sicherheitslücke.
Die Zeit kann eine Zeitspanne umfassen, welche einen Aufschluss darüber gibt, wie lange ein Angreifer benötigt, um eine Attacke auszuführen.
Die Schwere kann eine Risikostufe umfassen, welche basierend auf einer Datenbank (bspw. CVE (Common Vulnerabilities ans Exposure) bestimmt wird.
Die Schwere kann in einem Sicherheitsprotokoll, welches zu dem Satz von Sicherheitsprotokollen hinzugefügt wird, einbegriffen oder daraus bestimmbar sein (bspw. durch eine Programmierung, Codierung, und dergleichen des Sicherheitsprotokolls).
Durch eine automatisierte Suche (bspw. Webcrawler) können Sicherheitsprotokolle, welche einer vorgegebenen Schwere entsprechen, hinzugefügt werden.
Die durch eine automatisierte Suche gefundenen Sicherheitsprotokolle können, bevor sie hinzugefügt werden, mit der Risikostufe aus der Datenbank abgeglichen werden, sodass vorteilhafterweise ein Speicherplatz eingespart werden kann.
Beispielsweise, wenn ein TCP (Transmission Control Protocol), ein TLS (Transport Layer Security) Protokoll, und dergleichen überprüft werden soll, kann die Datenbank basierend auf Schlüsselwörtern (bspw. TCP, TSP, Buffer-Überlauf in TCP Stack, und dergleichen) gefiltert werden und basierend auf der Sequenz von Sicherheitsprotokollen abgeglichen werden, ob bereits entsprechende Einträge in der Datenbank existieren.
Beispielsweise, wenn eine Cipher Suite eines TLS Protokolls (als Informationssystem) überprüft werden soll und es konnte ein Ergebnis in der Datenbank gefunden werden, dann kann das Ergebnis (bspw. „hohe Schwere) aus der Datenbank angenommen werden.
Wenn kein Eintrag in der Datenbank existiert, kann daraus geschlussfolgert werden, dass die Sicherheitslücke (noch) nicht bekannt ist, sodass eine Sequenz von Sicherheitsprotokollen festgelegt wird, um die Sicherheitslücke zu überprüfen.
Der Ort kann den Ort eines (potentiellen) Angreifers umfassen.
Generell kann der Ort des Angreifers für ein Abschätzen eines potentiellen Schadens bei einem Angriff herangezogen werden.
Beispielsweise kann es sich um einen entfernten Angreifer handeln, wodurch die Sicherheitsüberprüfung über vorbestimmte Schnittstellen, wie beispielsweise W-LAN (Wireless Local Area Network), LTE (Long Term Evolution), 5G, GPS (Global Positioning System), und dergleichen ausgeführt werden kann.
Darüber hinaus kann es sich um einen nahen Angreifer handeln, wodurch die Sicherheitsüberprüfung über (andere) vorbestimmte Schnittstellen durchgeführt werden kann, wie beispielsweise Bluetooth, eine Ladeschnittstelle, ein Radar, eine Kamera, ein Fahrassistenzssystem, und dergleichen.
Es kann sich, in manchen Ausführungsbeispielen auch um einen Angreifer handeln, welcher physischen Zugang zu einem Kraftfahrzeug (oder zu einem Schlüssel eines Kraftfahrzeugs) haben kann, sodass hier die vorbestimmten Schnittstellen CAN, Ethernet, OBD, LIN, und USB umfassen können.
Der Ort des Angreifers soll in diesem Kontext nicht als der tatsächliche Ort verstanden werden, an welchem sich der Angreifer befindet, sondern als den Ort, an welchem er sich befinden muss, um einen Angriff auszuführen. Beispielsweise kann ein Angreifer, welcher physischen Zugang zu einem Kraftfahrzeug hat, auch einen entfernten Angriff durchführen.
Ein potentieller Schaden eines entfernten Angriffs kann höher abgeschätzt werden als der eines nahen Angriffs, welcher wiederum als höher abgeschätzt werden kann als der eines Angreifers mit physischem Zugang zu dem Kraftfahrzeug. Dies ist in diesem Kontext damit begründet, dass ein Angriff, bei welchem ein Angreifer weiter weg von einem Kraftfahrzeug sein kann, potentiell auf mehr Kraftfahrzeugen erfolgreich sein kann, ohne die vorliegende Erfindung darauf zu beschränken.
Daraus ergibt sich der Vorteil, dass eine Zeit einer Sicherheitsüberprüfung minimiert werden kann.
Ein Angriff kann über eine Schnittstelle stattfinden, beispielsweise von einer entfernten Angreifen, einem Angreifer mit Zugangsmitteln (bspw. indem erst ein Fahrzeug least, einen Schlüssel zum Fahrzeug hat), und dergleichen.
Ein entfernter Angreifer kann ein Fahrzeug über Bluetooth, WLAN, LTE, und dergleichen angreifen.
Ein naher Angreifer kann ein Fahrzeug bspw. über einen Sensor angreifen, bspw. GPS, Radar, Infrarotsensor, Kamera, und dergleichen.
Ein Angreifer, welcher physischen Zugang zu einem Fahrzeug hat, kann das Fahrzeug über CAN, Ethernet, LIN, NFC, RFID, OBD, DSI, Ladeschnittstelle (bspw. bei Elektro- oder Hybridfahrzeugen), USB-Schnittstelle, und dergleichen angreifen.
Ein entfernter Angreifer kann auch ein Fahrzeug angreifen (hacken), an welches bspw. ein Besitzer des Fahrzeugs ein externes (kompromittiertes) (End-)Gerät (bspw. Mobiltelefon, Tablet, und dergleichen) bspw. über ein Infotainment-System des Fahrzeugs angeschlossen hat (oder verbunden hat) (bspw. über USB, Bluetooth, WLAN, und dergleichen). In solch einem Fall kann der Angreifer über das externe Gerät das Infotainment-System angreifen, indem Schwächen in dem Infotainment-System findet und damit eine Sicherheitsgefahr für den Besitzer (oder Fahrer) des Fahrzeugs erzeugt oder einen finanziellen Schaden (oder Verlust) für den Hersteller des Fahrzeugs erzeugt.
Ein Infotainment-System kann ein Angreifer bspw. über Protokolle und/oder Schnittstellen angreifen, wie z. B. SOME/IP, ViWi, TLS, BAP, ISO-TP, DoIP, und dergleichen.
Die weitere Sicherheitslücke kann daraus entstehen, dass ein erster Angriff erfolgreich war. Daher kann, in manchen Ausführungsbeispielen, die Sequenz von Sicherheitsprotokollen so festgelegt werden, dass ein erstes Sicherheitsprotokoll das Informationssystem auf eine erste Sicherheitslücke testet und ein zweites Sicherheitsprotokoll auf eine zweite Sicherheitslücke testet.
In manchen Ausführungsbeispielen umfasst das wenigstens eine vorbestimmte Kriterium eine Expertise eine potentiellen Angreifers. Beispielsweise kann die Expertise als öffentliches Wissen bestimmt werden, wenn der Teilsatz von Sicherheitsprotokollen ausschließlich auf Open Source-Sicherheitsprotokollen, öffentlich zugänglichen Sicherheitsprotokollen, und dergleichen basiert.
In manchen Ausführungsbeispielen umfasst das wenigstens eine vorbestimmte Kriterium ein Tool, welches für einen potentiellen Angriff verwendet wird. Beispielsweise kann das Tool als Standard festgelegt werden, wenn es beispielsweise im Internet gefunden werden kann.
In manchen Ausführungsbeispielen wird eine Punktzahl ermittelt, die indikativ dafür ist, wie sicher das Informationssystem bzgl. einer (potentiellen) Sicherheitslücke ist (bspw. basierend darauf wie viel Angriffe von einer vorbestimmten Anzahl an Angriffen potentiell erfolgreich sind).
Bei der Sequenz von Sicherheitsprotokollen kann so für jedes durchgeführte Sicherheitsprotokoll eine Punktzahl ermittelt werden, aus der eine Gesamtpunktzahl des Informationssystems ermittelt werden kann (bspw. ein Durchschnitt), aus welchem vorteilhafterweise ein potentieller Schaden eines solchen Angriffs bzw. eine Sicherheitsstufe bestimmt werden kann.
Basierend auf der Sequenz von Sicherheitsprotokollen bzw. basierend auf den aufgedeckten Sicherheitslücken des Informationssystems wird, in manchen Ausführungsbeispielen eine Sicherheitsstufe des Informationssystems bestimmt.
Die Sicherheitsstufe kann mit einem Sicherheitszertifikat und dergleichen dargestellt werden, wie beispielsweise „Sehr sicher“, „sicher“, „Unsicher“, „Sehr unsicher“, sodass vorteilhafterweise eine Qualität des Sicherheitssystems visualisiert werden kann.
Die Sicherheitsstufe kann anhand einer Risikoeinschätzung bestimmt werden, wie beispielsweise mit folgender Tabelle:
Die erste Spalte der gezeigten Tabelle enthält einen abgeschätzten potentiellen Schaden bei einem Angriff, während in der ersten Zeile eine Wahrscheinlichkeit für einen Angriff eingetragen ist, wobei sich daraus ein Risiko für das Informationssystem ergibt, welches in den übrigen Zellen der Tabelle angegeben ist.
Es kann eine Vielzahl von vorbestimmten Kriterien in Betracht gezogen werden. Beispielsweise kann ein potentieller entfernter Angreifer ein Standardwerkzeug (für einen Angriff) benutzen, wobei der potentielle entfernte Angreifer darüber hinaus als Experte in seinem Gebiet eingeschätzt wird. Des Weiteren kann der potentielle Angreifer zwei Stunden für den potentiellen Angriff benötigen.
Aus diesen Kriterien wird die Wahrscheinlichkeit für einen Angriff als „sehr niedrig“ bestimmt.
Des Weiteren wird der potentielle Schaden bei einem Angriff auf das Informationssystem basierend auf einer Datenbank als „hoch“ eingestuft.
Deshalb wird anhand der Tabelle das Risiko als „sehr hoch“ bestimmt.
In manchen Ausführungsbeispielen weist die Programmierrahmenstruktur ein Backend auf, welches dazu eingerichtet ist, die Sequenz von Sicherheitsprotokollen auszuführen.
Das Backend ist typischerweise ein Teil des Frameworks, welcher dazu eingerichtet ist, die Sequenz von Sicherheitsprotokollen oder andere Anwendungen auszuführen, indem es sie beispielsweise kompiliert.
Die Sicherheitsprotokolle oder Anwendungen können ein Open Source Programm oder Skript sein, welche durch das Framework ausgeführt werden können
In manchen Ausführungsbeispielen ist das Backend ferner dazu eingerichtet, über eine Schnittstelle ansteuerbar zu sein.
Dazu können standardisierte Protokolle in das Backend integriert sein, welche eine Kompatibilität eines Endgerätes (beispielsweise externer Computer) über die Schnittstelle ermöglichen.
In manchen Ausführungsbeispielen umfasst die Schnittstelle wenigstens eines von einer digitalen Schnittstelle, einer virtuellen Schnittstelle, und einer Sensorschnittstelle.
Die digitale Schnittstelle kann beispielsweise Bluetooth, USB (Universal Serial Bus), W-LAN (wireless local area network), Ethernet, CAN (controller area network), DSI (Display Serial Interface), RFID (Radio Frequency Identification), OBD (On-Board Diagnose), DSI (Display Serial Interface), und NFC (Near Field Communication) umfassen.
Die virtuelle Schnittstelle kann beispielsweise ein Kommunikationsprotokoll umfassen, wie beispielsweise SOME/IP (Scalable Service Oriented Middlewar over IP (Internet Protocol)), ViWo (Volkswagen Infotainment Web Interface), TLS (Transport Layer Security), LIN (Local Interconnect Network), LTE (Long Term Evolution), 5G, ISO/TP (Transport Layer), BAP (Bedien- und Anzeigeprotokoll) und dergleichen.
Die Sensorschnittstelle kann beispielsweise einen Parksensor, einen Parkpilotsensor, einen Parkassistenzsensor, einen Abstandssensor (bspw. Radar, Lidar), eine Kamera, einen Ortungssensor (bspw. GPS-Sensor (Global Positioning System)), Ladeschnittstelle, eines Elektrokraftfahrzeugs (oder Hybridkraftfahrzeugs) und dergleichen, umfassen.
Die vorliegende Erfindung soll jedoch nicht nur auf die genannten Schnittstellen beschränkt sein, da jede Schnittstelle, welche mit einem Sicherheitsprotokoll, wie hierin beschrieben, überprüfbar sein kann. Darüber hinaus können auch mehrere Schnittstellen gleichzeitig und/oder nacheinander erfindungsgemäß überprüft werden.
In manchen Ausführungsbeispielen umfasst das Backend ferner ein Nachrichtenprotokoll.
Das Nachrichtenprotokoll kann dazu eingerichtet sein, eine Nachricht, Mitteilung, und dergleichen, basierend auf der Sicherheitsüberprüfung bzw. basierend auf dem wenigstens einen ausgeführten Sicherheitsprotokoll, zu generieren.
Diese Nachricht kann einem Nutzer, und dergleichen, welcher an einem Ergebnis der Sicherheitsüberprüfung interessiert ist, bereitgestellt werden, und somit eine Auswertung der Sicherheitsüberprüfung enthalten.
In manchen Ausführungsbeispielen umfasst das Backend ferner Fuzzy-Test-Protokolle.
Fuzzy-Test-Protokolle sind generell bekannt und können als weiteres Ausführungsbeispiel eines Sicherheitsprotokolls betrachtet werden und/oder dazu verwendet werden, um ein Sicherheitsprotokoll zu überprüfen.
In manchen Ausführungsbeispielen weist die Programmierrahmenstruktur ein Frontend (oder Überbau) auf, welches dazu eingerichtet ist, eine graphische Benutzeroberfläche bereitzustellen.
Das Frontend kann eine netzbasiertes Schnittstelle (Interface) sein, durch welche eine Administration, Steuerung, und dergleichen, des Frameworks bereitgestellt werden kann.
Die graphische Benutzeroberfläche kann, wie allgemein bekannt ist, durch einen Benutzer (bspw. Programmierer, Tester, Entwickler, Besitzer, und dergleichen) gesteuert werden.
Darüber hinaus kann, in manchen Ausführungsbeispielen, ein Sicherheitsprotokoll über die graphische Benutzeroberfläche erstellt werden (bspw. mit einer Sicherheitsprotokollvorlage, wie hierin diskutiert).
Die graphische Benutzeroberfläche kann Objekte bereitstellen, welche beispielsweise durch eine Verknüpfung, Schleifen, und dergleichen (programmierähnlich) miteinander in Bezug gestellt werden können, sodass ein Programm erstellt werden kann, welches einem Sicherheitsprotokoll entspricht, welches erfindungsgemäß mit dem Framework ausgeführt werden kann.
In manchen Ausführungsbeispielen werden verschiedene Sicherheitsfreigaben an Benutzer des Frameworks vergeben.
Beispielsweise können einem Besitzer, einem Entwickler, und dergleichen, volle Zugriffsrechte gewährt werden (höchste Sicherheitsfreigabe), einer Person mit einer geringeren Sicherheitsfreigabe kann dem Framework neue Sicherheitsprotokolle hinzufügen, während eine Person mit keiner Sicherheitsfreigabe bspw. nur die Sicherheitsüberprüfung ausführen kann.
So kann vorteilhafterweise eine Funktionalität des Frameworks gewährleistet werden.
In manchen Ausführungsbeispielen ist ein Sicherheitsprotokoll basierend auf einer Sicherheitsprotokollvorlage erstellbar.
Die Sicherheitsprotokollvorlage kann ein Rahmen (z. B. Template) sein, in welcher Spezifikationen für das Sicherheitsprotokoll vorgenommen werden, beispielsweise, indem Parameter festgelegt werden, Testschritte definiert werden, und dergleichen.
Beispielsweise kann die Sicherheitsprotokollvorlage auf YAML, XML oder einer anderen Sprache basieren, wobei in der Sicherheitsprotokollvorlage (bspw. eine Datei) Befehle, Objekte, und dergleichen, bereitgestellt werden können, sodass ein Sicherheitsprotokoll erstellt werden kann.
Eine Sicherheitsprotokollvorlage kann einen Namen des jeweiligen Sicherheitsprotokolls beinhalten, von Werkzeugen (bspw. Befehle, Objekte, und dergleichen), wobei die Werkzeuge selbst geschrieben, Open Source, oder von einem Hersteller bereitgestellt sein können, und Parameter (bspw. einen Input), welcher sich auf den Befehl und dergleichen bezieht, ein Parameter, welcher voraussichtlich ausgegeben wird, und eine vorgesehene Anzahl an Sequenzen, in welchen oder wie oft das Sicherheitsprotokoll ausgeführt werden soll.
Beispielsweise kann eine Sicherheitsprotokollvorlage in YAML, um einen CAN-Bus eines Kraftfahrzeugs zu testen, wie folgt aussehen:

 model: eae_can.testcases
 pk:
 fields: {
      module: ‚eae_can‘,
      testcase: ‚info_can‘,
      input: [], 
 }
 model: eae_can.testcases
 pk:
 fields: {
      module: ‚eae_can‘,
      testcase: ‚send_pdu‘
      input: [‚100‘, ‚01020304‘]
 }
 model: eae_can.testcases
 pk:
 fields: {
      module: ‚eae can‘
      testcase: ‚send_pdu‘
      input: [‚200‘, ‚05060708‘]
 }

Solch eine YAML-Datei kann manuell oder von einer grafischen Benutzerschnittstelle des Frameworks erstellt werden in Reaktion auf eine Eingabe eines Benutzers.

In manchen Ausführungsbeispielen kann eine Vorlage für eine Sicherheitsprotokollvorlage abgerufen oder erstellt werden, wodurch vorteilhafterweise eine komplexe Sicherheitsprotokollvorlage mit einfachen Mitteln erstellt werden kann.

In manchen Ausführungsbeispielen ist ein Sicherheitsprotokoll über eine automatisierte Suche hinzufüg bar.

Beispielsweise kann die automatisierte Suche in einem Netzwerk, auf einem oder mehreren Servern stattfinden, in welchem beispielsweise eine Datenbank für Sicherheitsprotokolle befindlich ist.

In manchen Ausführungsbeispielen kann hierzu ein Webcrawler, Searchbot, und dergleichen verwendet werden.

Des Weiteren kann auch ein manuell geschriebenes Skript (bspw. Open Source) als ein Sicherheitsprotokoll hinzugefügt werden, welches nicht auf einer Sicherheitsprotokollvorlage basiert, und welches durch das Framework ausgeführt werden kann.

Vorteilhafterweise kann dadurch eine Modularisierung des Frameworks ausgenutzt werden, sodass eine Aggregation von mehreren Sicherheitsprotokollen bereitgestellt werden kann, jedoch wird eine Anzahl von Sicherheitsüberprüfungsresultaten minimiert, sodass eine geringe Anzahl (z. B. eins) von Sicherheitsüberprüfungsberichten erstellt wird, was einerseits vorteilhaft ist zwecks einer Übersichtlichkeit der Sicherheitsüberprüfung und andererseits vorteilhaft ist zwecks einer Minimierung eines Speicherplatzes.

In anderen Worten kann ein Ablauf, eine Kette, und dergleichen, von mehreren (mindestens zwei) Sicherheitsprotokollen bereitgestellt werden. Beispielsweise kann der Ablauf (oder Kette) automatisiert basierend auf einer Vorgabe bereitgestellt werden oder ein Benutzer kann einen Ablauf von Sicherheitsprotokollen definieren.

Beispielsweise kann ein Port Scan als erstes Sicherheitsprotokoll definiert werden zum Bestimmen offener Ports. Ein zweites Sicherheitsprotokoll kann die bestimmten offenen Ports daraufhin bzgl. einer Angreifbarkeit testen.

Beispielsweise kann ein Skript oder ein Werkzeug (Tool) zur Sicherheitsüberprüfung über eine grafische Benutzerschnittstelle zu dem Framework hinzugefügt werden (bspw. Drag and Drop), das Skript oder Werkzeug kann auch in einen dafür vorgesehenen digitalen Ordner kopiert werden, auf welchen das Framework Zugriff hat, sodass es von dem Backend geladen und kompiliert werden kann.

Daraus ergibt sich der Vorteil, dass eine Person, welche eine Sicherheitsüberprüfung durchführt keine Sicherheitsfreigabe (bspw. Zugriff auf einen Quelltext des Frameworks und dergleichen) benötigt.

Eine Person mit einer Sicherheitsfreigabe kann jedoch den Quelltext des Frameworks ändern, sodass bspw. eine neue Sicherheitsprotokollvorlage abrufbar ist für einen Nutzer des Frameworks.

In manchen Ausführungsbeispielen kann ein Sicherheitsüberprüfungsbericht auf Grundlage der Sicherheitsüberprüfung erstellt werden, damit vorteilhafterweise eine Sichtbarkeit der Sicherheitsüberprüfung erzeugt werden kann.

Beispielsweise kann der Sicherheitsüberprüfungsbericht umfassen, welche Sicherheitsprotokolle ausgeführt wurden, und zu welchem Ergebnis dies jeweils geführt hat.

Der Sicherheitsüberprüfungsbericht kann vorteilhafterweise in einem bekannten Format (bspw. pdf (Portable Document Format)) ausgegeben werden.

Manche Ausführungsbeispiele betreffen eine Sicherheitsüberprüfungsvorrichtung, welche dazu eingerichtet ist, das erfindungsgemäße Verfahren zur Sicherheitsüberprüfung auszuführen.

Die Sicherheitsüberprüfungsvorrichtung kann eine Steuerungsanordnung sein, wie beispielsweise ein Prozessor (z. B. eine CPU (Central Processing Unit)) oder mehrere Prozessoren, ein Computer, ein Server (oder mehrere Server), und dergleichen.

Die Sicherheitsüberprüfungsvorrichtung kann ein Teil eines Kraftfahrzeugs sein oder losgelöst in einem Endgerät (beispielsweise Computer, Server) bereitgestellt sein, sodass eine Sicherheitsüberprüfung an einem Kraftfahrzeug durchgeführt werden kann, indem die Sicherheitsüberprüfungsvorrichtung mit dem Kraftfahrzeug (bzw. mit einem erfindungsgemäßen Informationssystem, siehe unten) verbunden wird, beispielsweise über die wenigstens eine Schnittstelle.

Manche Ausführungsbeispiele betreffen ein Informationssystem für ein Kraftfahrzeug, welches mit einer erfindungsgemäßen Sicherheitsüberprüfungsvorrichtung überprüfbar ist, wie hierin beschrieben.

Das Informationssystem kann eine (weitere) Steuerungsanordnung sein, wie beispielsweise ein Prozessor, mehrere Prozessoren, ein Computer, ein Server (oder jeweils mehrere), und dergleichen.

Die Sicherheitsüberprüfungsvorrichtung kann, in Ausführungsbeispielen, in denen sie ein Teil des Kraftfahrzeugs ist, in dem Informationssystem integriert sein oder mit dem Informationssystem verbunden sein.

Manche Ausführungsbeispiele betreffen ein Kraftfahrzeug, welches ein erfindungsgemäßes Informationssystem aufweist.

Das Kraftfahrzeug kann jedes beliebige durch einen Motor (z. B. Verbrennungsmaschine, Elektromaschine, etc.) betriebene Fahrzeug bezeichnen, wie zum Beispiel ein Automobil, ein Motorrad, einen Lastkraftwagen, einen Omnibus, land- oder forstwirtschaftliche Zugmaschinen, in welchem eine programmierbare (und damit angreifbare) Kraftfahrzeugelektronik vorhanden ist.

Ausführungsbeispiele der Erfindung werden nun beispielhaft und unter Bezugnahme auf die beigefügte Zeichnung beschrieben, in der:

1 schematisch ein Ausführungsbeispiel eines erfindungsgemäßen Verfahrens zur Sicherheitsüberprüfung;
2 schematisch ein weiteres Ausführungsbeispiel eines erfindungsgemäßen Verfahrens zur Sicherheitsüberprüfung;
3 ein Blockdiagramm eines erfindungsgemäßen Sicherheitsüberprüfungssystems;
4 ein Blockdiagramm eines Verfahrens, um ein Sicherheitsprotokoll zu dem Framework hinzuzufügen;
5 ein Blockdiagramm eines Verfahrens, um ein Sicherheitsprotokoll auszuführen; und
6 ein Verfahren für eine erfindungsgemäße Sicherheitsüberprüfung zeigt.

1 zeigt ein Ausführungsbeispiel eines erfindungsgemäßen Verfahrens 1.

In 2 wird eine Sequenz von Sicherheitsprotokollen aus einem Satz von Sicherheitsprotokollen einer Programmierrahmenstruktur festgelegt, wie hierin beschrieben.

In 3 wird die Sequenz von Sicherheitsprotokollen ausgeführt, wie hierin beschrieben.

2 zeigt weiteres Ausführungsbeispiel eines erfindungsgemäßen Verfahrens 10.

In 11 wird eine Sequenz von Sicherheitsprotokollen aus einem Satz von Sicherheitsprotokollen einer Programmierrahmenstruktur festgelegt, wie hierin beschrieben.

In 12 wird die Sequenz von Sicherheitsprotokollen ausgeführt, wie hierin beschrieben.

In 13 wird eine Sicherheitsstufe eines Informationssystems bestimmt, wie hierin beschrieben.

3 zeigt ein erfindungsgemäßes Sicherheitsüberprüfungssystem, welches ein Kraftfahrzeug 20 und eine erfindungsgemäße Sicherheitsüberprüfungsvorrichtung 21 umfasst.

Die Sicherheitsüberprüfungsvorrichtung 21 ist in diesem Ausführungsbeispiel ausgebildet als ein Personal Computer (PC), welcher über eine NFC-Schnittstelle mit dem Kraftfahrzeug 20 verbunden ist und welche ein erfindungsgemäßes Sicherheitsüberprüfungsverfahren ausführt.

Das Kraftfahrzeug 21 weist ein erfindungsgemäßes Informationssystem 22 auf, welches in diesem Ausführungsbeispiel als zentraler Bordcomputer ausgebildet ist.

Das Informationssystem 22 ist des Weiteren an Infotainment-Steuergeräte 23, 24, und 25 gekoppelt, auf welchen sich jeweils Software befindet, welche durch eine erfindungsgemäße Sicherheitsüberprüfung überprüft wird.

4 zeigt ein Blockdiagramm eines Verfahrens 30, um ein Sicherheitsprotokoll zu dem Framework hinzuzufügen.

Ein Nutzer 31 mit einer Sicherheitsfreigabe identifiziert eine potentielle Bedrohung 32, sodass in 33 ein Bedrohungsszenario identifiziert wird.

Daraufhin werden Sicherheitsüberprüfungsschritte 34 definiert, welche auf entsprechende Tools und Konfigurationen 35 im Framework erstellen, sodass das Backend 36 die Testschritte ausführen kann und einen Sicherheitsüberprüfungsbericht erstellen kann.

5 zeigt ein Blockdiagramm eines Verfahrens 40, um ein Sicherheitsprotokoll auszuführen.

Zunächst initiiert ein Nutzer 41 ein vorbestimmtes Sicherheitsprotokoll, welches auf einem Bedrohungsszenario 42 basiert, sodass auf voreingestellte Tools und Konfigurationen 43 zugegriffen wird und Sicherheitsüberprüfungsschritte 44 erstellt werden, woraufhin Sicherheitsüberprüfungsberichtseinträge 45 erstellt werden, sodass ein Sicherheitsüberprüfungsbericht 46 ausgegeben wird.

6 zeigt, in einem Blockdiagramm, ein Verfahren 50 für eine erfindungsgemäße Sicherheitsüberprüfung.

In 51 werden verschiedene Sicherheitsüberprüfungskonzepte (bzw. Sicherheitsprotokolle) basierend auf einer Auswahl von verschiedenen Sicherheitsprotokollvorlagen erstellt, d.h. ein Ablauf der Sicherheitsüberprüfung wird erstellt.

In 52 wird die erstellte Sicherheitsüberprüfung initiiert und daraufhin Angriffe auf ein Informationssystem simuliert, welche in 53 abgerufen werden.

In 54 wird die Sicherheitsüberprüfung durchgeführt, welche in 55 überwacht wird, sodass in 56 ein Sicherheitsüberprüfungsbericht erstellt wird.

Der Sicherheitsüberprüfungsbericht wird in 57 als Feedback für eine künftige Sicherheitsüberprüfung an einen Speicher gesendet, welche als Verbesserung eines gespeicherten Sicherheitsprotokolls dienen kann (oder mehrerer gespeicherter Sicherheitsprotokoll).

Außerdem wird der Sicherheitsüberprüfungsbericht verwendet, um vorbestimmte Kriterien 58 zur Sicherheitsüberprüfung (wie hierin beschrieben) zu definieren bzw. zu verbessern.

Die vorbestimmten Kriterien 58 werden verwendet, um in 59 die Sicherheitsüberprüfung zu verbessern, indem sie beispielsweise als neue Sicherheitsprotokolle und/oder Sicherheitsprotokollvorlagen, in 60, an das Framework übermittelt werden.

Die vorliegende Erfindung soll nicht so ausgelegt werden, dass sie ausschließlich für Kraftfahrzeuge eine Anwendung findet. Generell kann die vorliegende Erfindung auch bei Geräten im Internet der Dinge (loT, Internet of Things) angewendet werden.

Bezugszeichenliste

1: Verfahren zur Sicherheitsüberprüfung
2: Festlegen Sequenz von Sicherheitsprotokollen
3: Ausführen der Sequenz von Sicherheitsprotokollen
10: Verfahren zur Sicherheitsüberprüfung
11: Festlegen Sequenz von Sicherheitsprotokollen
12: Ausführen der Sequenz von Sicherheitsprotokollen
13: Bestimmen Sicherheitsstufe
20: Kraftfahrzeug
21: Sicherheitsüberprüfungsvorrichtung
22: Informationssystem
23: Infotainment-Steuergerät
24: Infotainment-Steuergerät
25: Infotainment-Steuergerät
30: Verfahren, um ein Sicherheitsprotokoll zu dem Framework hinzuzufügen
31: Nutzer mit Sicherheitsfreigabe
32: Bedrohung
33: Identifikation eines Bedrohungsszenarios
34: Sicherheitsüberprüfungsschritte
35: Konfigurationen im Framework
36: Backend
40: Verfahren, um ein Sicherheitsprotokoll auszuführen
41: Nutzer
42: Bedrohungsszenario
43: Tools und Konfigurationen
44: Sicherheitsüberprüfungsschritte
45: Sicherheitsüberprüfungsberichtseinträge
46: Sicherheitsüberprüfungsbericht
50: Verfahren für eine Sicherheitsüberprüfung
51: Erstellen von Sicherheitsüberprüfungskonzepten
52: Initiieren der Sicherheitsüberprüfung
53: Abrufen von simulierten Angriffen
54: Durchführen der Sicherheitsüberprüfung
55: Überwachen der Sicherheitsüberprüfung
56: Erstellen Sicherheitsüberprüfungsbericht
57: Senden des Sicherheitsüberprüfungsberichts an einen Speicher
58: Gemeinsame Kriterien zur Sicherheitsüberprüfung
59: Verbessern der Sicherheitsüberprüfung
60: Übermittlung der vorbestimmten Kriterien an das Framework

ZITATE ENTHALTEN IN DER BESCHREIBUNG

Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.

Zitierte Patentliteratur

EP 2415242 A1 [0005]
US 7269482 B1 [0006]
WO 2014/061021 A1 [0007]

Claims

Verfahren (1; 10) für eine Sicherheitsüberprüfung eines Informationssystems eines Kraftfahrzeugs, umfassend: Festlegen (2; 11) einer Sequenz von Sicherheitsprotokollen aus einem Satz von Sicherheitsprotokollen einer Programmierrahmenstruktur, welche durch ein Hinzufügen eines Sicherheitsprotokolls zu dem Satz von Sicherheitsprotokollen erweiterbar ist, wobei das Festlegen der Sequenz von Sicherheitsprotokollen auf wenigstens einem vorbestimmten Kriterium für eine Sicherheitsüberprüfung basiert; und Ausführen (3; 12) der Sequenz von Sicherheitsprotokollen zum Identifizieren wenigstens einer Sicherheitslücke des Informationssystems des Kraftfahrzeugs.
Verfahren (1; 10) nach Anspruch 1, wobei das wenigstens eine vorbestimmte Kriterium eine Zeit, eine Schwere, ein Ort, und eine weitere Sicherheitslücke umfasst.
Verfahren (1; 10) nach einem der vorherigen Ansprüche, ferner umfassend: Bestimmen (13) einer Sicherheitsstufe des Informationssystems.
Verfahren (1; 10) nach einem der vorherigen Ansprüche, wobei die Programmierrahmenstruktur ein Backend aufweist, welches dazu eingerichtet ist, die Sequenz von Sicherheitsprotokollen auszuführen.
Verfahren (1; 10) nach Anspruch 4, wobei das Backend ferner dazu eingerichtet ist, mit einer Schnittstelle ansteuerbar zu sein.
Verfahren (1; 10) gemäß Anspruch 5, wobei die Schnittstelle wenigstens eines von einer digitalen Schnittstelle, einer virtuellen Schnittstelle, und einer Sensorschnittstelle umfasst.
Verfahren (1; 10) nach einem der Ansprüche 4 bis 6, wobei das Backend ferner ein Nachrichtenprotokoll umfasst.
Verfahren (1; 10) nach einem der Ansprüche 4 bis 7, wobei das Backend ferner Fuzzy-Test-Protokolle umfasst.
Verfahren (1; 10) nach einem der vorherigen Ansprüche, wobei die Programmierrahmenstruktur ein Frontend aufweist, welches dazu eingerichtet ist, eine graphische Benutzeroberfläche bereitzustellen.
Verfahren (1; 10) nach Anspruch 9, wobei ein Sicherheitsprotokoll über die graphische Benutzeroberfläche erstellbar ist.
Verfahren (1; 10) nach einem der Ansprüche 8 bis 10, wobei ein Sicherheitsprotokoll basierend auf einer Sicherheitsprotokollvorlage erstellbar ist.
Verfahren (1; 10) nach einem der vorherigen Ansprüche, wobei ein Sicherheitsprotokoll über eine automatisierte Suche hinzufügbar ist.
Sicherheitsüberprüfungsvorrichtung (21), welche dazu eingerichtet ist, das Verfahren (1; 10) nach einem der vorherigen Ansprüche auszuführen.
Informationssystem (22) für ein Kraftfahrzeug (20), welches mit einer Sicherheitsüberprüfungsvorrichtung (21) nach Anspruch 13 überprüfbar ist.
Kraftfahrzeug (20), welches ein Informationssystem (22) nach Anspruch 14 aufweist.