julian straw iccc september 2007
Post on 10-Feb-2016
32 Views
Preview:
DESCRIPTION
TRANSCRIPT
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?
top related