1. Security Codesign Steve Dawson and Victoria Stavridou Bruno Dutertre, Josh Levy, Bob Riemenschneider, Hassen Saidi, Tomas Uribe System Design Laboratory SRI International OASIS PI Meeting, Santa Rosa, CA August 20, 2002

2. System Design Laboratory 20 August 2002 2 Outline Objectives Approach Security codesign overview Information assurance case (IAC) –Motivation –Building an IAC –IAC structure –An IAC for Dependable Intrusion Tolerance (DIT) Plans

3. System Design Laboratory 20 August 2002 3 Project Overview Objective: Advance both the science and the practice of the development of secure systems Motivation –Security is difficult to get right (and getting more difficult) –System developers need better tools for Capturing the security requirements Building systems that meet their requirements Making a convincing case that the requirements are met Main goal: Provide a practical process with a strong scientific basis for the development of secure systems –Must be useful to practitioners –Must provide stronger guarantees of information assurance

4. System Design Laboratory 20 August 2002 4 Approach Security codesign –Influenced by Hardware/software codesign Architecture refinement for dependable systems Development of safety-critical systems –Key idea: complement conventional systems engineering processes with a separate, but coordinated, security engineering effort Derive top-level security requirements from mission goals Elaborate security requirements as the functional design is elaborated Evaluate functional design decisions from a security perspective, providing both proactive and reactive advice Justify design and implementation choices by demonstrating that security requirements are satisfied

5. System Design Laboratory 20 August 2002 5 Security Codesign Why the decoupling of security engineering from functional elaboration? –Security engineering requires different skills and mindset –Emphasis on how to avoid undesired behavior rather than on how to achieve desired behavior –Similar to motivation for independent testing –Has the advantage that not all system designers need to be security experts (and vice versa)

6. System Design Laboratory 20 August 2002 6 Security Codesign

7. System Design Laboratory 20 August 2002 7 Codesign Object Base (COB) A complete record of the codesign process The basis for automated support of security codesign –Analyzers: assist in making design decisions, e.g. Identifying design candidates Detecting inconsistencies Evaluating alternatives –Generators: assist in generating products, e.g. Requirements and design documents Software source code Test cases Documentation IA case

8. System Design Laboratory 20 August 2002 8 The COB Vision of the COB and associated tools Codesign Object Base Requirements document generation Specification document generation Configuration generation Test suite generation IA case generation Security requirements document Functional requirements document System configuration Information assurance case Test suite and results Specification document...

9. System Design Laboratory 20 August 2002 9 Information Assurance Case (IAC) Intrusion tolerance focuses on building systems from less trustworthy components that have weaker requirements than the overall system It is therefore important to establish that the overall security requirements are met by showing that the lower-level components are assembled so as to guarantee security as well as correct functionality An IAC –Assembles relevant information into a case that the system meets its security requirements –Addresses various levels of abstraction –Facilitates independent evaluation and scrutiny –Is an evolving document that is updated throughout the system lifecycle

10. System Design Laboratory 20 August 2002 10 Building an IAC Claims –Requirements documentation Sources of evidence and assumptions –Process Use of secure programming techniques and tools Use of secure languages and operating systems Use of assessment tools and methodologies Use of skilled, security-aware engineers Security codesign –Product Design documentation Formal evaluation of architecture, policies, algorithms, etc. Run-time monitoring Verifying robustness against known attack scenarios Red-team penetration testing Codesign object base Arguments –Structured, sound, and broad to cover various levels of abstraction –Deterministic > Probabilistic > Qualitative –IAC templates for SEAS (Structured Evidence and Argumentation System)

11. System Design Laboratory 20 August 2002 11 IAC Structure

12. System Design Laboratory 20 August 2002 12 Structure of an IAC Argument

13. System Design Laboratory 20 August 2002 13 An IAC Argument in SEAS Stronger Weaker

14. System Design Laboratory 20 August 2002 14 An IAC for DIT

15. System Design Laboratory 20 August 2002 15 IAC Structure for DIT Mission Goals and basic approach Abstract architecture Proxy Application servers Communication components Concrete interoperation Network hardware IDS Application OS OS configuration Application software Software configuration policy Run-time compiler Implementation code OS

16. System Design Laboratory 20 August 2002 16 Plans Use DIT Web server as case study (replacing Genoa) –Simpler architecture –Better defined requirements –Better documented design and evolution Develop an IAC for DIT using the codesign approach –Build a “COB” capturing evolution of DIT requirements, design, and implementation –Develop a SEAS-based argument template –Fill in template from COB elements, producing the IAC