1 / 16

Security Codesign

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. Outline. Objectives Approach Security codesign overview

tess
Download Presentation

Security Codesign

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  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 configuration Specification document Test suite and results Configuration generation Test suite generation Functional requirements document Specification document generation Information assurance case IA case generation Requirements document generation Security requirements document Codesign Object Base . . . . . . The COB • Vision of the COB and associated tools

  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. 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. IAC Structure

  12. Structure of an IAC Argument

  13. Stronger Weaker An IAC Argument in SEAS

  14. An IAC for DIT

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

  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

More Related