Organically Assured and SurvivableInformation Systems (OASIS) Program

Validation Framework Summarization

Survivability Coverage

Dale Johnson (MITRE)

Myong Kang (Mitretek)

Doug Williams (MITRE)

2

Objective

• What is the space covered or protected by OASIS technologies?

• From the information assurance and survivability validation

framework summaries produced by the OASIS PIs create a

coverage matrix

that shows the overall coverage that the projects collectively

provide against a standard list of vulnerabilities and attacks to

yield the five main information assurance and survivability

attributes

3

Abstract Coverage Matrix

Confidentiality Integrity Availabiltiy Authentication Nonrepudiation

V/A1 P13: M1V/A2 P22: M7V/A3 P3: M4…V/An P4: M8 P5: M2 P9: M10

4

Basis (1 of 2)

• PIs provided validation framework summaries for 24 projects using the standard format discussed at the last PI Meeting in July 2001– Thanks to PIs for their excellent efforts

• OASIS projects cover an extensive set of domains of application

• Domains emerged from an initial analysis of the projects

• Validation framework summaries for the projects used various lists of vulnerabilities and attacks, which were not standardized over all the projects

5

Basis (2 of 2)

• Time (when) and place (where) of vulnerabilities and attacks were interpreted differently by various PIs: some were given at the point of “origin” where a countermeasure/mechanism can be effective and some were given at the point of the effect of the vulnerability or attack

• The standard format used the DoD attributes (Joint Pub 3-13, Joint Doctrine for Information Operations): confidentiality, integrity, system availability, authentication, and nonrepudiation

6

Development of Coverage Matrix (1 of 3)

• We grouped the 24 OASIS projects in the following application domain categories in order to provide some consistency for our analysis across the projects– Modeling– Implementation/source code– Mobile code– In-line technologies– Distributed applications/middleware– Server (Web or mail) and client– Distributed file system– Database– Firmware

7

Development of Coverage Matrix (2 of 3)

• We developed a “standard” list of 32 vulnerabilities and attacks grouped by design, implementation, and operation time (when) and place (where) hardware/firmware, network, servers/clients, etc.

• The list was derived from the sets of vulnerabilities and attacks provided by the PIs and our discussions and analysis

• A standard list is a “moving target”, which is difficult to finalize, but the list we developed seemed to fit current needs

8

Development of Coverage Matrix (3 of 3)

• We mapped the project vulnerabilities and attacks into our standard list of vulnerabilities and attacks as closely as possible– Not a straightforward task, since interpretations can vary

• We then used the rationale tables provided by PIs to map from the standard list of vulnerabilities and attacks to the five standard attributes with entries designating the projects and corresponding mechanisms (countermeasures) that counter the vulnerabilities and attacks to yield the attributes

9

Result

• A full coverage matrix– X-axis: Our standard list of common vulnerabilities and attacks

(reasons/motives for inserting mechanisms/countermeasures)– Y-axis: The five standard security attributes (positive results of

inserting mechanisms/countermeasures)– Entries: Projects and corresponding protection mechanisms from

the rationales provided by the PIs

• Coverage depends on the interpretation and effectiveness of the mechanisms that counter the vulnerabilities and attacks to yield forms of the standard attributes

10

Confidentiality Integrity Availabiltiy Authentication

No unauthorized release of data or

eavesdropping

No modification of data, code, or system

properties

No denial of service No unauthenticated access to systems

When

1

Poor, weak, incorrect design P4: M4, 5 P1: M1,2,3,4 P9: M1-25 P13: M1-13,15 P21: M1,5

P7: M3, 4 P15: M2 P4: M4, 5 P1: M1,2,3,4 P22: M1.2,1.3,2.1,2.2, 3.3,3.5,3.6,3.7,3.11 P17: M2,3

P7: M3, 4 P15: M2 P1: M1,2,3,4 P22: M1.2,1.3,2.1,2.2, 3.3,3.5,3.6,3.7,3.11 P9: M1-25

P4: M4, 5 P9: M1,2,17

2 Poor modularization of design P4: M4 P4: M4 P4: M4

3 Poor, weak interface design P4: M4 P4: M4 P4: M4

4

Poor security requirements, policy P4: M4, 5 P9: M1-25 P2:M5

P7: M3, 4 P4: M4, 5 P17: M1,2 P9: M1-25 P2:M5 P3:M6

P7: M3, 4 P9: M1-25 P2:M5

P4: M4, 5 P9: M1,17

NATURE OF COMPROMISE

ATTRIBUTES

Where

Design

11

Possible Changes from PIs

• Reclassify project placement in application domain categories

• Add or delete vulnerabilities and attacks that project addresses

• Add more mechanisms/countermeasures

• Adding items in the standard list of common vulnerabilities and attacks should be based on consensus

12

Possible Next Steps

• Analyze application domains further to characterize projects more accurately within those domains– Provide simple abstract models of the domains

• Determine coverage of projects in greater detail relative to individual entries in matrix, since entries correspond to shades of gray, not black or white

• Explore coverage with a view to selecting technologies for future integration efforts for building systems– Is it possible to produce a simple handbook to aid in selecting technologies for

integration efforts?

• Develop selection criteria for OASIS technologies