Suchen

Safety und Security

Zertifizierung von Sicherheitsprodukten nach Common Criteria

Seite: 3/4

Common Criteria Überblick

Die Common Criteria verfolgen das Ziel, die Sicherheitsfunktionalität eines Produkts auf Wirksamkeit und Korrektheit auf vergleichbare Art und Weise prüfbar zu machen. Des Weiteren werden die im Produkt enthaltenen und evaluierten Sicherheitsmechanismen durch die CC-Zertifizierung transparent gemacht. Für die Durchführung einer CC-Zertifizierung gibt es mehrere Gründe.

Prinzipiell kann jeder Hersteller seine IT-Sicherheitsprodukte zertifizieren lassen. Ein CC-Zertifikat steigert das Vertrauen der Kunden und kann somit für Marketingzwecke eingesetzt werden. Die evaluierten Sicherheitseigenschaften und Sicherheitsfunktionalitäten (inkl. der Prüftiefe) sind nach der Evaluierung in den Sicherheitsvorgaben für das Produkt dokumentiert.

Bildergalerie

Es gibt jedoch Fälle, in denen ein Kunde bzw. ein Auftraggeber eine gewisse Sicherheitsfunktionalität fordert und ohne ein entsprechendes CC-Zertifikat das Produkt nicht für den gewünschten Zweck eingesetzt oder erfolgreich vermarktet werden kann. Beispiele hierfür sind hoheitliche Dokumente (z. B. elektronischer Reisepass) und Komponenten für die Telematikinfrastruktur im Gesundheitswesen.

Hier werden die Sicherheitsfunktionalität und die Prüftiefe explizit gefordert (z. B. durch die zuständigen Bundesbehörden). In diesen Situationen kommen sogenannte Schutzprofile (Protection Profile, PP) zum Einsatz, welche die Anforderungen konkret und vereinheitlicht spezifizieren. Möchte also ein Hersteller ein Produkt in einem solchen Marktsegment unterbringen und zertifizieren lassen, ist eine Konformität der Sicherheitsvorgaben zum gewünschten Schutzprofil erforderlich.

Die Common Criteria V3.1R4 bestehen aus vier Teilen: Part 1-3 (ISO/IEC 15408) [2] und CEM, der Common Methodology for Information Technology Security Evaluation (ISO/IEC 18045) [3]. Teil 1 beschreibt die Philosophie, die CC Konzepte und definiert die Begriffswelt. Des Weiteren wird genau spezifiziert, wie die Sicherheitsvorgaben und die Schutzprofile zu gestalten sind. Es wird nicht immer notwendigerweise ein gesamtes Produkt evaluiert.

Zur Abgrenzung der zu evaluierenden Sicherheitsfunktionalität wird in Teil 1 der CC das Konzept „Evaluierungsgegenstand“ (Target of Evaluation, TOE) eingeführt. Die Evaluierung umfasst daher nur genau die Sicherheitsfunktionalität, die sich im Kontext des TOEs befindet und für die im ST und/oder PP geeigneten Sicherheitsanforderungen aufgestellt sind. Erst wenn die Sicherheitsvorgaben stimmig und konsistent sind und der TOE genau definiert ist, kann die eigentliche Evaluierung beginnen.

Teil 2 beschreibt einen Katalog mit Anforderungen an die Sicherheitsfunktionalität (Security Functional Requirements, SFR) des TOEs. Diese Anforderungen sind im ST und PP zu verwenden. Bestimmte Teile der Anforderungen sind nicht spezifiziert und müssen spätestens im ST konkretisiert werden.

Die Anforderungen aus Teil 2 spiegeln allgemein anerkanntes und akzeptiertes Expertenwissen wider. Sollten die SFRs in einzelnen Situation nicht ausreichen, können diese erweitert oder neue SFRs nach einem in der CC festgeschriebenen Vorgehen definiert werden. Die SFRs sind in Klassen und Familien mit mindestens einer Komponente strukturiert.

Teil 3 beschreibt eine Sammlung von Anforderungen an die Vertrauenswürdigkeit (Security Assurance Requirements, SAR). Die SARs stellen Anforderungen an den Inhalt der Prüfnachweise sowie an die für die Evaluierung notwendigen Tätigkeiten der Hersteller und Evaluatoren dar. Mit den SARs werden unter anderem der Prüfumfang und die Prüftiefe festgelegt.

Daher sind die Anforderungen ebenfalls in das ST/PP aufzunehmen. Die Strukturierung erfolgt ähnlich der Strukturierung der SFRs. Um den Umgang mit SARs zu vereinfachen und eine verständliche Metrik für die Vertrauenswürdigkeit zu geben, werden zudem Vertrauenswürdigkeitskomponenten in Evaluationsstufen für Vertrauenswürdigkeit (Evaluation Assurance Level, EAL) zusammengefasst. Mit steigender Evaluierungsstufe erhöhen sich der Prüfaufwand und die Prüftiefe.

Teil 3 der CC beschreibt in Form von Vertrauenswürdigkeitskomponenten, welche Inhalte (Dokumentation, Tests, Source Code, etc.) geprüft werden und welche Tätigkeiten von den an der Zertifizierung beteiligten Entwicklern und Evaluatoren grob erwartet werden. Die CEM verfeinert die Aktivitäten der Evaluatoren und gibt eine methodische Anleitung für die Durchführung.

Nur eine einheitliche Evaluierungsmethodik ermöglicht die Anerkennung der Zertifikate im Rahmen bestimmter Abkommen. Als Beispiel sei hier die Familie AVA_VAN (Vulnerability Assessment) genannt. Teil 3 besagt, dass im Rahmen dieser Familie eine Schwachstelleanalyse je nach konkreter Komponente mit unterschiedlichem Umfang und unterschiedlicher Tiefe durchgeführt werden muss. Die CEM unterteilt die jeweilige Komponente in einzelne detaillierte Arbeitsanweisungen (Work Units, WU) und gibt methodische Hinweise.

So wird beispielsweise das Angriffspotential für die Ausnutzung einer potentiellen Schwachstelle klassifiziert (Basic, Enhanced-Basic, Moderate und High). Des Weiteren bietet die CEM einen Mechanismus zur Bewertung einer potentiellen Schwachstelle hinsichtlich des für das Ausnutzen benötigten Angriffspotentials. Basierend auf der Analyse der potentiellen Schwachstellen, der durchgeführten Penetrationstests und der anschließenden Bewertung kann systematisch hergeleitet werden, welche Angreifer mit welchem Angriffspotential der TOE abwehren kann.

Informationen zu konkreten Angriffen kann die CEM aufgrund der Vielfalt der Produkte nicht bieten. Im Rahmen vom SOGIS-MRA werden jedoch in speziellen technischen Domänen konkrete Angriffe auf bestimmte Produkttypen untersucht und als unterstützende Dokumente herausgegeben.

Besonderheiten der CC für eingebettete Systeme

Im Rahmen der CC werden sowohl Software- als auch Hardwareprodukte zertifiziert. Vertreter reiner Softwareprodukte sind beispielsweise Firewalls und Desktop/Server Betriebssysteme. Ein häufiger Produkttyp im Hardwarebereich ist die Smartcard mit hohen Anforderungen an die Sicherheit. Dieser Produkttyp kommt in vielfältigen Bereichen zur Anwendung. Aufgrund der vielen domänenspezifischen Besonderheiten der jeweiligen Produkttypen werden im SOGIS-MRA Kontext sogenannte technische Domänen definiert.

Bisher sind es „Smartcards and Similar Devices“ und „Hardware Devices with Security Boxes”. Innerhalb der technischen Domänen werden für diese Bereiche spezifische Interpretationen der CC sowie weitere unterstützende Dokumente herausgegeben, welche zum Teil bei der entsprechenden CC Zertifizierung verbindlich zu berücksichtigen sind. Nachfolgend werden einige Besonderheiten der technischen Domäne „Smartcards and Similar Devices“ vorgestellt:

Composite Evaluation:

Die Sicherheitschips (Basis für die Smartcard Produkte) werden üblicherweise zusammen mit unterschiedlichen Betriebssystemen und Anwendungen eingesetzt. Würden nun im Rahmen einer jeden Zertifizierung die Anwendung, das Betriebssystem und die Hardwareplattform (Sicherheitschip inkl. der Firmware) einer kompletten Zertifizierung unterzogen, so müsste die Hardwareplattform jedes Mal erneut evaluiert werden. Daher bedarf es einer zusammengesetzten Evaluierung und Zertifizierung.

Die CC bieten einen Kompositionsmechanismus in Form der Vertrauenswürdigkeitsklasse ACO. Dieser Mechanismus adressiert eine zusammengesetzte Evaluierung bestehend aus bereits zertifizierten Komponenten. Dieser Ansatz ist für den Smartcard Bereich jedoch nicht geeignet, da in dieser technischen Domäne die Anforderung besteht, eine nicht zertifizierte Anwendung in Kombination mit einer zertifizierten Plattform zu betrachten. Hierzu haben sich die SOGIS Partner auf den Ansatz „Composite Product Evaluation“ geeinigt [9]. Bild 3 in der Bildergalerie vergleicht die beiden Ansätze „ACO“ und „Composite Product Evaluation“.

Der Ansatz Composite Product Evaluation ermöglicht eine vertikale Integration zertifizierter Subsysteme im Rahmen einer Zertifizierung des Gesamtsystems. Die unterstützenden Dokumente liefern neben dem generellen Ansatz ebenfalls eine konkrete Erweiterung der Methodik. Viele der bereits existierenden Prüfaspekte wurden in diesem Kontext erweitert (Prüfung der Kompatibilität auf ST Ebene, Berücksichtigung der Auflagen zu Verwendung der Plattform, Integrationstests, etc.).

Um einen TOE als Plattform für weitere Zertifizierungen nutzen zu können, muss im Rahmen der Plattformzertifizierung ein zusätzlicher Prüfbericht erstellt werden: Evaluation Technical Report for Composition. Dieses Dokument bildet die Grundlage für die auf der bereits zertifizierten Plattform aufbauende Zertifizierung.

Berechnung des Angriffspotentials im Smartcard Bereich

Smartcard Produkte müssen üblicherweise immer einem Angreifer mit hohem Angriffspotential widerstehen. Die in der CEM beschriebene Methodik zur Berechnung des Angriffspotentials für das erfolgreiche Ausnutzen einer potentiellen Schwachstelle hat sich in dieser technischen Domäne als unzureichend herausgestellt. Die JHAS Gruppe (JIL Hardware Attacks Subgroup) hat daher einen an die Domäne angepassten Ansatz definiert [8]. Eine der Haupterweiterungen besteht aus der Separierung der Angriffsphasen. So werden die Phasen „Identification“ und „Exploitation“ eines Angriffs separat betrachtet und bewertet. Die Phase „Identification“ bezieht sich auf den Aufwand, der notwendig ist, einen Angriff zu entdecken und seine Machbarkeit zu demonstrieren.

Die Phase „Exploitation“ betrachtet den Aufwand für die tatsächliche Durchführung des Angriffs. Erst die gemeinsame Betrachtung dieser Phasen liefert die Gesamtsichtweise auf das für den Angriff notwendige Angriffspotential. Auch die Betrachtung sogenannter „Open Samples“ (Exemplare des Produkts mit eingeschränkten Sicherheitsmechanismen oder bekannten Geheimnissen) fließt in die Berechnung des Angriffspotentials ein.

Anforderungen an die Produktions- und Entwicklungsstandorte

Unabhängig von der für die Zertifizierung des Smartcard Produkts verwendeten EAL Stufe (meistens EAL4 und höher) werden üblicherweise noch folgende SAR Komponenten hinzugezogen (Augmentierung der EAL Stufe): AVA_VAN.5 – Resistenz gegen Angreifer mit hohem Angriffspotential und ALC_DVS.2 – Hohe Sicherheit der Entwicklungs- und Produktionsumgebungen, geeignet für Zertifizierungen nach AVA_VAN.5. Für solche Zertifizierungen ist die Anwendung des Dokuments „Minimum Site Security Requirements“ [7] verbindlich. Dieses Dokument beschreibt die Anforderungen an die Entwicklungs- und Produktionsstandorte.

Neben Anforderung an die Dokumentation der Nachweise werden konkrete Vorgaben bzgl. relevanter Aspekte, wie Organisation der Informations- und Datensicherheit, Asset-Management, Personalsicherheit, physische und umgebungsbezogene Sicherheit, Kommunikation und Betriebsabläufe sowie Management der Zugriffskontrolle gegeben.

(ID:44290807)