Common Criteria: Unterschied zwischen den Versionen
Keine Bearbeitungszusammenfassung |
|||
| Zeile 14: | Zeile 14: | ||
{| class="wikitable sortable options" | {| class="wikitable sortable options" | ||
|- | |- | ||
! Organisation !! Nummer | ! Organisation !! Nummer | ||
|- | |- | ||
| EN ISO/IEC || 15408 | | EN ISO/IEC || 15408 | ||
| Zeile 26: | Zeile 26: | ||
== Vorgehensmodell == | == Vorgehensmodell == | ||
; Die Common Criteria unterscheiden zwischen der [[Funktionalität (Technik)|Funktionalität]] (Funktionsumfang) des betrachteten Systems und der [[Vertrauenswürdigkeit]] ([[Qualität]]). | ; Die Common Criteria unterscheiden zwischen der [[Funktionalität (Technik)|Funktionalität]] (Funktionsumfang) des betrachteten Systems und der [[Vertrauenswürdigkeit]] ([[Qualität]]). | ||
* Die Unterscheidung zwischen der Funktionalität eines Systems auf der einen Seite und dem Vertrauen, das durch eine Prüfung in diese Funktionalität entstehen kann, ist eines der wesentlichen Paradigmen der Common Criteria. | * Die Unterscheidung zwischen der Funktionalität eines Systems auf der einen Seite und dem Vertrauen, das durch eine Prüfung in diese Funktionalität entstehen kann, ist eines der wesentlichen Paradigmen der Common Criteria. | ||
* Die Vertrauenswürdigkeit wird nach den Gesichtspunkten der Wirksamkeit der verwendeten [[Methode (Softwaretechnik)|Methoden]] und der [[Korrektheit (Informatik)|Korrektheit]] der [[Implementierung]] betrachtet. | * Die Vertrauenswürdigkeit wird nach den Gesichtspunkten der Wirksamkeit der verwendeten [[Methode (Softwaretechnik)|Methoden]] und der [[Korrektheit (Informatik)|Korrektheit]] der [[Implementierung]] betrachtet. | ||
* Das Vorgehen kann als rückgekoppeltes [[Wasserfallmodell]] verstanden werden. | * Das Vorgehen kann als rückgekoppeltes [[Wasserfallmodell]] verstanden werden. | ||
; Idealerweise wird zunächst eine von fertigen Produkten unabhängige Sicherheitsbetrachtung durchgeführt, die zur Erstellung eines allgemeinen [[Schutzprofil]]s führt. | ; Idealerweise wird zunächst eine von fertigen Produkten unabhängige Sicherheitsbetrachtung durchgeführt, die zur Erstellung eines allgemeinen [[Schutzprofil]]s führt. | ||
* Aus diesem Sicherheitskatalog können dann für bestimmte Produkte gezielt [[Sicherheitsvorgaben]] erarbeitet werden, gegen die dann die Evaluierung gemäß CC durchgeführt wird. | * Aus diesem Sicherheitskatalog können dann für bestimmte Produkte gezielt [[Sicherheitsvorgaben]] erarbeitet werden, gegen die dann die Evaluierung gemäß CC durchgeführt wird. | ||
* Dabei wird die geforderte Vertrauenswürdigkeit, die ''Prüftiefe'', im Allgemeinen gemäß EAL (Evaluation Assurance Level, s. u.) festgelegt. | * Dabei wird die geforderte Vertrauenswürdigkeit, die ''Prüftiefe'', im Allgemeinen gemäß EAL (Evaluation Assurance Level, s. u.) festgelegt. | ||
* Eine Angabe der Prüftiefe ohne zugrunde liegende funktionale Sicherheitsanforderungen ist sinnlos. | * Eine Angabe der Prüftiefe ohne zugrunde liegende funktionale Sicherheitsanforderungen ist sinnlos. | ||
* Vor allem die Nennung der EAL-Stufen ohne weitere Angaben hat sich durchgesetzt, was vielfach zu Irritationen und hitzigen Debatten führt. | * Vor allem die Nennung der EAL-Stufen ohne weitere Angaben hat sich durchgesetzt, was vielfach zu Irritationen und hitzigen Debatten führt. | ||
; Im Dezember 1999 sind die Common Criteria zum International Standard [[International Organization for Standardization|ISO]]/[[International Electrotechnical Commission|IEC]] 15408 erklärt worden. | ; Im Dezember 1999 sind die Common Criteria zum International Standard [[International Organization for Standardization|ISO]]/[[International Electrotechnical Commission|IEC]] 15408 erklärt worden. | ||
* Der deutsche Anteil an dieser Arbeit wird u. a. vom [[IT-Sicherheitsverfahren|DIN NIA-01-27 IT-Sicherheitsverfahren]] betreut. | * Der deutsche Anteil an dieser Arbeit wird u. a. vom [[IT-Sicherheitsverfahren|DIN NIA-01-27 IT-Sicherheitsverfahren]] betreut. | ||
| Zeile 48: | Zeile 48: | ||
=== ISO/IEC-Standard === | === ISO/IEC-Standard === | ||
; Seit 1994 war die ''International Organization for Standardization'' (ISO) gemeinsam mit dem CCEB bzw. dem Nachfolger CCIB bemüht, einen internationalen Standard zu entwickeln. | ; Seit 1994 war die ''International Organization for Standardization'' (ISO) gemeinsam mit dem CCEB bzw. dem Nachfolger CCIB bemüht, einen internationalen Standard zu entwickeln. | ||
* Durch die Verabschiedung der Norm [[ISO]]/[[International Electrotechnical Commission|IEC]] 15408 am 1. Dezember 1999 in mehreren Teildokumenten | * Durch die Verabschiedung der Norm [[ISO]]/[[International Electrotechnical Commission|IEC]] 15408 am 1. Dezember 1999 in mehreren Teildokumenten sind die Common Criteria ein allgemeiner und weltweit anerkannter Standard. | ||
* Im Jahr 2005 folgte die Version 2.3, im September 2006 ein Versionssprung auf 3.1. | |||
* Neue Projektsponsoren sind seitdem Australien, Neuseeland, Japan und Spanien. | Die Norm unterliegt den üblichen Änderungsverfahren der ISO. | ||
* Im Jahr 2005 folgte die Version 2.3, im September 2006 ein Versionssprung auf 3.1. | |||
* Neue Projektsponsoren sind seitdem Australien, Neuseeland, Japan und Spanien. | |||
Im September 2012 wurde die vierte Revision der Common Criteria 3.1 veröffentlicht, im April 2017 folgte Revision 5. | |||
== Zertifizierung == | == Zertifizierung == | ||
; Den Common Criteria liegt ein Vier-Augen-Prinzip zugrunde | == Zertifizierung == | ||
; Vier-Augen-Prinzip | |||
Den Common Criteria liegt ein Vier-Augen-Prinzip zugrunde | |||
* Kann dann bei einer Zertifizierungsstelle zertifiziert werden | * Kann dann bei einer Zertifizierungsstelle zertifiziert werden | ||
* | |||
Zertifizierungsstelle | |||
* Deutschland: [[Bundesamt für Sicherheit in der Informationstechnik|Bundesamt für Sicherheit in der Informationstechnik (BSI)]] | |||
== Internationale Anerkennung == | == Internationale Anerkennung == | ||
Eine Zertifizierung gemäß den Common Criteria ist international nach [[CCRA]] bis zum EAL2 und nach [[SOGIS-MRA]] bis zum EAL 4 (siehe unten) gegenseitig anerkannt. | Eine Zertifizierung gemäß den Common Criteria ist international nach [[CCRA]] bis zum EAL2 und nach [[SOGIS-MRA]] bis zum EAL 4 (siehe unten) gegenseitig anerkannt. | ||
* Höhere EALs müssen international nicht anerkannt werden, haben aber in der privaten Wirtschaft wegen ihrer enormen Komplexität ohnehin kaum praktische Bedeutung. | * Höhere EALs müssen international nicht anerkannt werden, haben aber in der privaten Wirtschaft wegen ihrer enormen Komplexität ohnehin kaum praktische Bedeutung. | ||
* Innerhalb von Europa sind innerhalb des „SOGIS-Abkommens“ und innerhalb bestimmter technischer Gebiete auch Zertifizierungen bis EAL 7 unter Umständen anerkannt. | * Innerhalb von Europa sind innerhalb des „SOGIS-Abkommens“ und innerhalb bestimmter technischer Gebiete auch Zertifizierungen bis EAL 7 unter Umständen anerkannt. | ||
== Paradigma der Kriterien == | == Paradigma der Kriterien == | ||
; Das grundsätzliche Paradigma der Common Criteria ist die Trennung der Betrachtung von Funktionalität und Vertrauenswürdigkeit. | ; Das grundsätzliche Paradigma der Common Criteria ist die Trennung der Betrachtung von Funktionalität und Vertrauenswürdigkeit. | ||
* Grundsätzlich erfolgt durch die Kriterien keine Vorgabe, dass eine bestimmte Funktionalität umgesetzt werden muss oder dass diese mit einer bestimmten Vertrauenswürdigkeit geprüft werden muss. | * Grundsätzlich erfolgt durch die Kriterien keine Vorgabe, dass eine bestimmte Funktionalität umgesetzt werden muss oder dass diese mit einer bestimmten Vertrauenswürdigkeit geprüft werden muss. | ||
* Beide Aspekte werden zu Beginn der Evaluation vom Hersteller des Produkts in einem Dokument, dem „Security Target“, definiert. | * Beide Aspekte werden zu Beginn der Evaluation vom Hersteller des Produkts in einem Dokument, dem „Security Target“, definiert. | ||
| Zeile 74: | Zeile 82: | ||
; Im Gegensatz zu anderen Normen sind die Funktionalitätsklassen nicht hierarchisch gegliedert | ; Im Gegensatz zu anderen Normen sind die Funktionalitätsklassen nicht hierarchisch gegliedert | ||
* Stattdessen beschreibt jede Klasse eine bestimmte Grundfunktion der Sicherheitsarchitektur, die getrennt bewertet werden muss. | * Stattdessen beschreibt jede Klasse eine bestimmte Grundfunktion der Sicherheitsarchitektur, die getrennt bewertet werden muss. | ||
; Wichtige Funktionalitätsklassen | ; Wichtige Funktionalitätsklassen | ||
| Zeile 105: | Zeile 113: | ||
; Auswahl | ; Auswahl | ||
* Grundsätzlich obliegt die Auswahl der Funktionalität, die ein zu prüfendes System bereitstellen soll, dem Hersteller. | * Grundsätzlich obliegt die Auswahl der Funktionalität, die ein zu prüfendes System bereitstellen soll, dem Hersteller. | ||
* Es fällt in seinen Verantwortungsbereich, diese Funktionalität mit den anderen beteiligten Parteien – insbesondere dem Kunden – abzustimmen. | * Es fällt in seinen Verantwortungsbereich, diese Funktionalität mit den anderen beteiligten Parteien – insbesondere dem Kunden – abzustimmen. | ||
* Im Rahmen einer Evaluation nach Common Criteria werden prinzipiell nur solche Funktionen geprüft, die der Hersteller in seinem „Security Target“ modelliert hat. | * Im Rahmen einer Evaluation nach Common Criteria werden prinzipiell nur solche Funktionen geprüft, die der Hersteller in seinem „Security Target“ modelliert hat. | ||
; Bei der Auswahl von SFR aus Teil II der Common Criteria sind gewisse Rahmenbedingungen zu beachten. | ; Bei der Auswahl von SFR aus Teil II der Common Criteria sind gewisse Rahmenbedingungen zu beachten. | ||
* So pflegt Teil II der CC auch Abhängigkeiten zwischen SFRs, die bei der Auswahl beachtet werden müssen. | * So pflegt Teil II der CC auch Abhängigkeiten zwischen SFRs, die bei der Auswahl beachtet werden müssen. | ||
* Wird z. B. ein SFR zur Beschreibung einer Zugriffskontrollpolitik auf Daten verwendet, schreibt die Abhängigkeit vor, dass auch SFRs zur Authentisierung der Nutzer zu verwenden sind. | * Wird z. B. ein SFR zur Beschreibung einer Zugriffskontrollpolitik auf Daten verwendet, schreibt die Abhängigkeit vor, dass auch SFRs zur Authentisierung der Nutzer zu verwenden sind. | ||
; Kollektionen von SFRs werden zu [[Schutzprofil]]en zusammengefasst, die den typischen Funktionsumfang bestimmter Produkte (z. B. [[Firewall]]s, [[Smartcard]]s etc.) beschreiben. | ; Kollektionen von SFRs werden zu [[Schutzprofil]]en zusammengefasst, die den typischen Funktionsumfang bestimmter Produkte (z. B. [[Firewall]]s, [[Smartcard]]s etc.) beschreiben. | ||
* Solche Schutzprofile werden klassischerweise von Herstellerverbänden oder großen Kunden geschrieben, um ihre Anforderungen an eine bestimmte Klasse von Produkten auszudrücken. | * Solche Schutzprofile werden klassischerweise von Herstellerverbänden oder großen Kunden geschrieben, um ihre Anforderungen an eine bestimmte Klasse von Produkten auszudrücken. | ||
=== Vertrauenswürdigkeit === | === Vertrauenswürdigkeit === | ||
; Die Common Criteria definieren sieben Stufen der [[Vertrauenswürdigkeit]] (Evaluation Assurance Level, EAL1-7), die die Korrektheit der [[Implementierung]] des betrachteten Systems bzw. | ; Die Common Criteria definieren sieben Stufen der [[Vertrauenswürdigkeit]] (Evaluation Assurance Level, EAL1-7), die die Korrektheit der [[Implementierung]] des betrachteten Systems bzw. | ||
* die ''Prüftiefe'' beschreiben. | * die ''Prüftiefe'' beschreiben. | ||
* Mit steigender Stufe der Vertrauenswürdigkeit steigen die Anforderungen an die Tiefe, in der der Hersteller sein Produkt beschreiben muss und mit dem das Produkt geprüft wird. | * Mit steigender Stufe der Vertrauenswürdigkeit steigen die Anforderungen an die Tiefe, in der der Hersteller sein Produkt beschreiben muss und mit dem das Produkt geprüft wird. | ||
; Übersicht über die ''Evaluation Assurance Levels'' | ; Übersicht über die ''Evaluation Assurance Levels'' | ||
| Zeile 175: | Zeile 183: | ||
== Methodik der Bewertung für die Zertifizierung == | == Methodik der Bewertung für die Zertifizierung == | ||
; Ergänzend zu den Common Criteria wurde von den beteiligten Gremien und Einrichtungen eine Zertifizierungsmethodik entwickelt, die die Ergebnisse von Zertifizierungen nachvollziehbar und vergleichbar machen soll. | ; Ergänzend zu den Common Criteria wurde von den beteiligten Gremien und Einrichtungen eine Zertifizierungsmethodik entwickelt, die die Ergebnisse von Zertifizierungen nachvollziehbar und vergleichbar machen soll. | ||
* Derzeit (Stand 2007) sind sie für die Teile 1 und 2 ausgeführt und analog zu den EAL 1–4 aufgebaut. | * Derzeit (Stand 2007) sind sie für die Teile 1 und 2 ausgeführt und analog zu den EAL 1–4 aufgebaut. | ||
== Kritik == | == Kritik == | ||
; Den Common Criteria liegt ein sehr formaler Ansatz zu Grunde, der für die internationale Anerkennung der Zertifikate als Basis erforderlich ist. | ; Den Common Criteria liegt ein sehr formaler Ansatz zu Grunde, der für die internationale Anerkennung der Zertifikate als Basis erforderlich ist. | ||
* Dies führt zu der häufigen Kritik, dass in Prüfungen nach Common Criteria zu viel Papier und zu wenig Produkt geprüft wird. | * Dies führt zu der häufigen Kritik, dass in Prüfungen nach Common Criteria zu viel Papier und zu wenig Produkt geprüft wird. | ||
; Die Evaluierung nach CC ist generell recht aufwendig und nimmt einige Zeit in Anspruch. | ; Die Evaluierung nach CC ist generell recht aufwendig und nimmt einige Zeit in Anspruch. | ||
* Auch dies führt häufig zu Kritik an der Anwendung dieser Kriterien. | * Auch dies führt häufig zu Kritik an der Anwendung dieser Kriterien. | ||
; Im Jahr 2017 wurde die [[ROCA-Verwundbarkeit|ROCA-Schwachstelle]] in einer Liste von nach Common Criteria zertifizierten Chipkartenprodukten gefunden. | ; Im Jahr 2017 wurde die [[ROCA-Verwundbarkeit|ROCA-Schwachstelle]] in einer Liste von nach Common Criteria zertifizierten Chipkartenprodukten gefunden. | ||
* Die Schwachstelle machte mehrere Mängel des Common Criteria-Zertifizierungssystems deutlich: | * Die Schwachstelle machte mehrere Mängel des Common Criteria-Zertifizierungssystems deutlich: | ||
* Die Schwachstelle befand sich in einem selbst entwickelten [[RSA|RSA]]-Schlüsselgenerierungsalgorithmus, welcher nicht veröffentlicht und von der Kryptoanalyse-Community analysiert werden konnte. | * Die Schwachstelle befand sich in einem selbst entwickelten [[RSA|RSA]]-Schlüsselgenerierungsalgorithmus, welcher nicht veröffentlicht und von der Kryptoanalyse-Community analysiert werden konnte. | ||
* Die in Deutschland anerkannte Prüfstelle TÜV Informationstechnik GmbH ([[TÜViT]]) genehmigte jedoch seine Verwendung und die deutsche Zertifizierungsstelle BSI stellte Common Criteria-Zertifikate für die anfälligen Produkte aus. | * Die in Deutschland anerkannte Prüfstelle TÜV Informationstechnik GmbH ([[TÜViT]]) genehmigte jedoch seine Verwendung und die deutsche Zertifizierungsstelle BSI stellte Common Criteria-Zertifikate für die anfälligen Produkte aus. | ||
* In den [[Sicherheitsvorgaben]] des evaluierten Produkts wurde behauptet, dass die RSA-Schlüssel nach dem Standardalgorithmus erzeugt werden. | * In den [[Sicherheitsvorgaben]] des evaluierten Produkts wurde behauptet, dass die RSA-Schlüssel nach dem Standardalgorithmus erzeugt werden. | ||
* Als Reaktion auf diese Schwachstelle plant das BSI nun, die Transparenz zu verbessern, indem es verlangt, dass im Zertifizierungsbericht zumindest angegeben wird, wenn die implementierte proprietäre Kryptografie nicht genau mit einem empfohlenen Standard übereinstimmt. | * Als Reaktion auf diese Schwachstelle plant das BSI nun, die Transparenz zu verbessern, indem es verlangt, dass im Zertifizierungsbericht zumindest angegeben wird, wenn die implementierte proprietäre Kryptografie nicht genau mit einem empfohlenen Standard übereinstimmt. | ||
* Das BSI plant nicht, die Veröffentlichung des proprietären Algorithmus in irgendeiner Form zu verlangen. | * Das BSI plant nicht, die Veröffentlichung des proprietären Algorithmus in irgendeiner Form zu verlangen. | ||
* Obwohl die Zertifizierungsstellen inzwischen wissen, dass die in den Common Criteria-Zertifikaten spezifizierten Sicherheitsansprüche nicht mehr gelten, haben weder [[Agence nationale de la sécurité des systèmes d'information|ANSSI]] noch das BSI die entsprechenden Zertifikate widerrufen. | * Obwohl die Zertifizierungsstellen inzwischen wissen, dass die in den Common Criteria-Zertifikaten spezifizierten Sicherheitsansprüche nicht mehr gelten, haben weder [[Agence nationale de la sécurité des systèmes d'information|ANSSI]] noch das BSI die entsprechenden Zertifikate widerrufen. | ||
* Laut BSI kann ein Zertifikat nur dann zurückgezogen werden, wenn es unter falschen Voraussetzungen ausgestellt wurde, z. B. wenn sich herausstellt, dass falsche Nachweise vorgelegt wurden. | * Laut BSI kann ein Zertifikat nur dann zurückgezogen werden, wenn es unter falschen Voraussetzungen ausgestellt wurde, z. B. wenn sich herausstellt, dass falsche Nachweise vorgelegt wurden. | ||
* Nach der Ausstellung eines Zertifikats muss davon ausgegangen werden, dass die Gültigkeit des Zertifikats im Laufe der Zeit durch verbesserte und neu entdeckte Angriffe abnimmt. | * Nach der Ausstellung eines Zertifikats muss davon ausgegangen werden, dass die Gültigkeit des Zertifikats im Laufe der Zeit durch verbesserte und neu entdeckte Angriffe abnimmt. | ||
* Zertifizierungsstellen können Wartungsberichte ausstellen und sogar eine erneute Zertifizierung des Produkts durchführen. | * Zertifizierungsstellen können Wartungsberichte ausstellen und sogar eine erneute Zertifizierung des Produkts durchführen. | ||
* Diese Aktivitäten müssen jedoch vom Hersteller initiiert und unterstützt werden. | * Diese Aktivitäten müssen jedoch vom Hersteller initiiert und unterstützt werden. | ||
* Während mehrere nach Common Criteria zertifizierte Produkte von der ROCA-Schwachstelle betroffen waren, haben die Hersteller im Rahmen der Zertifizierung unterschiedlich reagiert. | * Während mehrere nach Common Criteria zertifizierte Produkte von der ROCA-Schwachstelle betroffen waren, haben die Hersteller im Rahmen der Zertifizierung unterschiedlich reagiert. | ||
* Für einige Produkte wurde ein Wartungsbericht herausgegeben, der besagt, dass nur RSA-Schlüssel mit einer Länge von 3072 und 3584 Bit ein Sicherheitsniveau von mindestens 100 Bit haben, während für andere Produkte im Wartungsbericht nicht erwähnt wird, dass die Änderung des [[Evaluierungsgegenstand]]s (EVG) die zertifizierte kryptografische Sicherheitsfunktionalität beeinträchtigt, sondern die Schlussfolgerung gezogen wird, dass die Änderung auf der Ebene der Anleitungsdokumentation liegt und keine Auswirkungen auf die Sicherheit hat. | * Für einige Produkte wurde ein Wartungsbericht herausgegeben, der besagt, dass nur RSA-Schlüssel mit einer Länge von 3072 und 3584 Bit ein Sicherheitsniveau von mindestens 100 Bit haben, während für andere Produkte im Wartungsbericht nicht erwähnt wird, dass die Änderung des [[Evaluierungsgegenstand]]s (EVG) die zertifizierte kryptografische Sicherheitsfunktionalität beeinträchtigt, sondern die Schlussfolgerung gezogen wird, dass die Änderung auf der Ebene der Anleitungsdokumentation liegt und keine Auswirkungen auf die Sicherheit hat. | ||
* Laut BSI hätten die Anwender der zertifizierten Endprodukte von den Herstellern über die ROCA-Schwachstelle informiert werden müssen. | * Laut BSI hätten die Anwender der zertifizierten Endprodukte von den Herstellern über die ROCA-Schwachstelle informiert werden müssen. | ||
* Diese Informationen erreichten jedoch nicht rechtzeitig die estnischen Behörden, die das anfällige Produkt auf mehr als 750.000 estnischen Personalausweisen eingesetzt hatten. | * Diese Informationen erreichten jedoch nicht rechtzeitig die estnischen Behörden, die das anfällige Produkt auf mehr als 750.000 estnischen Personalausweisen eingesetzt hatten. | ||
Version vom 25. April 2023, 09:23 Uhr
Common Criteria (CC) sind ein internationaler Standard zur Prüfung und Bewertung der Sicherheitseigenschaften von IT-Produkten
Beschreibung
- Common Criteria for Information Technology Security Evaluation
- Allgemeine Kriterien für die Bewertung der Sicherheit von Informationstechnologie
- Internationaler Standard zur Prüfung und Bewertung der Sicherheitseigenschaften von IT-Produkten
- ISO/IEC 15408
- Drei Teile
- Bereich: IT-Sicherheit
- Titel: Informationstechnik – IT-Sicherheitsverfahren – Evaluationskriterien für IT-Sicherheit
- Nationale Übernahmen
| Organisation | Nummer |
|---|---|
| EN ISO/IEC | 15408 |
| DIN EN ISO/IEC | 15408 |
| ÖVE/ÖNORM EN ISO/IEC | 15408 |
| SN EN ISO/IEC | 15408 |
Vorgehensmodell
- Die Common Criteria unterscheiden zwischen der Funktionalität (Funktionsumfang) des betrachteten Systems und der Vertrauenswürdigkeit (Qualität).
- Die Unterscheidung zwischen der Funktionalität eines Systems auf der einen Seite und dem Vertrauen, das durch eine Prüfung in diese Funktionalität entstehen kann, ist eines der wesentlichen Paradigmen der Common Criteria.
- Die Vertrauenswürdigkeit wird nach den Gesichtspunkten der Wirksamkeit der verwendeten Methoden und der Korrektheit der Implementierung betrachtet.
- Das Vorgehen kann als rückgekoppeltes Wasserfallmodell verstanden werden.
- Idealerweise wird zunächst eine von fertigen Produkten unabhängige Sicherheitsbetrachtung durchgeführt, die zur Erstellung eines allgemeinen Schutzprofils führt.
- Aus diesem Sicherheitskatalog können dann für bestimmte Produkte gezielt Sicherheitsvorgaben erarbeitet werden, gegen die dann die Evaluierung gemäß CC durchgeführt wird.
- Dabei wird die geforderte Vertrauenswürdigkeit, die Prüftiefe, im Allgemeinen gemäß EAL (Evaluation Assurance Level, s. u.) festgelegt.
- Eine Angabe der Prüftiefe ohne zugrunde liegende funktionale Sicherheitsanforderungen ist sinnlos.
- Vor allem die Nennung der EAL-Stufen ohne weitere Angaben hat sich durchgesetzt, was vielfach zu Irritationen und hitzigen Debatten führt.
- Der deutsche Anteil an dieser Arbeit wird u. a. vom DIN NIA-01-27 IT-Sicherheitsverfahren betreut.
- Die CC umfassen drei Teile
- Teil 1: Einführung und allgemeines Modell / Introduction and General Model
- Teil 2: Funktionale Sicherheitsanforderungen / Functional Requirements
- Teil 3: Anforderungen an die Vertrauenswürdigkeit / Assurance Requirements
- In Deutschland sind die Normteile als DIN-Normen DIN ISO/IEC 15408-1…3 veröffentlicht.
ISO/IEC-Standard
- Seit 1994 war die International Organization for Standardization (ISO) gemeinsam mit dem CCEB bzw. dem Nachfolger CCIB bemüht, einen internationalen Standard zu entwickeln.
- Durch die Verabschiedung der Norm ISO/IEC 15408 am 1. Dezember 1999 in mehreren Teildokumenten sind die Common Criteria ein allgemeiner und weltweit anerkannter Standard.
Die Norm unterliegt den üblichen Änderungsverfahren der ISO.
- Im Jahr 2005 folgte die Version 2.3, im September 2006 ein Versionssprung auf 3.1.
- Neue Projektsponsoren sind seitdem Australien, Neuseeland, Japan und Spanien.
Im September 2012 wurde die vierte Revision der Common Criteria 3.1 veröffentlicht, im April 2017 folgte Revision 5.
Zertifizierung
Zertifizierung
- Vier-Augen-Prinzip
Den Common Criteria liegt ein Vier-Augen-Prinzip zugrunde
- Kann dann bei einer Zertifizierungsstelle zertifiziert werden
Zertifizierungsstelle
Internationale Anerkennung
Eine Zertifizierung gemäß den Common Criteria ist international nach CCRA bis zum EAL2 und nach SOGIS-MRA bis zum EAL 4 (siehe unten) gegenseitig anerkannt.
- Höhere EALs müssen international nicht anerkannt werden, haben aber in der privaten Wirtschaft wegen ihrer enormen Komplexität ohnehin kaum praktische Bedeutung.
- Innerhalb von Europa sind innerhalb des „SOGIS-Abkommens“ und innerhalb bestimmter technischer Gebiete auch Zertifizierungen bis EAL 7 unter Umständen anerkannt.
Paradigma der Kriterien
- Das grundsätzliche Paradigma der Common Criteria ist die Trennung der Betrachtung von Funktionalität und Vertrauenswürdigkeit.
- Grundsätzlich erfolgt durch die Kriterien keine Vorgabe, dass eine bestimmte Funktionalität umgesetzt werden muss oder dass diese mit einer bestimmten Vertrauenswürdigkeit geprüft werden muss.
- Beide Aspekte werden zu Beginn der Evaluation vom Hersteller des Produkts in einem Dokument, dem „Security Target“, definiert.
Funktionalitätsklassen
- Teil II der Common Criteria enthält eine Reihe von sogenannten „Security Functional Requirements“ (SFR)
- Mit Hilfe dieser halbformalen Bausteine wird die Sicherheitsfunktionalität eines zu prüfenden Produkts beschrieben.
- Im Gegensatz zu anderen Normen sind die Funktionalitätsklassen nicht hierarchisch gegliedert
- Stattdessen beschreibt jede Klasse eine bestimmte Grundfunktion der Sicherheitsarchitektur, die getrennt bewertet werden muss.
- Wichtige Funktionalitätsklassen
| Klasse | Beschreibung |
|---|---|
| FAU | Sicherheitsprotokollierung |
| FCO | Kommunikation |
| FCS | Kryptographische Unterstützung |
| FDP | Schutz der Benutzerdaten |
| FIA | Identifikation und Authentisierung |
| FMT | Sicherheitsmanagement |
| FPR | Privatsphäre |
| FPT | Schutz der Sicherheitsfunktionen |
| FRU | Betriebsmittelnutzung |
| FTA | Schnittstelle |
| FTP | vertrauenswürdiger Pfad/Kanal |
- Auswahl
- Grundsätzlich obliegt die Auswahl der Funktionalität, die ein zu prüfendes System bereitstellen soll, dem Hersteller.
- Es fällt in seinen Verantwortungsbereich, diese Funktionalität mit den anderen beteiligten Parteien – insbesondere dem Kunden – abzustimmen.
- Im Rahmen einer Evaluation nach Common Criteria werden prinzipiell nur solche Funktionen geprüft, die der Hersteller in seinem „Security Target“ modelliert hat.
- Bei der Auswahl von SFR aus Teil II der Common Criteria sind gewisse Rahmenbedingungen zu beachten.
- So pflegt Teil II der CC auch Abhängigkeiten zwischen SFRs, die bei der Auswahl beachtet werden müssen.
- Wird z. B. ein SFR zur Beschreibung einer Zugriffskontrollpolitik auf Daten verwendet, schreibt die Abhängigkeit vor, dass auch SFRs zur Authentisierung der Nutzer zu verwenden sind.
- Kollektionen von SFRs werden zu Schutzprofilen zusammengefasst, die den typischen Funktionsumfang bestimmter Produkte (z. B. Firewalls, Smartcards etc.) beschreiben.
- Solche Schutzprofile werden klassischerweise von Herstellerverbänden oder großen Kunden geschrieben, um ihre Anforderungen an eine bestimmte Klasse von Produkten auszudrücken.
Vertrauenswürdigkeit
- Die Common Criteria definieren sieben Stufen der Vertrauenswürdigkeit (Evaluation Assurance Level, EAL1-7), die die Korrektheit der Implementierung des betrachteten Systems bzw.
- die Prüftiefe beschreiben.
- Mit steigender Stufe der Vertrauenswürdigkeit steigen die Anforderungen an die Tiefe, in der der Hersteller sein Produkt beschreiben muss und mit dem das Produkt geprüft wird.
- Übersicht über die Evaluation Assurance Levels
- Prüftiefen in anderen Kriterien
| CC EAL | Bedeutung | ITSEC E | BSI ITS Q | TCSEC |
|---|---|---|---|---|
| EAL1 | funktionell getestet | E0-E1 | Q0-Q1 | D-C1 |
| EAL2 | strukturell getestet | E1 | Q1 | C1 |
| EAL3 | methodisch getestet und überprüft | E2 | Q2 | C2 |
| EAL4 | methodisch entwickelt, getestet und durchgesehen | E3 | Q3 | B1 |
| EAL5 | semiformal entworfen und getestet | E4 | Q4 | B2 |
| EAL6 | semiformal verifizierter Entwurf und getestet | E5 | Q5 | B3 |
| EAL7 | formal verifizierter Entwurf und getestet | E6 | Q6 | A |
Methodik der Bewertung für die Zertifizierung
- Ergänzend zu den Common Criteria wurde von den beteiligten Gremien und Einrichtungen eine Zertifizierungsmethodik entwickelt, die die Ergebnisse von Zertifizierungen nachvollziehbar und vergleichbar machen soll.
- Derzeit (Stand 2007) sind sie für die Teile 1 und 2 ausgeführt und analog zu den EAL 1–4 aufgebaut.
Kritik
- Den Common Criteria liegt ein sehr formaler Ansatz zu Grunde, der für die internationale Anerkennung der Zertifikate als Basis erforderlich ist.
- Dies führt zu der häufigen Kritik, dass in Prüfungen nach Common Criteria zu viel Papier und zu wenig Produkt geprüft wird.
- Die Evaluierung nach CC ist generell recht aufwendig und nimmt einige Zeit in Anspruch.
- Auch dies führt häufig zu Kritik an der Anwendung dieser Kriterien.
- Im Jahr 2017 wurde die ROCA-Schwachstelle in einer Liste von nach Common Criteria zertifizierten Chipkartenprodukten gefunden.
- Die Schwachstelle machte mehrere Mängel des Common Criteria-Zertifizierungssystems deutlich:
- Die Schwachstelle befand sich in einem selbst entwickelten RSA-Schlüsselgenerierungsalgorithmus, welcher nicht veröffentlicht und von der Kryptoanalyse-Community analysiert werden konnte.
- Die in Deutschland anerkannte Prüfstelle TÜV Informationstechnik GmbH (TÜViT) genehmigte jedoch seine Verwendung und die deutsche Zertifizierungsstelle BSI stellte Common Criteria-Zertifikate für die anfälligen Produkte aus.
- In den Sicherheitsvorgaben des evaluierten Produkts wurde behauptet, dass die RSA-Schlüssel nach dem Standardalgorithmus erzeugt werden.
- Als Reaktion auf diese Schwachstelle plant das BSI nun, die Transparenz zu verbessern, indem es verlangt, dass im Zertifizierungsbericht zumindest angegeben wird, wenn die implementierte proprietäre Kryptografie nicht genau mit einem empfohlenen Standard übereinstimmt.
- Das BSI plant nicht, die Veröffentlichung des proprietären Algorithmus in irgendeiner Form zu verlangen.
- Obwohl die Zertifizierungsstellen inzwischen wissen, dass die in den Common Criteria-Zertifikaten spezifizierten Sicherheitsansprüche nicht mehr gelten, haben weder ANSSI noch das BSI die entsprechenden Zertifikate widerrufen.
- Laut BSI kann ein Zertifikat nur dann zurückgezogen werden, wenn es unter falschen Voraussetzungen ausgestellt wurde, z. B. wenn sich herausstellt, dass falsche Nachweise vorgelegt wurden.
- Nach der Ausstellung eines Zertifikats muss davon ausgegangen werden, dass die Gültigkeit des Zertifikats im Laufe der Zeit durch verbesserte und neu entdeckte Angriffe abnimmt.
- Zertifizierungsstellen können Wartungsberichte ausstellen und sogar eine erneute Zertifizierung des Produkts durchführen.
- Diese Aktivitäten müssen jedoch vom Hersteller initiiert und unterstützt werden.
- Während mehrere nach Common Criteria zertifizierte Produkte von der ROCA-Schwachstelle betroffen waren, haben die Hersteller im Rahmen der Zertifizierung unterschiedlich reagiert.
- Für einige Produkte wurde ein Wartungsbericht herausgegeben, der besagt, dass nur RSA-Schlüssel mit einer Länge von 3072 und 3584 Bit ein Sicherheitsniveau von mindestens 100 Bit haben, während für andere Produkte im Wartungsbericht nicht erwähnt wird, dass die Änderung des Evaluierungsgegenstands (EVG) die zertifizierte kryptografische Sicherheitsfunktionalität beeinträchtigt, sondern die Schlussfolgerung gezogen wird, dass die Änderung auf der Ebene der Anleitungsdokumentation liegt und keine Auswirkungen auf die Sicherheit hat.
- Laut BSI hätten die Anwender der zertifizierten Endprodukte von den Herstellern über die ROCA-Schwachstelle informiert werden müssen.
- Diese Informationen erreichten jedoch nicht rechtzeitig die estnischen Behörden, die das anfällige Produkt auf mehr als 750.000 estnischen Personalausweisen eingesetzt hatten.
Anhang
Siehe auch
Unterseiten
Sicherheit
Dokumentation
RFC
Man-Pages
Info-Pages
Links
Einzelnachweise
Projekt
Weblinks
- Überarbeitung im Rahmen der 7. CC-Konferenz
- Common Criteria beim Bundesamt für Sicherheit in der Informationstechnik (BSI)
- Common Criteria Official Website
- Inhaltsverzeichnis der DIN ISO/IEC 15408-1:2007-11 beim Beuth-Verlag
- Inhaltsverzeichnis der DIN ISO/IEC 15408-2:2007-11 beim Beuth-Verlag
- Inhaltsverzeichnis der DIN ISO/IEC 15408-3:2007-11 beim Beuth-Verlag
Testfragen
Testfrage 1
Antwort1
Testfrage 2
Antwort2
Testfrage 3
Antwort3
Testfrage 4
Antwort4
Testfrage 5
Antwort5