Einführung in die Common Criteria

Transkript

1 Proseminar Entwicklung sicherer Software Wintersemester 2008/2009 Einführung in die Common Criteria von Robert Fels Betreuer: Dipl. Medieninf. Martin Gruhn 22. März 2009 Zusammenfassung Die Bewertung von Sicherheitseigenschaften eines IT-Produkts stellt sowohl für die Anwender, als auch für die Entwickler ein wichtiges Anliegen dar. Die Anwender müssen der Sicherheit des Produkts vertrauen können und die Hersteller die Qualität ihrer Produkte gewährleisten können. Dieses Problem versuchen die Common Criteria(CC) als internationaler Standard zur Evaluation und Zertifizierung von IT-Produkten zu lösen. Die Anwender bzw. Hersteller können mit Hilfe von Schutzprofilen und Klassen ihre konkreten Vorstellungen von den Sicherheitsanforderungen ihres Produkts definieren. Die evaluierten Produkte erhalten am Ende der Evaluierung eine Bewertungsstufe von 1 bis 7. Diese Stufen sind für die Anwender ein guter Vergleichs-und Bewertungsmaßstab und für die Entwickler ein nützliches Mittel zur Qualitätssicherung der Produkte. Trotz einiger Mängel stellen die Common Criteria ein gutes Rahmenwerk zur Überprüfung und Entwicklung sicherer IT-Produkte dar. 1

2 Inhaltsverzeichnis 1 Einleitung Begriffe zur CC Die Zertifizierung Geschichte und Entstehung 4 3 Zweck und Ziele 5 4 Aufbau und Inhalt Teil1: Instruction and General Model Schutzprofile Die Klassenhierarchie und Sicherheitsvorgaben Teil 2: Securty Functional Requirements Teil 3: Security Assurance Requirements Vertrauenswürdigkeitsstufen Kritik 9 6 Fazit 9 Literatur 10 2

3 1 Einleitung IT-Produkte und das Vertrauen in deren Sicherheit spielen in den letzten Jahrzehnten sowohl in der Wirtschaft als auch für Privathaushalte eine immer wichtigere Rolle. Der Markt an IT Sicherheitsprodukten ist sehr vielfältig und der Kunde steht vor der schwierigen Entscheidung, das geeignete Produkt zu finden. Die meisten Abnehmer sind jedoch nicht in der Lage, zu bewerten, zu welchem Grad ein Produkt die erwünschten Sicherheitsanforderungen erfüllt oder nicht. Aus diesem Grund benötigt man Kriterien zur Bewertung der Sicherheit von IT-Produkten mit Sicherheitseigenschaften. Diese Kriterien sollten auf Grund der wachsenden Globalisierung international anerkannt sein, um einen weltweiten Vergleich von IT-Produkten zu gewährleisten. Um diesen Anforderungen gerecht zu werden, wurden die Common Criteria entwickelt. Dieser Abschnitt dient zur Einführung in die Common Criteria. Hierzu werde ich Begriffe einführen, die zum besseren Verständnis der Thematik benötigt werden. Zudem werde ich noch detaillierter auf die Zertifizierung eines Produkts eingehen. 1.1 Begriffe zur CC Zunächst zum Begriff Common Criteria (CC) selbst. Der offizielle Name der CC lautet im Deutschen Gemeinsame Kriterien für die Prüfung und Bewertung der Sicherheit von Informationstechnik. Sie stellen ein weit verbreiteten Sicherheitskriterienkatalog zur Evaluation und Zertifizierung von IT-Produkten bzw. Systemen mit Sicherheitseigenschaften dar. Im Folgenden werde ich IT-Produkte und Systeme mit Sicherheitseigenschaften nur noch Produkte nennen und weitere Begriffe aus der Sicht der IT-Sicherheit definieren. Sicherheitskriterienkataloge sind Standards, die mögliche Sicherheitseigenschaften bzw. Sicherheitsanforderungen von Produkten auflisten. Ein Standard ist eine allgemein anerkannte Regel oder Richtlinie zur Lösung eines Sachverhaltes. In unserem Fall ist die Evaluation und Zertifizierung der Sicherheit eines Produkts dieser Sachverhalt. Die erwähnten Sicherheitsanforderungen sind elementare Eigenschaften eines Produkts und Voraussetzungen, die eine gewisse Sicherheit und deren Nachweis erst ermöglichen. Solche Anforderungen können je nach Produkt variieren. Unter der oben genannten Evaluation versteht man die Prüfung und Bewertung der Sicherheitsanforderungen eines Produkts durch eine unabhängige, dritte Instanz. 1.2 Die Zertifizierung Die Zertifizierung ist ein Verfahren, bei dem eine dritte Instanz die Sicherheitseigenschaften schriftlich bestätigt. Dieses Zertifizierungsverfahren wird auf Basis der Kriterienkataloge ausgeführt und besteht aus der eigentlichen Evaluation und der Ausstellung eines Zertifikats. Die Sicherheitseigenschaften, die Bewertung der Wirksamkeit der Sicherheitsmechanismen und die Evaluierungsstufe des Produktss sind in dem ausgestellten Zertifikat enthalten. 3

4 Die Evaluation und die Ausstellung des Zertifikats erfolgt durch eine staatliche oder staatlich anerkannte Prüfstelle. In Deutschland werden die Zertifikate von dem Bundesamt für Sicherheit in der Informationstechnik (BSI) ausgestellt und von einer anerkannten Prüfstelle, wie z.b. dem TÜV, evaluiert. In den USA ist die National Security Agency (NSA) für die Evaluierung zuständig. Die Zertifikate werden in allen Ländern, die sich an dem Abkommen zur gegenseitigen Anerkennung(engl. Common Criteria Recognition Arrangement, CCRA) beteiligen, anerkannt. Mitglieder des Abkommens sind z.b. die USA, Kanada, Frankreich, Deutschland, Großbritannien, Japan und Australien. Alle derzeitigen Mitglieder sind auf der offiziellen Internetseite[1] zu finden. 2 Geschichte und Entstehung Abbildung 1: Überblick über die Entstehung der Common Criteria Der erste Kriterienkatalog zur Bewertung von IT-Sicherheit wurde 1985 vom Verteidigungsministerium der USA veröffentlicht: die Trusted Computer System Evaluation Criteria (TCSEC). Aufgrund der Farbe des Umschlags sind sie auch als Orange Book bekannt. Das Orange Book war eine wichtige Grundlage für alle nachfolgenden Kriterienkataloge. Es wurde aber eher für militärische Zwecke entwickelt und berücksichtigte die Anforderungen im kommerziellen Bereich nur unzureichend. Daraufhin entwickelten sich in den USA noch weitere Kriterienkataloge, bekannt als Rainbow Series[2]. Auch europäische Länder, wie England, Frankreich und Deutschland (Grünbuch) erschufen 1989 ihre eigenen Sicherheitskriterienkataloge. Um eine einheitliche Evaluierung und Zertifizierung in Europa zu gewährleisten, schlossen sich 1991 die europäischen Kriterien zu den Technology Security Evaluation Criteria (ITSEC) zusammen wurden dann der Entwurf der Ferderal Criteria der USA und 1993 die kanadischen Kriterien (CTCPEC) veröffentlicht. Die Common Criteria entstanden als eine Weiterentwicklung und Harmonisierung der europäischen ITSEC-Kriterien, der TCSEC bzw. Federal Criteria der USA und den kanadischen Kriterien(CTCPEC). Diesbezüglich flossen einige Modelle und Prinzipien in die CC mit ein oder wurden angepasst. Die Version 1.0 wurde 1996 veröffentlicht und 1999 als ISO/IEC Standard anerkannt. Damit wurde der Grundstein für eine international anerkannte Zertifizierung von Produkten gelegt. In der Abbildung 1 ist die Entstehung der CC vom Orange Book bis zur heutigen Version 3.1 anschaulich dargestellt. Detailliertere Informationen zu den genannten historischen Kriterien finden Sie in den Werken von Eckert[3] und Fischer-Hübner[2]. 4

5 3 Zweck und Ziele Die Zielgruppen der CC sind im Wesentlichen die Anwender, die Entwickler und die Evaluatoren eines Produkts. Für die Entwickler stellen die CC vor allem ein hervorragendes Mittel zur Qualitätssicherung dar. Sie können sich so ihre angepriesenen Sicherheitsfunktionen bestätigen lassen. Überdies können sie ihre Produkte auf der Grundlage von Schutzprofilen verbessern und bei der Überprüfung aufkommende Schwachstellen beseitigen. Im Allgemeinen werden die Produkte direkt unter den Richtlinien der CC entwickelt. Gemäß diesem Paper der BSI[4] fungiert die CC also auch als ein Leitfaden zur Entwicklung von Produkten. Aus Anwendersicht sichert die Zertifizierung eines Produkts nach der CC ein gewisses Maß an Vertrauen, da die Sicherheitsanforderungen des Produkts objektiv bestätigt wurden. Ohne diese Schutzzusicherung gäbe es nur die Möglichkeit, den Angaben der Hersteller zu vertrauen und das Produkt auf eigene Gefahr zu nutzen. Ein elementarer Zweck der CC ist, Produkte auf der ganzen Welt vergleichbar zu machen. Somit wird dem Anwender die Auswahl des geeigneten Produkts zumindest ein wenig erleichtert. Darüber hinaus sollen die CC helfen, die nötigen Sicherheitseigenschaften und die Qualität der Sicherheit für die entsprechende Bedrohungslage und den Wert der Daten zu bestimmen. Die Evaluatoren nutzen die Kriterien als Leitfaden für die Evaluierung und Zertifizierung und bestimmen am Ende des Prozesses die Evaluationsstufe des Produkts. Die CC stellt also auch eine Metrik für die Sicherheit eines Produkts dar. Ich habe bereits Ihnen vielleicht unbekannte Begriffe, wie Schutzprofil und Evaluationsstufe, verwendet. Auf diese werde ich im Abschnitt 4 näher eingehen. 4 Aufbau und Inhalt Die CC besteht aus drei Teilen: instruction and general model, security functional requirements und security assurance requirements. Jene drei Teile sind auf der offiziellen Internetseite[5] als PDF-Dateien zu finden. Ich gehe als erstes auf allgemeine Modelle und die Konzepte, wie zum Beispiel Schutzprofile, Sicherheitsvorgaben und die Klassenhierarchie der Sicherheitsanforderungen, ein. Anschließend werde ich darlegen, wie die Sicherheitsanforderungen eines Produkts dargestellt und unterteilt werden. 4.1 Teil1: Instruction and General Model Im ersten Teil werden die Prinzipien und Konzepte der CC vorgestellt. Außerdem erhält man einen Überblick über die erforderlichen Unterlagen für die Evaluation. Das Produkt, das zertifiziert werden soll, heißt Evaluationsgegenstand (EVG) (engl. Target of Evaluation,TOE). Wie man an den Teilabschnitten der CC erkennen kann, werden die Sicherheitsanforderungen in funktionale Anforderungen und Anforderungen an die Vertrauenswürdigkeit unterteilt. Wie kann man diese Anforderungen unterscheiden? 5

6 Die funktionalen Anforderungen spiegeln die eigentlichen Sicherheitsfunktionen eines EVG wieder. Diese Funktionen sind Maßnahmen, um die Risiken, die aus den Bedrohungen und Eigenschaften des EVG folgen, zu minimieren. Die Anforderungen an die Vertrauenswürdigkeit schaffen die Grundlage, den Sicherheitseigenschaften eines EVG überhaupt vertrauen zu können. Die objektive Überprüfung und Bewertung dieser Eigenschaften und weiterer Aspekte soll ein gewisses Maß an Vertrauen gewährleisten. Der strukturelle Aufbau der CC lässt sich im Wesentlichen mit drei Begriffen beschreiben: Klassenhierarchie der Sicherheitsanforderungen, Schutzprofile und Sicherheisvorgaben. Auf diese elementaren Elemente möchte ich anschließend eingehen Schutzprofile Ein Schutzprofil (engl. Protection Profile, PP) ist eine Menge von Sicherheitsanforderungen für eine bestimmte Produktkategorie. Sie bieten eine anerkannte Lösung für Standard-Sicherheitsprobleme einer Produktgruppe [6]. In den Schutzprofilen werden die Anforderungen an die Funktionalität und an die Vertrauenswürdigkeit zusammengefasst. Die Anwender können auf diese Weise ihre Bedürfnisse zur IT-Sicherheit in Form von präzisen Sicherheitskonzepten darlegen und definieren. Für die Hersteller stellt ein Schutzprofil ein sinnvolles, am Markt erwünschtes Konzept für ein Produkt dar, das auch als Vorlage für die Entwicklung dieses Produkts dienen kann. Die Berücksichtigung von Schutzprofilen bei der Produkt- und Systementwicklung erleichtert die Evaluierung und führt zu Produkten, die in besonderem Maße den anwenderspezifischen Anforderungen entsprechen. Durch die Verwendung von Schutzprofilen wird daher der Aufwand bei der Erstellung von Sicherheitsvorgaben für konkrete IT-Produkte erheblich reduziert[7]. Spezielle Schutzprofile existieren zum Beispiel für die Produktgruppen Firewalls, Betriebssysteme, Datenbanken und Smardcarts Die Klassenhierarchie und Sicherheitsvorgaben Die Sicherheitsanforderungen werden hierarchisch in Form von Klassen Familien Komponenten beschrieben. Die Komponenten enthalten dabei eine Menge von Sicherheitsanforderungen, die allgemein anerkanntes Expertenwissen repräsentieren. In Abbildung 2 auf der nächsten Seite stelle ich den Zusammenhang anschaulich dar. Ein weiteres zentrales Konzept der CC sind die Sicherheitsvorgaben (engl. Security Target, ST). Sie stellen die Gesamtheit der Sicherheitsanforderungen eines EVG dar und können somit Schutzprofile und zusätzlich noch weitere Sicherheitsanforderungen enthalten. Diese müssen nicht unbedingt Teil der CC-Komponenten sein und können auch selbst definiert werden. Somit kann auch auf Bedrohungen durch die Umgebung des EVG, wie z.b. natürlichen Bedrohungen, und auf Anforderungen von neuartigen, speziellen Produktkategorien eingegangen werden. Der Zusammenhang zwischen den Anforderungsklassen, den Schutzprofilen und den Sicherheitsvorgaben wird in Abbildung 2 nochmals deutlich. 6

7 Abbildung 2: Die Darstellung von Anforderungen in Klassen, Zusammenhang mit Schutzprofilen und Sicherheitsvorgaben 4.2 Teil 2: Securty Functional Requirements Der zweite Teil beinhaltet die funktionalen Anforderungen, die an ein EVG gestellt werden können. Diese sind, wie ich im Unterabschnitt zuvor schon erläutert habe, hierarchisch in Klassen, Familien und Komponenten unterteilt. Die Funktionsklassen beginnen mit F, für function, und die Familiennamen ergeben sich aus ihrer englischen Erläuterung. Die Komponenten werden durch eine Nummerierung dargestellt. Hier ist ein kleines Beispiel für eine Funktionskomponente für die Erstellung eines kryptografischen Schlüssels: FCS_CKM.1: Cryptographic key generation Es gibt 11 Funktionsklassen. Sie betreffen zum Beispiel die Sicherheitsprotokollierung (FAU), Kommunikation (FCO), Kryptographische Unterstützung (FCS), Identifikation und Authentisierung (FIA), den Schutz der Benutzerdaten (FDP) und Sicherheitsfunktionen (FPT) und den EVG Zugriff (FTA). In [3] finden sie die restlichen Funktionsklassen und deren ausführliche Beschreibung. 4.3 Teil 3: Security Assurance Requirements Analog zu den Funktionsanforderungen werden im 3. Teil die Vertraulichkeitsanforderungen mit Hilfe der genannten Klassenhierarchie beschrieben. Alle Klassennamen beginnen diesmal mit A, für assurance, und die Komponenten enthalten die jeweiligen Anforderungen. Hierbei wird zwischen den Anforderungen an den Entwickler 7

8 (D), an den Inhalt und die Form der Dokumentation (C) und den Anforderungen an den Evaluator (E) unterschieden. Auch hier möchte ich Ihnen ein kleines Beispiel für eine Entwickleranforderung geben[5]: ATE_FUN.1.2D: The developer shall provide test documentation. Es existieren 7 Klassen, die die Auslieferung und Betrieb (ADO), Entwicklung (ADV), Qualität der Handbücher (AGD), Funktionstests(ATE) und die Schwachstellenbewertung (AVA) betreffen. Weitere Informationen hierzu gibt es wieder im Eckert[3]. Die Vertrauenswürdigkeitskomponenten eines EVG werden am Ende der Evaluation zusammengefasst. Somit kann dem EVG ein gewisser Grad an Vertraulichkeit, in Form einer Vertrauenswürdigkeitsstufe (Evaluationsstufe), zugewiesen werden Vertrauenswürdigkeitsstufen Die einzelnen Vertrauenswürdigkeitskomponenten werden am Ende zusammengefügt und ergeben eine Vertrauenswürdigkeitsstufe (Evaluation Assurance Level, EAL). EAL-1 stellt dabei die niedrigste und EAL-7 die höchste Stufe dar. Die Bewertung eines Produkts unter EAL-1(EAL-0) ist nicht vertrauenswürdig. Die Stufen sind hierarchisch geordnet, das heißt die höheren Stufen beinhalten auch die darunter liegenden. Mit dem Anstieg der Stufen steigt auch die Tiefe und Genauigkeit der Evaluation und Dokumentationen. Im Folgenden habe ich die EAL-Stufen mit ihrer Bedeutung und Produktbeispielen in einer Tabelle zusammengefasst. EAL-Stufe Beschreibung EVG EAL-1 funktionell getestet Windows Vista EAL-2 strukturell getestet Windows Mobile 6.1 EAL-3 methodisch getestet und überprüft IBM DB2 EAL-4 methodisch entwickelt, getestet und Windows XP SP 2, Suse durchgesehen Linux ES 10(4+) EAL-5 semiformal entworfen und getestet Infineon Smart Card IC(Controller) EAL-6 semiformal verifizierter Entwurf, getestet Green Hills Integrity- 178B(Betriebssystem) EAL-7 formal verifizierter Entwurf, getestet - Der Hersteller legt im Allgemeinen die EAL-Stufe fest, nach der er evaluieren möchte. So hat zum Beispiel Microsoft sich dazu entschlossen, Windows Vista vorerst nach EAL-1 evaluieren zu lassen. Zu den genauen Definitionen der EAL-Stufen kann ich den Kriterienkatalog(CC)[5] selbst empfehlen. Dort werden die Stufen sehr detailliert beschrieben. Letztendlich geben die EAL-Stufen den Grad der Vertrauenswürdigkeit an und bilden so eine Metrik für die Sicherheit eines EVG. In [8] wird deutlich, dass die EAL-Stufen 5 bis 7 nur für Produkte, die schon im voraus mit tiefgreifenderen Sicherheitstechniken entworfen wurden, bestimmt sind. Die meiste kommerzielle Software wird jedoch nicht von Grund in dieser Weise entwickelt, sondern im Nachhinein mit Patches und wöchentlichen Updates nachgerüstet. Dies 8

9 hat zur Folge, dass gängige Software, wie Windows XP und SUSE Linux, nie über EAL-4 hinaus kommen. Dass es nicht unmöglich ist, ein Betriebssystem jenseits der EAL-4-Stufe zu entwickeln, hat der Hersteller Green Hills gezeigt. Integrity-178B wurde 2008 als erstes Betriebssystem nach EAL-6 evaluiert und soll hauptsächlich für militärische und medizinische Anwendungen, aber auch für Unternehmen geeignet sein. 5 Kritik Zum Abschluss möchte ich noch kurz auf Aspekte der CC eingehen, die stark kritisiert werden. Ross Anderson, Professor an der Cambridge Universität, geht diesbezüglich in seinem Buch Security Engineering[9] auf einige negative Aspekte der CC ein. Zum einen ist die Zertifizierung sehr teuer und aufwendig. Eine EAL-4-Evaluation kann von $ bis $ kosten und ein bis zwei Jahre andauern. Die Evaluatoren der BSI müssen laut Kostenverordnung[10] mit bis zu 84e pro Stunde honoriert werden. Resultierend aus den hohen Kosten und der langen Dauer ist die Reevaluation eines Produkts eher unwahrscheinlich. Außerdem kritisiert Anderson, dass die CC einen zu fokussierten Blick auf die technischen Features eines Produkts verfolgt. Wichtige Kriterien wie Bedienbarkeit, Brauchbarkeit des Produkts, sowie die Motivation und Fähigkeiten der Nutzer werden überhaupt nicht berücksichtigt. Ein System ist nur sicher, so lange die Verantwortlichen verantwortungsvoll damit umgehen. Ein gut geschütztes, verschlüsseltes Passwort bringt zum Beispiel wenig, wenn der Inhaber das Passwort am Bildschirm anbringt. Ein weiteres Problem habe ich im Abschnitt auf der vorherigen Seite schon erläutert. Die Evaluierungsstufen 5 bis 7 sind für kommerzielle Produkte kaum zu erreichen, weil dies wirtschaftlich gesehen für viele Unternehmen nicht rentabel wäre. 6 Fazit Nach dem Lesen dieser Arbeit haben Sie die Kenntnisse, um sich mit den CC näher zu beschäftigen, erworben. Sie haben einen kleinen historischen Überblick über die Entstehung erhalten und kennen die Zwecke der CC. Außerdem haben Sie die wesentlichen Modelle und Prinzipien der CC kennengelernt und anhand der Kritiken erfahren, dass die CC nicht ganz perfekt sind. Die Common Criteria stellen trotz aller Kritik ein gutes Rahmenwerk für die Entwicklung und Überprüfung sicherer Software dar. Die Anwender bzw. Hersteller können mit Hilfe von Schutzprofilen und Klassen ihre Sicherheitsanforderungen spezifizieren. Die EAL-Stufen bilden für die Hersteller ein gutes Mittel zur Qualitätssicherung und für die Anwender einen Bewertungsmaßstab für die Vertrauenswürdigkeit der Produkte. Auf Grund des standardisierten Verfahrens ist so die internationale Vergleichbarkeit von IT-Produkten gewährleistet. 9

10 Literatur [1] THE-COMMON-CRITERIA-RECOGNITION-ARRANGEMENT: offizielle CC- Homepage, Mitglieder. members.html. Version: 2008 [2] FISCHER-HÜBNER, Simone: IT-Security and Privacy. Springer, 2001 [3] ECKERT, Claudia: IT-Sicherheit. Oldenburg, 2006 [4] BSI: Leitfaden zur IT-Sicherheit. pdf. Version: 2008 [5] THE-COMMON-CRITERIA-RECOGNITION-ARRANGEMENT: Die offizielle Seite zur CC. Version: 2008 [6] BSI: Faltblatt Schutzprofile. F26SchutzprofileCC.pdf. Version: 2008 [7] BSI: IT-Sicherheitszertifizierung. zert/ancczer.htm. Version: [8] VOLKAMER, Melanie: Zum Nutzen hoher Zertifizierungsstufen nach den Common Criteria ( ) (VPN). l06129w1q /. Version: 2007 [9] ANDERSON, Ross: Security Engineering. Wiley, 2001 [10] BSI: Kostenverordnung zur CC. bsi-kostv_2005/bjnr html. Version: