WO2009077271A1

WO2009077271A1 - Verfahren zum identifizieren gegenseitiger beeinflussung von softwarekomponenten

Info

Publication number: WO2009077271A1
Application number: PCT/EP2008/065369
Authority: WO
Inventors: Efthimios Liakos; Roland Porsch; Stefan Rothbauer; Martin Rothfelder; Michael Zanzinger; Hartmut Zeilmann
Original assignee: Siemens Aktiengesellschaft
Priority date: 2007-12-18
Filing date: 2008-11-12
Publication date: 2009-06-25
Also published as: DE102008018680A1; US8620873B2; EP2225640A1; US20100313075A1

Abstract

Die vorliegende Erfindung bezieht sich auf ein Unterstützen eines sicherheitsgerichteten Systems, wobei das sicherheitsgerichtete System sicherheitskritische Softwarekomponenten und sicherheitsunkritische Softwarekomponenten aufweist. Dabei wird eine Möglichkeit einer gegenseitigen Beeinflussung einer sicherheitskritischen Softwarekomponente und einer sicherheitsunkritische Softwarekomponente identifiziert und einer Menge von technischen Maßnahmen zum Verhindern der Möglichkeit der Beeinflussung definiert. Auf diese Weise wird durch die vorliegende Erfindung eine Rückwirkungsfreiheit von sicherheitsunkritischen Softwarekomponenten auf sicherheitskritische Softwarekomponenten sowohl nachgewiesen als auch sichergestellt.

Description

Beschreibung

VERFAHREN ZUM IDENTIFIZIEREN GEGENSEITIGER BEEINFLUSSUNG VON SOFTWAREKOMPONENTEN

Die vorliegende Erfindung betrifft ein Verfahren zum Unterstützen eines sicherheitsgerichteten Systems.

Eines der Ziele eines sicherheitsrelevanten oder sicherheits- gerichteten Systems ist es, ein zuverlässiges und korrektes

Funktionieren von Softwarekomponenten, die an sicherheitskritischen Funktionen beteiligt sind, zu gewährleisten.

Bei der Ausführung einer Sicherheitsfunktion kann ihre Zuver- lässigkeit und Korrektheit durch das Auftreten von Fehlern beeinflusst werden. Dabei können Fehler wie z.B. zufällige Hardwarefehler oder systematische Designfehler auftreten. Als ein Beispiel für einen zufälligen Hardwarefehler könnte ein eventueller Defekt einer Recheneinheit genannt werden. Daraus ergibt sich eine Fehlfunktion, die das Handhaben einer Vorrichtung (z.B. eines Fahrzeugs), in der die Recheneinheit eingesetzt ist, beeinträchtigt. Mögliche Designfehler können bereits während der Entwicklungsphase beispielsweise durch falsches Umsetzen der Spezifikation (z.B. Modellierung oder Planung) entstehen. Solche und ähnliche Fehler können in sicherheitsrelevanten Systemen gravierende Folgen haben.

Betrachtet man als Beispiel den Bereich der Fahrzeuge (z.B. Bahn oder Flugzeuge) , können solche Fehler beispielsweise die Unbeherrschbarkeit eines Systems oder einer Vorrichtung (z.B. eines Fahrzeugs) mit den damit einhergehenden gravierenden Folgen für die Fahrgäste zur Folge haben. Ebenfalls ist auch eine nachhaltige Beeinträchtigung der Umwelt nicht auszuschließen .

Zur Sicherstellung einer funktionalen Sicherheit wird allgemein für jede spezifizierte Sicherheitsfunktion zumindest ei- ne Sicherheitsanforderung spezifiziert, um eine vorgegebene Sicherheitsstufe zu erreichen und/oder zu erfüllen. Eine funktionale Sicherheit wird dann als gegeben gesehen, wenn jede spezifizierte Sicherheitsfunktion ausgeführt wird und für jede Sicherheitsfunktion ein geforderter Erfüllungsgrad gemäß der entsprechenden Sicherheitsanforderungsstufe erreicht wird. Dabei ist zu beachten, dass eine Sicherheitsan- forderungsstufe (SAS oder Safety Integrity Level (SIL) ) eine Eigenschaft einer Sicherheitsfunktion ist und sich nicht auf ein System oder Teilsystem bezieht. Die Realisierung dieser Sicherheitsfunktion erfolgt aber durch eine Kombination von Systemen, welche aus Hardware- und Softwareteilen bestehen. Somit bezieht sich die Sicherheitsanforderungsstufe auf eine durchgehende Sicherheitsfunktion eines sicherheitsbezogenen Systems.

Wie jede andere Komponente des sicherheitsgerichteten Systems verfügt eine Softwarekomponente über keinen Safety Integrity Level (SIL), wenn sie isoliert von einem sicherheitsbezogenen System betrachtet wird. Wird die Softwarekomponente in ein

System integriert, so kann die Softwarekomponente zur Unterstützung von Sicherheitsfunktionen zu einem bestimmten SIL geeignet sein. Dies ist davon abhängig, wie die Softwarekomponente spezifiziert, entwickelt, implementiert und/oder ve- rifiziert wurde.

Die Software-Sicherheitsanforderungsstufe n bzw. SSAS n ist wie folgt spezifiziert: Software, die unter Verwendung angemessener Techniken und Maßnahmen entwickelt wurde, wobei die Techniken und Maßnahmen sicherstellen, dass die Software die Anforderungen an systematische Ausfälle einer bestimmten Sicherheitsfunktion X für SSAS n erfüllt.

Somit ist eine Software-Sicherheitsanforderungsstufe keine Eigenschaft von Systemen, Teilsystemen oder Komponenten. Die obige Spezifikation kann dahingehend interpretiert werden, dass das Softwaresystem, Softwareteilsystem oder die Soft- warekomponente in Sicherheitsfunktionen bis zum SSAS 1,2,3 oder 4 eingesetzt werden kann. Dies allein reicht aber nicht aus, um eine Sicherheitsfunktion für die geforderten SSAS aufzubauen. Die Software-Sicherheitsanforderungsstufe eines Teilsystems bestimmt den höchsten SSAS, der für eine Sicherheitsfunktion unter Verwendung dieses Teilsystems geltend gemacht werden kann. Die Befähigung bzw. Einsetzbarkeit eines Teilsystems für SSASn (mit n=l, 2, 3oder 4) wird erreicht, wenn das SW-Teilsystem Anforderungen vorbestimmter Safety- Normen (z.B. IEC 61508, EN50128 usw.) erfüllt.

Des Weiteren ist auch die Produkthaftung ein wichtiger Aspekt, wenn es um sicherheitsrelevante bzw. sicherheitsgerich- tete Systeme geht. Ist ein (gekauftes) Produkt fehlerhaft, so können unter Umständen auch Schadensersatzforderungen entstehen. Der Hersteller kann sich von der Verantwortung für den Schaden dann zurückziehen, wenn der Fehler beim Bringen des Produktes im Verkehr nicht vorhanden war oder wenn das Produkt vorgegebenen Sicherheitserwartungen und vorgegebenen Rechtsvorschriften entsprach.

Derzeit existiert in dem europäischen Rechtssystem keine gesetzliche Norm, die zwingende Anforderungen an elektronische Systeme in Bezug auf Überprüfung ihrer Fehlersicherheit bzw. funktionaler Sicherheit stellt. Dadurch, dass aber der Sektor der Elektronik immer größer wird und die Sicherheit demzufolge auch mehr an Bedeutung gewinnt, wurde eine Alternative erstellt, die die hier meist geforderte Sicherheit der Produkte gewährleistet. Demnach genügt es, wenn ein Nachweis und dem- entsprechend eine Begutachtung einer Ausfallsicherheit von elektronischen Systemen durch die zuständige Behörde (z.B. TÜV oder Eisenbahnbundesamt) und den technischen Dienst des Herstellers vorliegt. Die Begutachtung erfolgt dabei auf Basis vorgegebener Regeln oder Normen (z.B. IEC 61508, EN50128 usw. ) . Sicherheitsrelevanten oder sicherheitsgerichteten Systemen, die Softwarekomponenten aufweisen, werden durch die vorgegebenen Regeln oder Normen Sicherheitsanforderungen aufgestellt, die beschreiben, wie ein sicheres Verhalten des Sys- tems gewährleistet und das Auftreten von Gefahrensituationen verhindert werden kann.

Die Sicherheitsrelevanz technischer Systeme leitet sich aus der maximalen Sicherheitsanforderung an die durch diese Sys- teme zur Verfügung gestellten Funktionen ab. Betrachtet man den Einsatz von Software in sicherheitsgerichteten Systemen, so wird in der Regel nur ein kleiner Teil von Sicherheitsfunktionen durch die Software übernommen. D.h., die verwendeten Softwarekomponenten sind einerseits in sicherheitsrele- vante oder sicherheitskritische Softwarekomponenten und andererseits in nicht-sicherheitsrelevante oder sicherheitsunkritische Softwarekomponenten zu unterteilen. Da die Möglichkeit besteht, dass die sicherheitsunkritischen Softwarekomponenten die sicherheitskritischen Softwarekomponenten stören können, d.h. sich gegenseitig beeinflussen können, werden diese ebenso sicher wie die sicherheitskritischen Softwarekomponenten entwickelt .

Dabei darf die Ausführung einer nicht-sicherheitskritischen bzw. sicherheitsunkritischen Softwarekomponente oder Softwarefunktion die zuverlässige und korrekte Ausführung einer sicherheitskritischen Softwarekomponente oder Softwarefunktion nicht negativ beeinflussen. Diese Beeinflussung tritt als sogenannte Rückwirkung auf. Diese Rückwirkung kann durch eine konsequente Trennung zwischen den Funktionsklassen (sicherheitskritisch, nicht-sicherheitskritisch bzw. sicherheitsunkritisch, etc.) auf einem System unterbunden werden. Diese Trennung wird als Rückwirkungsfreiheit von nicht- sicherheitskritischen bzw. sicherheitsunkritischen Software- komponenten oder Funktionen auf sicherheitskritische Softwarekomponenten oder Funktionen verstanden. Das Implementieren der nicht-sicherheitskritischen bzw. sicherheitsunkritischen Softwarekomponenten oder Funktionen mit dem gleichen Sicherheitsmaß wie dem der sicherheitskritischen Softwarekomponenten oder Funktionen führt aber zu Einschrän- kungen bei den sicherheitsunkritischen Softwarekomponenten (z.B. hinsichtlich deren Funktionalität oder Codierrichtlinien) und zu hohen Aufwänden hinsichtlich der Entwicklung der einzusetzenden sicherheitsunkritischen Softwarekomponenten.

Weitere bekannte Vorgehensweisen gehen wiederum den Weg der Trennung der sicherheitskritischen und der sicherheitsunkritischen Softwarekomponenten durch Einrichten von Hardwarekomponenten, die entweder sicherheitskritische oder sicherheitsunkritischen Softwarekomponenten aufweisen. Auf diese Weise wird eine physikalische Trennung der Komponenten erreicht. Da diese dennoch zusammenwirken, müssen entsprechende sichere Schnittstellen eingerichtet werden. Sowohl die Ausgestaltung der Hardwarekomponenten als auch die Ausgestaltung der jeweiligen Schnittstellen haben einen hohen Aufwand mit zufolge.

Durch die oben genannte, bekannte Art der Einsetzung von Softwarekomponenten in sicherheitsgerichteten Systemen ist eine Gebundenheit der implementierten Software an den jeweiligen Anwendungsbereich gegeben. Möchte man eine implemen- tierte Software anderweitig einsetzen, um Entwicklungskosten zu sparen, ist es in der Regel nur mit einem großen Umstellungsaufwand möglich, wobei die Sicherheitsfragen erneut zu stellen und zu prüfen sind.

Der Erfindung liegt die Aufgabe zugrunde ein verbessertes Unterstützen eines sicherheitsgerichteten Systems, das sicherheitskritische Softwarekomponenten und sicherheitsunkritische Softwarekomponenten aufweist. Dabei umfasst das Unterstützen des sicherheitsgerichteten Systems insbesondere den Nachweis und/oder das Sicherstellen der Rückwirkungsfreiheit. D.h., das Unterbinden einer gegenseitigen Beeinflussung einer sicherheitskritischen Softwarekomponente und einer Sicherheit- sunkritische Softwarekomponente und den Nachweis dafür, dass eine solche gegenseitige Beeinflussung ausgeschlossen oder zumindest bis zum bestimmten möglichen Maximum ausgeschlossen ist .

Die Aufgabe wird gelöst durch ein Verfahren mit Merkmalen des Anspruchs 1, durch eine Vorrichtung mit Merkmalen des Anspruchs 10, durch ein System mit Merkmalen des Anspruchs 11, durch ein Computerprogramm mit Merkmalen des Anspruchs 12, durch einen Datenträger mit Merkmalen des Anspruchs 14 und/oder durch ein sicherheitsgerichtetes System mit Merkmalen des Anspruchs 15.

Die vorstehend genannte Aufgabe wird durch ein Verfahren zum Unterstützen eines sicherheitsgerichteten Systems gelöst, wobei das sicherheitsgerichtete System sicherheitskritische Softwarekomponenten und sicherheitsunkritische Softwarekomponenten aufweist und wobei das Verfahren aufweist: Identifizieren einer Möglichkeit einer gegenseitigen Beein- flussung einer sicherheitskritischen Softwarekomponente und einer sicherheitsunkritische Softwarekomponente; und Definieren einer Menge technischer Maßnahmen zum Verhindern der Möglichkeit der Beeinflussung.

Die vorliegende Erfindung ermöglicht eine Anwendung formaler Methoden und Techniken in der Software- und Systementwicklung, wodurch die Korrektheit eines Softwareentwurfs, eines Analyse- oder Entwurfsmodells gegenüber funktionalen Sicherheitsanforderungen gezeigt werden kann. Ferner wird dadurch möglich, höchste Sicherheitsansprüche an ein sicherheitsrelevantes bzw. sicherheitsgerichtetes System zu stellen und zu gewährleisten .

Gemäß der vorliegenden Erfindung kann im Rahmen des Identifi- zierens einer Möglichkeit einer gegenseitigen Beeinflussung einer sicherheitskritischen Softwarekomponente und einer si- cherheitsunkritische Softwarekomponente und/oder das Definieren einer Menge technischer Maßnahmen zum Verhindern der Möglichkeit der Beeinflussung unter Verwendung formaler Methoden und Techniken implementiert werden.

Gemäß einem Ausführungsbeispiel der vorliegenden Erfindung weist das Identifizieren ein Ermitteln einer Schnittmenge systemtechnischer Ressourcen eines Wirkungsbereichs der sicherheitskritischen Softwarekomponente und eines Wirkungsbe- reichs der sicherheitsunkritischen Softwarekomponente auf.

Auf diese Weise wird ein allgemein und somit wiedereinsetzbar gehaltenes Identifizieren von Möglichkeiten einer gegenseitigen Beeinflussung bzw. Sicherstellen einer Rückwirkungsfreiheit gestattet, welches zugleich auch gezielt eingesetzt wird.

Gemäß einem Ausführungsbeispiel der vorliegenden Erfindung weist das Identifizieren ein Bewerten zumindest einer systemtechnischen Ressource aus der Schnittmenge systemtechnischer Ressourcen hinsichtlich der Möglichkeit der gegenseitigen Beeinflussung auf. Damit kann eine mögliche von der ermittelten systemtechnischen Ressource (z.B. Hauptspeicher, Dateisystem, Software-Ressource, Kommunikationsmechanismus oder Kommunikationsmittel) genauer untersucht werden und hinsichtlich der Sicherheitstechnischen Relevanz entsprechend markiert werden.

Gemäß einem Ausführungsbeispiel der vorliegenden Erfindung kann das Definieren der Menge technischer Maßnahmen durch Analyse der Möglichkeit der gegenseitigen Beeinflussung aus- geführt werden.

Dabei kann das Definieren der Menge technischer Maßnahmen basierend auf der Bewertung der zumindest einen systemtechnischen Ressource durchgeführt werden.

Das Definieren der Menge technischer Maßnahmen kann gemäß der vorliegenden Erfindung verschiedene Arten technischer Maßnah- men aufweisen, was eine flexible Umsetzung der vorliegenden Erfindung ermöglicht. Dabei ist auch eine Mischform oder ein Kombinieren der verschiedenen Arten technischer Maßnahmen möglich.

Gemäß einem Ausführungsbeispiel der vorliegenden Erfindung kann das Definieren der Menge technischer Maßnahmen ein Bestimmen einer Konfigurationsmaßnahme aufweisen.

Ferner kann das Definieren der Menge technischer Maßnahmen eine softwaretechnische Analyse der sicherheitskritischen Softwarekomponente hinsichtlich der Möglichkeit der gegenseitigen Beeinflussung aufweisen.

Des Weiteren kann das Definieren der Menge technischer Maßnahmen ein Bestimmen einer Applikation zum Verhindern der Möglichkeit der gegenseitigen Beeinflussung aufweisen.

Zusätzlich kann zumindest eine sicherheitsunkritische Soft- warekomponente der Menge sicherheitsunkritischen Softwarekomponenten des sicherheitsgerichteten Systems eine Open Source Softwarekomponente sein. D.h., als die sicherheitsunkritischen Softwarekomponente, für die die Möglichkeit einer gegenseitigen Beeinflussung identifiziert wird und im Hinblick auf die eine Menge technischer Maßnahmen definiert wird, kann eine Open Source Softwarekomponente verwendet werden.

Der Einsatz von Publik Domain oder Open Source Software in sicherheitsgerichteten Systemen ist bislang gemieden worden, da die Publik Domain oder Open Source Software nicht nachweislich für sicherheitsgerichtete Anwendungen geeignet ist.

Aus wirtschaftlichen Gründen sind Unternehmen heutzutage oft gezwungen Software-Komponenten in einem System nicht selbst zu entwickeln, sondern auf Wiederverwendung vorhandener Komponenten zu setzen. Oft enthält der Softwarepool eines Unternehmens nicht genügend Softwareteile, um alle Bedürfnisse nach spezifischen Software-Komponenten in den jeweiligen, auf sicherheitsgerichtete Systeme ausgerichteten Projekten zu erfüllen .

Dabei können beispielsweise Softwarekomponenten, die hinzugekauft (sog. COTS, Commercial of the-shelf) oder aus dem unerschöpflichen Pool der Open Source Software bezogen werden können, eine Abhilfe bieten. Bei dem Einsatz von COTS (Commercial of the-shelf) oder Open Source Software in Sicher- heitssystemen müssen aber die Vorgaben der Sicherheitsnormen eingehalten werden. Wie bereits erwähnt, ist dieses bislang nicht gegeben.

Die vorliegende Erfindung bietet eine formalen Vorgehensweise zum Nachweisen und Sicherstellen von vorgegebenen sicherheitsrelevanten Normen. Dabei wird ein Nachweis der Rückwirkungsfreiheit beim Einsatz der jeweiligen (sicherheitsunkritischen) Komponenten im entsprechenden Projekt erbracht. Insbesondere wird der Nachweis für sicherheitsunkritische Soft- warekomponenten, die COTS oder Open Source Softwarekomponenten aufweisen können, gewährleistet. Dabei wird der Nachweis der Rückwirkungsfreiheit entsprechend der bestehenden Sicherheitsnormen nach formalen Methoden und Techniken erbracht. Gemäß der vorliegende Erfindung kann durch konstruktive, ana- lytische und/oder applikative Maßnahmen verhindert werden, dass Bedrohungen, welche durch Einsatz die Ausführung der sicherheitskritischen Funktionen im System negativ beeinflussen .

Die oben genannte Aufgabe wird mittels einer Vorrichtung gelöst, die zum Unterstützen eines sicherheitsgerichteten Systems ausgestaltet ist, wobei das sicherheitsgerichtete System sicherheitskritische Softwarekomponenten und sicherheitsunkritische Softwarekomponenten aufweist, und wobei die Vor- richtung konfiguriert ist:

- eine Möglichkeit einer gegenseitigen Beeinflussung einer sicherheitskritischen Softwarekomponente und einer si- cherheitsunkritische Softwarekomponente zu identifizieren; und

- eine Menge technischer Maßnahmen zum Verhindern der Möglichkeit der Beeinflussung zu definieren.

Insgesamt ist die Vorrichtung konfiguriert, die Schritte des oben skizzierten und nachstehend detaillierter erläuterten Verfahrens durchzuführen.

Die oben genannte Aufgabe wird auch mittels eines Systems gelöst, das ausgestaltet ist, Schritte des oben skizzierten und nachstehend detaillierter erläuterten Verfahrens auszuführen.

Ferner wird die oben genannte Aufgabe mittels eines Computer- programms durchgeführt, wobei das Computerprogramm eine Kodierung aufweist, die konfiguriert ist, Schritte des oben skizzierten und nachstehend detaillierter erläuterten Verfahrens auszuführen. Dabei kann das Computerprogramm auf einem Datenträger gespeichert sein.

Zusätzlich wird die oben genannte Aufgabe mittels eines Datenträgers gelöst, der das vorstehend genannte Computerprogramm aufweist.

Außerdem wird die oben genannte Aufgabe mittels eines sicher- heitsgerichteten Systems gelöst, das sicherheitskritische Softwarekomponenten und sicherheitsunkritische Softwarekomponenten aufweist und das konfiguriert ist, eine Rückwirkungsfreiheit auf die sicherheitskritischen Softwarekomponenten durch Ausführen der Schritte des oben skizzierten und nachstehend detaillierter erläuterten Verfahrens sicherzustellen. Wie bereits erläutert, kann dabei zumindest eine Open Source Softwarekomponente oder COTS als zumindest eine sicherheitsunkritische Softwarekomponente ausgestaltet sein,

Im Folgenden wird die Erfindung detailliert mit Bezug auf die schematischen Zeichnung näher beschrieben, in denen: Fig. 1 mögliche Interaktionen zwischen Softwarekomponenten eines sicherheitsgerichteten Systems gemäß einem Ausführungsbeispiel der vorliegenden Erfindung zeigt;

Fig. 2 eine Schnittstelle einer sicherheitskritischen

Softwarekomponente und einer sicherheitsunkritischen Softwarekomponente gemäß einem Ausführungs- beispiel der vorliegenden Erfindung zeigt;

Fig. 3 eine gemäß einem Ausführungsbeispiel der vorliegenden Erfindung umgesetzte bzw. ausgestaltete Rückwirkungsbarriere zeigt; und

Fig. 4 ein Blockdiagramm einer Analyse eines Source-Codes als applikative Maßnahme gemäß einem Ausführungsbeispiel der vorliegenden Erfindung zeigt.

Die Fig. 1 zeigt mögliche Interaktionen zwischen Softwarekomponenten eines sicherheitsgerichteten Systems gemäß einem Ausführungsbeispiel der vorliegenden Erfindung.

Im Nachfolgenden wird der Nachweis und die Sicherstellung der Rückwirkungsfreiheit beim Einsatz einer Open Source SW- Komponente, nämlich der SQLite Embedded-Datenbank als Meldungsarchiv, der Norm EN50128 mit formalen Methoden und Techniken gemäß einem Ausführungsbeispiel der vorliegenden Erfindung beschrieben. Dabei ist das Meldungsarchiv an der Ausfüh- rung nicht-sicherheitskritischer bzw. sicherheitsunkritischer Funktionen beteiligt. Diese können eine bedrohende Rückwirkung auf die korrekte und zuverlässige Ausführung von sicherheitskritischen Funktionen im sicherheitsgerichteten System haben. Durch konstruktive, analytische und applikative Maß- nahmen wird verhindert, dass diese Bedrohungen (entstanden durch gegenseitige Beeinflussungen der sicherheitskritischen und sicherheitsunkritischen Softwarekomponenten) die Ausfüh- rung der sicherheitskritischen Funktionen im System negativ beeinflussen .

Es versteht sich von selbst, dass die oben genannte Open Source Softwarekomponente als sicherheitsunkritische Softwarekomponente und die oben genannte Norm EN50128 lediglich zur Darstellung eines konkreten Beispiels dienen. Die vorliegende Erfindung findet keine Einschränkung hinsichtlich der verwendeten Softwarekomponenten und hinsichtlich der einzu- haltenden Sicherheitsnormen. Ebenfalls ist die vorliegende Erfindung auf kein Anwendungsgebiet beschränkt und ist in verschiedenen möglichen sicherheitsgerichteten Systemen anwendbar und umsetzbar.

Gemäß dem vorliegenden Ausführungsbeispiel werden die Softwarekomponenten 101, 111, 12, 13 und 14 in drei Funktionsklassen aufgeteilt:

Softwarekomponente beteiligt an der Ausführung von sicherheitskritischen Funktionen (SSAS > 0) ; Softwarekomponente führt unter anderem eine Überwachung von sicherheitskritischen Funktionen aus (SASS > 0); und Softwarekomponente ist an der Ausführung von nicht- sicherheitskritischen Funktionen beteiligt (SSAS = 0) .

Bei sicherheitskritische (sicherheitsrelevante) Softwarekomponenten 12, 13 wird die Realisierung einer sicherheitskritischen bzw. sicherheitsrelevanten Funktion in der Regel softwaretechnisch durch Kollaboration, d.h.. Zusammenarbeit von Softwarekomponenten in einem System realisiert. Dies ge- schieht unabhängig davon, ob die Sicherheitsfunktion kontinuierlich (contineouse mode) oder auf Anforderung (on de-mand mode) abläuft. Die kollaborierenden Komponenten gehören somit dem Sicherheitskreis an aus dem die Software- Sicherheitsanforderungsstufe (SSAS) resultiert. Alle Soft- warekomponenten 12, 14, die an der Ausführung einer sicherheitskritischen Funktionalität beteiligt sind, gehören zur Funktionsklasse der sicherheitskritischen Softwarekomponenten mit einer entsprechenden SSAS-Stufe.

Überwachende Softwarekomponenten 13 repräsentieren Selbst- test- und Überwachungs-/Diagnose-Softwarekomponenten . Diese haben die Aufgabe, Systemressourcen auf zufällige Hardwarefehler zu überprüfen. Solche Softwarekomponenten können beispielsweise auf einem Systemserver ein Monitoradapter in Zusammenarbeit mit einem SEP (Safety Environment Prozessor) sein. Dabei würde der SEP die sicherheitskritische Softwarekomponente und der Monitoradapter die nicht- sicherheitskritische bzw. sicherheitsunkritische Softwarekomponente sein. Alle Softwarekomponenten 13, die an einer Überwachung und Diagnose von Hardware beteiligt sind, gehören zur Funktionsklasse der überwachenden Softwarekomponenten. Auf diese darf ebenfalls keine Beeinflussung von anderen Softwarekomponenten erfolgen.

Als nicht-sicherheitskritische bzw. sicherheitsunkritische Softwarekomponenten 101, 111 werden solche Softwarekomponenten betrachtet, die an nicht-sicherheitskritischen bzw. sicherheitsunkritischen Funktionalitäten beteiligt sind. Diese Softwarekomponenten gehören sozusagen der SSAS 0 an. Zu dieser Klasse gehört gemäß dem vorliegenden Ausführungsbeispiel das Meldungsarchiv an.

In Fig. 1 sind die Beziehungen zwischen den Softwarekomponenten 101, 111, 12, 13, 14 durch Pfeile dargestellt. Dabei deuten die gepunkteten Pfeile, die von der überwachenden Soft- warekomponente 13 ausgehen, auf die Softwarekomponenten 12,

14, 101, 111, welche von der der überwachenden Softwarekomponente 13 überwacht werden. Die durchgehenden Pfeile zeigen auf, dass eine Kollaboration bzw. Zusammenarbeit zwischen den jeweiligen Softwarekomponenten 12 und 101, 12 und 14 statt- findet. Die gestrichelten Pfeile, die von der nicht- sicherheitskritischen bzw. sicherheitsunkritischen Softwarekomponente 101 zu den Softwarekomponenten 12, 13, 14 und 111 führen, deuten diejenigen Komponenten an, auf die die nicht- sicherheitskritische bzw. sicherheitsunkritische Softwarekomponente 101 (hier beispielhaft eine SQLite Embedded-Datenbank als Meldearchiv) eine Rückwirkung hat. D.h. zwischen der si- cherheitsunkritische Softwarekomponente 101 und den sicherheitskritischen Softwarekomponenten 12, 13 und 14 ist eine gegenseitigen Beeinflussung gegeben. Dabei umfasst eine gegenseitige Beeinflussung gemäß der vorliegenden Erfindung sowohl Beeinflussungen in beide Richtungen (Beeinflussung einer sicherheitsunkritischen Softwarekomponente 101 durch eine sicherheitskritische Softwarekomponente 12, 13 und 14 und Beeinflussung einer sicherheitskritische Softwarekomponente 12, 13 und 14 durch eine sicherheitsunkritische Softwarekomponente 101) als auch Beeinflussungen in nur eine Richtung (d.h., Beeinflussung einer sicherheitsunkritischen Softwarekomponente 101 durch eine sicherheitskritische Softwarekomponente 12,

13 und 14 oder Beeinflussung einer sicherheitskritische Softwarekomponente 12, 13 und 14 durch eine sicherheitsunkritische Softwarekomponente 101) .

Ferner ist anzumerken, dass in Fig. 1 die sicherheitsunkritischen Komponenten 101 und 111 jeweils eine Schnittstelle 10, 11 aufweisen, um mit den sicherheitskritischen Softwarekomponenten 12, 13, 14 zu interagieren, zu kommunizieren und/oder zusammenzuarbeiten. Diese Schnittstellen 10, 11 sind aber nicht zwingend notwendig, die vorliegende Erfindung ist auch ohne Einsatz solcher Schnittstellen 10, 11 umsetzbar und durchführbar .

Jede Softwarekomponente 101, 111, 12, 13, 14 hat in einem

System einen Wirkungsbereich. Ein Wirkungsbereich ist ein Bereich des sicherheitsgerichteten Systems, in dem oder im Rahmen dessen die jeweilige Softwarekomponente 101, 111, 12, 13,

14 wirkt, d.h., arbeitet, kommuniziert, interagiert und/oder mit anderen Komponenten des Systems zusammenarbeitet oder wirkt. Da ein sicherheitsbezogenes bzw. sicherheitsgerichte- tes System aus mehreren Softwarekomponenten 101, 111, 12, 13, 14 mit jeweils einem eigenen Wirkungsbereich besteht, ist die Gefahr der gegenseitigen Beeinflussung dieser Komponenten während der Ausführung einer Funktion potentiell gegeben. Die Beeinflussung tritt dabei über die Schnittstellen der Wir- kungsbereiche der Softwarekomponenten 101, 111, 12, 13, 14 auf. Es besteht damit die Gefahr der Rückwirkung bei der Ausführung einer Funktion auf das Ausführungsverhalten einer Sicherheitsfunktion, so dass die Korrektheit und Zuverlässigkeit dieses Sicherheitskreises nicht mehr gemäß der dazugehö- rigen Sicherheitsanforderungsstufe garantiert werden kann.

Um dem entgegenzuwirken, werden alle möglichen Rückwirkungen von einer nicht-sicherheitsrelevanten bzw. sicherheitsunkritischen Softwarekomponente auf eine sicherheitsrelevante bzw. sicherheitskritische Softwarekomponente untersucht. Dabei läuft die Beurteilung über die Schnittstellen der nicht- sicherheitskritischen Softwarekomponenten. Hier muss im Rückwirkungskontext der softwaretechnische Begriff der Schnittstelle erweitert werden. Als Schnittstelle wird nicht nur die direkte Kommunikation bzw. Kollaboration oder Zusammenarbeit zwischen Softwarekomponenten verstanden, sondern die gemeinsame Schnittmenge aller gegenseitigen Beeinflussungen, die über die Wirkungsbereiche der Softwarekomponenten 101, 111, 12, 13, 14 auftreten können. Im Fokus von sicherheitsbezoge- nen Systemen ist gemäß dem vorliegenden Ausführungsbeispiel die gerichtete Beeinflussung einer sicherheitskritischer Softwarekomponente 12, 13, 14 durch eine nicht- sicherheitskritische bzw. sicherheitsunkritische Softwarekomponente 101, 111 über die gemeinsame Schnittstelle.

In einem Software-System bilden diese Schnittstelle die gemeinsam genutzten Ressourcen des Betriebssystems bzw. des darüber liegenden Frameworks, welche den Ablaufrahmen der SW- Komponenten zur Verfügung stellen. Dabei erfolgt die Rückwir- kung zwischen den Softwarekomponenten 101, 111, 12, 13, 14 beispielsweise über den Hauptspeicher, das Dateisystem, Ker- nel-Ressourcen oder über die Kommunikationsmechanismen innerhalb eines Rechners oder auch rechnerübergreifend.

Fig. 2 zeigt beispielhaft eine Schnittstelle 22 (d.h., einer Schnittmenge systemtechnischer Ressourcen) der Wirkungsbereiche 21 und 20 einer sicherheitskritischen Softwarekomponente 211 und einer sicherheitsunkritischen Softwarekomponente 210 (z.B. einer SQLite Embedded-Datenbank als Meldearchiv) .

Gemäß dem Ausführungsbeispiel der vorliegenden Erfindung wird eine Art Barriere aufgebaut, um gewisse Beeinflussungen zwischen sicherheitskritischen und sicherheitsunkritischen Softwarekomponenten des sicherheitsgerichteten Systems zu unterbinden oder zu vermeiden und um damit eine Rückwirkung zu verhindern. Die sogenannte Barriere oder Schale ist ausgestaltet, die die verschiedenen Bedrohungen, welche von den jeweiligen Softwarekomponenten ausgehen, abzufangen und ggf. zu beseitigen. Dadurch können die notwendigen Maßnahmen vom sicherheitsgerichteten System ergriffen werden, um die Rückwir- kung abzufangen. So kann bei Eintritt eines störenden Ereignisses, durch das beispielsweise kein Hauptspeicher mehr zur Verfügung steht, die Ausführung einer von diesem Ereignis betroffenen nicht-sicherheitskritischen bzw. sicherheitsunkritischen Funktion durch das System (Betriebssystem bzw. Frame- work) beendet werden. Bei einem Eintritt eines anderen Ereignisses, durch das beispielsweise kein sekundärer Speicher zur Verfügung steht, kann gemäß der vorliegenden Erfindung das Ereignis abgefangen bzw. identifiziert werden und der Ausfüh- rungsprozess des Meldungsarchivs beendet werden, um Betriebs- Sicherheit des sicherheitsgerichteten Systems zu gewährleisten .

Fig. 3 zeigt eine gemäß dem Ausführungsbeispiel der vorliegenden Erfindung umgesetzte bzw. ausgestaltete Rückwirkungs- barriere. Die Komponenten der Fig. 3 entsprechen den Komponenten der Fig. 1. Auch die Beziehungen der Überwachung und der Kollaboration, die als gepunktete oder durchgezogene Pfeile gezeigt sind, sind zwischen den Softwarekomponenten wie ursprünglich gegeben bzw. ausgestaltet erhalten. Die erfindungsgemäß eingesetzte Rückwirkungsbarriere oder - Schale 30 bewirkt, dass die Rückwirkung der nicht-sicherheitskritischen bzw. sicherheitsunkritischen Softwarekomponente 101 auf die sicherheitskritischen Softwarekomponenten 12, 13 und 14 eingefangen wird, d.h., dass eine Rückwirkungsfreiheit gewährleistet wird. Das Einfangen der Rückwirkung ist durch das Eingrenzen der Rückwirkungsbeziehungen, die als gestrichelte Pfeile dargestellt sind, durch die Rückwirkungsbarriere 30 dargestellt. D.h., die nicht-sicherheitskritische bzw. sicherheitsunkriti- sehe Softwarekomponente 101 wird durch Etablierung einer Ablaufschale als Rückwirkungsbarriere 30 isoliert.

Dieses geschieht durch Definieren, Bestimmen und/oder Erfassen von Maßnahmen zur Vermeidung von Rückwirkung zwischen Softwarekomponenten in einem sicherheitsgerichteten Softwaresystem. Die Maßnahmen können dabei in konstruktive, applika- tive und analytische Maßnahmen unterschieden werden.

Konstruktive Maßnahmen sind eine Art präventive Maßnahmen, die bereits bei der Konfiguration berücksichtigt werden können, so dass keine Rückwirkung auf andere Softwarekomponenten 12, 13, 14, 111 durch eine sicherheitsunkritische Softwarekomponente 101 in einem sicherheitsgerichteten System entstehen kann. Dabei können bewährte Betriebssystemmechanismen zur Etablierung einer eigenen „Ablaufschale" der nicht- sicherheitskritischen bzw. sicherheitsunkritischen Softwarekomponente verwendet werden. Demnach kann eine Ablaufschale 30 beispielsweise durch entsprechendes Definieren bzw. Ausgestalten von Benutzerrechten, Dateisystem Partitionen etc. konfiguriert oder implementiert werden. Analytische oder verifizierende Maßnahmen haben die Prüfung, Bewertung und den (externen) Nachweis der Rückwirkungsfreiheit der Prüfgegenstände zum Ziel. Dieses kann beispielsweise durch eine gezielte Überprüfung des Softwarecodes durchge- führt werden, wobei eine Reihe an Softwareprüfungswerkzeugen und -Verfahren zu diesem Zweck verwendet werden kann.

Durch applikative Maßnahmen wird eine Verhinderung der Rückwirkung auf andere Softwarekomponenten im System durch pro- grammiertechnische Schritte umgesetzt werden (z.B. durch Betriebssystem-API Aufrufe zur Begrenzung des Hauptspeichers) . Dabei können standardisierte, auf die jeweilige Problemstellung ausgerichtete Softwarewerkzeuge eingesetzt werden, welche beispielsweise basierend auf Erfahrungen von Experten aufgebaut sind.

Wie bereits erwähnt, wird gemäß dem vorliegenden Ausführungsbeispiel eine SQLite Embedded-Datenbank in Form eines Meldungsarchivs als die nicht-sicherheitskritische bzw. si- cherheitsunkritische Softwarekomponente eingesetzt. Im Nachfolgenden werden Beispiele von identifizierten Möglichkeiten bzw. Schnittstellen (d.h. Schnittmenge systemtechnischer Ressourcen) einer gegenseitigen Beeinflussung einer sicherheitskritischen Softwarekomponente und der SQLite Embedded- Datenbank in Form eines Meldungsarchivs erläutert. Im Hinblick auf eine systemtechnischer Ressource wird eine Menge technischer Maßnahmen zum Verhindern der Möglichkeit der Beeinflussung und somit der Rückwirkung definiert.

Während einer Analyse oder während eines Identifizierens der Möglichkeiten einer gegenseitigen Beeinflussung wurden folgende Feststellungen oder Ergebnisse erzielt:

- Archiv wird von potenziell sicherheitskritischen Prozessen (z.B. Anlagenabbild) verwendet; - Archiv hat selbst keine sicherheitskritische Funktion;

- Rückwirkungsfreiheit der Komponente Archiv auf diese anderen Prozesse muss sichergestellt werden. Dabei sind gegenseitige Beeinflussungen oder Rückwirkungen über oder durch folgende systemtechnische Ressourcen möglich: Hauptspeicher, Flash-Speicher, CPU-Belastung, Globale Res- sourcen (Futex, Datei-Locks, Datei-Handies, Tasks) , Kommunikation (TCP/IP) .

Betrachtet man nun die Möglichkeit der Beeinflussung oder Rückwirkung durch die systemtechnische Ressource Hauptspei- eher, so ergibt eine Bewertung hinsichtlich des Hauptspeichers, dass eine mögliche Bedrohung für das sicherheitsge- richtete System in einem übermäßigen Verbrauch des Hauptspeichers durch die SQLite-Datenbank als Archiv 101 liegen kann, so dass andere Prozesse bzw. Softwarekomponenten 12, 13, 14, 111 behindert werden können. Archiv wird von potenziell sicherheitskritischen Prozessen (z.B. Anlagenabbild) verwendet und hat selbst keine sicherheitskritische Funktion. Um die Rückwirkungsfreiheit der Komponente Archiv 101 auf die anderen Prozesse sicherzustellen, kann beispielsweise eine kon- struktive Maßnahme wie Setzen eines definierten harten System-Limits für die Nutzung von Hauptspeicher definiert werden .

Ferner kann eine Bewertung hinsichtlich des Hauptspeichers ergeben, dass eine mögliche Bedrohung für das sicherheitsge- richtete System im Überschreiben von Dateien durch andere Prozesse oder Softwarekomponenten 12, 13, 14, 111 geschehen kann. Hier kann eine konstruktive Maßnahme wie das Realisieren der SQLite-Datenbank als eigenständiger Container im Sys- temframework definiert werden. Die SQLite-Datenbank als Archiv wird damit zu einem eigenen Betriebssystemprozess . Eine Beeinflussung von anderen Prozessen bzw. Softwarekomponenten 12, 13, 14, 111 durch die SQLite-Datenbank über den Hauptspeicher ist somit nicht möglich.

Betrachtet man nun die Möglichkeit der Beeinflussung oder Rückwirkung durch die systemtechnische Ressource Flashspei- eher, so ergibt eine Bewertung hinsichtlich des Flashspeichers, dass eine mögliche Bedrohung für das sicherheitsge- richtete System in einem übermäßigen Verbrauch des Flashspeichers durch die SQLite-Datenbank als Archiv 101 liegen kann, so dass andere Prozesse bzw. Softwarekomponenten 12, 13, 14, 111 behindert werden können. Um die Rückwirkungsfreiheit der Komponente SQLite-Datenbank als Archiv 101 auf die anderen Prozesse bzw. Softwarekomponenten sicherzustellen, kann beispielsweise eine konstruktive Maßnahme wie eine Ablage der SQLite-Datenbank-Dateien auf einer eigenen Partition im Dateisystem; ein Anwachsen der SQLite-Datenbank-Dateien über diese Größe hinaus ist somit durch das Betriebssystem unterbunden .

Ferner kann eine Bewertung hinsichtlich des Hauptspeichers ergeben, dass eine mögliche Bedrohung für das sicherheitsge- richtete System im versehentlichen Schreiben in eine andere Partition geschehen kann. Hier kann beispielsweise eine konstruktive Maßnahme wie Start der SQLite-Datenbank 101 als Ar- chivprozesses mit eingeschränkten Benutzerrechten definiert werden. Dadurch werden keine schreibenden Zugriffe auf andere Partitionen anderer Prozesse bzw. Softwarekomponenten 12, 13, 14, 111 gestattet.

Betrachtet man nun die Möglichkeit der Beeinflussung oder Rückwirkung durch die systemtechnische Ressource CPU- Belastung, so ergibt eine Bewertung hinsichtlich der CPU- Belastung, dass eine mögliche Bedrohung für das sicherheits- gerichtete System in einem übermäßiger Verbrauch von Rechen- zeit durch die SQLite-Datenbank als Archiv 101 liegen kann, so dass andere Prozesse bzw. Softwarekomponenten 12, 13, 14, 111 behindert werden. Hier können beispielsweise die folgenden applikativen Maßnahmen definiert werden:

- Überwachen aller laufenden Prozesse bzw. Softwarekomponenten mittels eines Heartbeat-Protokolls . Beim Ausbleiben eines laufenden Prozesses bzw. einer laufenden Softwarekomponente erfolgt Neustart der betroffenen Komponente;

- Überwachen des Systems sowie der restlichen Prozesse bzw. Softwarekomponenten durch ein SEP-Framework, bei Problemen erfolgt ein geregelter oder ggf. auch harter Shutdown.

Betrachtet man nun die Möglichkeit der Beeinflussung oder Rückwirkung durch die globale Ressourcen (z.B. Futex, Datei- Locks, Datei-Handies oder Tasks) , so ergibt eine Bewertung hinsichtlich der globalen Ressourcen, dass eine mögliche Bedrohung für das sicherheitsgerichtete System im übermäßigen Verbrauch von globalen Ressourcen durch die SQLite-Datenbank als Archiv 101 entstehen kann, so dass andere Prozesse bzw. Softwarekomponenten 12, 13, 14, 111 behindert werden. Dabei können die folgenden analytischen Maßnahmen definiert werden:

- Die generierte Bibliothek von SQLite 101 kann in Bezug auf Abhängigkeiten zu anderen Bibliotheken untersucht werden. Da- durch können Abhängigkeiten applikativ aufgedeckt und verhindert werden.

- Systemfunktionen können aufgerufen oder untersucht werden. Dabei kann die Nutzung von Futex, Datei-Locks, Datei-Handies und/oder Tasks näher untersucht werden. Mögliche Störungen können ggf. applikativ beseitigt werden.

Betrachtet man nun die Möglichkeit der Beeinflussung oder Rückwirkung durch Kommunikation (z.B. TCP/IP) , so ergibt eine Bewertung hinsichtlich der Kommunikation, dass eine mögliche Bedrohung für das sicherheitsgerichtete System in einem ungewollten Aufbau zu anderen Prozessen bzw. Softwarekomponenten 12, 13, 14, 111 durch die SQLite-Datenbank als Archiv 101 stattfinden kann. Dabei kann die folgende analytische Maßnah- me definiert werden: Aufrufe (z.B. bind, socket, listen oder accept unter Linux) , die eine Kommunikation als Folge haben, sollen soweit möglich (z.B. soweit andere Kommunikationswege gegeben sind) verhindert oder gemieden werden. Dieses kann entsprechend applikativ umgesetzt werden.

Dafür kann eine Analyse des entsprechenden Source-Codes, wie beispielhaft in Fig. 4 dargestellt, erfolgen. In Schritt 41 wird eine Konfiguration und Kompilation der sicherheitsunkritischen Softwarekomponente (hier der SQLite-Datenbank als Archiv) mit vorgegebenen Schalter durchgeführt. Daraufhin wird in Schritt 42 eine Analyse der externen Symbolabhängigkeiten des Programms bzw. der sicherheitsunkritischen Softwarekomponente und somit der SQLite-Datenbank als Archiv durchgeführt. Anschließend wird eine Abfrage 43 durchgeführt, bei der festgestellt wird, ob externe Symbolabhängigkeiten vorhanden sind. Sind keine externe Symbolabhängigkeiten vorhanden (durch „N" verdeutlich) , so wird die Analyse des entsprechenden Source-Codes beendet 44, d.h., es liegt keine Bedrohung hinsichtlich einer Überschneidung bei der Kommunikation zwischen der SQLite-Datenbank als Archiv und weiteren Softwarekomponenten bzw. Prozessen vor. Sonst, wenn externe Symbolab- hängigkeiten vorhanden sind (durch „J" verdeutlich) , wird eine Zuordnung 45 von externen Diensten der sicherheitsunkritischen Softwarekomponente und somit der SQLite-Datenbank als Archiv und Ermittlung von Softwarekomponenten bzw. Prozessen (z.B. Kernel-Ressourcen), die durch die sicherheitsunkriti- sehe Softwarekomponente und somit die SQLite-Datenbank als Archiv beeinflusst werden, durchgeführt. Anschließend wird eine Analyse 46 der Nutzung verbleibender Ressourcen durch die sicherheitsunkritische Softwarekomponente und somit die SQLite-Datenbank als Archiv durchgeführt und das Programm wird beendet 44.

Die Anforderungen aus einer vorgegebenen Sicherheitsnorm (hier beispielhaft EN50128) müssen bei der Entwicklung von nicht-sicherheitskritischen bzw. sicherheitsunkritischen Kom- ponenten (hier beispielhaft der Archivkomponente in Form von SQLite-Datenbank) berücksichtigt werden. Gemäß dem vorliegenden Ausführungsbeispiel wurde SQLite als Persisitierungsmedium unter verschiedenen Lösungsalternativen nach bestimmten Auswahlkriterien bewertet und als beste Lösung gewählt. Näheres ist der nachfolgenden Entscheidungsta- belle zu entnehmen, dabei sind mögliche Risiken, d.h., Rückwirkungen bzw. Beeinflussungsmöglichkeiten, und die auf diese definierten Maßnahmen aufgeführt.

Wie bereits erwähnt kann die Rückwirkung auf andere Software- komponenten oder -Systeme gemäß dem vorliegenden Ausführungsbeispiel über die Nutzung gemeinsamer Ressourcen zwischen den weiteren Softwarekomponenten und der Archivkomponente als SQLite-Datenbank erfolgen. Die gemeinsamen Ressourcen können dabei sein:

1. Speicher; a. Hauptspeicher; b. Dateisystem;

2. CPU-Zeit / Auslastung; 3. Kernel-Ressourcen (z.B. Mutex, Threads, etc.); und/oder 4. Kommunikation zu anderen SW-Komponenten.

Gemäß dem vorliegenden Ausführungsbeispiel wird davon ausgegangen, dass die Sicherheit der gemeinsamen Ressourcen eben- falls durch entsprechende Überwachungsmechanismen sicherstellt wird, d.h., dass für die gemeinsamen Ressourcen Schwachstellen (Rückwirkungen) auf das sicherheitsgerichtete System erkannt werden und dass gegebenenfalls entsprechend darauf reagiert wird.

Speicherüberschreiber, etc. bzw. Windows-Prozess läuft und damit die Speicherschutzmechanismen des jeweiligen Betriebssystems greifen.

Den zur Verfügung stehenden

Die Archivkomponente darf Hauptspeicher für die Archivnicht zuviel Hauptspeicher in komponente über das BetriebsAnspruch nehmen, so dass für system begrenzen. In Linux das sicherheitsgerichtete Sysz.B. mit Hilfe der API- tem oder für die anderen SoftFunktion setrlimitO . warekomponenten auf dem Server des Systems nicht genügend Hauptspeicher zur Verfügung steht und somit ein sicheres Funktionieren des sicherheits- gerichteten Systems beeinträchtigt wird. zu l.b. Dateisystem

Es besteht die Gefahr, dass Eigene Partition für die die Archivkomponente zuviel SQLite-Datenbank als Archiv Speicher des sicherheitsge- definieren . richteten System belegt, so dass die anderen Softwarekomponenten und das sicherheitsgerichtete System selbst nicht mehr genügend Speicher auf dem File System zur Verfügung haben .

Eigene User-Rechte definie¬

Es besteht die Gefahr, dass ren . SQLite-Datenbank als Archiv versucht, auf eine ihr nicht Hier muss mit dem sicher- zugeordneten Partition zu- heitsgerichteten System ge- zugreifen (z.B. durch Lesen klärt werden, ob es möglich und/oder Schreiben) . ist, verschiedene User (Rechte) für unterschiedliche Dienstcontainer des sicher- heitsgerichteten Systems zu definieren .

Alternativ kann man beim Systemstart die gleichen Gruppenrechte allen Dienstcontainern des sicherheitsgerichte- ten Systems geben und danach dem Dienstcontainer, in dem die Archivkomponente läuft, Rechte entziehen. Dabei könnte geprüft werden, ob im Falle eines Linux-Systems dieses auch prozessess-spezifisch möglich ist.

zu 2. CPU-Zeit / Auslastung

Es besteht die Gefahr, dass Gemäß dem vorliegenden Ausdie Archivkomponente bzw. die führungsbeispiel wird das si- SQLite-Datenbank zu viel an cherheitsgerichtete System Prozessorzeit beansprucht, so von einem LSM (Linux Safety dass die anderen SoftwarekomManager) überwacht. Falls der ponenten, insbesondere die siLSM seiner Überwachungsfunkcherheitskritischen Softwaretion bzw. -Aufgabe nicht komponenten nicht oder zuminnachkommen kann, übernimmt dest nicht ausreichend Prozesder SEP (Safety Execution sorzeit nutzen können. Processor) diese Aufgabe.

Die sicherheitskritischen Komponenten werden innerhalb des sicherheitsgerichteten Systems durch eine Heartbeat-

Im Nachfolgenden werden beispielhaft einige mögliche Kernel- Ressourcen des gemäß dem vorliegenden Ausführungsbeispiel eingesetzten Linux-Betriebssystems aufgelistet, die von der SQLite-Datenbank verwendet werden können:

#if OS_UNIX

#define sqlite3OsOpenReadWrite sqlite3UnixOpenReadWrite

#define sqlite3OsOpenExclusive sqlite3UnixOpenExclusive #define sqlite3OsOpenReadOnly sqlite3UnixOpenReadOnly

#define sqlite3OsDelete sqlite3UnixDelete

#define sqlite3OsFileExists sqlite3UnixFileExists

#define sqlite3OsFullPathname sqlite3UnixFullPathname

#define sqlite3OsIsDirWritable sqlite3UnixIsDirWritable #define sqlite30sSyncDirectory sqlite3UnixSyncDirectory

#define sqlite3OsTempFileName sqlite3UnixTempFileName

#define sqlite30sRandomSeed sqlite3UnixRandomSeed

#define sqlite3OsSleep sqlite3UnixSleep

#define sqlite3OsCurrentTime sqlite3UnixCurrentTime #define sqlite3OsEnterMutex sqlite3UnixEnterMutex

#define sqlite3OsLeaveMutex sqlite3UnixLeaveMutex

#define sqlite3OsInMutex sqlite3UnixInMutex

#define sqlite3OsThreadSpecificData sqlite3UnixThread-

SpecificData #define sqlite30sMalloc sqlite3GenericMalloc

#define sqlite30sRealloc sqlite3GenericRealloc

#define sqlite3OsFree sqlite3GenericFree

#define sqlite30sAllocationSize sqlite3Generic-

AllocationSize #define sqlite30sDlopen sqlite3UnixDlopen

#define sqlite3OsDlsym sqlite3UnixDlsym

#define sqlite30sDlclose sqlite3UnixDlclose #endif Somit bezieht sich die vorliegende Erfindung auf ein Unterstützen eines sicherheitsgerichteten Systems, wobei das si- cherheitsgerichtete System sicherheitskritische Softwarekomponenten und sicherheitsunkritische Softwarekomponenten auf- weist. Dabei wird eine Möglichkeit einer gegenseitigen Beeinflussung einer sicherheitskritischen Softwarekomponente und einer sicherheitsunkritische Softwarekomponente identifiziert und einer Menge von technischen Maßnahmen zum Verhindern der Möglichkeit der Beeinflussung definiert. Auf diese Weise wird durch die vorliegende Erfindung eine Rückwirkungsfreiheit von sicherheitsunkritischen Softwarekomponenten auf sicherheitskritische Softwarekomponenten sowohl nachgewiesen als auch sichergestellt. Dies ist insbesondere der Fall, wenn als eine sicherheitsunkritische Komponente eine frei verfügbare Soft- warekomponente, z.B. eine Open Source Softwarekomponente, eingesetzt wird.

Obwohl die vorliegende Erfindung vorstehend mit Bezug auf die Ausführungsform gemäß der beiliegenden Zeichnungen erklärt wird, ist es ersichtlich, dass die Erfindung nicht auf diese beschränkt ist, sondern innerhalb des Bereichs der oben und in den anhängigen Ansprüchen offenbarten erfinderischen Idee modifiziert werden kann. Es versteht sich von selbst, dass es noch weitere Ausführungsformen geben kann, die den Grundsatz der Erfindung darstellen und äquivalent sind, und dass somit verschiedene Modifikationen ohne Abweichen vom Umfang der Erfindung implementiert werden können.

Claims

Patentansprüche

1. Verfahren zum Unterstützen eines sicherheitsgerichteten Systems, wobei das sicherheitsgerichtete System sicherheits- kritische Softwarekomponenten und sicherheitsunkritische Softwarekomponenten aufweist und wobei das Verfahren aufweist:

Identifizieren einer Möglichkeit einer gegenseitigen Beein- flussung einer sicherheitskritischen Softwarekomponente und einer sicherheitsunkritische Softwarekomponente; und Definieren einer Menge technischer Maßnahmen zum Verhindern der Möglichkeit der Beeinflussung.

2. Verfahren nach Anspruch 1, wobei das Identifizieren aufweist:

Ermitteln einer Schnittmenge systemtechnischer Ressourcen eines Wirkungsbereichs der sicherheitskritischen Softwarekomponente und eines Wirkungsbereichs der sicherheitsunkritischen Softwarekomponente.

3. Verfahren nach Anspruch 2, wobei das Identifizieren ferner aufweist:

Bewerten zumindest einer systemtechnischen Ressource aus der Schnittmenge systemtechnischer Ressourcen hinsichtlich der Möglichkeit der gegenseitigen Beeinflussung.

4. Verfahren nach einem der vorstehenden Ansprüche, wobei das Definieren der Menge technischer Maßnahmen durch Analyse der Möglichkeit der gegenseitigen Beeinflussung ausgeführt wird.

5. Verfahren nach einem der vorstehenden Ansprüche, wobei das Definieren der Menge technischer Maßnahmen basie- rend auf der Bewertung der zumindest einen systemtechnischen Ressource durchgeführt wird.

6. Verfahren nach einem der vorstehenden Ansprüche, wobei das Definieren der Menge technischer Maßnahmen ein Bestimmen einer Konfigurationsmaßnahme aufweist.

7. Verfahren nach einem der vorstehenden Ansprüche, wobei das Definieren der Menge technischer Maßnahmen eine softwaretechnische Analyse der sicherheitskritischen Softwarekomponente hinsichtlich der Möglichkeit der gegenseitigen Beeinflussung aufweist.

8. Verfahren nach einem der vorstehenden Ansprüche, wobei das Definieren der Menge technischer Maßnahmen ein Bestimmen einer Applikation zum Verhindern der Möglichkeit der gegenseitigen Beeinflussung aufweist.

9. Verfahren nach einem der vorstehenden Ansprüche, wobei als die sicherheitsunkritischen Softwarekomponente eine Open Source Softwarekomponente verwendet wird.

10. Vorrichtung, die zum Unterstützen eines sicherheitsge- richteten Systems ausgestaltet ist, wobei das sicherheitsge- richtete System sicherheitskritische Softwarekomponenten und sicherheitsunkritische Softwarekomponenten aufweist und wobei die Vorrichtung derart konfiguriert ist:

eine Möglichkeit einer gegenseitigen Beeinflussung einer sicherheitskritischen Softwarekomponente und einer sicherheitsunkritische Softwarekomponente zu identifizieren; und eine Menge technischer Maßnahmen zum Verhindern der Möglich- keit der Beeinflussung zu definieren.

11. System, das ausgestaltet ist,

Schritte des Verfahrens nach einem der Ansprüche 1 bis 9 auszuführen .

12. Computerprogramm, das eine Kodierung aufweist, die konfiguriert ist, Schritte des Verfahrens nach einem der Ansprüche 1 bis 9 auszuführen .

13. Computerprogramm nach Anspruch 12, wobei das Computerprogramm auf einem Datenträger gespeichert ist .

14. Datenträger, der ein Computerprogramm nach Anspruch 12 aufweist .

15. Sicherheitsgerichtetes System, das sicherheitskritische Softwarekomponenten und sicherheitsunkritische Softwarekomponenten aufweist und das derart konfiguriert ist, eine Rückwirkungsfreiheit auf die sicherheitskritischen Softwarekompo- nenten durch Ausführen der Schritte des Verfahrens nach einem der Ansprüche 1 bis 9 sicherzustellen.