Julian StrawICCC September 2007

Outline

• Status of v3.1 revisions

• Analysis of evaluation trends in 2006/7

• The need for progress to v4

• Issues for the development of v4

• Ideas for change in v4

Achievements of v3.1

• Rationalisation of ST/PP requirements

• ST Lite for EAL1

• Restructuring of lifecycle requirements under ALC

• Security architecture ADV_ARC

• Removal of two layer design approach ADV_TDS

• More focus on security critical aspects of design

• Revised vulnerability approach AVA_VAN

• Composition approach ACO

Unfinished business in v3.1

• Part 2 needs not addressed

• Need for improved guidance in CEM, especially at higher assurance

• Composition approach and packages untried and will need revision

• Need to improve appeal of high and low assurance levels

• Underlying platform assurance

• Development environment assurance

• Assurance continuity

Why think about CCv4?

• Issues remaining unresolved in CCv3

• Lead times for new criteria are long– Consult

– Discuss

– Develop

– Review

– Agree

• Need to begin now for e.g. 2011 release

• Existence of other initiatives indicates need to improve

• There are new ideas to consider

Issues for v4

• What to change?

• What balance to achieve between compliance checking and vulnerability search?

• Who to consult?– A voice for vendors?

• When to release?– Every 5 years?

• How to manage the process?

Completed evaluationsJan 2006 - Sep 2007 EAL7,1

EAL5,18 EAL1, 11

EAL2, 81

EAL3, 73

EAL4,114(38%)

Source: CC portal

0

20

40

60

80

100

120

EAL1 EAL2 EAL3 EAL4 EAL5 EAL6 EAL7

Analysis of trends

• Very few evaluations at EAL1– v3 addresses this to some degree with ST Lite– Little evidence of demand stimulus despite improvements– Should v4 go further to meet demand for low-cost, 3rd party testing– Should EAL1 be the most common level?

• Very few evaluations above EAL4– Design requirements are high cost for little perceived benefit– Evaluation duration too long for product cycle– Perceived/actual difficulty of going above EAL4

• Continuing stream of new entrants– >40 new vendors on EPL so far in 2007

Emphasis of v3 assurance classes

Process quality

Def

ect r

educ

tion

AVA

ALC

AGD

ATE

ADV

What do wewant from CC?

What can CCDeliver?

Augmentations at EAL4+Jan 2006 – Sep 2007

05

1015202530354045

Analysis of augmentations

• Demonstrates need for attainable assurance beyond EAL4– 80% of EAL4 evaluations use augmentation

– No use made of design augmentation

– Most popular are source code and vulnerability assessment

• Understanding nature of + quite hard

• Use of augmentation should be encouraged

• Need to provide some structure

+++

X

The need for change

• Part 2 – Reassess v3.0

• Part 3– Bring FLR into assurance levels?

– Code analysis family

– Control use of +

– Introduce assurance scores to augment/replace EALs

– Revisit pass/fail notion

ten things

CC v3.0 Part 2

• Completely overhauled and rationalised

• Classes 11>6, families 67>45, pages 354>130

• Concepts simplified and clarified

….but

• Created problems for transition

• Major re-learning effort required

• Uncertainty over correctness

• Abandoned due to time constraints

• Needs to be revived and reconsidered

Basic assurance scoring

• Objective– To replace use of + with more meaningful information

• Approach– Allocate each component a number of points

– Result then becomes EAL4(+n)

• Benefit– Gives more credit to more onerous augmentations

– Shows degree of augmentation

Enhanced assurance scoring

• Objective– To give finer granularity of assurance measure and to permit

substitutions

• Approach– Allocate each component a number of points – Abolish assurance levels– Assurance then be represented as points A(n)

• Benefits– Encourages more thought about assurance profile– Allows substitutions (e.g. more source code analysis and less design)– Allows evaluations to focus on vulnerability search or process quality

Removal of pass/fail paradigm

• Objective– To provide more information about the TOE– To increase evaluation flexibility

• Approach– Allocate each component a number of points– Evaluation result scores some % of those points for each component– Results given as % score and a sheet giving points breakdown– Only exploitable vulnerabilities cause failure

• Benefits– Faster evaluations as no delays while evidence is created– Greater differentiation between products

Better entry level evaluations

• Need to decide what is the minimum assurance required to use the CC mark

• Need to generate greater demand for entry level evaluations– Just 6 EAL1 certificates in 2007

• Third party testing of simple claims statement?

CC organisational issues

• Number of certificate authorising nations has risen from 6 to 11 (+13 certificate consuming)

• Many schemes under greater financial/resource pressure

• Resource turnover high

• National specialisations influence needs

• Commitment level uncertain

• Change process model unclear

"You MUST be the change you wish to see in the world."--Mahatma Gandhi

• The process needs ideas

• We must observe how the CC is used

• We must apply the results of our experience and that of other approaches

• Penalty for inaction– CC seen as less relevant

– National divergence

• The time for action is now

Thank you

Questions?