1. © Crown Copyright (2000) Module 2.6 Vulnerability Analysis

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

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

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

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

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

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

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

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

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

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

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

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

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

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

16. ITSEC Requirements - 3 ITSEC Figure 4

17. Common Criteria Requirements

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

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

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

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

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

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

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