IT-Security Evaluation Criteria

IT-Security Evaluation Criteria
Why we need IT Security Evaluation Criteria:
- objective yardstick
- guideline for evaluation and certification of IT-Security
- stimulation of manufacturers to build secure commercial products
- legal requirements (§ 14 German Digital Signature Act, § 17 Digital
Signature Ordinance)
History of Documents:
USA:
Trusted Computer Evaluation Criteria,
(TCSEC, Orange Book), DoD, 1983/1985
Federal Criteria, NIST, NSA, 1st Draft, December 1992
Europe:
Information Technology Security Evaluation Criteria,
(ITSEC), EC-Commission, V 1.2, June 1991
Canada:
The Canadian Trusted Computer Product Evaluation Criteria, (CTCPEC),
Canadian System Security Centre, V 3.0e, January 1993
Europe, USA, Canada:
Common Criteria VERSION 2.1 / ISO IS 15408, August 1999
Tillämpad datasäkerhet (DAVC17) – Security Evaluation Criteria Simone Fischer-Hübner 1
Tillämpad datasäkerhet (DAVC17) – Security Evaluation Criteria Simone Fischer-Hübner 2
TCSEC (Orange Book)
Scope:
- Protection of confidentiality of classified information processed by DoD
- oriented towards on mainframe computer systems
- Interpretations of TCSEC for other systems:
• Trusted Network Interpretation (Red Book), 1987
• Trusted Database Management System Interpretation (Lavender Book),
1991
Four Divisions (D, C, B, A) with 7 hierarchically- ordered security classes
(D, C1, C2, B1, B2, B3, A1)
with increasing security requirements for the aspects:
- Security policy
Functionality (contains what a system
- Accountability does to be secure)
- Assurance
Quality (confidence that may be held
- Documentation in the correct enforcement)
- Certification of systems by the National Computer Security Centre (NCSC)
Tillämpad datasäkerhet (DAVC17) – Security Evaluation Criteria Simone Fischer-Hübner 3
Tillämpad datasäkerhet (DAVC17) – Security Evaluation Criteria Simone Fischer-Hübner 4

Summary of TCSEC- Security Classes:
Division C: Discretionary Protection:
Division D/ Class D: Minimal Protection:
- unrated, no security characteristics required
Class C1: Discretionary Security Protection:
- for cooperating users processing at the same level of security
- discretionary access controls (DAC): users can protect their own data and
keep other users from accidentally reading or destroying their data
- identification and authentication
- penetration testing
-
Example: MVS/RACF
Tillämpad datasäkerhet (DAVC17) – Security Evaluation Criteria Simone Fischer-Hübner 5
Tillämpad datasäkerhet (DAVC17) – Security Evaluation Criteria Simone Fischer-Hübner 6
C2: Controlled Access Protection:
Features of C1 +:
- more finely grained DAC:
protection must be implementable at the degree of a single user
- auditing
- object reuse
Examples: VAX VMS, MVS/ACF, Windows NT
Division B: Mandatory Protection
Class B1: Labelled Security Protection:
Features of C2 +:
- informal statement of security model
- security labelling
- mandatory access control (MAC) policy of the Bell LaPadula model
- thorough analysis and testing of design documentation,
source code, object code,
- removal of security related flaws
Examples: Trusted Solaris CMW 1.1, Trusted Oracle 7, Unix System V/MLS
Tillämpad datasäkerhet (DAVC17) – Security Evaluation Criteria Simone Fischer-Hübner 7
Tillämpad datasäkerhet (DAVC17) – Security Evaluation Criteria Simone Fischer-Hübner 8

Class B2: Structured Protection:
Features of B1 +:
- formal security model
- descriptive top-level specification (DTLS)
- DAC and MAC enforcement shall be applied to all subjects and objects (also
devices)
- covert channel analysis
- TCB must be structured into protection critical and non-protection critical
elements (TCB: security-relevant portions of a system)
- authentication mechanisms are strengthened
- more thorough testing and code review
- system is “relatively resistant to penetration”
- separate operator and administrator functions
-
Example: Honeywell Multics
Tillämpad datasäkerhet (DAVC17) – Security Evaluation Criteria Simone Fischer-Hübner 9
Class B3: Security Domains:
Features of B2 +:
- TCB satisfies the reference monitor concept
- TCB is structured to exclude code not essential to security policy
enforcement
- auditing mechanisms signal security-related events
- system recovery procedures
- the system is highly resistant to penetration
- convincing argument shall be given that DTLS is consistent with the model
- system is “highly resistant to penetration”
Tillämpad datasäkerhet (DAVC17) – Security Evaluation Criteria Simone Fischer-Hübner 10
Division A: Verified Protection
Class A1: Verified Design:
Systems in A1 are functionally equivalent to those in B3,
but Class A1 requires a formally verified system design
Formal Model
Formal Top-Level
Specification
Implementation
demonstration using formal or informal techniques
consistency informally shown
ITSEC
Harmonisation and extension of existing national criteria:
- UK Systems Security Confidence Levels, CESG 1989
- UK DTI Commercial Computer Security Centre
Evaluation Manual/ Functionality Manual 1989
- German IT-Security Criteria, ZSI (now BSI) 1989
- French "Blue-White-Red Book", SCSSI 1989
Aim:
- compatible basis for certification by national certification bodies
- mutual recognition of evaluation results
Example: Honeywell Scomp
Tillämpad datasäkerhet (DAVC17) – Security Evaluation Criteria Simone Fischer-Hübner 11
Tillämpad datasäkerhet (DAVC17) – Security Evaluation Criteria Simone Fischer-Hübner 12

Main differences to TCSEC:
- Security in ITSEC is defined as:
• Confidentiality
• Integrity
• Availability
- ITSEC separates/decouples functionality and quality/assurance
requirements
- ITSEC is aimed at the evaluation of both products and systems (Target of
Evaluation - TOE)
Product: hardware/software package that can be incorporated into
a variety of systems
System: specific IT installation with a particular purpose and known
operational environment
Tillämpad datasäkerhet (DAVC17) – Security Evaluation Criteria Simone Fischer-Hübner 13
Functionality:
Sponsors of evaluation define security functionality either by
a.) predefined example functionality classes (Annex A):
F-C1
F-C2
F-B1
F-B2
F-B3
F-IN:
F-AV:
F-DI:
F-DC:
F-DX:
hierarchically ordered confidentiality classes,
correspond closely to the functionality
requirements of TCSEC classes C1 to B3
Integrity of Data/ Programs
System Availability
Integrity of Data during Data Exchange
Confidentiality of Data during Data Exchange
Confidentiality and Integrity of information to be exchanged in networks
(possible combinations of functionality classes: one or none of F-C1, F-C2, F-B1, F-B2,
F-B3 and a subset of {F-IN, F-AV, F-DI, F-DC, F-DX})
Tillämpad datasäkerhet (DAVC17) – Security Evaluation Criteria Simone Fischer-Hübner 14
b.) Specifying individual functionality claims
It is recommended to use the following generic headings:
- Identification & Authentication
- Access Control
- Accountability
- Object Reuse
- Audit
- Accuracy
- Reliability of Service
- Data Exchange
Quality/Assurance:
Confidence in the
- correctness of the implementation
- effectiveness of the security functions and mechanisms
Correctness:
7 (hierarchically ordered) evaluation levels are defined representing ascending
levels of the confidence in the correctness of a TOE:
E0 E1 E2 E3 E4 E5 E6
no confidence highest confidence
Tillämpad datasäkerhet (DAVC17) – Security Evaluation Criteria Simone Fischer-Hübner 15
Tillämpad datasäkerhet (DAVC17) – Security Evaluation Criteria Simone Fischer-Hübner 16

Effectiveness:
- assesses suitability of the functionality, binding of the functionality, ease of
use
- deals with the strength of the security enforcing mechanism, assesses the
ability to withstand direct attacks
- If an exploitable vulnerability exists: Overall evaluation level = E0
Correspondence between ITSEC and TCSEC:
ITSEC: TCSEC:
EO D
F-C1, E1 C1
F-C2, E2 C2
F-B1, E3 B1
F-B2, E4 B2
F-B3, E5 B3
F-B3, E6 A1
Tillämpad datasäkerhet (DAVC17) – Security Evaluation Criteria Simone Fischer-Hübner 17
Tillämpad datasäkerhet (DAVC17) – Security Evaluation Criteria Simone Fischer-Hübner 18
Common Criteria (CC):
http://csrc.nist.gov/cc/
Objectives:
- Harmonised criteria widely useful within the international community
- World-wide mutual recognition of evaluation results
- International standard (ISO IS 15408)
CC Structure:
Part 1: Introduction and General Model
Part 2: Security Functional Requirements
Part 3: Security Assurance Requirements
CC Project Sponsoring Organisations:
National Security agencies of
- Canada
- Germany
- France
- The Netherlands
- UK
- USA (NSA, NIST)
Tillämpad datasäkerhet (DAVC17) – Security Evaluation Criteria Simone Fischer-Hübner 19
Tillämpad datasäkerhet (DAVC17) – Security Evaluation Criteria Simone Fischer-Hübner 20

Organisation and Construction of Security Requirements:
Classb Family k Component Packages
Component
…. Protection Profile
Component Possible
Input sources
for PP
Classa Familiy j Component
Package:
Reusable set of either functional or assurance components (e.g, EALs )
Security Target (ST):
Set of security requirements used as a basis for evaluation of an identified
TOE
Family i Component
Component
…,
Component Security Target
Possible
Component Optional extended input sources
…… (non-CC) Security for ST
Component Requirements
Tillämpad datasäkerhet (DAVC17) – Security Evaluation Criteria Simone Fischer-Hübner 21
Tillämpad datasäkerhet (DAVC17) – Security Evaluation Criteria Simone Fischer-Hübner 22
Protection Profile (PP):
Implementation-independent, reusable set of security-requirements for a
category of TOEs that meet specific consumer needs
Example PPs:
- Commercial security profile
- Profiles to replicated TCSEC C2 and B1 requirements
- A role based access control (RBAC) profile
- Smart card profiles
- Firewall profiles
CC registry system for approved PPs
Functional Security Requirements (Part 2):
Classes of Security Functional Requirements:
• FAU (Security Audit)
• FCO (Communication/Non-Repudiation)
• FCS (Cryptographic Support)
• FDP (User Data Protection)
• FIA (Identification and Authentication)
• FMT (Security Management)
• FPR (Privacy)
• FPT (Protection of the TOE Security Functions)
• FRU (Resource Utilisation)
• FTA (TOE Access)
• FTP (Trusted path/channels).
Tillämpad datasäkerhet (DAVC17) – Security Evaluation Criteria Simone Fischer-Hübner 23
Tillämpad datasäkerhet (DAVC17) – Security Evaluation Criteria Simone Fischer-Hübner 24

Example: Class-Family-Component Hierarchy:
Class Family Components
Identification and Authentication Authentication Failure
Authentication Failures Handling
FIA FIA_AFL FIA_AFL.1
……
User Authentication Timing of Authentication
FIA_UAU FIA_UAU.1
…..
Re-Authenticating
FIA_UAU.6
Protected Authentication Feedback
FIA_UAU.7
Assurance Requirements (Part 3):
Classes of assurance components (covering the correctness and
effectiveness:
• ACM (Configuration Management)
• ADO (Delivery and Operation)
• ADV (Development)
• AGD (Guidance Documentation)
• ALC (Life-Cycle Support)
• ATE (Tests)
• AVA (Vulnerability Assessment)
User Identification Timing of Identification
FIA_UID FIA_UID.1
……
….. ……. ……
Tillämpad datasäkerhet (DAVC17) – Security Evaluation Criteria Simone Fischer-Hübner 25
Tillämpad datasäkerhet (DAVC17) – Security Evaluation Criteria Simone Fischer-Hübner 26
Useful combinations of assurance components are combined into seven
Evaluation Assurance Levels (EALs):
EAL1 – functionally tested (new)
EAL2 – structurally tested (like C1 – E1)
EAL3 – methodically tested and checked (like C2 – E2)
EAL4 – methodically designed, tested, and reviewed (like B1 – E3)
EAL5 – semiformally designed and tested (like B2 – E4)
EAL6 – semiformally verified design and tested (like B3 – E5)
EAL7 – formally verified design and tested (like A1 – E6)
Shortcomings
• Costs of evaluation (10% - 40%) of developing costs
• Time delay until an evaluation is completed
• Cost of re-evaluating new versions of an evaluated product
• Certificates only apply to a particular version and a particular configuration of
a product
• Criteria have been biased on protecting system owners and operators, no
satisfactory protection of usees
• CC are too voluminous and complex
Tillämpad datasäkerhet (DAVC17) – Security Evaluation Criteria Simone Fischer-Hübner 27
Tillämpad datasäkerhet (DAVC17) – Security Evaluation Criteria Simone Fischer-Hübner 28