1

IT Security Evaluation

Simone Fischer-Hübner

Why do we need securityevaluationTo provide a basis for specifying security expectationsTo verify that a computer product/system fulfills the requirements imposed on itTo establish a metric for the degree of trust that can be placed on a security product/system (“objective yardstick”)To guide developers which security is expectedTo fulfil legal requirements (§ 14 German Digital Signature Act, § 17 Digital Signature Ordinance)

Some Security Standards

Aiming for evaluation

Presented in this lecture

History – Product/System Evaluation

Trusted ComputerEvaluation Criteria

(TCSEC)DoD 1985

Information TechnologySecurity Evaluation

Criteria (ITSEC)EU 1991

UK system securityconfidence levels

1989

German IT-SecurityCriteria1989

French „Blue-White-Red“ Book

1989 Canadian TrustedComputer ProductEvaluation Criteria

1993

Common Criteria(CC)

ISO 1999

The Federal Criteria

NIST/NSA 1992

TCSECScope

Protection of confidentiality of classified information processed by DoDOriented towards isolated computer systems (mainframes)Interpretations of TCSEC for other systems:

Trusted Network Interpretation (Red Book), 1987Trusted Database Management System Interpretation(Lavender Book), 1991

Historic but well known and the base for most other product evaluation standardsAlso known as “Orange Book”

TCSEC Requirements

2

TCSEC Hierarchy Class D – Minimal Protection (unrated)Class C – Discretionary Protection

C1 Discretionary security protectionC2 Controlled Access protection

Class B – Mandatory ProtectionB1 Labeled Security ProtectionB2 Structured ProtectionB3 Security Domains

Class A – Verified ProtectionA1 Verified Design

Increasing requirements for

functionality & quality

Common CriteriaHarmonized criteria for the international community for evaluation and recognition

ISO IS 15408Current Version 3.1 from 2006/2007

Available at: http://www.commoncriteriaportal.org/The scope of the common criteria covers

Systems (specific IT installation with a particular purpose and known operational environment)

andProducts (hardware/software package that can be incorporated

into a variety of systems )

Common Criteria Structure

Part 1: Introduction and General ModelPart 2: Security Functional RequirementsPart 3: Security Assurance Requirements

Target of evaluation

Target Of Evaluation (TOE)An IT product or system possibly accompanied by guidance documentation that is the subject of an evaluation

Requirements construction and organization

Source: Common criteria

Requirement expression

ClassA grouping of families that share a common focus

FamilyA grouping of components that share security objectives but may differ in emphasis or rigor

ComponentThe smallest selectable set of elements that may be included in a PP, a ST, or a package

Source: Common criteria

3

Requirement use

PackageA reusable set of either functional or assurance components (e.g. An EAL), combined together to satisfy a set of identified security objectives

Security Target (ST)A set of security requirements and specifications to be used as the basis for evaluation of an identified TOE

Protection Profile (PP)An implementation-independent, re-usable set of security requirements for a category of TOEs that meet specific consumer needs

Protection Profile

Source: Common criteria

Protection ProfileProtection profiles focus on an area specified by the sponsorNo single repository – e.g. US Government PP or German BSI PP Example areas:

RBAC ProfileFirewall ProfilesIDS ProfilesBiometric ProfilesPKI ProfilesOS Profiles

Functional SecurityRequirements

Class FAU: Security audit Class FCO: Communication Class FCS: Cryptographic supportClass FDP: User data protectionClass FIA: Identification and authenticationClass FMT: Security management Class FPR: PrivacyClass FPT: Protection of the TSF Class FRU: Resource utilisationClass FTA: TOE accessClass FTP: Trusted path/channels

Example: FCO CommunicationFCO Non-repudiation of origin ensures that the originator of information cannot successfully deny having sent the information.

FCO_NRO.1 Selective proof of origin requires the TSF (TOE Sec. Funct.) to provide subjects with the capability to request evidence of the origin of information.FCO_NRO.2 Enforced proof of origin requires that the TSF always generate evidence of origin for transmitted information.

Assurance Requirements

Class ACM: Configuration managementClass ADO: Delivery and operationClass ADV: DevelopmentClass AGD: Guidance documentsClass ALC: Life cycle supportClass ATE: TestsClass AVA: Vulnerability assessment

4

Combination of assurance requriements –

Evaluation Assurance Level (EAL)

EAL1 - functionally testedEAL2 - structurally testedEAL3 - methodically tested and checkedEAL4 - methodically designed, tested and reviewedEAL5 - semiformally designed and testedEAL6 - semiformally verified design and testedEAL7 - formally verified design and testedTO

E is

desi

gned

with

eval

uatio

nin

min

d

Eval

uatio

n is

not

a

prim

ary

goal

du

ring

desi

gn

Combination of assurance requriements –

Evaluation Assurance Levels

Source: Comm

on criteria

Evaluation Preperation

InitiationThe sponsors starts the process

Feasibility studyThe evaluator checks if the evaluation can be performedA list of evaluation deliverables is included where all involved parties agree to

Source: Common Evaluation Methodology for Information Technology Security

Evaluation ConductEvaluation

Review the evaluation deliverables and perform evaluator actions required by the assurance criteriaObservation reports can be generated during the evaluation

Evaluation Technical Report is produce

It contains the verdict and the justification

Source: Common Evaluation Methodology for Information Technology Security

Evaluation Conclusion

Conformance to CC assessed

The overseer reviews the ETR for conformance with the CC

Evaluation Summary report is generated

It bases on the ETR and includes the result of the overseer review

Source: Common Evaluation Methodology for Information Technology Security