WO2022117305A1 - Verfahren zum hinterlegen von programmdaten in einer datenbank - Google Patents

Verfahren zum hinterlegen von programmdaten in einer datenbank Download PDF

Info

Publication number
WO2022117305A1
WO2022117305A1 PCT/EP2021/081375 EP2021081375W WO2022117305A1 WO 2022117305 A1 WO2022117305 A1 WO 2022117305A1 EP 2021081375 W EP2021081375 W EP 2021081375W WO 2022117305 A1 WO2022117305 A1 WO 2022117305A1
Authority
WO
WIPO (PCT)
Prior art keywords
program data
information
database
data
computing system
Prior art date
Application number
PCT/EP2021/081375
Other languages
English (en)
French (fr)
Inventor
Sabine Wenz
Original Assignee
Robert Bosch Gmbh
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 Robert Bosch Gmbh filed Critical Robert Bosch Gmbh
Publication of WO2022117305A1 publication Critical patent/WO2022117305A1/de

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities

Definitions

  • the present invention relates to a method for storing program data in a database provided on a computer system, as well as a computer system and a computer program for executing it.
  • Quality checks or "quality gates" to be passed during development and before delivery of the software are usually anchored in the manufacturer's software development process and are therefore independent of the requirements of the functional safety standards.
  • the invention deals with storing (or setting or storing) program data in a database provided on a computer system, in particular in the so-called cloud, i.e. a server that can be reached via the Internet, for example.
  • the program data can in particular include software such as a software application or a function thereof, but also only data that is used, for example, in the context of such software applications or functions, e.g. maps or application curves.
  • program data that is to be used, for example, for control devices in vehicles or other machines, is or should be stored or made available in this way is the idea that a development platform can be created, the companies involved provide program data, e.g. develop software) offers the possibility to host their program data (centrally) and then make them available or released to customers or users on request. For this purpose, however, compliance with safety standards must be guaranteed across all manufacturers.
  • the manufacturers or developers of a software application or other program data are usually not aware of the end customer's security requirements for the software application or program data and therefore usually have no direct interest in verifying one or more domain-specific standards.
  • program data such as functions of and data for software applications are directly or indirectly subject to certain functional safety requirements.
  • a direct reference exists if the program data, such as a software application or a function provided by it, itself has a certain risk potential or is used to avert a risk potential. This includes, for example, software applications that are used in a vehicle cause steering movements or access the brakes.
  • Another indirect reference is when the program data is stored in a software-hardware unit (e.g. in a control unit or an encapsulated part thereof, but also on any other memory such as a database) together with other program data such as a software application or one of these provided function that has a potential risk or is used to avert such. From the point of view of functional safety and the safety and integrity requirements derived from it, this aspect is particularly critical. It is assumed (or must be assumed) that any program data that is located in a software-hardware unit with other program data, software applications or functions without proven separation will "contaminate" them with regard to the guaranteed security requirements.
  • the following procedure is proposed for storing - or setting or storing - program data such as a software application in a database provided on a computing system for later downloading, for example, which is automated by the computing system (i.e. from the cloud or the underlying server or server network) is carried out.
  • the computing system is correspondingly in a integrate network.
  • the program data is received, as well as reference data with information about the program data and about security requirements for the program data.
  • This reference data may also be provided by the developer or manufacturer providing the program data. Both program data and reference data can then be transmitted to the computing system via a suitable interface such as a web interface.
  • the reference data includes two different types of information, namely that which is (directly) associated with the program data (so-called “context catalogue”) and that which relates to its security requirements. (so-called “safety requirements catalogue”).
  • the information about the program data includes, for example, the responsible manufacturer of the program data, standards used, the version of the program data, a unique identifier for the version and the supplied catalogs (context catalogue, security requirements catalogue) (for e.g. cryptographic checksums), Point in time, validity, or self-assessment of the software integrity level of the program data. In general, one can also speak of a “context catalogue”.
  • the information about the security requirements for the program data includes, for example, a description of the conformity with security requirements from applicable standards, e.g. DIN EN ISO25519 for agriculture already mentioned, DIN EN ISO 13849 for machines or DIN EN ISO26262 for automotive.
  • the creation on the part of the supplier i.e.
  • the manufacturer of the program data should preferably be based on automated evaluations of the program data (or software) and the quality artifacts (e.g. test protocols, test design documents, software design documents, static and dynamic, automated code checkers and reviews ) and a conformity check of the software development processes.
  • quality artifacts e.g. test protocols, test design documents, software design documents, static and dynamic, automated code checkers and reviews
  • the program data and the reference data are then temporarily stored on an input area.
  • the entrance area - like the database - is provided by the computing system placed, but separate from the database. But it is also a memory.
  • This input area which is separate from the database, ensures that the program data is not located in a hardware/software unit together with other program data or other software, so that contamination is ruled out.
  • the input area can be separated from the database or parts of the database, for example physically, ie with separate storage units, or via software that creates appropriate partitions. In this case, however, the software must meet the relevant security requirements, which in practice are the highest available, and must be approved for this.
  • the information in the reference data is then checked for one or more criteria. It is expedient to check for several criteria, both in the information about the program data and in the information about security requirements for the program data. This can be done as a two-stage check, so that first the information about the program data is checked for at least one criterion, then the information about security requirements for the program data is checked for at least one criterion.
  • the verification of the information about the program data can include as a criterion, for example, that the received version of the program data (as contained in the information) corresponds to a specific or predetermined version. For example, it can be provided that the criterion is not met if program data with the same version number from the same manufacturer are already present in the database. Further criteria can be, for example, a clear affiliation of the program data or from the catalogs already mentioned to the version of the received program data. To check, for example, a comparison can be made between the requirements stored and the requirements for the uploaded program data, in particular in an automated manner.
  • the program data is not stored in the database and in particular also removed from the entrance area. If a number of setting attempts in which program data received from a specific manufacturer (or provider) does not meet criteria exceeds a predetermined number, it can be provided in particular that further setting attempts by this specific manufacturer are no longer permitted (i.e. blocked) by the computing system. This can also be made more concrete in the two stages or in the two types of information.
  • the verification of the information about the program data is negative, i.e. if at least one of these criteria is not met, not only can it be provided to remove the program data from the input area (i.e. to delete it), but also that e.g. a report is generated and sent to the responsible authorities on the part of the manufacturer (or provider) of program data and computing system (there e.g. the operator) is sent. These reports can also be collected in a log profile for each manufacturer. If a predetermined number of faulty settings in the input area is exceeded, this can not only be blocked for the manufacturer. Here, too, a report can be generated and sent to the responsible authorities, as mentioned above. In this way, it can be prevented that e.g. less trustworthy manufacturers or providers can no longer provide program data in this way in the future.
  • the criteria for the information about security requirements for the program data can be checked in the second stage.
  • the criteria can include, for example, that specified or required values are met depending on the standard used for functional safety, date, integrity class or other parameters. For example, it can be provided that specific documents for the design of the program data (or software) are available, for example also with a specific content.
  • it can be checked which security requirements the program data ultimately meet in order to decide whether or where exactly the program data should be stored.
  • a report can be generated (also at this point) and sent to the responsible authorities, as already mentioned above.
  • the reports can also be collected here in a log profile for each manufacturer. If a predetermined number of incorrect settings is exceeded, which in this second stage corresponds in particular to violations of the software integrity requirements, the input area for the manufacturer can be blocked. Here, too, a report can be generated and sent to the responsible authorities, as mentioned above.
  • a security directory is created that includes at least some of the information in the reference data, preferably all of the information (of both types) contained therein. However, it can also include, for example, a date and/or a result of the check, possibly also a classification of the safety requirement for the checked standards on the computer system side.
  • the program data is then stored in a sub-area of the database that corresponds to a security requirement for the program data and is thus made available, for example, for later downloading or obtaining by a customer or user.
  • the database has several sub-areas that are provided separately from one another and are intended for storing program data with different security requirements.
  • the security directory can then later be used, for example, so that a customer can check whether the program data meets his desired security requirements or not.
  • a particularly relevant aspect of the proposed procedure is the security directory mentioned and its creation.
  • this contains information on software integrity, software reliability, data integrity and context (software version, market, date, period of validity, provider).
  • the admissibility of using the program data for a specific level of functional safety can be determined automatically, the assumptions (delivery) can be controlled in a central software repository (the database), and ultimately the delivery ( Deployment) to a customer or there in a local software repository.
  • a central point here is also the control, classification and, if necessary, rejection of program data with insufficient integrity requirements from a security point of view.
  • a computing system e.g. a server, is set up, in particular in terms of programming, to carry out a method according to the invention.
  • Suitable data carriers for providing the computer program are, in particular, magnetic, optical and electrical memories, such as hard drives, flash memories, EEPROMs, DVDs, etc. It is also possible to download a program via computer networks (Internet, intranet, etc.).
  • FIG. 1 schematically shows a sequence of a method according to the invention in a preferred embodiment.
  • FIG. 1 schematically shows a sequence of a method according to the invention in a preferred embodiment, specifically using a computing system 120 that is set up accordingly.
  • a manufacturer or provider 100 (developer) of e.g. a specific software application for a control unit of a vehicle or a specific function for this program data 110, e.g. a software application or function or also specific data for this, in e.g. a current version for customers.
  • This should take place on the computing system 120 or in a database 130 there, from where the program data 110 can then be downloaded, for example.
  • this program data 110 is not contaminated by other program data with lower security requirements (e.g. according to software integrity level) or other program data with higher security requirements.
  • the provider 100 provides not only the program data 110 itself but also reference data, which on the one hand include information 112 about the program data 110 and information 114 about security requirements for the program data 110 .
  • the information 112 about the program data 110 for example, the responsible manufacturer (this can be one, but several manufacturers are also conceivable) of the program data, standards used, the version of the program data, a unique identifier for the version and supplied catalogues, times , validity, or self-classification of the software Integrity levels of the program data include.
  • Information 112 thus represents a "context catalog”.
  • the information 114 about security requirements for the program data 110 can include, for example, a description of the conformity with security requirements from applicable standards. For the example of a vehicle, this is DIN EN ISO26262 for automotive.
  • the program data 110 and the reference data or information 112, 114 are received by the computing system 120 and temporarily stored there in an input area 122, that is to say a corresponding memory or memory area.
  • the provider 100 can transmit the data to the computing system, e.g. via a web interface or another suitable interface.
  • the information 112, 114 in the reference data is then checked for specific criteria. This is preferably done in two stages. In a first stage, the information 112 about the program data 110 is checked with regard to at least one criterion 140 . As mentioned, it can be checked here, for example, whether the current version of the program data is already in the database 130. If all of the necessary criteria are not met, the program data 110 is deleted from the front end 122 . The same can apply to the reference data.
  • the information 114 about security requirements for the program data 110 can be checked with regard to at least one criterion 142 in the second stage. As mentioned, it can be checked here, for example, whether the values required for the functional safety standard used, e.g. DIN EN ISO26262 or DIN EN ISO25519, are being met for the program data 110, for example the existence of certain documents on the design.
  • the functional safety standard used e.g. DIN EN ISO26262 or DIN EN ISO25519
  • a safety directory 150 is created, which includes, for example, all information 112 and 114 and also, for example, a date and a result of the check, possibly also a classification of the safety requirement for the standards checked.
  • the program data 110 are then stored in a subarea 124 of the database 130 corresponding to a security requirement of the program data.
  • Other program data with other security requirements would be stored in one of the sub-areas 126 or 128, for example. In this way it is ensured that the program data 110 is not contaminated by other program data with lower security requirements or other program data with higher security requirements.
  • the security directory 150 can also be stored together with the program data 110 in the subarea 124 , but if necessary also at a different location and then linked to the program data 110 .
  • a customer or user can now download the program data 110 from the database 130 as required, e.g. to a control unit 160 of a vehicle.
  • the customer will have certain requirements for the program data with regard to security requirements.
  • the customer can use the security directory 150 to check whether the program data 110 meet his desired security requirements. If so, he can download it, otherwise he can refrain from doing so. This process of checking can also be automated, for example.

Abstract

Die Erfindung betrifft ein Verfahren zum Hinterlegen von Programmdaten (110) in einer auf einem Rechensystem (120) bereitgestellten Datenbank (130), mit folgenden, automatisiert von dem Rechensystem (120) durchgeführten Schritten: Empfangen der Programmdaten (110) und von Referenzdaten (112, 114) mit Informationen über die Programmdaten (110) sowie über Sicherheitsanforderungen an die Programmdaten (110), Zwischenspeichern der Programmdaten (110) und der Referenzdaten (112, 114) in einem von dem Rechensystem (120) getrennt von der Datenbank (130) bereitgestellten Eingangsbereich (122), Überprüfen der Informationen (112, 114) in den Referenzdaten auf eines oder mehrere Kriterien (140, 142) und Erstellen, wenn das eine oder die mehreren Kriterien (140, 142) erfüllt sind, eines Sicherheitsverzeichnisses (150), das zumindest einen Teil der Informationen (112, 114) in den Referenzdaten umfasst, und Speichern der Programmdaten (110) in einem einer Sicherheitsanforderung der Programmdaten (110) entsprechenden Teilbereich (124) der Datenbank (130).

Description

Beschreibung
Titel
Verfahren zum Hinterlegen von Programmdaten in einer Datenbank
Die vorliegende Erfindung betrifft ein Verfahren zum Hinterlegen von Programmdaten in einer auf einem Rechensystem bereitgestellten Datenbank sowie ein Rechensystem und ein Computerprogramm zu dessen Durchführung.
Hintergrund der Erfindung
Für Produkte in sicherheitsrelevanten Bereichen, z.B. bei Fahrzeugen oder Maschinen, existieren je nach Domäne oder Anwendung Normen zur funktionalen Sicherheit. Dies betrifft nicht nur die Hardware, sondern auch die Software oder allgemein Programmdaten, dort insbesondere sog. Software-Integritäts-Level (SIL). Diese Normen beschreiben z.B. Anforderungen an den Software- Entwicklungsprozess und an die Daten- bzw. Softwarebereitstellung. Solche Normen sind z.B. die DIN EN ISO25519 für Landwirtschaft, die DIN EN ISO 13849 für Maschinen, oder die DIN EN ISO26262 für Automotive.
Während der Software-Entwicklung sind dabei je nach Norm unterschiedliche Qualitätsdaten zu erheben und nachzuweisen. Dies kann manuell oder auch automatisch erfolgen. Zu durchlaufende Qualitätsprüfungen (oder auch "Quality Gates") während der Entwicklung und vor Auslieferung der Software sind in der Regel im Software-Entwicklungsprozess des Herstellers verankert und damit unabhängig von Anforderungen aus den Normen der funktionalen Sicherheit.
Offenbarung der Erfindung Erfindungsgemäß werden ein Verfahren zum Hinterlegen von Programmdaten in einer Datenbank sowie ein Rechensystem und ein Computerprogramm zu dessen Durchführung mit den Merkmalen der unabhängigen Patentansprüche vorgeschlagen. Vorteilhafte Ausgestaltungen sind Gegenstand der Unteransprüche sowie der nachfolgenden Beschreibung.
Die Erfindung beschäftigt sich mit dem Hinterlegen (oder Einstellen bzw. Speichern) von Programmdaten in einer auf einem Rechensystem bereitgestellten Datenbank, insbesondere in der sog. Cloud, also einem z.B. über Internet erreichbaren Server. Die Programmdaten können dabei insbesondere Software wie eine Softwareanwendung oder eine Funktion hiervon umfassen, ebenso aber auch nur Daten, die z.B. im Rahmen von solchen Softwareanwendungen oder Funktionen verwendet werden, z.B. Karten oder Applikationskurven.
Ein Grund, weshalb Programmdaten, die z.B. für Steuergeräte in Fahrzeugen oder anderen Maschinen verwendet werden sollen, auf diese Weise hinterlegt bzw. bereitgestellt werden oder werden sollen, ist die Überlegung, dass eine Entwicklungs-Plattform geschaffen werden kann, die beteiligten Unternehmen (die die Programmdaten bereitstellen, also z.B. Software entwickeln) die Möglichkeit bietet, ihre Programmdaten (zentral) zu hosten und dann auf Anforderung an Kunden bzw. Anwender bereitzustellen bzw. herauszugeben. Hierfür muss aber herstellerübergreifend die Einhaltung von Sicherheitsnormen gewährleistet sein.
Die Hersteller bzw. Entwickler einer Softwareanwendung oder anderer Programmdaten kennen in der Regel die Sicherheitsanforderung des Endkunden an die Softwareanwendung bzw. Programmdaten nicht und haben daher meist auch kein direktes Interesse am Nachweis für eine oder mehrere domänen-spezifische Normen. Programmdaten wie Funktionen von und Daten für Softwareanwendungen unterliegen aber direkt oder indirekt gewissen Anforderungen der funktionalen Sicherheit. Ein direkter Bezug liegt vor, wenn die Programmdaten, wie eine Softwareanwendung oder eine von ihr bereitgestellte Funktion, selbst ein gewisses Gefährdungspotential aufweisen oder zur Abwendung eines Gefährdungspotentials dienen. Hierunter fallen z.B. Softwareanwendungen, die in einem Fahr- zeug Lenkbewegungen verursachen oder auf die Bremsen zugreifen. Ein indirekter Bezug liegt vor, wenn Programmdaten wie eine Softwareanwendung oder eine von ihr bereitgestellte Funktion selbst zwar kein Gefährdungspotential aufweisen bzw. zur Abwendung eines solchen dienen, aber im Zusammenhang mit einer solchen Softwareanwendung bzw. Funktion verwendet werden. Ein Beispiel hierfür wäre die Messung oder Anzeige von Entfernungen, z.B. zum nächsten Hindernis vor einem Fahrzeug. Dies ist an sich zwar nicht sicherheitsrelevant, wird aber für sicherheitsrelevante Funktionen wie z.B. einem rechtzeitigen Bremsen benötigt.
Ein weiterer indirekter Bezug liegt vor, wenn die Programmdaten in einer Software-Hardware-Einheit (z.B. in einem Steuergerät oder einem abgekapselten Teil davon, aber auch auf jedem anderen beliebigen Speicher wie einer Datenbank) zusammen mit anderen Programmdaten wie einer Softwareanwendung oder einer von dieser bereitgestellten Funktion liegen, die ein Gefährdungspotential aufweist bzw. zur Abwendung eines solchen dient. Dieser Aspekt ist vom Gesichtspunkt der funktionalen Sicherheit und der daraus abgeleiteten Sicherheits- bzw. Integritätsanforderungen her gesehen ein besonders kritischer. Es wird nämlich unterstellt (oder muss unterstellt werden), dass beliebige Programmdaten, die ohne nachgewiesene Trennung in einer Software-Hardware-Einheit mit anderen Programmdaten, Softwareanwendungen oder Funktionen liegen, diese hinsichtlich der gewährleisteten Sicherheitsanforderungen „kontaminieren“.
Die Folge davon ist, dass alle Programmdaten dieser Hardware-Software-Einheit den Softwareintegritätslevel der Programmdaten mit der niedrigsten Integritätseinstufung einnehmen. In der Konsequenz muss eine solche Kontamination der in der Cloud bzw. der Datenbank liegenden Programmdaten verhindert werden.
Vor diesem Hintergrund wird folgendes Vorgehen für das Hinterlegen - bzw. Einstellen oder Speichern - von Programmdaten wie z.B. einer Softwareanwendung in einer auf einem Rechensystem bereitgestellten Datenbank für z.B. späteres Herunterladen vorgeschlagen, das automatisiert von dem Rechensystem (also sozusagen von der Cloud bzw. dem zugrundliegenden Server oder Serververbund) durchgeführt wird. Das Rechensystem ist hierzu entsprechend in ein Netzwerk einzubinden. Zunächst werden die Programmdaten empfangen, ebenso wie Referenzdaten mit Informationen über die Programmdaten sowie über Sicherheitsanforderungen an die Programmdaten.
Diese Referenzdaten können von dem Entwickler oder Hersteller, von dem die Programmdaten bereitgestellt werden, ebenfalls bereitgestellt werden. Beides, Programmdaten und Referenzdaten, kann dann z.B. über eine geeignete Schnittstelle wie z.B. ein Web-Interface an das Rechensystem übermittelt werden. Die Referenzdaten umfassen dabei zwei verschiedene Arten von Informationen, nämlich solche, die (direkt) mit den Programmdaten assoziiert sind (sog. "Kontext-Katalog"), sowie solche, die dessen Sicherheitsanforderungen betreffen. (sog. "Sicherheitsanforderungs-Katalog").
Die Informationen über die Programmdaten umfassen z.B. die verantwortlichen Hersteller der Programmdaten, verwendete Normen, die Version der Programmdaten, einen eindeutigen Identifier für die Version sowie mitgelieferte Kataloge "(Kontext-Katalog", "Sicherheitsanforderungs-Katalog") (für z.B. kryptographische Prüfsummen), Zeitpunkte, Gültigkeit, oder Selbsteinstufung des Software- Integritätslevels der Programmdaten. Hier kann allgemein auch von einem "Kontext-Katalog" gesprochen werden. Die Informationen über die Sicherheitsanforderungen an die Programmdaten umfassen z.B. eine Beschreibung der Konformität mit Sicherheitsanforderungen aus anzuwenden Normen, z.B. die eingangs schon genannte DIN EN ISO25519 für Landwirtschaft, die DIN EN ISO 13849 für Maschinen oder die DIN EN ISO26262 für Automotive. Die Erstellung auf Seiten des Zulieferers (also des Herstellers der Programmdaten) sollte bevorzugt auf automatisierten Auswertungen der Programmdaten (oder Software) und der Qualitäts-Artefakte (z.B. Testprotokolle, Testdesigndokumente, Softwartedesigndokumente, statische und dynamische, automatisiert ablaufende, Code-Checker, sowie Reviews) sowie einer Konformitätsüberprüfung der Software- Entwicklungsprozesse erfolgen.
Die Programmdaten sowie die Referenzdaten (mit beiden Arten von Informationen) werden dann auf einem Eingangsbereich zwischengespeichert. Der Eingangsbereich wird - wie auch die Datenbank - von dem Rechensystem bereit- gestellt, aber getrennt von der Datenbank. Es handelt sich aber ebenfalls um einen Speicher. Durch diesen von der Datenbank getrennten Eingangsbereich wird sichergestellt, dass die Programmdaten nicht in einer Hardware-Software-Einheit zusammen mit anderen Programmdaten oder sonstiger Software liegen, sodass eine Kontamination ausgeschlossen wird. Eine Trennung des Eingangsbereichs von der Datenbank bzw. von Teilen der Datenbank kann z.B. physisch, also mit separaten Speichereinheiten, erfolgen, oder aber auch über eine Software, die entsprechende Partitionen erstellt. Hier muss die Software dann aber der entsprechenden Sicherheitsanforderung, in der Praxis der höchsten verfügbaren, genügen und dafür freigegeben sein.
Nachfolgend werden die Informationen in den Referenzdaten auf eines oder mehrere Kriterien überprüft. Zweckmäßig ist die Überprüfung auf mehrere Kriterien, und zwar sowohl bei den Informationen über die Programmdaten als auch bei den Informationen über Sicherheitsanforderungen an die Programmdaten. Dies kann als zweistufige Prüfung erfolgen, sodass zunächst die Informationen über die Programmdaten auf wenigsten ein Kriterium überprüft werden, danach die Informationen über Sicherheitsanforderungen an die Programmdaten auf wenigsten ein Kriterium.
Die Überprüfung der Informationen über die Programmdaten kann als Kriterium z.B. umfassen, dass die empfangene Version der Programmdaten (wie sie in den Informationen enthalten ist) einer bestimmten oder vorgegebenen Version entspricht. Beispielsweise kann vorgesehen sein, dass das Kriterium als nicht erfüllt gilt, wenn Programmdaten mit gleicher Versionsnummer vom selben Hersteller bereits in der Datenbank vorhanden sind. Weitere Kriterien können z.B. eine eindeutige Zugehörigkeit der Programdaten oder von den schon erwähnten Katalogen zur Version der empfangene Programmdaten sein. Zur Überprüfung kann z.B. ein Abgleich zwischen hinterlegten Anforderung mit den Anforderungen zu den hochgeladenen Programmdaten erfolgen, und zwar insbesondere automatisiert.
Wenn das eine oder zumindest eines der mehreren Kriterien nicht erfüllt ist, werden die Programmdaten nicht in der Datenbank gespeichert und insbesondere auch aus dem Eingangsbereich entfernt. Wenn eine Anzahl an Einstellversuchen, bei denen von einem bestimmten Hersteller (oder Anbieter) empfangene Programmdaten Kriterien nicht erfüllen, eine vorbestimmte Anzahl übersteigt, kann insbesondere vorgesehen werden, dass weitere Einstellversuche dieses bestimmten Herstellers von dem Rechensystem nicht mehr zugelassen (also blockiert) werden. Auch dies kann bei den beiden Stufen bzw. bei den beiden Arten von Informationen nochmals konkretisiert werden.
Fällt die Überprüfung der Informationen über die Programmdaten negativ aus, d.h. ist wenigstens eines dieser Kriterien nicht erfüllt, so kann nicht nur vorgesehen sein, die Programmdaten aus dem Eingangsbereich zu entfernen (also zu löschen), sondern auch, dass z.B. ein Bericht generiert und an die verantwortlichen Instanzen auf Seiten der Hersteller (bzw. Anbieter) von Programmdaten und Rechensystem (dort z.B. der Betreiber) gesendet wird. Diese Berichte können auch in einem Log-Profil für jeden Hersteller gesammelt werden. Bei Überschreiten einer vorbestimmten Menge an fehlerhaften Einstellungen in den Eingangsbereich kann dieser nicht nur für den Hersteller blockiert werden. Auch hier kann ein Bericht generiert und an die verantwortlichen Instanzen, wie vorstehend schon genannt, gesendet werden. Auf diese Weise kann verhindert werden, dass z.B. wenig vertrauenswürde Hersteller oder Anbieter in Zukunft keine Programmdaten mehr auf diesem Wege bereitstellen können.
Ist die Überprüfung in der erste Stufe hingegen erfolgreich, d.h. sind alle nötigen Kriterien bei den Informationen über die Programmdaten erfüllt, kann in der zweiten Stufe die Überprüfung der Kriterien der Informationen über Sicherheitsanforderungen an die Programmdaten erfolgen. Hier können die Kriterien z.B. umfassen, dass abhängig von der verwendeten Norm zur funktionalen Sicherheit, Datum, Integritäts-Klasse oder sonstiger Parameter vorgegebene oder geforderte Werten erfüllt sind. Beispielsweise kann z.B. vorgesehen sein, dass bestimmte Dokumente zum Design der Programmdaten (oder Software) vorliegen, z.B. auch mit einem bestimmten Inhalt. Zudem kann in diesem Zusammenhang geprüft werden, welche Sicherheitsanforderung die Programmdaten letztlich erfüllen, um zu entscheiden, ob oder wo genau die Programmdaten gespeichert werden sollen. Sind die Überprüfungen fehlerhaft, d.h. ist wenigstens eines dieser Kriterien nicht erfüllt, so kann (auch an dieser Stelle) ein Bericht generiert und an die verantwortlichen Instanzen, wie vorstehend schon genannt, gesendet werden. Auch können hier die Berichte in einem Log-Profil für jeden Hersteller gesammelt werden. Bei Überschreiten einer vorbestimmten Menge an fehlerhaften Einstellungen, was in dieser zweiten Stufe insbesondere Verletzungen der Software- Integritätsanforderungen entspricht, kann der Eingangsbereich für den Hersteller blockiert werden. Auch hier kann ein Bericht generiert und an die verantwortlichen Instanzen, wie vorstehend schon genannt, gesendet werden.
Sind hingegen alle Überprüfungen erfolgreich, d.h. sind alle nötigen Kriterien erfüllt, wird ein Sicherheitsverzeichnis erstellt, das zumindest einen Teil der Informationen in den Referenzdaten, vorzugsweise sämtliche darin enthaltenen Informationen (beider Arten) umfasst. Ebenso können aber z.B. ein Datum und/oder ein Ergebnis der Überprüfung, ggf. auch eine Klassifizierung der Sicherheitsanforderung für die überprüften Normen auf Seiten des Rechensystems darin umfasst sein. Die Programmdaten werden dann in einem einer Sicherheitsanforderung der Programmdaten entsprechenden Teilbereich der Datenbank gespeichert und damit für z.B. ein späteres Herunterladen bzw. Beziehen durch einen Kunden oder Anwender bereitgestellt. In diesem Zusammenhang ist es auch zweckmäßig, wenn die Datenbank mehrere, voneinander getrennt bereitgestellte, Teilbereiche aufweist, die zum Speichern von Programmdaten mit verschiedenen Sicherheitsanforderungen vorgesehen sind. Das Sicherheitsverzeichnis kann dann später z.B. dazu verwendet werden, damit ein Kunde überprüfen kann, ob die Programmdaten seine gewünschten Sicherheitsanforderungen erfüllen oder nicht.
Auf diese Weise kann also erreicht werden, dass Programmdaten wie Softwareanwendungen oder Funktion oder sonstige Daten hierfür derart in der Datenbank gespeichert und bereitgestellt werden können, dass eine Kontamination von Programmdaten mit höheren Sicherheitsanforderungen durch Programmdaten mit geringeren Sicherheitsanforderungen sicher vermieden wird. Ein besonders relevanter Aspekt des vorgeschlagenen Vorgehens ist dabei das erwähnte Sicherheitsverzeichnis bzw. dessen Erstellung. Dieses enthält insbesondere Informationen zur Software-Integrität, Software-Zuverlässigkeit (Reliability), Daten-Integrität sowie zum Kontext (Version der Software, Markt, Datum, Gültigkeitsdauer, Anbieter). Anhand dieser Informationen kann die Zulässigkeit des Einsatzes der Programmdaten für ein bestimmtes Level der funktionalen Sicherheit automatisch bestimmt werden, es können die Annahmen (Delivery) in ein zentrales Software-Repository (die Datenbank) gesteuert werden, und es kann darüber letztlich auch die Auslieferung (Deployment) an einen Kunden bzw. dort in ein lokales Software-Repository gesteuert werden. Ein zentraler Punkt hierbei ist auch die Kontrolle, Einordnung und ggf. Zurückweisung von Programmdaten mit aus Sicherheits-Gesichtspunkten ungenügenden Integritätsanforderungen.
Ein erfindungsgemäßes Rechensystem z.B. ein Server, ist, insbesondere programmtechnisch, dazu eingerichtet, ein erfindungsgemäßes Verfahren durchzuführen.
Auch die Implementierung eines erfindungsgemäßen Verfahrens in Form eines Computerprogramms oder Computerprogrammprodukts mit Programmcode zur Durchführung aller Verfahrensschritte ist vorteilhaft, da dies besonders geringe Kosten verursacht, insbesondere wenn ein ausführendes Rechensystem noch für weitere Aufgaben genutzt wird und daher ohnehin vorhanden ist. Geeignete Datenträger zur Bereitstellung des Computerprogramms sind insbesondere magnetische, optische und elektrische Speicher, wie z.B. Festplatten, Flash-Speicher, EEPROMs, DVDs u.a.m. Auch ein Download eines Programms über Computernetze (Internet, Intranet usw.) ist möglich.
Weitere Vorteile und Ausgestaltungen der Erfindung ergeben sich aus der Beschreibung und der beiliegenden Zeichnung.
Die Erfindung ist anhand eines Ausführungsbeispiels in der Zeichnung schematisch dargestellt und wird im Folgenden unter Bezugnahme auf die Zeichnung beschrieben. Kurze Beschreibung der Zeichnungen
Figur 1 zeigt schematisch einen Ablauf eines erfindungsgemäßen Verfahrens in einer bevorzugten Ausführungsform.
Ausführungsform(en) der Erfindung
Figur 1 zeigt schematisch einen Ablauf eines erfindungsgemäßen Verfahrens in einer bevorzugten Ausführungsform, und zwar insbesondere anhand eines Rechensystems 120, das entsprechend dazu eingerichtet ist.
Beispielsweise will ein Hersteller oder Anbieter 100 (Entwickler) von z.B. einer bestimmten Softwareanwendung für ein Steuergerät eines Fahrzeugs oder einer bestimmten Funktion hierfür Programmdaten 110, z.B. eine Softwareanwendung oder Funktion oder auch bestimmte Daten hierfür, in z.B. einer aktuellen Version für Kunden zur Verfügung stellen. Dies soll auf dem Rechensystem 120 bzw. dort einer Datenbank 130 erfolgen, von wo die Programmdaten 110 dann z.B. heruntergeladen werden können.
Im Rahmen der Erfindung soll, wie erwähnt, erreicht werden, dass diese Programmdaten 110 nicht von anderen Programmdaten mit niedrigeren Sicherheitsanforderungen (z.B. gemäß Software-Integritäts-Level) kontaminiert werden oder andere Programmdaten mit höheren Sicherheitsanforderungen kontaminieren. Hierzu stellt der Anbieter 100 neben den Programmdaten 110 selbst auch noch Referenzdaten zur Verfügung, die einerseits Informationen 112 über die Programmdaten 110 sowie Informationen 114 über Sicherheitsanforderungen an die Programmdaten 110 umfassen.
Wie erwähnt, können die Informationen 112 über die Programmdaten 110 z.B. die verantwortlichen Hersteller (dies kann einer sein, denkbar sind aber auch mehrere Hersteller) der Programmdaten, verwendete Normen, die Version der Programmdaten, einen eindeutigen Identifier für die Version sowie mitgelieferte Kataloge, Zeitpunkte, Gültigkeit, oder Selbsteinstufung des Software- Integritätslevels der Programmdaten umfassen. Informationen 112 stellen damit einen "Kontext-Katalog" dar. Die Informationen 114 über Sicherheitsanforderungen an die Programmdaten 110 können z.B. eine Beschreibung der Konformität mit Sicherheitsanforderungen aus anzuwenden Normen umfassen. Für das Beispiel eines Fahrzeugs ist dies z.B. die DIN EN ISO26262 für Automotive.
Die Programmdaten 110 und die Referenzdaten bzw. Informationen 112, 114 werden von dem Rechensystem 120 empfangen und dort zunächst auf einem Eingangsbereich 122, also einem entsprechenden Speicher oder Speicherbereich zwischengespeichert. Hierzu kann der Anbieter 100 die Daten z.B. über ein Web-Interface oder eine andere geeignete Schnittstelle an das Rechensystem übermitteln.
Die Informationen 112, 114 in den Referenzdaten werden dann auf bestimmte Kriterien überprüft. Dies erfolgt bevorzugt in zwei Stufen. Zunächst werden in einer ersten Stufe die Informationen 112 über die Programmdaten 110 hinsichtlich zumindest eines Kriteriums 140 überprüft. Wie erwähnt, kann hier z.B. geprüft werden, ob die vorliegende Version der Programmdaten schon in der Datenbank 130 vorhanden ist. Wenn nicht alle nötigen Kriterien erfüllt werden, werden die Programmdaten 110 aus dem Eingangsbereich 122 gelöscht. Gleiches kann für die Referenzdaten gelten.
Wenn die Kriterien 140 allerdings erfüllt sind, können in der zweiten Stufe die Informationen 114 über Sicherheitsanforderungen an die Programmdaten 110 hinsichtlich zumindest eines Kriteriums 142 überprüft werden. Wie erwähnt, kann hier z.B. geprüft werden, ob die bei der verwendeten Norm zur funktionalen Sicherheit, also z.B. der DIN EN ISO26262 oder DIN EN ISO25519, geforderten Werte bei den Programdaten 110 eingehalten werden, beispielsweise das Vorliegen bestimmter Dokumente zum Design.
Wenn auch Kriterien 142 erfüllt sind, wird ein Sicherheitsverzeichnis 150 erstellt, das z.B. sämtliche Informationen 112 und 114 umfasst sowie z.B. auch ein Datum und ein Ergebnis der Überprüfung, ggf. auch eine Klassifizierung der Sicherheitsanforderung für die überprüften Normen. Die Programmdaten 110 werden dann in einem einer Sicherheitsanforderung der Programmdaten entsprechenden Teilbereich 124 der Datenbank 130 gespeichert. Andere Programmdaten mit anderen Sicherheitsanforderungen würden z.B. in einem der Teilbereiche 126 oder 128 gespeichert. Auf diese Weise wird sichergestellt, dass die Programmdaten 110 nicht von anderen Programmdaten mit niedrigeren Sicherheitsanforderungen kontaminiert werden oder andere Programmdaten mit höheren Sicherheitsanforderungen kontaminieren.
Das Sicherheitsverzeichnis 150 kann ebenfalls zusammen mit den Programmdaten 110 in dem Teilbereich 124 gespeichert werden, ggf. aber auch an einer anderen Stelle und dann mit den Programmdaten 110 verknüpft werden.
Ein Kunde oder Anwender kann die Programmdaten 110 aus der Datenbank 130 nun bei Bedarf herunterladen, z.B. auf ein Steuergerät 160 eines Fahrzeugs. Der Kunde wird dabei bestimmte Anforderungen an die Programmdaten hinsichtlich der Sicherheitsanforderungen haben. Anhand des Sicherheitsverzeichnisses 150 kann der Kunde dabei überprüfen, ob die Programdaten 110 seinen gewünschten Sicherheitsanforderungen entsprechen. Falls dem so ist, kann er sie herunterladen, andernfalls kann er davon absehen. Dieser Vorgang der Überprüfung kann z.B. auch automatisiert erfolgen.

Claims

Ansprüche
1 . Verfahren zum Hinterlegen von Programmdaten (110) in einer auf einem Rechensystem (120) bereitgestellten Datenbank (130), mit folgenden, automatisiert von dem Rechensystem (120) durchgeführten Schritten:
Empfangen der Programmdaten (110) und von Referenzdaten (112, 114) mit Informationen über die Programmdaten (110) sowie über Sicherheitsanforderungen an die Programmdaten (110),
Zwischenspeichern der Programmdaten (110) und der Referenzdaten (112, 114) auf einem auf dem Rechensystem (120) getrennt von der Datenbank (130) bereitgestellten Eingangsbereich (122),
Überprüfen der Informationen (112, 114) in den Referenzdaten auf eines oder mehrere Kriterien (140, 142),
Erstellen, wenn das eine oder die mehreren Kriterien (140, 142) erfüllt sind, eines Sicherheitsverzeichnisses (150), das zumindest einen Teil der Informationen (112, 114) in den Referenzdaten umfasst, und
Speichern der Programmdaten (110) in einem einer Sicherheitsanforderung der Programmdaten (110) entsprechenden Teilbereich (124) der Datenbank (130).
2. Verfahren nach Anspruch 1 , wobei die Informationen (112) über die Programmdaten (110) zumindest eines der folgenden umfassen: Hersteller (100), verwendete Normen, Version, Identifier für die Version, Zeitpunkte, Gültigkeit, Selbsteinstufung der Sicherheitsanforderung.
3. Verfahren nach Anspruch 1 oder 2, wobei die Informationen (114) über Sicherheitsanforderungen an die Programmdaten (110) eine Beschreibung einer Konformität der Programmdaten (110) mit Sicherheitsanforderungen aus anzuwenden Normen umfasst.
4. Verfahren nach einem der vorstehenden Ansprüche, wobei die Informationen (112, 114) in den Referenzdaten auf mehrere Kriterien (140, 142) geprüft werden, wobei die Informationen (112) über die Programmdaten (110) auf wenigstens ein Kriterium (140) überprüft werden, und wobei die Informationen (114) über Sicherheitsanforderungen an die Programmdaten (110) auf wenigstens ein Kriterium (142) überprüft werden.
5. Verfahren nach einem der vorstehenden Ansprüche, wobei, wenn das eine oder zumindest eines der mehreren Kriterien (140, 142) nicht erfüllt ist, die Programmdaten (110) nicht in der Datenbank (130) gespeichert werden, und insbesondere auch aus dem Eingangsbereich (122) entfernt werden.
6. Verfahren nach einem der vorstehenden Ansprüche, wobei, wenn eine Anzahl an Einstellversuchen, bei denen von einem bestimmten Hersteller (100) empfangene Programmdaten (110) Kriterien nicht erfüllen, eine vorbestimmte Anzahl übersteigt, weitere Einstellversuche dieses bestimmten Herstellers (100) nicht mehr zugelassen werden.
7. Verfahren nach einem der vorstehenden Ansprüche, wobei die von dem Rechensystem (120) bereitgestellte Datenbank (130) mehrere, voneinander getrennt bereitgestellte, Teilbereiche (124, 126, 128) aufweist, die zum Speichern von Programmdaten mit verschiedenen Sicherheitsanforderungen vorgesehen sind.
8. Rechensystem (120), das dazu eingerichtet ist, alle Verfahrensschritte eines Verfahrens nach einem der vorstehenden Ansprüche durchzuführen.
9. Computerprogramm, das ein Rechensystem (120) dazu veranlasst, alle Verfahrensschritte eines Verfahrens nach einem der Ansprüche 1 bis 7 durchzuführen, wenn es auf dem Rechensystem (120) ausgeführt wird.
10. Maschinenlesbares Speichermedium mit einem darauf gespeicherten Computerprogramm nach Anspruch 9.
PCT/EP2021/081375 2020-12-03 2021-11-11 Verfahren zum hinterlegen von programmdaten in einer datenbank WO2022117305A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102020215292.6 2020-12-03
DE102020215292.6A DE102020215292A1 (de) 2020-12-03 2020-12-03 Verfahren zum Hinterlegen von Programmdaten in einer Datenbank

Publications (1)

Publication Number Publication Date
WO2022117305A1 true WO2022117305A1 (de) 2022-06-09

Family

ID=78709431

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2021/081375 WO2022117305A1 (de) 2020-12-03 2021-11-11 Verfahren zum hinterlegen von programmdaten in einer datenbank

Country Status (2)

Country Link
DE (1) DE102020215292A1 (de)
WO (1) WO2022117305A1 (de)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014088914A1 (en) * 2012-12-05 2014-06-12 Symantec Corporation Method and apparatus for secure storage segmentation based on security context in a virtual environment
US20200012799A1 (en) * 2014-12-09 2020-01-09 International Business Machines Corporation Automated management of confidential data in cloud environments

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014088914A1 (en) * 2012-12-05 2014-06-12 Symantec Corporation Method and apparatus for secure storage segmentation based on security context in a virtual environment
US20200012799A1 (en) * 2014-12-09 2020-01-09 International Business Machines Corporation Automated management of confidential data in cloud environments

Also Published As

Publication number Publication date
DE102020215292A1 (de) 2022-06-09

Similar Documents

Publication Publication Date Title
DE60315996T2 (de) Verfahren und vorrichtung zur datenbewegung mittels sperren
WO2006100078A1 (de) Vergleich von schnittstellen zwischen softwarekomponenten
DE102008012843A1 (de) Unternehmensdatenmanagement
DE10309246B4 (de) Verfahren für das Event Management
WO2020011655A1 (de) Verfahren und system zur datenerfassung in fahrzeugen
EP3732608B1 (de) Verfahren zur rechnergestützten parametrierung eines technischen systems
WO2022117305A1 (de) Verfahren zum hinterlegen von programmdaten in einer datenbank
DE102019001100A1 (de) Verfahren zur Überwachung einer Funktionalität eines Fahrzeuginformationssystems eines Kraftfahrzeugs, sowie elektronische Recheneinrichtung, Computerprogramm und Datenträger
DE102010021382A1 (de) Verfahren und System zur Erzeugung eines Integrationsmodells
EP3508928A1 (de) Verfahren zum verarbeiten von alarmen in einem prozessleitsystem sowie operator-system
DE10110949A1 (de) Automatisierte Versions-Analyse von zu einer Softwareapplikation gehörenden Softwarekomponenten
WO2022117306A1 (de) Verfahren zum bereitstellen von programmdaten aus einer datenbank
DE19644680A1 (de) Verfahren und Vorrichtung zur Handhabung von Kennzeichnungsdaten einer Mehrzahl von Komponenten eines Produktes
DE102019213738A1 (de) Software-Komponenten für eine Software-Architektur
DE10213735A1 (de) Verfahren und Vorrichtung zum Vergleichen von Produkteigenschaften
DE102005049510B4 (de) Verfahren zum Verwalten eines Sicherheitssystems
WO2018206522A1 (de) Produktreifebestimmung eines technischen systems und insbesondere eines autonom fahrenden fahrzeugs
DE102016207768A1 (de) Vorrichtung und Verfahren zum Bereitstellen einer Menge von Modultypen
DE102021211830A1 (de) Verfahren für eine Überprüfung einer komplexen Regulationssituation
DE102019131639B4 (de) System zum Bereitstellen eines Erklärungsdatensatzes für ein KI-Modul
EP1708062A1 (de) Vorrichtung und Verfahren zur Verwaltung von Daten, die einem komplexen Gegenstand zugeordnet sind
DE102021109399A1 (de) Vorrichtung und Verfahren zur Identifizierung von Veränderungen an einer Maschinenanordnung
EP3690689A1 (de) System und verfahren zum sicheren ausführen von anwendungsprogrammen
DE102022207085A1 (de) Verfahren zum Erzeugen eines digitalen Zwillings eines autonom fahrenden Kraftfahrzeuges
WO2023186800A1 (de) Verfahren zur bereitstellung von werkzeugdatensätzen für bearbeitungswerkzeuge

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21810979

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21810979

Country of ref document: EP

Kind code of ref document: A1