-
Die
vorliegende Erfindung betrifft ein Verfahren zum Unterstützen
eines sicherheitsgerichteten Systems.
-
Eines
der Ziele eines sicherheitsrelevanten oder sicherheitsgerichteten
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 Zuverlä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 Sicherheitsanforderungsstufe
(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 verifiziert 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 = 1, 2, 3 oder 4) wird erreicht, wenn das SW-Teilsystem
Anforderungen vorbestimmter Safety-Normen (z. B. IEC 61508, EN
50128 usw.) erfüllt.
-
Des
Weiteren ist auch die Produkthaftung ein wichtiger Aspekt, wenn
es um sicherheitsrelevante bzw. sicherheitsgerichtete 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 dementsprechend
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, EN 50128 usw.).
-
Sicherheitsrelevanten
oder sicherheitsgerichteten Systemen, die Softwarekomponenten aufweisen, werden
durch die vorgegebenen Regeln oder Normen Sicherheitsanforderungen
aufgestellt, die beschreiben, wie ein sicheres Verhalten des Systems
gewährleistet und das Auftreten von Gefahrensituationen
verhindert werden kann.
-
Die
Sicherheitsrelevanz technischer Systeme leitet sich aus der maximalen
Sicherheitsanforderung an die durch diese Systeme 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 sicherheitsrelevante 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 Softwarekomponenten 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änkungen 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 implementierte 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 Beeinflussung 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 Identifizierens 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 Wirkungsbereichs 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 ausgefü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 Softwarekomponente 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 Sicherheitssystemen 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
Softwarekomponenten, 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,
analytische 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 Vorrichtung 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 Computerprogramms 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 sicherheitsgerichteten
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:
-
1 mögliche
Interaktionen zwischen Softwarekomponenten eines sicherheitsgerichteten
Systems gemäß einem Ausführungsbeispiel
der vorliegenden Erfindung zeigt;
-
2 eine
Schnittstelle einer sicherheitskritischen Softwarekomponente und
einer sicherheitsunkritischen Softwarekomponente gemäß einem
Ausführungsbeispiel der vorliegenden Erfindung zeigt;
-
3 eine
gemäß einem Ausführungsbeispiel der vorliegenden
Erfindung umgesetzte bzw. ausgestaltete Rückwirkungsbarriere
zeigt; und
-
4 ein
Blockdiagramm einer Analyse eines Source-Codes als applikative Maßnahme
gemäß einem Ausführungsbeispiel der vorliegenden
Erfindung zeigt.
-
Die 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 EN
50128 mit formalen Methoden und Techniken gemäß einem
Ausführungsbeispiel der vorliegenden Erfindung beschrieben.
Dabei ist das Meldungsarchiv an der Ausführung 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 EN 50128 lediglich zur Darstellung eines konkreten
Beispiels dienen. Die vorliegende Erfindung findet keine Einschränkung
hinsichtlich der verwendeten Softwarekomponenten und hinsichtlich
der einzuhaltenden 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 geschieht 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 Softwarekomponenten 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 Selbsttest-
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 1 sind
die Beziehungen zwischen den Softwarekomponenten 101, 111, 12, 13, 14 durch
Pfeile dargestellt. Dabei deuten die gepunkteten Pfeile, die von
der überwachenden Softwarekomponente 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 stattfindet.
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 sicherheitsunkritische
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 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. sicherheitsgerichtetes 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 Wirkungsbereiche
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 sicherheitsbezogenen 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ückwirkung 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.
-
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ückwirkung 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. Framework) 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ührungsprozess des Meldungsarchivs beendet werden,
um Betriebssicherheit des sicherheitsgerichteten Systems zu gewährleisten.
-
3 zeigt
eine gemäß dem Ausführungsbeispiel der
vorliegenden Erfindung umgesetzte bzw. ausgestaltete Rückwirkungsbarriere.
-
Die
Komponenten der 3 entsprechen den Komponenten
der 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. sicherheitsunkritische
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, applikative 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
durchgefü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 programmiertechnische
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. sicherheitsunkritische
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 Ressourcen
(Futex, Datei-Locks, Datei-Handles, Tasks), Kommunikation (TCP/IP).
-
Betrachtet
man nun die Möglichkeit der Beeinflussung oder Rückwirkung
durch die systemtechnische Ressource Hauptspeicher, so ergibt eine
Bewertung hinsichtlich des Hauptspeichers, dass eine mögliche
Bedrohung für das sicherheitsgerichtete 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 konstruktive
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 sicherheitsgerichtete
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 Systemframework
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 cher, so ergibt eine
Bewertung hinsichtlich des Flashspeichers, dass eine mögliche
Bedrohung für das sicherheitsgerichtete 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 sicherheitsgerichtete
System im versehentlichen Schreiben in eine andere Partition geschehen
kann. Hier kann beispielsweise eine konstruktive Maßnahme
wie Start der SQLite-Datenbank 101 als Archivprozesses
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 sicherheitsgerichtete System in einem übermäßiger
Verbrauch von Rechenzeit 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-Handles
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. Dadurch 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-Handles 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ßnahme 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 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 Symbolabhä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 sicherheitsunkritische
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 EN
50128) müssen bei der Entwicklung von nicht-sicherheitskritischen
bzw. sicherheitsunkritischen Komponenten (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 Entscheidungstabelle 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
Softwarekomponenten 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 ebenfalls 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.
| Mögliches
Risiko | Maßnahme |
| zu 1. a.
Hauptspeicher |
| Die
Archivkomponente darf den Speicherbereich der anderen Softwarekomponenten
nicht beeinflussen (z. B. aus Versehen Speicherüberschreiber,
etc.)
Die Archivkomponente darf nicht zuviel Hauptspeicher
in Anspruch nehmen, so dass für das sicherheitsgerichtete
System oder für die anderen Soft-warekomponenten auf dem
Server des Systems nicht genügend Hauptspeicher zur Verfügung steht
und somit ein sicheres Funktionieren des sicherheitsgerichteten
Systems beeinträchtigt wird. | Die
Archive Komponente wird als Dienst in einem eigenen Dienstcontainer
ablaufen gelassen, da ein Dienstcontainer in einem eigenen Linux-
bzw. Windows-Prozess läuft und damit die Speicherschutzmechanismen
des jeweiligen Betriebssystems greifen.
Den zur Verfügung
stehenden Hauptspeicher für die Archivkomponente über
das Betriebs-system begrenzen. In Linux z. B. mit Hilfe der APIFunktion
setrlimit(). |
| zu 1. b.
Dateisystem |
| Es
besteht die Gefahr, dass die Archivkomponente zuviel Speicher des
sicherheitsgerichteten 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.
Es
besteht die Gefahr, dass SQLite-Datenbank als Archiv versucht, auf
eine ihr nicht zugeordneten Partition zuzugreifen (z. B. durch Lesen
und/oder Schreiben). | Eigene
Partition für die SQLite-Datenbank als Archiv definieren.
Eigene
User-Rechte definieren.
Hier muss mit dem sicherheitsgerichteten
System geklärt werden, ob es möglich ist, verschiedene User
(Rechte) für unterschiedliche Dienstcontainer des sicherheitsgerichteten
Systems zu definieren.
Alternativ kann man beim Systemstart
die gleichen Gruppenrechte allen Dienstcontainern des sicherheitsgerichteten
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 die Archivkomponente bzw. die SQLite-Datenbank
zu viel an Prozessorzeit beansprucht, so dass die anderen Softwarekomponenten,
insbesondere die sicherheitskritischen Softwarekomponenten nicht
oder zumindest nicht ausreichend Prozessorzeit nutzen können. | Gemäß dem
vorliegenden Ausführungsbeispiel wird das sicherheitsgerichtete
System von einem LSM (Linux Safety Manager) überwacht.
Falls der LSM seiner Überwachungsfunktion bzw. -Aufgabe
nicht nachkommen kann, übernimmt der SEP (Safety Execution
Processor) diese Aufgabe.
Die sicherheitskritischen Komponenten
werden innerhalb des sicherheitsgerichteten Systems durch eine Heartbeat-Funktionalität überwacht.
Hierfür müssen alle LCM-Teilkomponenten der Archivkomponente
diese Funktionalität implementieren.
Diese Überwachungsfunktionalitäten
können anschließend im Test verifiziert werden. |
| zu
3. Kernel-Ressourcen | |
| Es
besteht die Gefahr, dass die SQLite-Datenbank unbegrenzt Kernel-Ressourcen
verwenden. Beispiele für solche Ressourcen sind beispielsweise Mutex(e)
oder File Handle. Bei File Handle kann es mehrere „File
Open" ohne entsprechende Anzahl von „File Close" für
die SQLite-Datenbank geben. Dadurch läuft der File Handler
im Kernel „voll", so dass andere Softwarekomponenten keine
Dateioperationen durchführen können. | Hier
ist eine Analyse des softwarecodes sinnvoll. Dabei wird feststellt,
welche, wie viele und wie die Kernel-Ressourcen durch die SQLite-Datenbank
benutzt werden. Da-bei werden die von SQLite benutzten Kernel Ressourcen
aufgedeckt. Ggf. wird applikativ sichergestellt, dass diese rückwirkungsfrei
verlaufen. |
| zu
4. Kommunikation | |
| Hier
besteht die Gefahr, dass die SQLite-Datenbank eine ungewollte Kommunikation
zu anderen SW-Komponenten aufbaut. | Hier
kann z. B. ein „grep"-Befehl auf dem Quellcode von SQLite
ausgeführt werden, um nach solchen Stichworten wie bind,
socket, etc. zu suchen. Dabei kann sichergestellt werden, dass die
SQLite-Datenbank, keine Kommunikation zu anderen Softwarekomponenten
aufbaut. |
-
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:
-
Somit
bezieht sich die vorliegende Erfindung 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.
Dies ist insbesondere der Fall, wenn als eine sicherheitsunkritische
Komponente eine frei verfügbare Softwarekomponente, 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.
-
ZITATE ENTHALTEN IN DER BESCHREIBUNG
-
Diese Liste
der vom Anmelder aufgeführten Dokumente wurde automatisiert
erzeugt und ist ausschließlich zur besseren Information
des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen
Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt
keinerlei Haftung für etwaige Fehler oder Auslassungen.
-
Zitierte Nicht-Patentliteratur
-
- - EN 50128 [0008]
- - EN 50128 [0010]
- - EN 50128 [0047]
- - EN 50128 [0048]
- - EN 50128 [0077]
