Security

Mit einem Masterplan für alle Safety & Security-Standards und -Level kommt man schneller ans Ziel und kann seine Applikationen agiler weiterentwickeln. (Bild: Sysgo)

Die Prozesse der Softwareentwicklung sind für jedweden Anwendungsfall der funktionalen Sicherheit zwar in weiten Teilen identisch. Aber, was für die jeweilige Branchenzertifizierung ganz konkret verlangt wird, ist oftmals sehr spezifisch. Selbst wenn eine Software höchste Anforderungen wie den DO 178C-Level A erfüllt, der in der Luftfahrtbranche zum Einsatz kommt, kann sie nicht 1:1 für die ISO 26262 Zertifizierung der Automotive-Branche genutzt werden.

Unterschiedliche Sicherheitslevel erfüllen

Heterogene Anforderungen gibt es aufgrund der unterschiedlichen Sicherheitslevel auch innerhalb einer jeden einzelnen Zertifizierungsnorm. In der Avionik gibt es beispielsweise den DO-178C Level A, der für den Schutz vor einem „Catastrophic Effect“ geschaffen wurde. Hierfür sind höchstredundante Systeme und Software zu entwickeln. Beim DO-178C Level D, der für Software gilt, die bei Versagen die Sicherheitsmarge nur geringfügig verändert, sind die Anforderungen deutlich geringer. Aufwendungen, die man für den höchsten Level tätigen muss, will man für niedrigere Level nicht tätigen, weil sie Zeit und Geld kosten. Ein ähnliches Konzept verfolgt quasi jeder Zertifizierungs-Standard der einzelnen Industriebereiche. Dennoch kann man ein und dasselbe Master-Prozessmodell nutzen, um alle Anforderungen der unterschiedlichen Normen und Level für Funktionale Sicherheit (FuSi) mittels standardisierter Vorgehensweisen erfüllen zu können. Der Prozess muss lediglich die für den konkreten Anwendungsfall erforderliche Route nehmen können, um bei minimalem Aufwand das jeweils geforderte Ergebnis einer normenkonform zertifizierbaren Lösung zu schaffen.

Softwarecode
Bevor der funktional sicherer Code geschrieben werden kann, müssen die erforderlichen Rahmenbedingungen abgesteckt sein. (Bild: Sysgo)

Unterschiedliche Branchen bedienen

Ein solches branchenübergreifendes Prozessmodell ist beispielsweise für Lösungsanbieter interessant, die Steuerungen mit integrierter Situationserkennung entwickeln. Sie wollen ihre Technologie mit Wachstumspotenzial schließlich in möglichst allen Branchen vertreiben: Von autonomen kollaborativen Robotern (IEC 61508) und bildgeführter Operationsrobotik (IEC 62304) über automatisiert geführte innerbetriebliche Logistikfahrzeuge und autonome Landmaschinen bis hin zu autonomen Bahnen (EN 50128), Flugzeugen (DO178C) und Drohnen sowie für Kraftfahrzeuge (ISO26262), die derzeit das wohl größte Anwendungsfeld darstellen.

Geht es hier beispielsweise um die Kollisionsvermeidung mit zunehmend komplexer Logik zur Entscheidungsfindung auf Basis der Daten von unterschiedlichster Sensorik, die zur Umwelterkennung eingesetzt wird, wird die Aufgabe, eine ASIL D konforme Logik zu entwickeln, komplex, weshalb bereits Ansätze diskutiert werden, wie man die Umwelterkennung mit spezifischen Methoden (SOTIF-Tests, HARA-Analysen) ohne die komplexen Entwicklungs-Anforderungen der ISO26262 ausführen kann.

Zertifizierbare funktionale Sicherheit ist also aufgrund der Vielfalt der möglichen unterschiedlichen Anforderungen und damit einhergehenden erforderlichen Lösungsansätze keine einfache Aufgabenstellung. Sie erfordert vielmehr profundes Know-how bezüglich der einzelnen Normen, ihrer unterschiedlichen Sicherheitslevel und den sich daraus ergebenden unterschiedlichen Anforderungen an die Softwarefunktionalität und die Prozesse, wie man zu ihr kommt und wie man dies auch zertifizierbar dokumentiert.

Mixed-Critical-Applikationen entwickeln

Aufgrund höher integrierter Prozessortechnologie werden die Aufgabenstellungen zudem zunehmend komplexer: Wurden einzelne Aufgaben einer Gesamtlösung je nach Level ihrer funktionalen Sicherheit früher diskret auf dedizierte Controller verteilt und Zertifizierungen einzeln angegangen, ist es heute das Ziel, Mixed-Critical-Systeme auf heterogenen SoCs (System-on-Chip) zu integrieren. Infolge multiplizieren sich die Aufgaben und Interdependenzen, sodass ganzheitliche Lösungsansätze gefunden werden müssen. Ansonsten kann man sich nämlich verzetteln und Effizienzsteigerungspotenziale lassen sich nicht nutzen, wenn für einzelne Teilaufgaben unterschiedliche Herangehensweisen gewählt werden.

Wie geht man also eine Zertifizierung bei zunehmender Komplexität möglichst effizient an? Grundsätzlich lässt sich der Prozess unabhängig von der Komplexität der Gesamtlösung in vier Phasen unterteilen. Zuerst kommt die grundlegende Planung, danach die eigentliche Entwicklung gefolgt von der Analyse und Verifizierung des Ergebnisses bis man am Ende des Prozesses das System abschließend für die Zertifizierung qualifiziert.

Zertifizierung
Es lohnt sich, große Systeme im Hinblick auf die Zerlegung in Teilsysteme mit unterschiedlichem Kritikalitätsgrad zu analysieren. Dadurch wird die Komplexität des Teilsystems reduziert. (Bild: Sysgo)

Alle Prozessbeteiligten orchestrieren

Bereits in der Planungsphase sind die Grundlagen einer erfolgreichen Zertifizierung zu entwickeln. Nach der Festlegung der angestrebten Normen und Zertifizierungsprozesse gilt es im ersten Schritt, die Expertise aller beteiligten Partner in Bezug auf die avisierten Normen zu analysieren. Gegebenenfalls sind identifizierte Schwachstellen im Rahmen des Projekts ausbesserbar oder Alternativen zu finden. Nicht ohne Belang ist auch das Zusammenspiel aller Partner von der Hardware mit Sicherheitsnachweis über das zertifizierbare Betriebssystem bis hin zur Applikationssoftware, da alle Parteien in der Regel unterschiedliche Interessen haben und ihren Aufwand minimieren wollen. Hier ist ein gemeinsames Verständnis in Bezug auf die Zuständigkeiten zu schaffen und Aufgaben eindeutig zuzuordnen. Jede gekaufte Komponente hat schließlich auch Usage Constraints, die es zu beachten gilt bzw. die zwischen den einzelnen Entitäten abgestimmt werden müssen.

Für Mixed-Critical-Applikationen, die auf heterogenen SoCs basieren, ist zudem sicherzustellen, dass nicht-zertifizierbare Software-Komponenten wie ein Linux-basiertes GUI mittels Separation-Kernel und Hypervisor-Technologie von sicherheitsrelevanten Instanzen getrennt werden. Durch die Verlagerung in eine sauber und sicher abgrenzbaren Partition, die keinen kritischen Code ausführt, kann sichergestellt werden, dass sie keinerlei Auswirkung auf die zu zertifizierenden Teile des Systems haben. Je mehr Funktionen man auf diese Weise aus der Zertifizierung ausklammern kann, desto geringer der Aufwand. Soll das GUI jedoch ebenfalls funktional sicher sein, muss es Bestandteil des Safety-Engineering-Prozesses werden. Je vielfältiger und heterogener die Safety-Anforderungen einer Gesamtapplikation sind, desto wichtiger wird der Masterplan.

Auch ist die Selektion der Zertifizierungsstelle nicht unerheblich, da von ihr auch abhängt, welche Grundlagen bis wann für die konkreten Audits der Zertifizierung zu schaffen sind. Zudem macht es Sinn, diese Autoritäten direkt in der Planungsphase in die Prozesse zu integrieren. So können sie die aufzusetzenden Planungsdokumente auch direkt überprüfen. Namentlich sind dies der Safety Plan, die Entwicklungspläne (Development, Verifikation und Validation, Qualität und Konfigurations-Management) und insbesondere die Compliance-Tabellen, in denen ausgeführt wird, mit welchen Prozessen man welche Normen-Teile erfüllt.

Master-Safety-Plan und Compliance-Tabellen für alle Zertifizierungsanforderungen

Genau an dieser Stelle ist es enorm vorteilhaft, einen Master-Safety-Plan für alle Zertifizierungsanforderungen zu haben. In ihm wird unter anderem festgelegt, wie das Betriebssystem und seine BSPs und hardwarenahen Treiber entwickelt, validiert, getestet und dokumentiert werden. Dieser kann dann unterschiedliche Routen nehmen, je nachdem für welchen Standard und welchen Sicherheitslevel die Lösung entwickelt werden soll. Unterstützt wird dieses Vorgehen durch Compliance-Matrizen für jede Zertifizierungsnorm, die auf ein generisches Entwicklungskonzept aufsetzen.

Vorteilhaft für Kunden ist dabei, dass der Aufwand für die Erstellung der Safety-Pläne deutlich minimiert wird, da es bereits einen Masterplan gibt, der für alle Normen adaptierbar ist. Auch ist durch zahlreiche Zertifizierungen bereits belegt, dass sie die Anforderungen an die Zertifizierung vollumfänglich erfüllen, was Kunden entsprechende Verfahrenssicherheit bietet. Schlussendlich schafft ein Masterplan auch die Grundlage, Zertifizierungen einer Branche leicht in andere Branchen portieren zu können oder ursprünglich niedrigere Sicherheitslevel einfacher auf höhere Level heben zu können, da alles ineinandergreift. Durch einen Masterplan und mithilfe von adaptierbaren Compliance-Matrizen schützt man sich auch vor Sackgassen in der Entwicklung, die man nicht erkennt, wenn man sich auf den jeweils ganz konkreten Projektfokus beschränkt.

Synergieeffekte zwischen Safety- und Security-Zertifizierung

Die Prozesse, die man für eine Safety-Zertifizierung genutzt hat, können auch für Security-Zertifizierung herangezogen werden. Im Umkehrschluss ergibt sich daraus der Vorteil, dass Safety-Entwicklungen, die auf Basis eines Safety & Security Masterplans entwickelt wurden, bereits wesentliche Grundlagen für die Security-Zertifizierung schaffen. Für die Security-Zertifizierung einer Safety-Applikation sind dann nur noch die Elemente zu ergänzen, die nicht bereits über die Safety-Zertifizierung abgearbeitet wurden. Derart ganzheitlich integrierte Lösungsansätze bieten dem OEM deutliche Effizienzsteigerungen, da alles ineinandergreift und aufeinander abgestimmt ist.

Aufgaben, die über die Safety-Zertifizierung hinausgehen sind beispielsweise die Implementierung eines Secure Developments zur Vermeidung der Infiltrierung durch Schadcode. Auch muss sichergestellt werden, dass Schwachstellen nicht offengelegt werden, damit Hacker diese nicht auf dem Tablett serviert bekommen, um sie ausnutzen zu können. Auch sind zusätzliche Vulnerability-Analysen oder Penetrationstests typischerweise nicht Bestandteil einer Safety Zertifizierung, für eine Security Zertifizierung aber unerlässlich. Die Spezifikation, wie Requirements ausgelegt sein sollten und dass es einen Code-Review geben muss, um Vulnerabilitäten/Schwachstellen zu evaluieren, kann bereits den Safety-Spezifikationen entnommen werden. So können Projekte mit Safety- und Security-Zertifizierung von Anfang an harmonisiert angegangen werden. Beim Thema Security kann man sich schlussendlich vollkommen auf das konzentrieren, was speziell für Security erforderlich ist, was wiederum Effizienzsteigerungspotenziale mit sich bringt.

In heutigen Zeiten wird man Safety- und Security ohnehin nicht mehr voneinander trennen können, denn Safety kann es bei IoT-angebundenen Devices ohne Security eigentlich gar nicht mehr geben. Insofern werden Masterpläne für eine ganzheitliche Sicherheit ohnehin mandatorisch. Haben Applikationsentwickler für Safety ihren OS-Zuschnitt folglich bereits nach einem solchen Masterplan entwickeln lassen, kann eine spätere Security-Zertifizierung davon profitieren.

Safety
Durch einem Master-Safety-Plan für alle Zertifizierungsanforderungen minimiert sich der Aufwand für die Erstellung der Safety-Pläne deutlich, da er für alle Normen adaptierbar ist. (Bild: Sysgo)

Ganzheitlicher Lösungsbaukasten

Sysgo ist ein Unternehmen, das Safety- und Security-Zertifizierungen des eigenen Betriebssystems PikeOS Sysgo ist ein Unternehmen, das Safety- und Security-Zertifizierungen des eigenen Betriebssystems PikeOS sowie kundenspezifische I/O und hardwarenahe Treiber entwickelt und somit einen solchen Masterplan vollumfänglich unterstützt. Zusätzlich unterstützt das Unternehmen dieses Prinzip bei kundenspezifischen Lösungen auch innerhalb der Systemintegration. Zudem bietet es mit PikeOS ein Echtzeit-Betriebssystem und Type 1 Echtzeit-Hypervisor Bundle an, das bereits in vielen Branchen nach den höchsten Sicherheitsstufen der funktionalen Sicherheit zertifiziert wurde und dessen Separationkernel der Version 5.1.3 zudem nachweislich höchste Security-Levels bis hin zum Common Criteria Evaluation Assurance Level EAL 5+ erreicht. Das Zusammenspiel von Mixed-Critical-Applikationen ist bereits in den Safety & Security Masterplänen eingearbeitet und im Rahmen von Kundenprojekten der gesamte Prozess umfassend durch Beratungs- und Schulungsangebote flankiert, sodass OEM schneller und sicherer ans Ziel kommen, als wenn sie eigenständig versuchen, ihr spezifisches Lösungspaket auf Basis heterogener Komponenten zu schnüren. Schlussendlich ist es der Applikationscode, der wettbewerbsentscheidend ist.

Sie möchten gerne weiterlesen?

Unternehmen

SYSGO GmbH

Am Pfaffenstein 8
55270 Klein-Winternheim
Germany