Julian Straw ICCC September 2007

1. Issues for CC v4 Julian Straw ICCC September 2007

2. 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

3. 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 v3.1

4. 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

5. 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

6. 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?

7. EAL7,1 EAL1, 11 EAL5,18 EAL2, 81 EAL4,114 (38%) EAL3, 73 Completed evaluationsJan 2006 - Sep 2007 Source: CC portal

8. 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

9. Emphasis of v3 assurance classes AVA What do we want from CC? ATE What can CC Deliver? ADV Defect reduction AGD ALC Process quality

10. Augmentations at EAL4+Jan 2006 – Sep 2007

11. 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 + + +

12. 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

13. 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

14. 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

15. 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

16. 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

17. 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?

18. 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

19. "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

20. Thank youQuestions? v4.0