Die Motive für Cyberattacken spielen in der Common Criteria jedoch keine beziehungsweise nur eine untergeordnete Rolle, weil Akteuren Rollen zugewiesen werden, die sie als Gefahr greifbar machen. Es wird zwar unterschieden, ob ein Benutzer unwillentlich ein System kompromittiert oder ein Angreifer (von der Common Criteria als Threat Agent bezeichnet) bewusst ein System attackiert. Aber dies spielt nur insofern eine Rolle, als dass diese Kategorien unter dem Blickwinkel des Schadens und der zu „verteidigenden Assets“ (also konkret der Bestandteile eines Systems) betrachtet werden.

So läuft eine Zertifizierung nach Common Criteria ab

Nehmen wir an, ein Hersteller - Systemintegrator - von interaktiven Kiosken möchte eine neue Serie von Kiosken zertifizieren. Dieser Kiosk, bestehend aus Hardware (SoC, Zahlungsterminal und Display) und Software (Betriebssystem, Hardware-Abstraktionsschicht und Anwendungen für die Bestellung von Waren und die Bezahlung über das Netz), wird dann zu diesem Zweck in seiner Gesamtheit geprüft.

Wer nach Common Criteria zertifiziert, hat ein ganzes System, bzw. Embedded System/IT-Produkt (in der Common Criteria als Target of Evaluation, kurz TOE genannt), das gegen Schaden durch oben beschriebene Akteure geschützt werden soll. Dies umfasst gewöhnlich, aber nicht notwendigerweise die Hardware, die vor physischem Missbrauch wie Diebstahl, Manipulation und dergleichen geschützt, als auch die Software, die nach bestimmten Paradigmen evaluiert werden muss. Es können aber auch andere Sicherheitsziele ausgerufen werden.

Neben dem System-Integrator, gibt es eine weitere Instanz (in der Regel ein Prüflabor), die bei der Zertifizierung unterstützt sowie eine (meist staatliche) Autorität, die die Zertifizierung verleiht. Es werden alle denkbaren und plausiblen Akteure identifiziert, die mit dem System zu tun haben, wie die Benutzer (Kunden), Programmierer (die ja eventuell aus welchen Motiven auch immer einen Trojaner einbauen könnten), aber auch Menschen, die den Kiosk mutwillig beschädigen. Alle denkbaren Angriffe dieser Akteure werden benannt und in der Sprache der Common Criteria zugeordnet. Es werden Gegenmaßnahmen aufgezeigt, wie der Schaden solcher Angriffe bestenfalls ausgeschlossen oder minimiert werden kann, so dass die Bestandteile (Assets) geschützt sind. Eine Autorität (wie beispielsweise das staatliche deutsche Bundesamt für Sicherheit in der Informationstechnik (BSI)) überprüft in letzter Instanz, ob eine Zertifizierung verliehen werden kann und vergibt oder verweigert diese dann auch.

Die Philosophie der Common Criteria

Die Common Criteria ist eine aktuelle und regelmäßig gepflegte generische Sicherheitszertifizierung. Sie ist so angelegt, dass sie möglichst allgemein und damit möglichst überall passend eingesetzt werden kann im Gegensatz zu beispielsweise der spezifischen Sicherheitszertifizierung DO-356A / ED-203A, die für Avioniksysteme konzipiert wurde und auch nur dort (also in Flugzeugen) Anwendung findet. Die Common Criteria ist explizit so angelegt, dass Erkenntnisse aus der IT-Sicherheitsforschung in sie einfließen können und einfließen, da die Struktur flexibel genug ist, um erweitert bzw. modifiziert werden zu können. Die Flexibilität erlaubt auch, dass ein Großteil der Anforderungen für spezifische Zertifizierungen wie der DO-356A / ED-203A verwendet werden kann. So ist es einerseits möglich bereits zertifizierte Artefakte vergleichsweise bequem auf neue Projekte zu übertragen, ganz gleich welche spezifische Zertifizierung gewünscht ist und andererseits lässt sich ein so vorzertifiziertes System als Grundlage für neue Projekte nutzen. Das ergibt unter anderem für Betriebssystem-Hersteller Sinn, da hier nicht klar ist, ob das Betriebssystem Verwendung in einem Auto, einer Drohne, einem Industrieroboter, einem Exoskelett oder einem Satelliten findet.

Möchte nun beispielsweise ein Flugzeugbauer sein Avioniksystem nach DO-356A / ED-203A zertifizieren lassen, benötigt dafür ein Echtzeitbetriebssystem, weil Anwendungen also in einer bestimmten Zeit garantiert ein gewünschtes Ergebnis produzieren sollen (das nennen wir Determinismus und könnte beispielsweise sein, dass Seitenruder in einer bestimmten Zeit reagieren sollen, müssen und es werden), gibt es nur wenige Anforderungen, die nicht abgedeckt sind durch die Common Criteria. Tatsächlich teilt sich die DO-356A / ED-203A mit der Common Criteria insgesamt 32 Anforderungen, die ganz oder zumindest zum größten Teil übereinstimmen und nur 7 Anforderungen sind nicht anwendbar. Bei dem vergleichsweise neuen Standard ISO/SAE 21343, der für elektronische Systeme in Fahrzeugen konzipiert wurde, sind es 93 deckungsgleiche oder fast deckungsgleiche Anforderungen und nur 9, die nicht von der Common Criteria abgedeckt werden. Jede deckungsgleiche Anforderung kann zur entsprechenden Anforderung einer spezifischen Sicherheitszertifizierung gemappt werden. Dies ist kein Zufall: Die meisten spezifischen Sicherheitszertifizierungen gehen auf die Common Criteria zurück. Man kann sie durchaus als die Mutter der Sicherheitszertifizierungen schlechthin bezeichnen.

Um auf das Beispiel des Flugzeugbauers zurückzukommen: Da nun der Betrieb eines Seitenruders unmittelbaren Einfluss auf die funktionale Sicherheit hat, ist klar ersichtlich, dass in Zeiten von staatlichen Hackerattacken und Erpresserbanden, die damit drohen Flugzeuge abstürzen zu lassen, Cybersicherheit und funktionale Sicherheit nunmehr untrennbar miteinander verwoben sind. Dies ruft nach Software, die für Safety als auch für Security ausgelegt ist und durch die entsprechenden Zertifizierungen den integren Betrieb nachweisen kann. In diesem Falle ist also eine Zertifizierung nach DO-356A / ED-203A als auch nach der Safety-Norm DO-178C notwendig. Ein Systemintegrator, der nun nach einer geeigneten Grundlage für sein Projekt sucht, wird mit einem Betriebssystem sehr viel Zeit, Aufwand und Geld sparen, das gegen seinen Industrie-Safety-Standard zertifiziert ist (bzw. durch Zertifizierungskits bequem erreichbar ist) und darüber hinaus gegen die Common Criteria auf hohem Niveau zertifiziert ist um auch seinen industriespezifischen Cybersicherheitsstandard abzudecken.

Die Bewertung der Sicherheit

Die indirekte Vertrauensausweisung beruht auf der Tatsache, dass es in Fragen der IT-Security keine absoluten Sicherheiten geben kann. Während bei einem Safety-Level wie DAL A statistische (Ausfall-)Wahrscheinlichkeiten Vertrauen begründen, weil man nur die technischen Begebenheiten analysiert, ist für die Common Criteria und ganz allgemein die IT-Security der Faktor Mensch entscheidend, weil wir es mit einem Antagonisten zu tun haben, der anders als technische Systeme, willentlich Fehlverhalten eines Systems hervorrufen kann. Ein technisches System kann vielleicht ausfallen, aber es kann nichts gezielt dafür unternehmen, dass es ausfällt. Diesem Umstand und der Philosophie der Common Criteria ist die Tatsache geschuldet, dass offen mit allen Möglichkeiten kalkuliert wird. Das spiegelt sich in dem Verfahren wider, dass im Laufe der Evaluierung die Angreiferperspektive eingenommen wird und nach Schwachstellen gesucht wird (je nach Stufe) mittels Ansätzen wie Flaw Hypothesis Methodology, Pentesting und weiteren Maßnahmen.

Nichtsdestotrotz oder gerade wegen dieses Vorgehens, liefert die Common Criteria eine Art Blaupause bzw. einen Baukasten wie ein System so von Grund auf konstruiert werden kann, dass Schwachstellen möglichst vermieden werden können und Assets den bestmöglichen Schutz genießen. Je mehr Aufwand in die Evaluierung hiermit investiert wird, desto größer ist die Zuversicht in ein System. Dies spiegelt sich mit steigendem Niveau in den Stufen wider.

EAL-Stufen der Common Criteria

Will man eine der sieben EAL-Stufen erreichen, müssen bestimmte Bedingungen erfüllt werden. Zunächst: Die drei Dimensionen, die wichtig für die Einstufung eines Embedded Systems sind, sind der Umfang, die Tiefe und die Strenge. Mit Umfang ist schlicht gemeint wie groß der Teil des jeweiligen Embedded Systems ist (man kann nämlich auch lediglich Teilbereiche eines Embedded Systems zertifizieren lassen – die Common Criteria lässt einem die Freiheit zu zertifizieren, was man zertifizieren möchte). Die Tiefe gibt an wie feingranular die Betrachtung des Produkts vorgenommen wird, wie detailliert die Analyse ausgeführt wird. Die Strenge schließlich gibt an wie rigide die Evaluation vorgenommen wird. Dies reicht bis zu formalen Beweisen, dass etwas sicher ist. Nach einer vorgegebenen Matrix werden Klassen mit Unterfamilien aufgelistet, die jeweils Ziele und Anforderungen an das zu zertifizierende Embedded System erheben. Die drei Dimensionen sind hier der Kompass für das jeweilige Level der Klassen. Die Bereiche (man spricht hier von Klassen), die zu Rate gezogen werden, sind Entwicklung, Leitfaden-Dokumente, Lifecycle-Unterstützung, Security Target Evaluation (das Security Target ist das zentrale Dokument, mit dem der System-Integrator seine Bemühungen nachweist), Tests und Schwachstellenbewertung. Die Klasse Test beispielsweise enthält unter anderem die Unterfamilien Tiefe (ATE_DPT) und Funktionstests (ATE_FUN). Tiefe (ATE_DPT) ist dabei nicht zu verwechseln mit der vorherig angesprochenen Dimension Tiefe.

Die jeweiligen Stufen der Unterfamilien müssen für das Erreichen einer gewissen EAL-Stufe (mindestens) alle von der jeweiligen EAL-Stufe geforderten Höhen erreichen. Möchte man beispielsweise die Stufe EAL 5 erreichen, muss in der Klasse Test, bei der Unterfamilie Tiefe mindestens die Unterfamilien-Stufe 3 erreicht werden, was einem modularen Design entspricht während Stufe 1 einem Basis-Design entspricht. Für das Basic-Design der Stufe 1 wird lediglich eine (vergleichsweise oberflächliche) Beschreibung der Sicherheitsfunktionen (TSF) gefordert und dass diese wie beschrieben funktionieren. Auf Stufe 3 werden bereits für das TSF und für jedes deren Module detaillierte Beschreibungen eingefordert, die (interne) Funktionsweisen und Interfaces beschreiben und dass diese wie angegeben funktionieren. Umfang, Tiefe und Strenge sind hier größer. Mit der Offenlegung, das sagt die Common Criteria, steigt die Zuversicht, dass Fehler vermieden werden. So sind über alle Klassen hinweg bestimmte Teilziele zu erreichen, damit ein bestimmtes Level erreicht werden kann.

EAL-Stufen 3 oder 5 – Was ist da der Unterschied?

Die letztmalige Zertifizierung des PikeOS Separation Kernel erfolgte auf der Stufe EAL 3+ (das Pluszeichen gibt an, dass neben allen Stufen der Unterfamilien, die erreicht werden mussten zusätzliche Evaluierung stattfand mit optionalen Klassen, die sinnvoll im Kontext des Embedded Systems erschienen). Stufe EAL 3 gibt an, dass das Embedded System methodisch getestet und geprüft wurde. Dazu gehört beziehungsweise darunter versteht man ein vollständiges Security Target, in dem die Sicherheitsfunktionsanforderungen (SFR) analysiert wurden, eine Beschreibung der Sicherheits-Architektur des Embedded Systems um dessen Funktionalität zu verstehen, Interface-Beschreibungen sowie Leitfadendokumente. Daneben sind Funktions- und Pen-Tests und eine Schwachstellenanalyse erforderlich. Einige weitere Anforderungen müssen erfüllt werden wie ein Konfigurationsmanagement des Embedded Systems und der Nachweis von Secure Delivery Procedures. Die Common Criteria spricht von einem insgesamt moderaten Sicherheitsniveau für Entwickler und Anwender, das von unabhängiger Stelle bestätigt werden kann.

Der Separation Kernel von PikeOS hat nun die Stufe EAL 5+ erreicht in der Version 5.1.3. Die Stufe sieht unter anderem vor, dass neben den oben genannten Anforderungen, erstmalig verbindlich modulares Sicherheitsfeature-Design (TSF, TOE Security Functions) hinzukommt. Die TSFs umfassen dabei die Hardware, Software, Firmware (also die Hardware Abstraction Layer, was das BIOS oder Board Support Packages sein können), die den beschriebenen Anforderungen (Security Functional Requirements, SFRs) gerecht werden müssen. Der größte Unterschied besteht darin, dass das Embedded System nicht nur methodisch getestet und geprüft wurde, sondern strukturierter und damit analysierbarer entwickelt wurde und eine semiformale Beschreibung existiert.

Durch das Pluszeichen ( + ) wird im Falle von PikeOS bekundet, dass neben allen Anforderungen der Stufe EAL 5 außerdem (unter anderem) die optionalen Klassen AVA_VAN (Vulnerability Analysis), ADV_IMP (Implementation Representation), ALC_DVS (Development Security), ALC_CMC (CM Capabilities) auf der Höchststufe EAL 7 erreicht wurden. In anderen Worten: PikeOS hat punktuell EAL-7-Niveau. Insbesondere für die Vulnerability-Analysis-Klasse ist das ein starker Mehrwert für Systemintegratoren, weil nachgewiesen wurde, dass verbleibende Schwachstellen des TOEs nur ausnutzbar durch Angreifer sind mit dem Angriffspotenzial von (in der Sprache der Common Criteria) „beyond high“. Dies ist die höchstmögliche Einstufung. Sie richtet sich nach einem Punktestand, der durch Faktoren bestimmt wird wie dem Zeitaufwand für die Identifizierung und Ausnutzung (Elapsed Time), dem erforderlichen technischen Fachwissen, worunter nicht nur das Fachwissen, sondern auch die Anzahl der Angreifer gezählt wird (Expertise), der Kenntnis des Entwurfs und der Funktionsweise des TOEs (Knowledge of TOE), dem „Einbruchszeitfenster“ (Window of Opportunity) sowie der erforderlichen Ausrüstung wie IT-Hardware/Software oder sonstigen für die Ausnutzung erforderlichen Werkzeugen (Equipment).

Darüber hinaus erfordert EAL 5 ein umfassendes Konfigurationsmanagement des Embedded System, das auch einen gewissen Grad an Automation umfasst sowie eine vollständige Interface-Beschreibung. Die Common Criteria versichert, dass ein so entwickeltes Produkt (anders als bei EAL 3) nicht nur Attacken auf einem Basis-Level standhält, sondern moderatem Angriffspotenzial. Da es sich bei PikeOS dem Wesen nach um einen hartechtzeit-fähigen Separation Kernel handelt, der Applikationen sicher in Raum und Zeit (also in Partitionen und Abläufen) trennt, kann theoretisch ein Angreifer, der es geschafft hat, Zugriff auf eine Partition zu erlangen, keinen Zugriff auf eine weitere Partition erlangen. Er kann auch keine weitere Privilege Escalation herbeiführen, sondern hätte in diesem Fall nur Zugriff auf diese einzelne Applikation. Selbst das ist aber sehr unwahrscheinlich, da eben durch die geforderten und implementierten Sicherheitsfeatures ein sehr striktes Rechtemanagement existiert und daneben Mitigationstechniken wie Secure Boot oder eine Hardware-Software Vertrauenskette sowie weitere Features existieren.

Fazit

Auf der Stufe EAL 5 wird auch erstmalig ein gewisses Level von Security-Engineering-Techniken vorausgesetzt beim System-Integrator, deren Entwicklungskosten aber – das sagt die Common Criteria – sich nicht in unvernünftigen Sphären bewegen. Was das für das Endprodukt bedeutet, kann nur nach einer vorherigen Prüfung der Anforderungen genauer bestimmt werden. Aus den intensiven Bemühungen ein sicheres Produkt zu erschaffen, resultiert aber auch, das sagt die Common Criteria, dass hier hohe Sicherheitsanforderungen erfüllt werden und dies unabhängig bestätigt wird.

EAL 5 (und im Falle von PikeOS sogar EAL 5+) besetzt hier somit einen Sweet Spot zwischen Sicherheit und Wirtschaftlichkeit und bietet mit seinem reichen Funktionsumfang die Möglichkeiten moderne, vernetzte und sichere Embedded Systeme zu erschaffen.

Mehr Informationen unter: Common Criteria CertKits