Organically Assured and Survivable Information Systems OASIS Program Validation Framework Summarizat

1
Organically Assured and SurvivableInformation
Systems (OASIS) Program Validation Framework
SummarizationSurvivability 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
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/counterm
  easures)
• 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
(No Transcript)
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