© Crown Copyright (2000) Module 2.6 Vulnerability Analysis

You Are Here M2.1 Security Requirements M2.2 Development Representations M2.3 Functional Testing M2.4 Development Environment M2.5 Operational Environment M2.6 Vulnerability Analysis M2.7 Penetration Testing M2.8 Assurance Maintenance/Composition MODULE 2 - ASSURANCE

What is Vulnerability Analysis? A search for vulnerabilities in the TOE or its intended operation Analysis of their impact Input to penetration testing Involves –assessment of developers analysis –evaluator analysis based on previous results

Vulnerabilities - A Few Terms potential vulnerability –suspected, not proven known vulnerability –demonstrated by developer or evaluator exploitable vulnerability –leading to compromise of assets non-exploitable vulnerability –assets will not be compromised in practice

Sources of Vulnerability The security functions could be inadequate to counter the threats incorrectly implemented bypassed tampered with directly attacked misused

Bypassing Attacks Avoid monitored interface Inherit privilege to bypass Access unprotected area Attacker Asset Security Function

Covert Channels Subject A Resource Subject B Reads Modifies Access Denied Unclassified Secret

Tampering Attacks Modify/spoof/read critical data Undermine assumptions/dependencies De-activate, disable or delay enforcement Attacker Asset Security Function

Direct Attacks Security function behaves as specified Attacker manipulates input/outputs Attacker Asset Security Function

Misuse Consider all modes of operation Examine potential for insecure states: –mis-configuration of security functions –insecure use of TOE Can insecure states be detected or prevented? Repeat/witness TOE installation procedures

Exploitability Are known vulnerabilities exploitable? Suitable countermeasures –procedural –technical Relevance to Security Target? Within attacker capabilities?

Strength Determination - 1 Confirm minimum strength met LevelResistant to BasicCasual unsophisticated attacks MediumKnowledgeable attackers with limited opportunities or resources HighBeyond normal practicality to defeat

Strength Determination - 2 STRENGTH RATING Detection Equipment Time Collusion Expertise Chance

ITSEC Requirements - 1 Effectiveness Analysis Developer Analysis –Binding –Strength of Mechanisms –Ease of Use –Construction & Operational Vulnerability Assessment Independent Vulnerability Analysis

Binding Analysis Analysis of mechanism interactions –permissible –mandatory –forbidden Protection against indirect attack Absence of conflict ITSEC Requirements - 2

ITSEC Requirements - 3 ITSEC Figure 4

Common Criteria Requirements

Evaluation Reporting Examination of documentation –show how & where requirements satisfied Analysis –demonstrate completeness with respect to vulnerabilities considered –justify non-exploitability

Summary Methodical search for vulnerabilities –checklist approach Validation of developer analysis –confirm absence of exploitable vulnerabilities Independent analysis by evaluators Input to penetration testing

Further Reading - 1 ITSEC Evaluation UKSP 05 Part III, Chapter 3 UKSP 05 Part V UKSP 04 Part III, Chapter 4 ITSEM, Annex 6.C

Further Reading - 2 CC Evaluation CC Part 3, Sections and 14 CEM Part 2, Chapters 6-8 (AVA sections) & Annex B UKSP 05 Part V

Exercise 1 - Vulnerabilities Client Object Server Mechanism access request notify object mediates subject (client) object details

Exercise 2 - Strength Password mechanism can be defeated by –manual attack, taking 20 days –automated attack, taking 5 minutes What is the strength of this mechanism? How might the strength be improved?

Exercise 3 - Misuse Should lamp be lit in –CIPHER mode? –CLEAR mode? CRYPTO DEVICE DATA CIPHER Encrypted CLEAR Cleartext