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

March 13, 2002

13 March 2002 2System Design Laboratory

Outline

• Objectives• Approach• Security codesign overview• Recent developments

– Codesign Object Base (COB)– Analysis of Genoa CrisisNet– Genoa II security codesign

• Plans


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


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


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)


Security Codesign

Mission GoalsSecurity Functionality

Adversaries / Threats

Attacks

Vulnerabilities

Functional Description

Mechanisms

Operational Requirements

Security elaboration

Security elaboration

Security-preserving refinement

Security-preserving refinement

Leve

l of a

bstr

actio

n

High

Low


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


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


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


The COB

• Longer-term 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

. . .

. . .


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


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


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?


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

Security Codesign

Documents

Transcript of Security Codesign