De Common Criteria for Information Technology Security Evaluation (ook wel Common Criteria of CC genoemd) is een internationale norm (ISO / IEC 15408) voor computerbeveiligingscertificering. De huidige versie is 2022.
Common Criteria is een raamwerk waarin gebruikers van IT producten hun beveiligingsfunctionaliteit en zekerheidsvereisten (respectievelijk SFR's en SAR's) kunnen specificeren in Protection Profiles (PP's).
Producenten beschrijven dan de claims over de beveiligingskenmerken van hun product in een Security Target (ST). Een ST kan gebaseerd worden op een of meer PP'[s. Een Testlaboratorium evalueert het product (Target of Evaluation, TOE) om te bepalen of het daadwerkelijk aan de claims voldoet. De "Certification Body" geeft een certificaat uit wanneer het testlaboratorium aangegeven heeft dat de TOE aan de claims voldoet. De certification body bewaakt ook het evaluatie proces.
Common Criteria specificeert hoe het proces van specificatie, implementatie en evaluatie van een computerbeveiligingsproduct op een rigoureuze en gestandaardiseerde en herhaalbare manier wordt uitgevoerd op een niveau dat in overeenstemming is met de beoogde gebruiksomgeving. Common Criteria houdt een lijst bij van gecertificeerde producten, waaronder besturingssystemen, toegangscontrolesystemen, databases en sleutelbeheersystemen.
Kernbegrippen
Common Criteria-evaluaties worden uitgevoerd op computerbeveiligingsproducten. Een groot deel van de evaluaties betreft "embedded" producten zoals chipkaarten.
Target of Evaluation (TOE) – het product dat onderwerp is van de evaluatie. De evaluatie dient om beweringen over het product te valideren. Dit gebeurt via het volgende proces:
Protection Profile (PP) – een document, meestal gemaakt door een gebruikersgemeenschap, waarin beveiligingsvereisten worden geïdentificeerd voor een klasse van producten (bijvoorbeeld smartcards, producten voor digitale handtekeningen of netwerkfirewalls). Producenten kunnen ervoor kiezen om producten te implementeren die voldoen aan een of meer PP's. In een dergelijk geval dient een PP als sjabloon voor de ST (Security Target, zoals hieronder gedefinieerd) van het product.
Klanten die op zoek zijn naar bepaalde soorten producten, kunnen zich richten op producten die gecertificeerd zijn volgens de PP's die aan hun eisen voldoen.
Security Target (ST) – het document dat onder andere de beveiligingseigenschappen van het doel van de evaluatie identificeert. Het ST kan aanspraak maken op conformiteit met een of meer PP's. De TOE wordt getoetst aan de SFR's (Security Functional Requirements, zie hieronder) die vastgelegd in zijn in het ST, niet meer en niet minder. Hierdoor kunnen producenten de functionaliteit afstemmen op het beoogde gebruik van hun product. Dit betekent dat een netwerkfirewall niet aan dezelfde functionele eisen hoeft te voldoen als een databasemanagementsysteem en dat verschillende firewalls zelfs aan totaal verschillende eisenlijsten kunnen worden getoetst.
Het ST beschrijft het "beveiligingsprobleem", wat de TOE beschermt, welke aannamen gemaakt worden, en welke bescherming door de omgeving van de TOE verwacht wordt.
Het ST en het "certificatie rapport" worden gepubliceerd zodat potentiële gebruikers de beveiligingseigenschappen kunnen zien die door de evaluatie zijn gecertificeerd. Voor sommige producten wordt alleen een "ST-lite" gepubliceerd, waarin bepaalde technische details die een aanvaller zouden kunnen helpen weggelaten zijn.
Functionele beveiligingsvereisten (Security Functional Requirements, SFR's) – specificeren de beveiligingsfuncties die door het product worden geleverd. De Common Criteria bevat een standaardcatalogus van dergelijke functies. Een SFR kan bijvoorbeeld aangeven hoe een gebruiker die een bepaalde rol vervult, kan worden geverifieerd. Hoewel Common Criteria geen SFR's voorschrijft die in een ST of PP moeten worden opgenomen, identificeert het afhankelijkheden waarbij de correcte werking van één functie (zoals de mogelijkheid om toegang te beperken op basis van rollen) afhankelijk is van een andere (zoals de mogelijkheid om individuele rollen te identificeren).
Het is mogelijk nieuwe SFR's te definiëren in een PP of ST. Dit worden "extended" SFR's genoemd.
In het ST moet aangetoond worden dat alle aspecten van het "beveiligingsprobleem" door een of meer SFR's opgelost worden.
Het evaluatieproces beoordeelt ook de kwaliteitsborgingsprocessen om zo het niveau van vertrouwen vast te stellen:
Beveiligingseisen (Security Assurance Requirements, SAR's) – beschrijvingen van de maatregelen die tijdens de ontwikkeling, productie, en levering van het product zijn genomen om naleving van de geclaimde beveiligingsfunctionaliteit te waarborgen. Een evaluatie kan bijvoorbeeld vereisen dat alle broncode in een versiebeheersysteem wordt bewaard of dat volledige functionele tests worden uitgevoerd. De Common Criteria biedt een catalogus hiervan. De vereisten zijn gedocumenteerd in het ST en PP.
Evaluatie Betrouwbaarheidsniveau (Evaluation Assurance Level, EAL) – Specificeert de diepte en nauwkeurigheid van een evaluatie. Elke EAL komt overeen met een pakket van beveiligingseisen (SAR's, zie hierboven) dat de volledige ontwikkeling en gebruik van een product dekt, met een bepaald niveau van striktheid. Common Criteria definieert zeven niveaus, met EAL1 als de meest basale (en daarom het goedkoopst om te implementeren en te evalueren) en EAL7 als de strengste (en duurste). Normaal gesproken selecteert een ST- of PP-auteur geen individuele assurance-eisen, maar kiest hij voor een van de "EAL pakketten", waarbij hij de eisen op enkele gebieden mogelijk 'aanvult' met eisen van een hoger niveau. In zulke gevallen wordt een "+" aan het EAL niveau toegevoegd. Hogere EAL's impliceren niet noodzakelijkerwijs "betere beveiliging", ze betekenen alleen dat de geclaimde veiligheidsfuncties van de TOE uitgebreider geverifieerd zijn.
De correctheid van cryptografische implementaties binnen de TOE valt buiten de reikwijdte van de CC, behalve dat vanaf bepaalde EALs ook beoordeeld wordt hoe goed de producent alle SFR's test. Nationale standaarden, zoals FIPS 140-2, geven meer gedetailleerde specificaties voor cryptografische modules.
Common Criteria evaluaties van producten met cryptografie beoordelen vaak wel de robuustheid van de cryptografische implementaties, bij voorbeeld de ongewenste lekkage van de sleutel.
Geschiedenis
De CC is ontstaan uit drie standaarden:
ITSEC – De Europese norm, begin jaren negentig ontwikkeld door Frankrijk, Duitsland, Nederland en het VK. Het was ook een samenvoeging van eerder werk, zoals de twee Britse benaderingen (het CESG UK Evaluation Scheme gericht op de defensie-/inlichtingenmarkt en het DTI Green Book gericht op commercieel gebruik), en werd overgenomen door een aantal andere landen, bijv. Australië.
CTCPEC – De Canadese standaard volgde op de Amerikaanse DoD-standaard, maar vermeed verschillende problemen en werd gezamenlijk gebruikt door beoordelaars uit zowel de VS als Canada. De CTCPEC-standaard werd voor het eerst gepubliceerd in mei 1993.
TCSEC – Het Amerikaanse ministerie van Defensie DoD 5200.28 Std, genaamd het Orange Book en delen van de Rainbow Series. Het Orange Book is ontstaan uit computerbeveiligingswerk, waaronder het Anderson-rapport, uitgevoerd door de National Security Agency en het National Bureau of Standards (de NBS werd uiteindelijk NIST) eind jaren zeventig en begin jaren tachtig. Het Orange Book is gebaseerd op de beschermingsmechanismen ontwikkeld door Dave Bell en Len LaPadula.
De CC is tot stand gekomen door deze reeds bestaande standaarden te verenigen, voornamelijk zodat bedrijven die computerproducten voor de overheidsmarkt verkopen (voornamelijk voor gebruik door defensie of inlichtingendiensten) deze alleen hoeven te laten evalueren op basis van één set standaarden. De CC is ontwikkeld door de regeringen van Canada, Frankrijk, Duitsland, Nederland, het VK en de VS.
Accreditatie van testlaboratoria
Alle testlaboratoria moeten voldoen aan ISO/IEC 17025 en de certificeringsinstanties zullen normaal gesproken worden toegelaten volgens ISO/IEC 17065.
De conformiteit met ISO/IEC 17025 wordt doorgaans bevestigd door een nationale goedkeuringsinstantie:
In Canada accrediteert de Standards Council of Canada (SCC) onder Program for the Accreditation of Laboratories (PALCAN) Common Criteria Evaluation Facilities (CCEF).
In Italië accrediteert de OCSI (Organismo di Certificazione della Sicurezza Informatica) Common Criteria-evaluatielaboratoria.
In India evalueert en certificeert het STQC-directoraat van het Ministerie van Elektronica en Informatietechnologie IT-producten op betrouwbaarheidsniveaus EAL 1 tot en met EAL4.
In het VK accrediteerde de United Kingdom Accreditation Service (UKAS) Commercial Evaluation Facilities (CLEF); het VK is sinds 2019 slechts een consument in het CC-ecosysteem.
In de VS accrediteert het National Voluntary Laboratory Accreditation Program (NVLAP) van het National Institute of Standards and Technology (NIST) Common Criteria Testing Laboratories (CCTL).
In Duitsland is het Bundesamt für Sicherheit in der Informationstechnik (BSI).
In Spanje accrediteert het National Cryptologic Centre] (CCN) Common Criteria Testing Laboratories die actief zijn in het Spaanse schema.
In Nederland accrediteert het Nederlandse schema voor certificering op het gebied van IT-beveiliging (NSCIB) IT-beveiligingsevaluatiefaciliteiten (ITSEF).
In Zweden verleent de Zweedse certificeringsinstantie voor IT-beveiliging (CSEC) licenties voor IT-beveiligingsevaluatiefaciliteiten (ITSEF).
Regeling wederzijdse erkenning
Naast de Common Criteria-standaard is er ook een Common Criteria MRA (Mutual Recognition Arrangement) op sub-verdragsniveau, waarbij elke partij daarbij evaluaties tegen de Common Criteria-standaard erkent die door andere partijen zijn gedaan. Oorspronkelijk ondertekend in 1998 door Canada, Frankrijk, Duitsland, het Verenigd Koninkrijk en de Verenigde Staten.
Australië en Nieuw-Zeeland sloten zich aan bij 1999, gevolgd door Finland, Griekenland, Israël, Italië, Nederland, Noorwegen en Spanje in 2000. De regeling is sindsdien omgedoopt tot Common Criteria Recognition Arrangement (CCRA) en het aantal leden blijft zich uitbreiden. Binnen de CCRA worden alleen evaluaties t/m EAL 2 wederzijds erkend (inclusief de uitbreiding met een process om fouten te corrigeren). De Europese landen binnen de SOGIS-MRA erkennen doorgaans ook hogere EAL's voor bepaalde TOE categorieën.
Problemen
Vereisten
Common Criteria is erg algemeen; het geeft niet direct een lijst met productbeveiligingseisen of -functies voor specifieke (klassen van) producten.
Dit is deels opgelost door de creatie van PP's, maar ook door afgeleide schema's zoals SESIP.
Flexibiliteit
Een certificaat geldt voor een bepaalde versie van de TOE. Als de TOE gewijzigd wordt, bij voorbeeld door een beveiligingsupdate, is het certificaat niet geldig voor de geüpdatete versie. Voor kleine veranderingen is er een (sneller) update proces: de producent maakt een overzicht van de veranderingen en hoe deze de gecertificeerde functies beïnvloeden. De ITSEF beoordeelt deze en kan besluiten dat het certificaat ook voor de nieuwe versie kan gelden, ze testen alleen de veranderde functies, of ze besluiten dat de TOE helemaal opnieuw gecertificeerd moet worden.
Waarde van de certificering
Common Criteria-certificering kan de veiligheid niet garanderen, maar kan er wel voor zorgen dat beweringen over de beveiligingskenmerken van het gecertificeerde product onafhankelijk zijn geverifieerd. Met andere woorden, producten die zijn gecertificeerd op basis van een Common Criteria-standaard, vertonen een duidelijke bewijsketen dat het proces van specificatie, implementatie en evaluatie op een rigoureuze en gestandaardiseerde manier is uitgevoerd.
Verschillende Microsoft Windows-versies, waaronder Windows Server 2003 en Windows XP, zijn gecertificeerd. Dit is mogelijk omdat het proces van het verkrijgen van een Common Criteria-certificering een leverancier in staat stelt de certificering te beperken tot bepaalde beveiligingskenmerken en om bepaalde aannames te doen over de omgeving en de sterkte van de bedreigingen.
De gebruiker kan dit echter in het openbare ST nalezen en beoordelen of het relevant is voor zijn situatie. Sommige toezichthouders gaan zelfs zo ver dat ze een niet serieuze en/of misleidende ST niet certificeren willen.
In 2017 werd de ROCA kwetsbaarheid gevonden in een aantal Common Criteria-gecertificeerde smartcardproducten. De behandeling van deze kwetsbaarheid bracht verschillende tekortkomingen van het Common Criteria-certificeringsschema aan het licht:
De kwetsbaarheid zat in een nieuw algoritme voor het genereren van RSA-sleutels, dat niet is gepubliceerd en geanalyseerd door de cryptografische gemeenschap. Het testlaboratorium TÜV Informationstechnik GmbH (TÜViT) in Duitsland keurde het gebruik echter goed en de certificatie-instelling BSI in Duitsland gaf Common Criteria-certificaten af voor deze producten. Het ST van het geëvalueerde product beweerde dat RSA-sleutels worden gegenereerd volgens het standaardalgoritme. Als reactie op deze kwetsbaarheid is BSI nu van plan de transparantie te verbeteren door te eisen dat het certificeringsrapport op zijn minst specificeert of de geïmplementeerde eigen cryptografie niet precies voldoet aan een aanbevolen standaard. BSI is niet van plan om op enigerlei wijze te eisen dat het bedrijfseigen algoritme wordt gepubliceerd.
Hoewel de certificatie-instellingen zich er nu van bewust zijn dat de beveiligingsclaims die zijn gespecificeerd in de Common Criteria-certificaten niet meer geldig zijn, hebben noch ANSSI noch BSI de overeenkomstige certificaten ingetrokken. Volgens BSI kan een certificaat alleen worden ingetrokken als het onder een misvatting is afgegeven, bijvoorbeeld als blijkt dat er een verkeerd bewijs is overlegd. Nadat een certificaat is uitgegeven, moet worden aangenomen dat de geldigheid van het certificaat in de loop van de tijd afneemt door verbeterde en nieuwe aanvallen die worden ontdekt. Certificatie-instellingen kunnen onderhoudsrapporten uitbrengen en zelfs een hercertificering van het product uitvoeren. Deze activiteiten moeten echter door de producent worden geïnitieerd en gesponsord.
Hoewel verschillende Common Criteria-gecertificeerde producten zijn getroffen door de ROCA-fout, zijn de reacties van leveranciers in de context van certificering verschillend. Voor sommige producten is een onderhoudsrapport afgegeven, waarin staat dat alleen RSA-sleutels met een lengte van 3072 en 3584 bits een beveiligingsniveau hebben van minimaal 100 bits, terwijl voor sommige producten in het onderhoudsrapport niet wordt vermeld dat de wijziging van de TOE gevolgen heeft voor gecertificeerde cryptografische beveiligingsfunctionaliteit, maar concludeert dat de wijziging op het niveau van begeleidingsdocumentatie is en geen effect heeft op de zekerheid.
Volgens BSI hadden de gebruikers van de gecertificeerde eindproducten door de leveranciers moeten worden geïnformeerd over de ROCA-kwetsbaarheid. Deze informatie bereikte echter niet tijdig de Estse autoriteiten die het kwetsbare product op meer dan 750.000 Estse identiteitskaarten hadden ingezet.