IT Security Evaluation Why do we need security evaluation To - - PDF document

it security evaluation why do we need security evaluation
SMART_READER_LITE
LIVE PREVIEW

IT Security Evaluation Why do we need security evaluation To - - PDF document

IT Security Evaluation Why do we need security evaluation To provide a basis for specifying security expectations To verify that a computer product/system fulfills the requirements imposed on it To establish a metric for the degree


slide-1
SLIDE 1

1

IT Security Evaluation Why do we need security evaluation

To provide a basis for specifying

security expectations

To verify that a computer

product/system fulfills the requirements imposed on it

To establish a metric for the degree of

trust that can be placed on a security product/system

To guide developers which security is

expected

slide-2
SLIDE 2

2

Some Security Standards

Aiming for evaluation

Evaluation process

Evaluation Framework

Source: Common Evaluation Methodology for Information Technology Security

slide-3
SLIDE 3

3

Evaluation principles

Appropriate

The evaluation activities should be appropriate to

the intended level of assurance

Impartial

All evaluations shall be free from bias

Objective

Minimum subjective judgment that is possible

Repeatable

Given the same process and TOE the same

evidence should yield the same result

Sound

The result should be complete and technical

correct

Key Parties in evaluation

Evaluator

Conducts the evaluation according to the

methodology

Developer

Seeks for evaluation

and choose the evaluation criteria

Consumer

Consumes the

evaluation report

CEM for CC as example

Source: Common Evaluation Methodology for Information Technology Security

slide-4
SLIDE 4

4

Roles in Evaluation

CEM for CC as example

Source: Common Evaluation Methodology for Information Technology Security

Product/System Evaluation

slide-5
SLIDE 5

5

History – Product/System Evaluation

Trusted computer evaluation criteria (TCSEC) DoD 1985 Information Technology security evaluation criteria (ITSEC) EU 1991 UK system security confidence levels 1989 German IT-Security criteria 1989 French „Blue- White-Red“ Book 1989 Canadian Trusted Computer Product evaluation criteria 1993 Common criteria (CC) ISO 1999

TCSEC

Scope

Protection of confidentiality of classified

information processed by DoD

Oriented towards isolated computer systems

(mainframe)

Historic but well known and the base for most

  • ther product evaluation standards

Also known as “Orange Book”

slide-6
SLIDE 6

6

TCSEC Requirements

Security policy What security (access to resoruces) is required in the system/product Accountability How the system links individuals to actions and audit orderly behavior Functionality What does the system to be secure Assurance How certain can we be that the functionality is correct Documentation How well is the functionality and the development documented Quality Is the defined security enforced in the expected way

TCSEC Hierachy

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

C1 Discretionary security protection C2 Controlled Access protection

Class B – Mandatory Protection

B1 Labeled Security Protection B2 Structured Protection B3 Security Domains

Class A – Verified Protection

A1 Verified Design

slide-7
SLIDE 7

7

Common Criteria

Harmonized criteria for the international

community for evaluation and recognition

ISO IS 15408

Currently Version 2.1 from August 1999

Available at: http://csrc.nist.gov/cc/index.html

The scope of the common criteria covers

Systems and Products

Target of evaluation

Target Of Evaluation (TOE)

An IT product or system and its associated

administrator and user guidance documentation that is the subject of an evaluation.

slide-8
SLIDE 8

8

TOE Evaluation Process Requirements construction and organization

Source: Common criteria

slide-9
SLIDE 9

9

Requirement expression

Class

A grouping of families

that share a common focus

Family

A grouping of components that share security

  • bjectives but may differ in emphasis or rigour

Component

The smallest selectable set of elements that may

be included in a PP, an ST, or a package

Source: Common criteria

Requirement use

Package

A reusable set of either functional or assurance

components (e.g. An EAL), combined together to satisfy a set of identified security objectives

Security Target

A set of security requirements and specifications

to be used as the basis for evaluation of an identified TOE

Protection Profile

An implementation-independent set of security

requirements for a category of TOEs that meet specific consumer needs

slide-10
SLIDE 10

10

Functional Security Requirements

Class FAU: Security audit Class FCO: Communication Class FCS: Cryptographic support Class FDP: User data protection Class FIA: Identification and authentication Class FMT: Security management Class FPR: Privacy Class FPT: Protection of the TSF Class FRU: Resource utilisation Class FTA: TOE access Class FTP: Trusted path/channels

Example: FCO Communication

FCO Non-repudiation

  • f origin ensures that

the originator of information cannot successfully deny having sent the information.

FCO_NRO.1 Selective proof of origin requires the TSF to

provide subjects with the capability to request evidence

  • f the origin of information.

FCO_NRO.2 Enforced proof of origin requires that the

TSF always generate evidence of origin for transmitted information.

slide-11
SLIDE 11

11

Assurance Requirements

Class ACM: Configuration management Class ADO: Delivery and operation Class ADV: Development Class AGD: Guidance documents Class ALC: Life cycle support Class ATE: Tests Class AVA: Vulnerability assessment

Combination of assurance requriements –

Evaluation Assurance Level (EAL)

EAL1 - functionally tested EAL2 - structurally tested EAL3 - methodically tested and checked EAL4 - methodically designed, tested

and reviewed

EAL5 - semiformally designed and tested EAL6 - semiformally verified design and

tested

EAL7 - formally verified design and

tested

TOE is designed with evaluation in mind Evaluation is not a primary goal during design

slide-12
SLIDE 12

12

Combination of assurance requriements –

Evaluation Assurance Levels

Source: Common criteria

Protection Profile

Source: Common criteria

slide-13
SLIDE 13

13

Protection Profile

Protection profiles focus on an area specified

by the sponsor

No single repository – e.g. US Government PP

  • r German BSI PP

Example areas:

RBAC Profiles Firewall Profiles IDS Profiles Biometric Profiles PKI Profiles OS Profiles

Protection Profile Title: Role-Based Access Control Protection Profile

http://www.cesg.gov.uk/site/iacs/i tsec/media/protection- profiles/RBAC_987.pdf

slide-14
SLIDE 14

14

Functional Requirements Functional Requirements

slide-15
SLIDE 15

15

Evaluation Preperation

Initiation

The sponsors starts

the process

Feasibility study

The evaluator checks

if the evaluation can be performed

A list of evaluation

deliverables is included where all involved parties agree to

Source: Common Evaluation Methodology for Information Technology Security

slide-16
SLIDE 16

16

Evaluation Conduct

Evaluation

Review the evaluation

deliverables and perform evaluator actions required by the assurance criteria

Observation 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

  • verseer review

Source: Common Evaluation Methodology for Information Technology Security

slide-17
SLIDE 17

17

Process Evaluation Systems Security Engineering Capability Maturity Model

SSE-CMM is a process reference model SSE-CMM concern the system security

engineering activities for a secure product or a trusted system addressing the complete lifecycle

ISO Standard 21827

Available at: http://www.sse-cmm.org/index.html

slide-18
SLIDE 18

18

Process areas - Security Best Practices

PA01 – Administer Security Controls PA02 – Assess Impact PA03 – Assess Security Risk PA04 – Assess ThreatPA05 – Assess Vulnerability PA06 – Build Assurance Argument PA07 – Coordinate Security PA08 – Monitor Security Posture PA09 – Provide Security Input PA10 – Specify Security Needs PA11 – Verify and Validate Security

Process areas – Project and Organizational Best Practices

PA12 – Ensure Quality PA13 – Manage Configurations PA14 – Manage Project Risk PA15 – Monitor and Control Technical Effort PA16 – Plan Technical Effort PA17 – Define Organization's Systems Engineering

Process

PA18 – Improve Organization's Systems Engineering

Processes

PA19 – Manage Product Line Evolution PA20 – Manage Systems Engineering Support

Environment

PA21 – Provide Ongoing Skills and Knowledge PA22 – Coordinate with Suppliers

slide-19
SLIDE 19

19

Capability Levels SSE Appraisal Method

Source: SSE-CMM