Common Criteria (for
Information Technology
Security Evaluation)
PV017 – Řízení informační bezpečnosti
Vashek Matyáš
Agenda
• Kritéria hodnocení (bezpečnosti) – úvod
• Příklad profilu bezpečnosti
• Funkčnost (functionality) a záruka (assurance)
• 7 úrovní záruky (EAL) – Společná kritéria
• Zajímavý příklad s Win2K
• Závěr
2
Kritéria hodnocení bezpečnosti
• USA – konec 60. let a 70. léta – potřeba
minimalizace nákladů na individuální hodnocení
• 1985 – Trusted Computer System Evaluation
Criteria – “Orange Book”
– Třída D – žádná bezpečnost
– A1 – nejvyšší bezpečnost (matematický formalismus)
Vývoj kritérií
• Evropa – ITSEC – oddělení funkčnosti a záruk
(plus metodologie – ITSEM)
• Kanada – CTCPEC – funkčnost rozdělena do
skupin důvěrnost, integrita, zodpovědnost a
dostupnost (plus krypto)
• US – Federal Criteria – vývoj zastaven
• Společná kritéria (Common Criteria) –
celosvětový standard
– ISO/IEC 15408
Pojmy
• Akreditace – oficiální souhlas (pověření) s
prováděním určité činnosti
• Certifikace – vydání daného osvědčení na
základě provedeného hodnocení
• Hodnocení (evaluace) – ověření shody
deklarovaných vlastností (dle kritérií)
• Validace – ověření platnosti/souladu, v US
terminologii „hodnocení“ – viz výše
Důležité pojmy z CC
• Předmět hodnocení (Target of Evaluation, TOE) –
produkt nebo systém (nebo jeho část), který je
předmětem hodnocení
• Specifikace bezpečnosti (Security Target, ST) –
cílová kombinace komponent spojených s
konkrétním produktem nebo systémem
• Profil bezpečnosti (Protection Profile, PP) –
implementačně nezávislá skupina bezpečn.
požadavků určité skupiny TOE
6
Common Criteria model
• TOE: Target of
Evaluation – the
evaluated system
• TSF: TOE Security
Functions – HW, SW,
FW used by the TOE
• TSC: TSF Scope of
Control – interactions
under the TOE
security policy
7
Platnost CC certifikátů
8
Společná kritéria
• Zájem uživatelů, výrobců, hodnotitelů
• Profil bezpečnosti (čipové karty, biometriky, DBMS,
poštovní razítkovače ap.)
– „Minikritéria“ – katalogovány jako samostatný hodnotitelský
dokument
– Popisy bezpečnostních potřeb často různorodé 
• Security target (ST) – teoretický koncept/cíl
• Hodnocení TOE = odpovídá realita teorii (ST)?
• Požadavky na funkčnost (angl. functionality) a záruky
(angl. assurance)
Certifikovaná zařízení (dle CC)
10
Certifikovaná zařízení (dle CC) – pokr.
11
Agenda
• Kritéria hodnocení (bezpečnosti) – úvod
• Příklad profilu bezpečnosti
• Funkčnost (functionality) a záruka (assurance)
• 7 úrovní záruky (EAL) – Společná kritéria
• Zajímavý příklad s Win2K
• Závěr
12
Study of a particular PP
• PP BSI-PP-0025 – German (BSI) Common Criteria
Protection Profile for USB Storage Media
• PP organisation:
– the TOE description,
– the TOE security environment,
– the security objectives,
– the IT security requirements and
– the rationale.
13
PP BSI-PP-0025 – roles in the TOE
• Authorised user (S1)
– Holds the authentication attribute required to access the
TOE protected memory area, in which the confidential data
is stored.
– Can modify the authentication attribute.
14
PP BSI-PP-0025 – roles in the TOE, cont’d
• Non-authorised user (S2)
– Wishes to access S1’s confidential data in the USB
storage medium’s memory (examples of confidential data
are given in Section 2.5).
– Does not have the authentication attribute to access the
protected data.
– Can obtain a USB storage medium of the same type. Can
try out both logical and physical attacks on this USB
storage medium.
– Can gain possession of the TOE relatively easily since the
TOE has a compact form.
15
PP BSI-PP-0025 – threats (countered)
• T.logZugriff – Assuming that S2 gains possession of the
TOE, he/she accesses the confidential data on the TOE.
S2 gains logical access by, for example, connecting the
TOE to the USB interface of a computer system.
• T.phyZugriff – Assuming that S2 gains possession of the
TOE, he/she accesses the TOE’s memory by means of a
physical attack. Such an attack could take the following
form, for example: S2 removes the TOE memory and
places it into another USB storage medium which he/she
uses for the purpose of logical access to the memory.
16
PP BSI-PP-0025 – threats, cont’d
• T.AuthÄndern – Assuming that S2 gains
possession of the TOE, he/she sets a new
authentication attribute, with the result that the
data becomes unusable for S1.
• T.Störung – A failure (e.g., power failure or
operating system error) stops the TOE operating
correctly. As a result, confidential data remains
unencrypted or the TOE’s file system is damaged.
17
Agenda
• Kritéria hodnocení (bezpečnosti) – úvod
• Příklad profilu bezpečnosti
• Funkčnost (functionality) a záruka (assurance)
• 7 úrovní záruky (EAL) – Společná kritéria
• Zajímavý příklad s Win2K
• Závěr
18
Common Criteria – two catalogues
• Two catalogues of components for specification of
assurance and functionality requirements, with a
standard terminology.
• Functionality – rules governing access to & use of
TOE resources, and thus information and services
controlled by the TOE
• Assurance
– grounds for confidence that an entity meets its security
objectives (CC v2.3)
– grounds for confidence that a TOE meets the SFRs (CC
v3.1)
19
CC – going for evaluation (in a nutshell)
1. Define the product/system for evaluation
2. Specify its functionality
3. Specify the assurance level claimed
4. See details of evaluation with a certification body
5. Prepare evidence
20
CC functional classes
• FAU: SECURITY AUDIT
• FCO: COMMUNICATION
• FCS: CRYPTOGRAPHIC SUPPORT
• FDP: USER DATA PROTECTION
• FIA: IDENTIFICATION AND AUTHENTICATION
• FMT: SECURITY MANAGEMENT
• FPR: PRIVACY
• FPT: PROTECTION OF THE TSF
• FRU: RESOURCE UTILISATION
• FTA: TOE ACCESS
• FTP: TRUSTED PATH/CHANNELS
21
CC assurance classes
• APE: PROTECTION PROFILE EVALUATION
• ACE: PROTECTION PROFILE CONFIGURATION
EVALUATION
• ASE: SECURITY TARGET EVALUATION
• ADV: DEVELOPMENT
• AGD: GUIDANCE DOCUMENTS
• ALC: LIFE-CYCLE SUPPORT
• ATE: TESTS
• AVA: VULNERABILITY ASSESSMENT
• ACO: COMPOSITION
22
CC assurance paradigms
• assurance based upon an evaluation (active
investigation)
• measuring the validity of the documentation and of
the resulting IT product by expert evaluators with
increasing emphasis on scope, depth, and rigour
• CC does not exclude, nor does it comment upon,
the relative merits of other means of gaining
assurance
23
24
Assurance elements – 3 exclusive classes
1. Developer action elements: activities that shall be
performed by the developer. Further qualified by
evidential material referenced in the following set of
elements. Req’s marked by “D” at the element No.
2. Content and presentation of evidence elements: the
evidence required, what the evidence demonstrates,
what the evidence shall convey. Marked by “C”.
3. Evaluator action elements: activities that shall be
performed by the evaluator. Marked by “E”.
25
Agenda
• Kritéria hodnocení (bezpečnosti) – úvod
• Příklad profilu bezpečnosti
• Funkčnost (functionality) a záruka (assurance)
• 7 úrovní záruky (EAL) – Společná kritéria
• Zajímavý příklad s Win2K
• Závěr
26
27
7 evaluation assurance levels (EALs)
• Hierarchical system – higher or new components
– bold faced text in the description for the added
components
• The following slides present first the EALs from a
practical perspective.
28
CC certified products by country & EAL
29
EAL1 – functionally tested
• analysis supported by independent testing of a
sample of the security functions;
• applicable where confidence in correct operation is
required but the security threat assessment is low.
• This EAL is particularly suitable for legacy systems
as it should be achievable without the assistance of
the developer.
30
EAL2 – structurally tested
• analysis exercises a functional and interface
specification and the high-level design of the
subsystems of the TOE;
• independent testing of the security functions;
• evidence required of developer 'black box' testing
and development search for obvious vulnerabilities.
• EAL2 is applicable where a low to moderate level of
independently assured security is required.
31
EAL3 – methodically tested and checked
• analysis supported by 'grey box' testing, selective
independent confirmation of the developer test
results and evidence of a developer search for
obvious vulnerabilities;
• development environment controls and TOE
configuration management are also required.
• EAL3 for a moderate level of independently assured
security, with a thorough investigation of the TOE
and its development, without incurring substantial reengineering
costs.
32
EAL4 – methodically designed, tested, and
reviewed
• analysis supported by the low-level design of TOE
modules and a subset of the implementation;
• testing supported by an independent search for
obvious vulnerabilities;
• development controls supported by a life-cycle
model, identification of tools and automated
configuration management.
• EAL4 for a moderate to high level security, where
some additional security-specific engineering costs
may be incurred.
33
EAL5 – semiformally designed and tested
• analysis includes all of the implementation;
• supplemented by a formal model, a semiformal
presentation of the functional specification and high
level design and a semiformal demonstration of
correspondence;
• search for vulnerabilities must ensure resistance to
penetration attackers with a moderate attack potential;
• covert channel analysis and modular design required.
• EAL5 for a high level of security in a planned
development coupled with a rigorous development
approach.
34
EAL6 – semiformally verified design and
tested
• analysis supported by a modular approach to
design and a structured presentation of the
implementation;
• independent search for vulnerabilities must ensure
resistance to penetration attackers with a high
attack potential;
• a systematic search for covert channels;
• EAL6 where a specialised security TOE is required
for high risk situations.
35
EAL7 – formally verified design and tested
• the formal model is supplemented by a formal
presentation of the functional specification and high
level design, showing correspondence;
• evidence of developer 'white box‘ testing and
complete independent confirmation of developer
test results.
• EAL7 where a specialised security TOE is required
for extremely high risk situations.
36
Agenda
• Kritéria hodnocení (bezpečnosti) – úvod
• Příklad profilu bezpečnosti
• Funkčnost (functionality) a záruka (assurance)
• 7 úrovní záruky (EAL) – Společná kritéria
• Zajímavý příklad s Win2K
• Závěr
37
Famous issue – Windows 2000
• Windows 2000 operating system was certified
(Common Criteria) at EAL-4 in 2002.
– with SP3 and one patch;
– EAL-4, augmented with ALC_FLR.3 (Systematic Flaw
Remediation);
– Microsoft invested millions of dollars and three years of
effort to gain the certification. (S. Bekker, Redmond
Magazine).
• Controlled Access Protection Profile (CAPP)
38
CAPP assumption A.PEER
“Any other systems with which the TOE communicates
are assumed to be under the same management
control and operate under the same security policy
constraints.
The TOE is applicable to networked or distributed
environments only if the entire network operates under
the same constraints and resides within a single
management domain.
There are no security requirements that address the
need to trust external systems or the communications
links to such systems.”
39
Controlled Access Protection Profile
• Level of protection appropriate for an assumed nonhostile
and well-managed user community
– requiring protection against threats of inadvertent or casual
attempts to breach the system security.
• The profile is not intended to be applicable to
circumstances in which protection is required
against determined attempts by hostile and well
funded attackers to breach system security.
• CAPP does not fully address the threats posed by
malicious system development or administrative
personnel.
40
Windows 2000 EAL-4 certification
• EAL4 rating means that you did a lot of paperwork
related to the software process, but says absolutely
nothing about the quality of the software itself. (J.S.
Shapiro)
• System disconnected from networks (at different
security level), disabled media drives, etc.
• Don't hook this to the internet, don't run email, don't
install software unless you can 100 percent trust the
developer, and if anybody who works for you turns
out to be out to get you, you are toast. (J.S. Shapiro)
41
Agenda
• Kritéria hodnocení (bezpečnosti) – úvod
• Příklad profilu bezpečnosti
• Funkčnost (functionality) a záruka (assurance)
• 7 úrovní záruky (EAL) – Společná kritéria
• Zajímavý příklad s Win2K
• Závěr
42
Vztah data certifikace a data CVE
43
Assurance viewed by…
• Customer – what level of guarantee do I get that
security has been implemented in the product?
• Developer – what (inputs and cooperation) will my
team have to provide for the evaluation?
• Evaluator – did I get all required inputs and did all
tests run OK to confirm the claim?
• Operator – what assumptions can I build on when
preparing for my actions?
44
Význam a výhody kritérií
• Usnadňují nasazení a používání bezpečných systémů
– jednodušší srovnávání a výběr podle skutečných
potřeb
• Usnadňují specifikaci požadavků
• Ujasňují požadavky na návrh a vývoj
Problémy kritérií (CC)
• Hodnocení není levné ani rychlé (>$100k, >3 měs)
• Certifikace platí jen pro přesně danou konfiguraci
(HW i SW!!)
• Marketingové označení “Common Criteria certified”
(ToE details, achieved EAL, PP conformance,
laboratory used…) není to stejné jako “Common
Criteria ready”
• Řada detailů hodnocení není veřejně dostupná
46
47
Certified
product
48
National Certificate
Authorizing Schemes
(BSI, ANSSI, NAIP…)
Common Criterial
Certification portal
https://www.commoncriteriaportal.org
/
Certification artifacts (Certificate, Security Target, Security Policy…)
Evaluation
laboratory
Vendor
NIST CMVP
(Cryptographic Module
Validation Program)
https://csrc.nist.gov/Projects/crypto
graphic-module-validation-program/
NIST CMVP portal
Common Criteria NIST FIPS 140-2/3
Seccerts webpage
https://seccerts.org/Seccerts git repository
https://github.com/crocs-
muni/sec-certs
Seccerts API
Python CLI, Jupyter Notebooks,
Binder, Docker
Extracted data (JSON)
Analyses and
visualizations
NVD vulnerability
database
https://nvd.nist.gov/
List of platforms and
vulnerabilities (CPE, CVE)
49
Vhledy…
50
DĚKUJI ZA POZORNOST!
51 I Vložte zápatí dokumentu
Použité zdroje
• Common Criteria for Information Technology Security
Evaluation, v 3.1, release 5, April 2017
– https://www.commoncriteriaportal.org/
• Separation Kernel Protection Profile Revisited: Choices
and Rationale, T.E. Levin et al., 4th Annual Layered
Assurance Workshop, 2010
• Common Criteria Certification in the UK – UK IT security
evaluation & certification scheme, CESG
• Understanding the Windows EAL4 evaluation, J.S.
Shapiro, IEEE Computer 03/2003
• https://seccerts.org
52