Software Engineering for Security: a Roadmap

1. Software Engineering for Security: a Roadmap By: PremKumar T. Devanbu (UC Davis) Stuart Stubblebine (CertCo)

2. Overview • Paper tries to highlight Interactions between SE and Security. • Structured like waterfall approach • Main points of focus include: • Security Policy & Requirements • Re-engineering for security and related challenges • Software Piracy & Protection issues • Trusting Software Components • Verification of Systems • Secure Software Deployment

3. Requirements and Policies • Security, like beauty, is in the eye of beholder. • Policy = Requirements ? • Security Models and Policies • Mandatory Access Control (MAC) • Discretionary Access Control (DAC) e.g Capabilities in Amoeba • Multilevel Security model • Challenges: • Unifying Security with Systems Engineering • Unifying Security and system Models • Unified system and security policy design • Modularity, compactness and reuse in policy representation • Leverage of existing standards based tools

4. Re-engineering for security • Security is an afterthought • Challenges: • Legacy Security Mismatches • E.g. UNIX and CORBA ? • Wrappers and sandboxes • Separating the Security “Aspect” • AOP / Crosscutting concerns / Aspect Weavers • Component/Connectors

5. Software Piracy and Protection • Adversary Economics Cost of one item Cost of first hack the copy protection Cost of each item after hacked Risks of getting caught(prosecution Prob.) Possibly subjective cost of each item(fine) Good things in life are for free For rest, you pay a license fee !

6. Piracy: Approaches to Protection(Contd..) • Hardware and Software Tokens • Dongle/Dynamic tokens ( raise Ch ) • Problems: Code Patching • Dynamic Decryption of Code • Problems: Memory monitoring / nobody uses it • Watermarking – Stealth and Resilience • Static and Dynamic approaches • More successful in digital image and sound • Code Partitioning • ROM (address Instruction map) • Secure Server (Performance and Privacy) • Smart Cards (Space/Processor) • Challenge: Attacker Cost Model

7. Trusting Software Components • Related to increasing use of COTS • Black box Approaches • Grey Box Approaches • Cryptographic Coverage Verification • Unbiased Coin Flip • Tamper Resistant Hardware • Proof Checker on a smart card • Challenge: More Grey box approaches

8. Verification of Systems • Important due to increase in use of COTS • Formal methods: • Significant human labour  Expensive • Based in specs rather then implementation • Hence, “confidence subjected to fidelity and completeness of specs and their relation to final implementation” • Don’t guarantee complete elimination of defects • Challenge: Implementation-based verification methods

9. Secure Software Deployment • Post Deployment Configuration Management (PDCM) • Challenges: • Controlled Delegation • Multiple sites with varying levels of trust • User may rely upon PDCM admin to identify trusted sources • Privacy Protection

10. Secure Computation • Test Oracle required - Proof of Correctness of test results • Proof Checkers • Quorum’s for distributing trust – Performance Issues • Secure Data Structures • Proof carrying answers – either prove correct or prove violation

11. Strengths/Weaknesses • Strengths • Merges the two fields of SE and Security well by pointing various commons grounds and challenges • Brings to focus imp issue of security being after thought • Weaknesses • Inconsistent at times (Formal proofs and verification) • Some approaches suggested not practical (Smart cards) • All sections not very clear (Secure Computing)

12. Relevance to Embedded Systems • Security always a general concern. • Afterthought may not be possible in Embedded systems • Talks of Smart Cards / Temper resistant hardware as solution to many problems • Formal Verification methods are imp for safety critical embedded software

13. Thank You