Security Codesign

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, Hilton Head, SC March 13, 2002

2. Outline • Objectives • Approach • Security codesign overview • Recent developments • Codesign Object Base (COB) • Analysis of Genoa CrisisNet • Genoa II security codesign • Plans

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. 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. 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. Security Codesign Mission Goals Functionality Security High Operational Requirements Adversaries / Threats Security-preserving refinement Security elaboration Attacks Functional Description Level of abstraction Security-preserving refinement Security elaboration Vulnerabilities Mechanisms Low

7. Security Codesign • Involves many processes • Requirements development • Design and implementation • Testing • Deployment and maintenance • Justification (demonstration of requirements satisfaction) • Generates many products • Requirements and design documents • Software and hardware • Test plans and results • Configurations • Information assurance (IA) case • Maintenance history

8. Codesign Object Base (COB) • Processes involved in security codesign can be viewed as facets of a larger process • Products can be derived from a common store of information generated as a result of the process • Goals, requirements, reasoning, alternatives, choices, ... • Not just items of data, but also relationships among them • The keys to making this information useful are • Capturing it completely • Capturing it in a form that supports analysis and product generation

9. The 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

10. Security requirements document Functional requirements document Information assurance case System configuration Test suite and results Specification document Requirements document generation Specification document generation Configuration generation Test suite generation IA case generation Codesign Object Base . . . . . . The COB • Longer-term vision of the COB and associated tools

11. Testing the Approach • Genoa CrisisNet • (Former) information infrastructure of the Genoa crisis assessment system • Security requirements • Not made explicit by the developers • Had to be inferred from mission briefs, use scenarios, implementation, demonstrations, interviews • Findings from the codesign process • Security and functional elaboration revealed security flaws at the functional interface level • Applications had to be trusted to be well behaved in their use of the CrisisNet API • CrisisNet API needed redesign to address security deficiencies

12. Refining the Approach • Redesign CrisisNet (as an exercise) • Start from top-level Genoa mission goals and requirements of existing tools (applications) • Security codesign with a “clean slate” • Results to date • Initial formulation of the Codesign Object Base concept • Application of security codesign principles to the development of intrusion tolerant systems (DIT) • Generalized vision of security codesign to dependability codesign

13. Genoa II Security Codesign • Genoa II information infrastructure • Replaces CrisisNet • Use of some COTS products anticipated • Interesting and challenging issues • Collaborative (interorganizational) analysis • Information not always equally accessible to all participants • Need to support different projections, or views, of information based on security concerns • Satisfying security requirements • To what extent do the COTS products help satisfy them? • What more must be done to ensure satisfaction?

14. Plans • Continue security codesign case study using new Genoa II information infrastructure • Build a “paper COB” • Identify ontological elements • Refine the COB structure • Expected products • Security requirements document • Functional requirements and design (in outline form) • Information assurance case as a SEAS structured argument