Gemeinsame Kriterien - Common Criteria

Die Common Criteria for Information Technology Security Evaluation (auch Common Criteria oder CC genannt ) ist ein internationaler Standard ( ISO / IEC 15408) für die Zertifizierung der Computersicherheit . Es befindet sich derzeit in der Version 3.1, Revision 5.

Common Criteria ist ein Rahmen , in dem Computersystem können Benutzer festlegen , ihre Sicherheit funktionalen und Sicherungsanforderungen (SFRs und SARs jeweils) in einem Sicherheitsvorgaben (ST) und kann entnommen werden Schutzprofile (PPs). Anbieter können dann die Sicherheitsmerkmale ihrer Produkte implementieren oder geltend machen, und Testlabore können die Produkte bewerten , um festzustellen, ob sie die Ansprüche tatsächlich erfüllen. Mit anderen Worten, Common Criteria bietet die Gewissheit, dass der Prozess der Spezifikation, Implementierung und Bewertung eines Computersicherheitsprodukts in einer rigorosen, standardisierten und wiederholbaren Weise auf einem Niveau durchgeführt wurde, das der zu verwendenden Zielumgebung entspricht. Common Criteria führt eine Liste zertifizierter Produkte, einschließlich Betriebssysteme, Zugangskontrollsysteme, Datenbanken und Schlüsselverwaltungssysteme.

Schlüssel Konzepte

Common Criteria-Bewertungen werden für Computersicherheitsprodukte und -systeme durchgeführt.

  • Ziel der Bewertung (TOE)  – das Produkt oder System, das Gegenstand der Bewertung ist. Die Auswertung dient dazu, Aussagen über das Ziel zu validieren. Um einen praktischen Nutzen zu haben, muss die Evaluierung die Sicherheitsmerkmale des Ziels überprüfen. Dies geschieht durch Folgendes:
    • Schutzprofil (PP)  - ein Dokument,Regel durch einen Benutzer oder BenutzerCommunity geschaffen, die identifiziert Sicherheitsanforderungen für eine Klasse von Sicherheitsvorrichtungen (zB Smartcards verwendet bieten digitale Signaturen oder Netzwerk - Firewalls ) relevant für diesen Benutzer für ein besonderer Zweck. Produktanbieter können Produkte implementieren, die einem oder mehreren PPs entsprechen, und ihre Produkte anhand dieser PPs bewerten lassen. In einem solchen Fall kann ein PP als Vorlage für die ST des Produkts (Sicherheitsziel, wie unten definiert) dienen, oder die Autoren der ST werden zumindest sicherstellen, dass alle Anforderungen in relevanten PPs auch im ST-Dokument des Ziels erscheinen. Kunden, die nach bestimmten Produkttypen suchen, können sich auf diejenigen konzentrieren, die nach dem PP zertifiziert sind, das ihren Anforderungen entspricht.
    • Sicherheitsvorgaben (ST)  - das Dokumentdass identifiziert die Sicherheitseigenschaften des Ziels der Bewertung. Der ST kann die Konformität mit einem oder mehreren PPs beanspruchen. Der EVG wird anhand der in seinem ST festgelegten SFRs (Security Functional Requirements. Auch siehe unten) bewertet, nicht mehr und nicht weniger. Dies ermöglicht es Anbietern, die Bewertung so zu gestalten, dass sie den beabsichtigten Fähigkeiten ihres Produkts genau entspricht. Das bedeutet, dass eine Netzwerk-Firewall nicht die gleichen funktionalen Anforderungen erfüllen muss wie ein Datenbank- Management-System, sondern unterschiedliche Firewalls sogar gegen ganz unterschiedliche Anforderungskataloge bewertet werden können. Der ST wird in der Regel veröffentlicht, damit potenzielle Kunden die konkreten Sicherheitsmerkmale ermitteln können, die durch die Evaluierung zertifiziert wurden.
    • Funktionale Sicherheitsanforderungen (SFRs)  - spezifizieren einzelne Sicherheitsfunktionen , die von einem Produkt zur Verfügung gestellt werden können. Die Common Criteria bietet einen Standardkatalog solcher Funktionen. Ein SFR kann beispielsweise angeben, wie ein Benutzer, der eine bestimmte Rolle ausführt, authentifiziert werden kann . Die Liste der SFRs kann von einer Evaluierung zur nächsten variieren, selbst wenn es sich bei zwei Zielen um den gleichen Produkttyp handelt. Obwohl Common Criteria keine SFRs vorschreibt, die in eine ST aufgenommen werden sollen, identifiziert es Abhängigkeiten, bei denen der korrekte Betrieb einer Funktion (z ).

Der Bewertungsprozess versucht auch, das Vertrauensniveau zu ermitteln, das durch Qualitätssicherungsprozesse in die Sicherheitsmerkmale des Produkts gesetzt werden kann:

  • Security Assurance Requirements (SARs)  – Beschreibungen der Maßnahmen, die während der Entwicklung und Bewertung des Produkts ergriffen wurden, um die Einhaltung der beanspruchten Sicherheitsfunktionalität sicherzustellen. Beispielsweise kann eine Evaluierung erfordern, dass der gesamte Quellcode in einem Änderungsmanagementsystem aufbewahrt wird oder dass vollständige Funktionstests durchgeführt werden. Die Common Criteria bietet einen Katalog davon, und die Anforderungen können von einer Evaluierung zur nächsten variieren. Die Anforderungen an bestimmte Ziele oder Produkttypen sind im ST bzw. PP dokumentiert.
  • Evaluation Assurance Level (EAL)  – die numerische Bewertung, die die Tiefe und Strenge einer Bewertung beschreibt. Jede EAL entspricht einem Paket von Security Assurance Requirements (SARs, siehe oben), das die komplette Entwicklung eines Produkts mit einem bestimmten Grad an Strenge abdeckt. Common Criteria listet sieben Stufen auf, wobei EAL 1 die einfachste (und daher am billigsten zu implementierende und auszuwertende) und EAL 7 die strengste (und teuerste) ist. Normalerweise wählt ein ST- oder PP-Autor die Assurance-Anforderungen nicht einzeln aus, sondern wählt eines dieser Pakete aus und „ergänzt“ möglicherweise Anforderungen in einigen Bereichen mit Anforderungen einer höheren Ebene. Höhere EALs bedeuten nicht unbedingt „bessere Sicherheit“, sie bedeuten lediglich, dass die behauptete Sicherheitszusicherung des EVG umfassender verifiziert wurde .

Bisher waren die meisten PPs und die meisten evaluierten STs/zertifizierten Produkte für IT-Komponenten (zB Firewalls, Betriebssysteme , Smartcards) bestimmt. Für die IT-Beschaffung wird manchmal eine Common Criteria-Zertifizierung vorgeschrieben. Andere Normen, die zB Interoperation, Systemmanagement, Benutzerschulung, Supplement CC und andere Produktnormen enthalten. Beispiele sind die ISO/IEC 27002 ) und der deutsche IT-Grundschutz .

Einzelheiten der kryptographischen Implementierung innerhalb des EVG liegen außerhalb des Geltungsbereichs des CC. Stattdessen geben nationale Standards wie FIPS 140-2 die Spezifikationen für kryptografische Module an, und verschiedene Standards spezifizieren die verwendeten kryptografischen Algorithmen.

In jüngerer Zeit fügen PP-Autoren kryptografische Anforderungen für CC-Bewertungen hinzu, die normalerweise von FIPS 140-2-Bewertungen abgedeckt würden, und erweitern die Grenzen des CC durch schemaspezifische Interpretationen.

Einige nationale Bewertungssysteme stellen EAL-basierte Bewertungen aus und akzeptieren nur Produkte zur Bewertung, die eine strikte Konformität mit einem zugelassenen PP beanspruchen. Die Vereinigten Staaten erlauben derzeit nur PP-basierte Bewertungen. Kanada ist dabei, EAL-basierte Evaluierungen auslaufen zu lassen.

Geschichte

CC entstand aus drei Standards:

  • ITSEC  – Der europäische Standard, der Anfang der 1990er Jahre von Frankreich, Deutschland, den Niederlanden und Großbritannien entwickelt wurde. Es war auch eine Vereinheitlichung früherer Arbeiten, wie der beiden britischen Ansätze (das CESG UK Evaluation Scheme für den Verteidigungs-/Geheimdienstmarkt und das DTI Green Book für die kommerzielle Nutzung) und wurde von einigen anderen Ländern, zB Australien, übernommen.
  • CTCPEC  – Der kanadische Standard folgte dem US-DoD-Standard, vermied jedoch mehrere Probleme und wurde von Evaluatoren aus den USA und Kanada gemeinsam verwendet. Der CTCPEC-Standard wurde erstmals im Mai 1993 veröffentlicht.
  • TCSEC  – Das US-Verteidigungsministerium DoD 5200.28 Std, genannt das Orange Book und Teile der Rainbow Series . Das Orange Book entstand aus der Computersicherheitsarbeit, einschließlich des Anderson-Berichts, der von der National Security Agency und dem National Bureau of Standards (aus der NBS wurde schließlich NIST ) in den späten 1970er und frühen 1980er Jahren erstellt wurde. Die zentrale These des Orange Book ergibt sich aus der Arbeit von Dave Bell und Len LaPadula für eine Reihe von Schutzmechanismen.

CC wurde durch die Vereinheitlichung dieser bereits bestehenden Standards erstellt, vor allem, damit Unternehmen, die Computerprodukte für den staatlichen Markt (hauptsächlich für den Verteidigungs- oder Geheimdienstgebrauch) verkaufen, diese nur anhand einer Reihe von Standards bewerten lassen müssen. Das CC wurde von den Regierungen Kanadas, Frankreichs, Deutschlands, der Niederlande, des Vereinigten Königreichs und der USA entwickelt

Prüforganisationen

Alle Prüflaboratorien müssen ISO/IEC 17025 einhalten , und Zertifizierungsstellen werden normalerweise nach ISO/IEC 17065 zugelassen.

Die Konformität mit ISO/IEC 17025 wird typischerweise einer nationalen Zulassungsbehörde nachgewiesen:

Merkmale dieser Organisationen wurden untersucht und auf der ICCC 10 präsentiert.

Vereinbarung über die gegenseitige Anerkennung

Neben dem Common Criteria-Standard gibt es auf Untervertragsebene Common Criteria MRA (Mutual Recognition Arrangement), bei der jede Vertragspartei Bewertungen gegen den Common Criteria-Standard anderer Vertragsparteien anerkennt. Ursprünglich 1998 von Kanada, Frankreich, Deutschland, dem Vereinigten Königreich und den Vereinigten Staaten unterzeichnet, traten Australien und Neuseeland 1999 bei, gefolgt von Finnland, Griechenland, Israel, Italien, den Niederlanden, Norwegen und Spanien im Jahr 2000 in Common Criteria Recognition Arrangement ( CCRA ) umbenannt und die Mitgliederzahl wächst weiter . Innerhalb der CCRA werden nur Bewertungen bis EAL 2 gegenseitig anerkannt (einschließlich Augmentation mit Fehlerbeseitigung). Die europäischen Länder innerhalb des früheren ITSEC-Abkommens erkennen in der Regel auch höhere EALs an. Bewertungen bei EAL5 und höher beziehen sich in der Regel auf die Sicherheitsanforderungen der Regierung des Gastlandes.

Im September 2012 hat die Mehrheit der CCRA-Mitglieder eine Vision erstellt, wonach die gegenseitige Anerkennung von CC-bewerteten Produkten auf EAL 2 (einschließlich Augmentation mit Fehlerbeseitigung) gesenkt wird. Darüber hinaus deutet diese Vision auf eine Abkehr von den Sicherheitsstufen hin, und die Bewertungen werden sich auf die Einhaltung von Schutzprofilen beschränken, für die keine Sicherheitsstufe angegeben ist. Dies wird durch technische Arbeitsgruppen erreicht, die weltweite PPs entwickeln, und eine Übergangsfrist ist noch nicht vollständig festgelegt.

Am 2. Juli 2014 wurde ein neues CCRA gemäß den im Leitbild von 2012 dargelegten Zielen ratifiziert . Zu den wichtigsten Änderungen des Arrangements gehören:

  • Anerkennung von Bewertungen nur gegen ein kollaboratives Schutzprofil (cPP) oder Bewertungssicherungsstufen 1 bis 2 und ALC_FLR.
  • Die Entstehung internationaler Technical Communities (iTC), Gruppen technischer Experten, die mit der Schaffung von cPPs betraut sind.
  • Ein Übergangsplan der vorherigen CCRA, einschließlich der Anerkennung von Zertifikaten, die im Rahmen der vorherigen Version der Vereinbarung ausgestellt wurden.

Themen

Anforderungen

Common Criteria ist sehr allgemein gehalten; Es enthält keine direkte Liste von Produktsicherheitsanforderungen oder -merkmalen für bestimmte (Klassen von) Produkten: Dies folgt dem Ansatz von ITSEC , war jedoch eine Quelle der Debatte für diejenigen, die an den stärker präskriptiven Ansatz anderer früherer Standards wie z TCSEC und FIPS 140 -2.

Wert der Zertifizierung

Eine Common-Criteria-Zertifizierung kann keine Sicherheit garantieren, aber sie kann sicherstellen, dass die Angaben zu den Sicherheitsattributen des bewerteten Produkts unabhängig überprüft wurden. Mit anderen Worten, Produkte, die nach einem Common Criteria-Standard bewertet wurden, weisen eine klare Beweiskette auf, dass der Spezifikations-, Implementierungs- und Bewertungsprozess auf strenge und standardisierte Weise durchgeführt wurde.

Verschiedene Microsoft Windows-Versionen, einschließlich Windows Server 2003 und Windows XP , wurden zertifiziert , aber Sicherheitspatches zur Behebung von Sicherheitslücken werden von Microsoft immer noch für diese Windows-Systeme veröffentlicht. Dies ist möglich, da der Prozess der Erlangung einer Common Criteria-Zertifizierung es einem Anbieter ermöglicht, die Analyse auf bestimmte Sicherheitsfunktionen zu beschränken und bestimmte Annahmen über die Betriebsumgebung und die Stärke der Bedrohungen zu treffen, denen das Produkt in dieser Umgebung ausgesetzt ist. Darüber hinaus erkennt das CC die Notwendigkeit an, den Bewertungsbereich einzuschränken, um kostengünstige und nützliche Sicherheitszertifizierungen bereitzustellen, so dass bewertete Produkte bis zu einem durch das Assurance Level oder PP festgelegten Detaillierungsgrad untersucht werden. Evaluierungsaktivitäten werden daher nur bis zu einem bestimmten Umfang, Zeit- und Ressourcenaufwand durchgeführt und bieten eine angemessene Sicherheit für das beabsichtigte Umfeld.

Im Fall von Microsoft beinhalten die Annahmen A.PEER:

Es wird davon ausgegangen, dass alle anderen Systeme, mit denen der EVG kommuniziert, unter derselben Managementkontrolle stehen und unter denselben Sicherheitsrichtlinienbeschränkungen arbeiten. Der EVG gilt nur für vernetzte oder verteilte Umgebungen, wenn das gesamte Netzwerk unter denselben Beschränkungen arbeitet und sich innerhalb eines eine einzige Verwaltungsdomäne. Es gibt keine Sicherheitsanforderungen, die darauf abzielen, externen Systemen oder den Kommunikationsverbindungen zu solchen Systemen zu vertrauen."

Diese Annahme ist im Controlled Access Protection Profile (CAPP) enthalten, an das sich ihre Produkte halten. Basierend auf diesen und anderen Annahmen, die für die gängige Verwendung von Allzweck-Betriebssystemen nicht realistisch sein können, werden die beanspruchten Sicherheitsfunktionen der Windows-Produkte bewertet. Sie sollten daher nur unter den angenommenen, spezifizierten Umständen, auch als bewertete Konfiguration bezeichnet , als sicher angesehen werden .

Unabhängig davon, ob Sie Microsoft Windows in der genau evaluierten Konfiguration ausführen oder nicht, sollten Sie die Sicherheitspatches von Microsoft für die Sicherheitslücken in Windows installieren, sobald diese weiterhin auftreten. Wenn eine dieser Sicherheitslücken in der evaluierten Konfiguration des Produkts ausgenutzt werden kann, sollte die Common Criteria-Zertifizierung des Produkts vom Hersteller freiwillig zurückgezogen werden. Alternativ sollte der Anbieter das Produkt neu bewerten, um die Anwendung von Patches zur Behebung der Sicherheitsschwachstellen in die bewertete Konfiguration einzubeziehen. Wenn der Verkäufer keinen dieser Schritte unternimmt, würde die Zertifizierung des Produkts durch die Zertifizierungsstelle des Landes, in dem das Produkt bewertet wurde, unfreiwillig entzogen werden.

Die zertifizierten Microsoft Windows-Versionen bleiben bei EAL4+, ohne die Anwendung von Microsoft-Sicherheitslücken-Patches in ihre evaluierte Konfiguration aufzunehmen. Dies zeigt sowohl die Einschränkung als auch die Stärke einer evaluierten Konfiguration.

Kritikpunkte

Im August 2007 untersuchte der Kolumnist der Government Computing News (GCN) William Jackson die Common Criteria-Methodik und ihre US-Implementierung durch das Common Criteria Evaluation and Validation Scheme (CCEVS) kritisch. In der Kolumne wurden Führungskräfte aus der Sicherheitsbranche, Forscher und Vertreter der National Information Assurance Partnership (NIAP) interviewt. Zu den im Artikel genannten Einwänden gehören:

  • Die Evaluierung ist ein kostspieliger Prozess (häufig in Hunderttausenden von US-Dollar gemessen) – und die Rendite des Anbieters aus dieser Investition ist nicht unbedingt ein sichereres Produkt.
  • Die Bewertung konzentriert sich in erster Linie auf die Bewertung der Bewertungsdokumentation, nicht auf die tatsächliche Sicherheit, technische Korrektheit oder Vorzüge des Produkts selbst. Bei US-Auswertungen nehmen erst ab EAL5 Experten der National Security Agency an der Analyse teil; und nur bei EAL7 ist eine vollständige Quellcodeanalyse erforderlich.
  • Der Aufwand und die Zeit, die für die Erstellung von Bewertungsnachweisen und anderer bewertungsrelevanter Dokumentation erforderlich sind, sind so umständlich, dass das zu bewertende Produkt am Ende der Arbeiten in der Regel veraltet ist.
  • Der Input der Industrie, auch von Organisationen wie dem Common Criteria Vendor's Forum , hat im Allgemeinen wenig Einfluss auf den Prozess als Ganzes.

In einem Forschungspapier aus dem Jahr 2006 schlug der Computerspezialist David A. Wheeler vor, dass der Common Criteria-Prozess gegen freie und auf Open-Source-Software (FOSS) ausgerichtete Organisationen und Entwicklungsmodelle diskriminiert . Die Anforderungen der Common Criteria-Zusicherung sind in der Regel von der traditionellen Wasserfall- Softwareentwicklungsmethodik inspiriert . Im Gegensatz dazu wird ein Großteil der FOSS-Software nach modernen agilen Paradigmen erstellt. Obwohl einige argumentiert haben, dass beide Paradigmen nicht gut zusammenpassen, haben andere versucht, beide Paradigmen in Einklang zu bringen. Der Politologe Jan Kallberg äußerte Bedenken über die fehlende Kontrolle über die tatsächliche Produktion der Produkte nach der Zertifizierung, das Fehlen einer ständig besetzten Organisation, die die Einhaltung überwacht, und die Vorstellung, dass das Vertrauen in die Common Criteria IT-Sicherheitszertifizierungen über geopolitische Grenzen hinweg aufrechterhalten werden.

Im Jahr 2017 wurde die ROCA-Schwachstelle in einer Liste von nach Common Criteria zertifizierten Smartcard-Produkten gefunden. Die Sicherheitsanfälligkeit hat mehrere Mängel des Common Criteria-Zertifizierungsschemas aufgezeigt:

  • Die Schwachstelle lag in einem selbst entwickelten Algorithmus zur RSA-Schlüsselgenerierung, der von der Kryptoanalyse-Community nicht veröffentlicht und analysiert wurde. Das Prüflabor TÜV Informationstechnik GmbH (TÜViT) in Deutschland hat jedoch den Einsatz genehmigt und die Zertifizierungsstelle BSI in Deutschland hat Common Criteria-Zertifikate für die gefährdeten Produkte ausgestellt. Das Security Target des evaluierten Produkts behauptete, dass RSA-Schlüssel nach dem Standardalgorithmus generiert werden. Als Reaktion auf diese Schwachstelle plant das BSI nun, die Transparenz zu verbessern, indem es verlangt, dass im Zertifizierungsbericht zumindest angegeben wird, ob die implementierte proprietäre Kryptographie nicht genau einem empfohlenen Standard entspricht. Das BSI plant in keiner Weise eine Veröffentlichung des proprietären Algorithmus zu verlangen.
  • Auch wenn den Zertifizierungsstellen mittlerweile bekannt ist, dass die in den Common Criteria-Zertifikaten genannten Sicherheitsansprüche nicht mehr gelten, haben weder ANSSI noch BSI die entsprechenden Zertifikate widerrufen. Ein Zertifikat kann laut BSI nur dann entzogen werden, wenn es fälschlicherweise ausgestellt wurde, zB wenn sich herausstellt, dass ein falscher Nachweis vorgelegt wurde. Nach der Ausstellung eines Zertifikats muss davon ausgegangen werden, dass die Gültigkeit des Zertifikats im Laufe der Zeit durch die Entdeckung verbesserter und neuer Angriffe abnimmt. Zertifizierungsstellen können Wartungsberichte erstellen und sogar eine Rezertifizierung des Produkts durchführen. Diese Aktivitäten müssen jedoch vom Anbieter initiiert und gesponsert werden.
  • Während mehrere nach Common Criteria zertifizierte Produkte von dem ROCA-Fehler betroffen waren, waren die Reaktionen der Anbieter im Zusammenhang mit der Zertifizierung unterschiedlich. Für einige Produkte wurde ein Wartungsbericht erstellt, der besagt, dass nur RSA-Schlüssel mit einer Länge von 3072 und 3584 Bit eine Sicherheitsstufe von mindestens 100 Bit haben, während für einige Produkte der Wartungsbericht nicht erwähnt, dass die Änderung des EVG sich auswirkt zertifizierte kryptografische Sicherheitsfunktionalität, kommt jedoch zu dem Schluss, dass sich die Änderung auf der Ebene der Leitliniendokumentation befindet und keine Auswirkungen auf die Zuverlässigkeitsgewähr hat.
  • Laut BSI hätten die Anwender der zertifizierten Endprodukte von den Herstellern über die ROCA-Schwachstelle informiert werden sollen . Diese Informationen erreichten jedoch nicht rechtzeitig die estnischen Behörden, die das gefährdete Produkt auf mehr als 750.000 estnischen Personalausweisen eingesetzt hatten .

Alternative Ansätze

Während der gesamten Lebensdauer CC, es war nicht allgemein angenommen , auch von den Schöpfer Nationen wurde, mit, insbesondere Verschlüsselungs Zulassungen separat behandelt werden, wie von der kanadischen / US Implementierung von FIPS-140 und die CESG Produkte Scheme Assisted (CAPS ) im Vereinigten Königreich.

Das Vereinigte Königreich hat auch eine Reihe von alternativen Systemen entwickelt, wenn sich herausstellte, dass Zeitrahmen, Kosten und Gemeinkosten der gegenseitigen Anerkennung das Funktionieren des Marktes behindern:

  • Die CESG System Evaluation (SYSn) und Fast Track Approach (FTA) Systeme zur Absicherung von Regierungssystemen anstelle von generischen Produkten und Dienstleistungen, die jetzt in den CESG Tailored Assurance Service (CTAS) zusammengeführt wurden
  • Das CESG Claims Tested Mark (CCT Mark), das darauf abzielt, weniger erschöpfende Sicherheitsanforderungen für Produkte und Dienstleistungen kosten- und zeiteffizient zu handhaben

Anfang 2011 veröffentlichte die NSA/CSS ein Papier von Chris Salter, das einen schutzprofilorientierten Ansatz zur Bewertung vorschlug . Bei diesem Ansatz bilden sich Interessengemeinschaften um Technologietypen herum, die wiederum Schutzprofile entwickeln, die die Bewertungsmethodik für den Technologietyp definieren. Das Ziel ist eine robustere Bewertung. Es bestehen gewisse Bedenken, dass dies negative Auswirkungen auf die gegenseitige Anerkennung haben könnte .

Im September 2012 veröffentlichte die Common Criteria ein Vision Statement, das die Gedanken von Chris Salter aus dem Vorjahr weitgehend umsetzt. Zu den wichtigsten Elementen der Vision gehörten:

  • Technical Communities werden sich auf die Erstellung von Schutzprofilen (PP) konzentrieren, die ihr Ziel von vernünftigen, vergleichbaren, reproduzierbaren und kosteneffektiven Bewertungsergebnissen unterstützen
  • Bewertungen sollten nach Möglichkeit gegen diese PPs durchgeführt werden; andernfalls wäre die gegenseitige Anerkennung von Sicherheitszielbewertungen auf EAL2 beschränkt

Siehe auch

Verweise

Externe Links