Information Assurance Requirements Development and Satisfaction Steve Dawson

Information Assurance: Requirements Development and Satisfaction Steve Dawson and Victoria Stavridou Bruno Dutertre, Josh Levy, John Lowrance, Bob Riemenschneider, Hassen Saidi, Tomas Uribe System Design Laboratory SRI International OASIS PI Meeting, Santa Fe, NM July 25, 2001 25 July 2001

Project Overview • Objective: Advance both the science and the practice of the development of secure systems – With particular emphasis on large, distributed systems • Motivation – Increasing efficiency and productivity demands are driving the integration of existing information systems into largescale, internetworked systems – More attention needed to • Adequate capturing of security requirements • Assurance that systems meet these requirements System Design Laboratory 25 July 2001 2

Project Overview • 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 • Two parts – Developing the security requirements • How to express them (language/ontology) • How to discover and collect them (process) – Building the information assurance case • How to show that the requirements are satisfied System Design Laboratory 25 July 2001 3

Background • What’s going on now and what has gone before? – Significant diversity in approaches • Reflects diversity in requirements, understanding, interests, capabilities – Tendency toward emphasizing either practicality or wellfoundedness • Two broad classes of approaches to secure systems development – Formal methods (mathematical modeling) • Authorization models, information flow analysis, noninterference, protocol analyses, . . . – Structured and standards-based development • “Orange Book”, Common Criteria, “best practices” System Design Laboratory 25 July 2001 4

Existing Approaches • Formal methods – (+) High precision; mechanized reasoning – (+) Successful when applied to highly focused, well defined problems – (-) Lack of compositionality – (-) Potential failures at lower levels of abstraction – (-) Specialized knowledge; expertise required • Developmental methodologies – – – (+) Capture “community wisdom” (+) Structure provides focus (+) Diverse participation better coverage (-) Imprecision, incompleteness (-) Never completely successful (red team successes) System Design Laboratory 25 July 2001 5

State of the Art • General conclusions – “Security” is multi-faceted; no one approach works for everything – Existing approaches have much to contribute – “Big picture” needs more attention – Absolute security is unachievable • Conflicting security requirements • Usability and reliability tradeoffs – Security requirements engineering is not getting enough attention and remains a major challenge • Evidence: 1 st Symposium on Requirements Engineering for Information Security, Indianapolis, March 2001 System Design Laboratory 25 July 2001 6

Security Requirements • Approach: Security co-design – Security requirements developed alongside functional requirements – Some separation of security and functional concerns, but mutual influence throughout the process • Key ideas – Security-preserving refinement – Level of formality adaptable as appropriate to the system/application – “Effort to breach” as a means of measuring compliance and comparing alternatives – Augmenting, not replacing, the system engineering process System Design Laboratory 25 July 2001 7

Security Co-design • Challenges – Disentangling security from functionality – Identifying appropriate levels of abstraction for security that relate well to levels of functional abstraction – Modeling / measuring effort-to-breach – Modeling and managing tradeoffs between security, usability, reliability/availability • Benefits – Not all system designers and engineers need to be security experts – Traceability of requirements System Design Laboratory 25 July 2001 8

High-level view of security co-design Security Mission Goals Functionality High Operational Requirements Adversaries / Threats Security-preserving refinement Level of abstraction Security refinement Attacks Functional Description Security-preserving refinement Security refinement Vulnerabilities Mechanisms Low System Design Laboratory 25 July 2001 9

Security Co-design • Security-preserving refinement – Security requirements as constraints on functional refinement – Theory interpretation • Functional refinement Interpretation • Security-preserving refinement Faithful interpretation • Mapping from formulas in the language of abstract theory Tabs to formulas in the language of concrete theory Tconc is a faithful theory interpretation if System Design Laboratory 25 July 2001 10

Validating the Approach • One small success: SDTP – Secure Distributed Transaction Protocol – Multilevel secure adaptation of DTP • A real-world test: Genoa Crisis. Net – Core infrastructure of the Genoa crisis assessment system – Large, distributed, multi-organization system System Design Laboratory 25 July 2001 11

Genoa Case Study • Benefits – A real system – Significant security concerns • Challenges – Operationally, Genoa is in an advanced stage of development • Many design/architectural decisions already made • Some security mechanisms already in place – Strong emphasis on usability and availability – Security requirements often implicit • Applying the co-design approach – Start from top-level mission goals – Derive security requirements as they should have been – Examine how the approach would have altered the system System Design Laboratory 25 July 2001 12

IA Case Development • What is an IA case? – A formal representation of • System IA requirements • Evidence that the system does or does not meet its IA requirements • An argument that the system does (or does not) meet its IA requirements • Why develop an IA case? – Allows assessment of conclusions, evidence, and arguments by experts – Can be reexamined and refined as experience is gained – Formalization enables automated support tools to be used System Design Laboratory 25 July 2001 13

IA Case Development • Technologies that can contribute, based on experience in formalization of safety cases – Graph-based formalisms: nodes are evidence and conclusions drawn from evidence; links show influence; universally preferred to logical proof-based formalisms – Commercial tools: essentially hypertext rather than fully formalized non-demonstrative arguments (represent strength of evidential links but not determination of strengths of conclusions from strengths of hypotheses) – Experiments with the use of Bayesian nets suggests that experts find sufficiently accurate assessment of relevant conditional probabilities very difficult System Design Laboratory 25 July 2001 14

IA Case Development • Contributing technologies (cont’d) – SEAS provides a practical intermediate level of formalization • Graph-based • Fully formalizes non-demonstrative arguments (conclusions have strengths based on strengths of hypotheses and strengths of influence) • Replaces probabilities by small ranges of discrete values that are meaningful to users • Replaces conditional probabilities and Bayesian inference by simple user-selected rules for strength propagations (e. g. , max, min, mean) System Design Laboratory 25 July 2001 15

IA Case Development • Current plan – Attempt to use SEAS as is • Design an argument structure template • Flesh out the template to create an IA case for Genoa – Assess the resulting IA case • If it provides an adequate formalization, we’re done • If not, extend SEAS to support a more complex inference scheme (Bayesian, Dempster-Shafer, . . . ) • Choice of inference scheme based on assessment of the IA case System Design Laboratory 25 July 2001 16

Summary • The big picture of information assurance needs more attention – Getting the requirements right – Showing that systems meet their requirements • System developers need more help in terms of guidance and tools to develop the requirements and build the information assurance case • Security co-design – – Augment the system engineering process Traceability of requirements Security-preserving refinement Structured, formal argumentation to build the IA case System Design Laboratory 25 July 2001 17