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

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

System Design Laboratory 20 August 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

System Design Laboratory 20 August 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

System Design Laboratory 20 August 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)

System Design Laboratory 20 August Security Codesign

System Design Laboratory 20 August 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

System Design Laboratory 20 August 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...

System Design Laboratory 20 August 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

System Design Laboratory 20 August 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)

System Design Laboratory 20 August IAC Structure

System Design Laboratory 20 August Structure of an IAC Argument

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

System Design Laboratory 20 August An IAC for DIT

System Design Laboratory 20 August 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

System Design Laboratory 20 August 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