Autoren: Jaroslav Svacina, Nadja Menz, Thilo Ernst, Fraunhofer FOKUS<\/p>\n
Die Digitalisierung vieler gesellschaftlicher Bereiche schreitet mit enormer Geschwindigkeit voran. Unz\u00e4hlige Branchen setzen immer mehr auf Digitalisierung von Daten, Automatisierung von Prozessen sowie Vernetzung einzelner Komponenten und Systeme. Neben den entsprechenden Vorteilen bietet die aktuelle Entwicklung jedoch\u00a0vielf\u00e4ltige\u00a0neue Angriffspotentiale, welche, wenn richtig ausgenutzt, zu enormen finanziellen oder Personensch\u00e4den f\u00fchren k\u00f6nnen. Um das Vertrauen in die Sicherheit zu steigern, k\u00f6nnen Software- und Hardwareprodukte nach ISO\/IEC 15408 (Common Criteria) zertifiziert werden. Dieser Beitrag gibt einen \u00dcberblick \u00fcber die Zertifizierung von Sicherheitsprodukten nach Common Criteria und geht dabei gezielt auf einige Besonderheiten im Kontext der eingebetteten Systeme ein.<\/strong><\/p>\n Die zunehmende Digitalisierung und Technologisierung verschiedenster Bereiche bringen viele Vorteile f\u00fcr den Endkunden. So ist es beispielsweise m\u00f6glich, sein Eigenheim mit dem Smartphone zu steuern, aus dem vernetzten Fahrzeug auf Internetdienste zuzugreifen oder Daten \u00fcber die \u00e4rztliche Behandlung digitalisiert und in der Telematikinfrastruktur des Gesundheitswesens sicher zu verwalten. Der Einsatz neuer, komplexer und vernetzter Technologien bietet jedoch auch zus\u00e4tzliches Missbrauchspotential durch neue Sicherheitsl\u00fccken. Die b\u00f6swillige Ausnutzung solcher Sicherheitsl\u00fccken f\u00fchrt nicht selten zu erheblichen Sch\u00e4den.<\/p>\n Ein hohes Sicherheitslevel und das entsprechende Vertrauen in die Sicherheitsprodukte spielen daher sowohl in der Wirtschaft als auch im privaten Bereich eine immer wichtigere Rolle. Gerade der Wunsch nach Vertrauen in IT-Sicherheitsprodukte stellt den Kunden vor eine gewaltige Herausforderung. Viele Kunden sind oftmals nicht in der Lage zu erfassen, welche Sicherheitsfunktionalit\u00e4t ein Produkt bietet und inwieweit es die gew\u00fcnschten Sicherheitsanforderungen erf\u00fcllt. Des Weiteren ist es f\u00fcr den Kunden ohne eine unabh\u00e4ngige Expertenbegutachtung nahezu unm\u00f6glich in Erfahrung zu bringen, inwieweit die angegebenen Mechanismen korrekt umgesetzt sind. Mit den Common Criteria (ISO\/IEC 15408, Common Criteria for Information Technology Security Evaluation, kurz CC) [2] wurde ein Standard zur Bewertung und Pr\u00fcfung von Sicherheitsfunktionalit\u00e4ten von IT-Produkten nach gestaffelten Vertrauensw\u00fcrdigkeitsstufen geschaffen.<\/p>\n Die Common Criteria bieten Mittel zur Spezifikation der Sicherheitsanforderungen und eine einheitliche Methodik zur Evaluierung und Bewertung der umgesetzten Sicherheitsfunktionalit\u00e4ten. Im Rahmen spezieller Abkommen ist ein Common Criteria IT-Sicherheitszertifikat international anerkannt und erm\u00f6glicht die Gegen\u00fcberstellung der Sicherheitseigenschaften zertifizierter Produkte. Ein CC-Zertifikat liefert klare Aussagen bez\u00fcglich der behaupteten Sicherheitseigenschaften: Korrektheit der Sicherheitsfunktionalit\u00e4t, Wirksamkeit der Sicherheitsfunktionalit\u00e4t gegen Angriffe, Analyse der potentiellen Schwachstellen sowie entsprechende Pr\u00fcftiefe. Ausgehend von den Sicherheitsvorgaben (Security Target, ST), die dem Zertifikat zugrundeliegen, hat der Abnehmer des zertifizierten Produkts die M\u00f6glichkeit, die entsprechende Sicherheitsfunktionalit\u00e4t zu erfassen und zu entscheiden, inwieweit dieses Produkt f\u00fcr den geplanten Einsatzzweck und die vorgesehene Einsatzumgebung aus sicherheitstechnischer Sicht geeignet ist.<\/p>\n Abbildung 1 (siehe\u00a0PDF<\/a>) zeigt die Entstehungsgeschichte der Common Criteria. Die ersten Kriterien zur methodischen Bewertung der Sicherheit in der Informationstechnik waren Trusted Computer System Evaluation Criteria (TCSEC) des amerikanischen Verteidigungsministeriums. Im gleichen Zeitraum entstanden in Gro\u00dfbritannien, Deutschland und Frankreich vergleichbare Kriterien, die dann 1991 zusammen mit den TCSEC in die gemeinsamen europ\u00e4ischen Kriterien eingeflossen sind. Mit der voranschreitenden Globalisierung entstand der Wunsch nach einheitlichen und international anerkannten Kriterien, die in Form der Common Criteria entwickelt wurden. Die CC sind eine Weiterentwicklung und Harmonisierung der europ\u00e4ischen ITSEC-Kriterien, der TCSEC bzw. Federal Criteria der USA sowie der kanadischen Kriterien (CTCPEC) [1].<\/p>\n Die globalen Ziele der Common Criteria Mitgliedstaaten sind ein gemeinsames standardisiertes Kriterienwerk f\u00fcr IT-Sicherheitsprodukte sowie eine Evaluierungsmethodik, welche die Resultate vergleichbar macht. Diese Vergleichbarkeit bildet die Grundlage f\u00fcr die gegenseitige internationale Anerkennung der Zertifikate.<\/p>\n Die globale Zusammenarbeit findet im Kontext des Common Criteria Recognition Arrangement (CCRA) statt [4]. Auf dieser Ebene gibt es Arbeitsgruppen, welche unter anderem die Weiterentwicklung der Common Criteria und der begleitenden Dokumente forcieren sowie die gegenseitige Begutachtung der jeweiligen nationalen Zertifizierungsschemata organisieren und durchf\u00fchren. Im Kontext der CCRA gibt es L\u00e4nder, die ein Zertifikat ausstellen d\u00fcrfen (z.B. Deutschland, Frankreich, USA) und L\u00e4nder, die ein Zertifikat nur anerkennen d\u00fcrfen (z.B. Tschechische Republik, Israel). Das CCRA schlie\u00dft Zertifizierungen nach international abgestimmten Schutzprofilen (collaborative Protection Profile, cPP) sowie Zertifikate f\u00fcr Vertrauensw\u00fcrdigkeitskomponenten bis einschlie\u00dflich der Stufe EAL 2 ein.<\/p>\n Des Weiteren findet eine dedizierte Zusammenarbeit auf europ\u00e4ischer Ebene auf Grundlage des sogenannten SOGIS-MRA (Senior Official Group Information Systems Security \u2013 Mutual Recognition Agreement) statt [5]. Auch in diesem Kontext werden die teilnehmenden L\u00e4nder bzgl. ihrer Rolle klassifiziert. Es gibt einerseits L\u00e4nder, die Zertifikate ausstellen (und nat\u00fcrlich auch anerkennen), und L\u00e4nder, die Zertifikate nur anerkennen d\u00fcrfen. Dies gilt \u00fcblicherweise f\u00fcr Zertifikate bis zur EAL-Stufe 4. In bestimmten technischen Dom\u00e4nen werden innerhalb des SOGIS-MRA Zertifikate bis EAL 7 gegenseitig anerkannt. Dar\u00fcber hinaus sind die SOGIS-Arbeitsgruppen bem\u00fcht, eine Harmonisierung der Anwendung von CC-Sicherheitskriterien und der Vorgehensweisen in Zertifizierungsverfahren mittels sogenannter Joint Interpretation Library (JIL) Dokumente voranzutreiben. Diese Interpretationen werden dann in der Regel in das CCRA eingebracht und von der entsprechenden CCRA-Arbeitsgruppe (CC Development Board) als sogenannte CC-unterst\u00fctzende Dokumente verabschiedet.<\/p>\n In den jeweiligen L\u00e4ndern sind staatliche oder staatlich anerkannte Institutionen f\u00fcr die Zertifizierung nach CC verantwortlich. Die entsprechenden Prozesse und nationalen Charakteristika werden durch die nationalen Zertifizierungsschemata festgelegt. In Deutschland ist das Bundesamt f\u00fcr Sicherheit in der Informationstechnik (BSI) f\u00fcr die Zertifizierung von Produkten nach Common Criteria verantwortlich. Das BSI begleitet deren Evaluierung, so dass die Vergleichbarkeit der Bewertung sowie ein hohes Vertrauen in die Ergebnisse gew\u00e4hrleistet sind. Die rechtliche Grundlage zur Durchf\u00fchrung von Zertifizierungsverfahren bilden die Zertifizierungsverordnung und das Gesetz zur St\u00e4rkung der Sicherheit der Informationstechnik des Bundes. Abbildung 2 (siehe\u00a0PDF<\/a>) zeigt die in Deutschland am Zertifizierungsverfahren beteiligten Parteien, wobei die Beauftragung des CertLab von Fraunhofer FOKUS bei Bedarf durch das BSI erfolgt.<\/p>\n Der Prozess beginnt, indem der Produkthersteller einen Zertifizierungsantrag beim BSI stellt. Das BSI begutachtet den Antrag bez\u00fcglich grunds\u00e4tzlicher Zertifizierbarkeit und erteilt im positiven Fall eine Zertifizierungs-ID. Die Evaluierung (Pr\u00fcfung der Dokumentation, Audit der relevanten Standorte, unabh\u00e4ngige Korrektheitstests und Schwachstellenanalyse mit Penetrationstests) wird von einer unabh\u00e4ngigen Pr\u00fcfstelle durchgef\u00fchrt. Die Pr\u00fcfstelle muss zuvor vom BSI entsprechend akkreditiert worden sein. Die Resultate der einzelnen Pr\u00fcfaspekte werden in Form von Pr\u00fcfberichten dokumentiert. Die Zertifizierungsstelle (BSI) \u00fcberwacht die Prozesse und stellt eine einheitliche Vorgehensweise sowie die Vergleichbarkeit der Pr\u00fcfergebnisse sicher. Die Zertifizierungsstelle beh\u00e4lt sich vor, konkrete Interpretationen der CC sowie zus\u00e4tzliche Sicherheitsanforderungen, beispielsweise an Kryptoalgorithmen und Zufallszahlengeneratoren, in die Zertifizierung einflie\u00dfen zu lassen. Abschlie\u00dfend werden bei positiver Zertifizierungsentscheidung die Pr\u00fcfberichte abgenommen und das Zertifikat vom BSI ausgestellt.<\/p>\n Nachdem ein Hersteller beim BSI einen Antrag auf Zertifizierung gestellt hat, wird vom BSI bei Bedarf das CertLab im Fraunhofer FOKUS mit der Pr\u00fcfbegleitung des Verfahrens beauftragt. Ein Mitarbeiter des CertLab \u00fcbernimmt dabei im Auftrag des BSI gro\u00dfe Teile der Pr\u00fcfbegleitung. Die Verfahrenshoheit und insbesondere die Verantwortung f\u00fcr das Verfahren und das ausgestellte Zertifikat verbleiben zu jeder Zeit beim BSI.<\/p>\n Zu einigen Aspekten geben die Common Criteria keine Auskunft bzw. lassen Interpretationsspielr\u00e4ume offen. Daher publizieren die nationalen Zertifizierungsstellen und Standardisierungsgremien zus\u00e4tzliche Dokumente, die bestimmte Aspekte pr\u00e4zisieren oder v\u00f6llig neue Konzepte einf\u00fchren. Auf CCRA- und SOGIS-Ebene handelt es sich um die CC Supporting Documents und JIL Dokumente, auf nationaler Ebene sind es die Anwendungshinweise und Interpretationen zum Schema (AIS Dokumente) [6].<\/p>\n Die Common Criteria verfolgen das Ziel, die Sicherheitsfunktionalit\u00e4t eines Produkts auf Wirksamkeit und Korrektheit auf vergleichbare Art und Weise pr\u00fcfbar zu machen. Des Weiteren werden die im Produkt enthaltenen und evaluierten Sicherheitsmechanismen durch die CC-Zertifizierung transparent gemacht. F\u00fcr die Durchf\u00fchrung einer CC-Zertifizierung gibt es mehrere Gr\u00fcnde. Prinzipiell kann jeder Hersteller seine IT-Sicherheitsprodukte zertifizieren lassen. Ein CC-Zertifikat steigert das Vertrauen der Kunden und kann somit f\u00fcr Marketingzwecke eingesetzt werden. Die evaluierten Sicherheitseigenschaften und Sicherheitsfunktionalit\u00e4ten (inkl. der Pr\u00fcftiefe) sind nach der Evaluierung in den Sicherheitsvorgaben f\u00fcr das Produkt dokumentiert. Es gibt jedoch F\u00e4lle, in denen ein Kunde bzw. ein Auftraggeber eine gewisse Sicherheitsfunktionalit\u00e4t fordert und ohne ein entsprechendes CC-Zertifikat das Produkt nicht f\u00fcr den gew\u00fcnschten Zweck eingesetzt oder erfolgreich vermarktet werden kann. Beispiele hierf\u00fcr sind hoheitliche Dokumente (z.B. elektronischer Reisepass) und Komponenten f\u00fcr die Telematikinfrastruktur im Gesundheitswesen. Hier werden die Sicherheitsfunktionalit\u00e4t und die Pr\u00fcftiefe explizit gefordert (z.B. durch die zust\u00e4ndigen Bundesbeh\u00f6rden). In diesen Situationen kommen sogenannte Schutzprofile (Protection Profile, PP) zum Einsatz, welche die Anforderungen konkret und vereinheitlicht spezifizieren. M\u00f6chte also ein Hersteller ein Produkt in einem solchen Marktsegment unterbringen und zertifizieren lassen, ist eine Konformit\u00e4t der Sicherheitsvorgaben zum gew\u00fcnschten Schutzprofil erforderlich.<\/p>\n 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 und die CC-Konzepte und definiert die Begriffswelt. Des Weiteren wird genau spezifiziert, wie die Sicherheitsvorgaben und Schutzprofile zu gestalten sind. Es wird nicht immer notwendigerweise ein gesamtes Produkt evaluiert. Zur Abgrenzung der zu evaluierenden Sicherheitsfunktionalit\u00e4t wird in Teil 1 der CC das Konzept „Evaluierungsgegenstand“ (Target of Evaluation, TOE) eingef\u00fchrt. Die Evaluierung umfasst daher nur genau die Sicherheitsfunktionalit\u00e4t, die sich im Kontext des TOEs befindet und f\u00fcr 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.<\/p>\n Teil 2 beschreibt einen Katalog mit Anforderungen an die Sicherheitsfunktionalit\u00e4t (Security Functional Requirements, SFR) des TOEs. Diese Anforderungen sind im ST und PP zu verwenden. Bestimmte Teile der Anforderungen sind nicht spezifiziert und m\u00fcssen sp\u00e4testens 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\u00f6nnen 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.<\/p>\n Teil 3 beschreibt eine Sammlung von Anforderungen an die Vertrauensw\u00fcrdigkeit (Security Assurance Requirements, SAR). Die SARs stellen Anforderungen an den Inhalt der Pr\u00fcfnachweise sowie an die f\u00fcr die Evaluierung notwendigen T\u00e4tigkeiten der Hersteller und Evaluatoren dar. Mit den SARs werden unter anderem der Pr\u00fcfumfang und die Pr\u00fcftiefe festgelegt. Daher sind die Anforderungen ebenfalls in das ST\/PP aufzunehmen. Die Strukturierung erfolgt \u00e4hnlich der Strukturierung der SFRs. Um den Umgang mit SARs zu vereinfachen und eine verst\u00e4ndliche Metrik f\u00fcr die Vertrauensw\u00fcrdigkeit zu geben, werden zudem Vertrauensw\u00fcrdigkeitskomponenten in Evaluationsstufen f\u00fcr Vertrauensw\u00fcrdigkeit (Evaluation Assurance Level, EAL) zusammengefasst. Mit steigender Evaluierungsstufe erh\u00f6hen sich der Pr\u00fcfaufwand und die Pr\u00fcftiefe.<\/p>\n Teil 3 der CC beschreibt in Form von Vertrauensw\u00fcrdigkeitskomponenten, welche Inhalte (Dokumentation, Tests, Source Code etc.) gepr\u00fcft und welche T\u00e4tigkeiten von den an der Zertifizierung beteiligten Entwicklern und Evaluatoren grob erwartet werden. Die CEM verfeinert die Aktivit\u00e4ten der Evaluatoren und gibt eine methodische Anleitung f\u00fcr die Durchf\u00fchrung. Nur eine einheitliche Evaluierungsmethodik erm\u00f6glicht 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\u00fchrt werden muss. Die CEM unterteilt die jeweilige Komponente in einzelne detaillierte Arbeitsanweisungen (Work Units, WU) und gibt methodische Hinweise.<\/p>\n So wird beispielsweise das Angriffspotential f\u00fcr 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\u00fcr das Ausnutzen ben\u00f6tigten Angriffspotentials. Basierend auf der Analyse der potentiellen Schwachstellen, der durchgef\u00fchrten Penetrationstests und der anschlie\u00dfenden 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\u00e4nen konkrete Angriffe auf bestimmte Produkttypen untersucht und als unterst\u00fctzende Dokumente herausgegeben.<\/p>\n Im Rahmen der CC werden sowohl Software- als auch Hardwareprodukte zertifiziert. Vertreter reiner Softwareprodukte sind beispielsweise Firewalls und Desktop\/Server-Betriebssysteme. Ein h\u00e4ufiger Produkttyp im Hardwarebereich ist die Smartcard mit hohen Anforderungen an die Sicherheit. Dieser Produkttyp kommt in vielf\u00e4ltigen Bereichen zur Anwendung. Aufgrund der vielen dom\u00e4nenspezifischen Besonderheiten der jeweiligen Produkttypen werden im SOGIS-MRA Kontext sogenannte technische Dom\u00e4nen definiert. Bisher sind es „Smartcards and Similar Devices“ und „Hardware Devices with Security Boxes“. Innerhalb der technischen Dom\u00e4nen werden f\u00fcr diese Bereiche spezifische Interpretationen der CC sowie weitere unterst\u00fctzende Dokumente herausgegeben, welche zum Teil bei der entsprechenden CC-Zertifizierung verbindlich zu ber\u00fccksichtigen sind. Nachfolgend werden einige Besonderheiten der technischen Dom\u00e4ne „Smartcards and Similar Devices“ vorgestellt.<\/p>\n Composite Evaluation<\/strong><\/p>\n Die Sicherheitschips (Basis f\u00fcr die Smartcard-Produkte) werden \u00fcblicherweise zusammen mit unterschiedlichen Betriebssystemen und Anwendungen eingesetzt. W\u00fcrden nun im Rahmen einer jeden Zertifizierung die Anwendung, das Betriebssystem und die Hardwareplattform (Sicherheitschip inkl. der Firmware) einer kompletten Zertifizierung unterzogen, so m\u00fcsste die Hardwareplattform jedes Mal erneut evaluiert werden. Daher bedarf es einer zusammengesetzten Evaluierung und Zertifizierung. Die CC bieten einen Kompositionsmechanismus in Form der Vertrauensw\u00fcrdigkeitsklasse ACO. Dieser Mechanismus adressiert eine zusammengesetzte Evaluierung bestehend aus bereits zertifizierten Komponenten. Dieser Ansatz ist f\u00fcr den Smartcard-Bereich jedoch nicht geeignet, da in dieser technischen Dom\u00e4ne 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]. Abbildung 3 (siehe\u00a0PDF<\/a>) vergleicht die beiden Ans\u00e4tze „ACO“ und „Composite Product Evaluation“.<\/p>\n Der Ansatz Composite Product Evaluation erm\u00f6glicht eine vertikale Integration zertifizierter Subsysteme im Rahmen einer Zertifizierung des Gesamtsystems. Die unterst\u00fctzenden Dokumente liefern neben dem generellen Ansatz ebenfalls eine konkrete Erweiterung der Methodik. Viele der bereits existierenden Pr\u00fcfaspekte wurden in diesem Kontext erweitert (Pr\u00fcfung der Kompatibilit\u00e4t auf ST-Ebene, Ber\u00fccksichtigung der Auflagen zu Verwendung der Plattform, Integrationstests etc.). Um einen TOE als Plattform f\u00fcr weitere Zertifizierungen nutzen zu k\u00f6nnen, muss im Rahmen der Plattformzertifizierung ein zus\u00e4tzlicher Pr\u00fcfbericht erstellt werden: Evaluation Technical Report for Composition. Dieses Dokument bildet die Grundlage f\u00fcr die auf der bereits zertifizierten Plattform aufbauende Zertifizierung.<\/p>\n Berechnung des Angriffspotentials im Smartcard-Bereich<\/strong><\/p>\n Smartcard-Produkte m\u00fcssen \u00fcblicherweise immer einem Angreifer mit hohem Angriffspotential widerstehen. Die in der CEM beschriebene Methodik zur Berechnung des Angriffspotentials f\u00fcr das erfolgreiche Ausnutzen einer potentiellen Schwachstelle hat sich in dieser technischen Dom\u00e4ne als unzureichend herausgestellt. Die JHAS-Gruppe (JIL Hardware Attacks Subgroup) hat daher einen an die Dom\u00e4ne 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\u00fcr die tats\u00e4chliche Durchf\u00fchrung des Angriffs. Erst die gemeinsame Betrachtung dieser Phasen liefert die Gesamtsichtweise auf das f\u00fcr den Angriff notwendige Angriffspotential. Auch die Betrachtung sogenannter „Open Samples“ (Exemplare des Produkts mit eingeschr\u00e4nkten Sicherheitsmechanismen oder bekannten Geheimnissen) flie\u00dft in die Berechnung des Angriffspotentials ein.<\/p>\n Anforderungen an die Produktions- und Entwicklungsstandorte<\/strong><\/p>\n Unabh\u00e4ngig von der f\u00fcr die Zertifizierung des Smartcard-Produkts verwendeten EAL-Stufe (meistens EAL4 und h\u00f6her) werden \u00fcblicherweise noch folgende SAR-Komponenten hinzugezogen (Augmentierung der EAL-Stufe): AVA_VAN.5 \u2013 Resistenz gegen Angreifer mit hohem Angriffspotential und ALC_DVS.2 \u2013 Hohe Sicherheit der Entwicklungs- und Produktionsumgebungen, geeignet f\u00fcr Zertifizierungen nach AVA_VAN.5.<\/p>\n F\u00fcr solche Zertifizierungen ist die Anwendung des Dokuments „Minimum Site Security Requirements“ [7] verbindlich. Dieses Dokument beschreibt die Anforderungen an die Entwicklungs- und Produktionsstandorte. Neben Anforderungen 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\u00e4ufe sowie Management der Zugriffskontrolle, gegeben.<\/p>\n F\u00fcr den Nutzer bzw. Kunden ist es essenziell zu wissen, in welchem Ma\u00dfe er Zusicherungen \u00fcber die Sicherheit eines Produktes tats\u00e4chlich vertrauen kann. Die Common Criteria verfolgen daher das Ziel, dem Nutzer je nach EAL-Stufe eine dem Sicherheitsbedarf angepasste Menge von Belegen f\u00fcr die Vertrauensw\u00fcrdigkeit des Produkts an die Hand zu geben. Diese Belege zeigen, welche Ma\u00dfnahmen bei Entwicklung und Realisierung des Produkts getroffen wurden, um das Produkt sicher zu machen. Die so belegte Vertrauensw\u00fcrdigkeit ist nat\u00fcrlich an verschiedene Bedingungen gebunden. Beispielsweise muss der Nutzer stets in der Lage sein zu identifizieren, ob er tats\u00e4chlich das zertifizierte Produkt (in der zertifizierten Version) in der Hand hat. Auch Handb\u00fccher, Datenbl\u00e4tter und andere „Guidance-Dokumente“ werden im Rahmen der Common Criteria evaluiert. Dadurch wird sichergestellt, dass dem Nutzer alle n\u00f6tigen Informationen zur Verf\u00fcgung stehen, um das Produkt sachgem\u00e4\u00df und vor allem ohne (sonst evtl. selbst verursachte) Sicherheitsbeeintr\u00e4chtigungen einsetzen zu k\u00f6nnen.<\/p>\n Die CC ber\u00fccksichtigen auch die zuk\u00fcnftige Weiterentwicklung zertifizierter Produkte sowie die parallel stattfindende Evolution von Bedrohungen und Angriffstechniken. Wenn im Rahmen einer Produktweiterentwicklung sicherheitsrelevante \u00c4nderungen vorgenommen wurden, wird eine Re-Zertifizierung erforderlich. Bei wesentlichen \u00c4nderungen der Bedrohungslage wird analog ein Re-Assessment durchgef\u00fchrt. Hersteller sind weiterhin verpflichtet, der Zertifizierungsstelle neu bekannt gewordene Angriffe auf zertifizierte Produkte mitzuteilen. Dar\u00fcber hinaus ist generell der G\u00fcltigkeitszeitraum eines CC-Zertifikats stets zeitlich beschr\u00e4nkt.<\/p>\n Zur Sicherheitsbewertung werden h\u00e4ufig vertrauliche Informationen des Herstellers ben\u00f6tigt, die nicht einer breiteren \u00d6ffentlichkeit bekannt werden sollen. Die Vertraulichkeit solcher Informationen ist verl\u00e4sslich \u00fcber den gesamten Prozess einer CC-Zertifizierung gesichert: Nur ein kleiner Personenkreis bei der Zertifizierungsbeh\u00f6rde und der Pr\u00fcfstelle erh\u00e4lt Zugriff auf vertrauliche Produktinformationen. Besonders sensitives Material wird nur vor Ort beim Hersteller kurzzeitig eingesehen.<\/p>\n Der Hersteller entscheidet auch, ob der Zertifizierungsbericht ver\u00f6ffentlicht wird und welche Informationen darin enthalten sein d\u00fcrfen. F\u00fcr die Sicherheitsvorgaben besteht die M\u00f6glichkeit einer Ver\u00f6ffentlichung in reduzierter Form („ST-light“). Bei zertifizierten Plattformen, die als Basis einer sp\u00e4teren Composite-Evaluierung vorgesehen sind, kann ein reduzierter Pr\u00fcfbericht zur Verwendung im Kompositionsverfahren erstellt werden („ETR for Composition“). Dabei handelt es sich um ein nicht-\u00f6ffentliches Dokument, das jedoch zur Weitergabe an Beteiligte des Kompositionsverfahrens vorgesehen ist.<\/p>\n Gerade im Embedded-Bereich gewinnt die IT-Sicherheit aktuell und in naher Zukunft weiter an Bedeutung. Der in verschiedenen Branchen (Automotive, eHealth, Smart Energy und weitere) aufkommende Trend zur Verschiebung der Nachfrage in Richtung vertrauensw\u00fcrdiger Komponenten kann durch Common Criteria-Zertifizierung hervorragend unterst\u00fctzt werden. Es ist davon auszugehen, dass dieser Trend insbesondere f\u00fcr Zulieferer in den n\u00e4chsten Jahren immer mehr an Relevanz gewinnt. Umso wichtiger ist es, die Zusammenarbeit der jeweiligen Zertifizierungsschemata zu forcieren und weiterhin einen gemeinsamen internationalen Kurs zu verfolgen. Die Fortentwicklung von nationalen Protection Profiles hin zu collaborative Protection Profiles zeigt das gemeinsame Bestreben der Nationen im CCRA auf, die kontinuierliche gegenseitige Anerkennung von Zertifikaten zu sichern. Die cPP-Entwicklung wird von international Technical Communities (iTC) vorangetrieben. Die iTC umfassen alle relevanten Interessengruppen wie Produkthersteller, Endkunden, Zertifizierungsstellen und Pr\u00fcfstellen.<\/p>\n Die Zertifizierung nach Common Criteria sorgt f\u00fcr die Einhaltung bestimmter Standards bei der Realisierung von Sicherheitsfunktionalit\u00e4ten sowie bei der Verwendung von Kryptographie in IT-Sicherheitsprodukten. Die Zertifizierung erfordert offenkundig einen gewissen Aufwand, schafft jedoch einheitliche Sicherheitsma\u00dfst\u00e4be im wachsenden Markt f\u00fcr sichere Hardware- sowie Softwareprodukte. Die CC-Standards sind ein offenes Framework, das flexibel auf verschiedenste Anwendungsf\u00e4lle und Kosten\/Nutzen-Szenarien anwendbar ist und st\u00e4ndig weiterentwickelt wird. Die teilnehmenden L\u00e4nder arbeiten im Kontext der CCRA- und SOGIS-Abkommen sowohl an Konkretisierungen der CC f\u00fcr bestimmte technische Dom\u00e4nen als auch an der Optimierung der CC-Prozesse und Evaluierungst\u00e4tigkeiten. Dadurch wird sichergestellt, dass die aktuellen technologischen, organisatorischen und prozesstechnischen Entwicklungen ad\u00e4quat in den Common Criteria ber\u00fccksichtigt werden.<\/p>\n [1]\u00a0 Eckert, Claudia: IT-Sicherheit. Oldenburg, 2006<\/p>\n [2]\u00a0 Common Criteria for Information Technology Security Evaluation, Version 3.1, Rev. 4, September 2012.<\/p>\n Part 1: Introduction and general model \/ Part 2: Functional security components \/ Part 3: Assurance security components<\/p>\n [3]\u00a0 Common Methodology for Information Technology Security Evaluation, Version 3.1, Rev. 4, September 2012.<\/p>\n [4]\u00a0\u00a0About The Common Criteria<\/a>\u00a0(October 2015)<\/p>\n [5]\u00a0\u00a0SOGIS \u2013 Senior Officials Group Information Systems Security<\/a>\u00a0(October 2015)<\/p>\n [6]\u00a0\u00a0BSI: Anwendungshinweise und Interpretationen (AIS)<\/a>\u00a0(October 2015)<\/p>\n [7]\u00a0 JIL: Minimum Site Security Requirements, Version 1.1 (for trial use), July 2013<\/p>\n [8]\u00a0 JIL: Application of Attack Potential to Smartcards, Version 2.9, January 2013<\/p>\n [9]\u00a0 JIL: Composite product evaluation for Smart Cards and similar devices, Version 1.4, August 2015<\/p>\n Beitrag als PDF downloaden<\/strong><\/a><\/p>\n Wollen Sie sich auf den aktuellen Stand der Technik bringen?<\/strong><\/p>\n Dann informieren Sie sich\u00a0hier<\/strong>\u00a0<\/a>zu Schulungen\/ Seminaren\/ Trainings\/ Workshops und individuellen Coachings von MircoConsult zum Thema\u00a0Qualit\u00e4t, Safety & Security<\/strong>.<\/p>\n Hier<\/strong>\u00a0<\/a>finden Sie au\u00dferdem Schulungen zum Thema Software- und Vertragsrecht.<\/p>\n Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie\u00a0hier<\/a>.<\/strong><\/p>\n Wertvolles Fachwissen zum Thema Qualit\u00e4t, Safety & Securitysteht\u00a0hier\u00a0<\/a>f\u00fcr Sie zum kostenfreien Download bereit.<\/p>\nEinleitung<\/h2>\n
CC-Zertifizierungslandschaft<\/h2>\n
Common Criteria im \u00dcberblick<\/h2>\n
Besonderheiten der CC f\u00fcr eingebettete Systeme<\/h2>\n
Verl\u00e4sslichkeit und Nachhaltigkeit der Zertifizierung<\/h2>\n
Trends und aktuelle Entwicklungen<\/h2>\n
Zusammenfassung<\/h2>\n
Literatur<\/h2>\n
\nUnsere Trainings & Coachings<\/h2>\n
\nQualit\u00e4t, Safety & Security – Fachwissen<\/h2>\n