# Presentation: 012154

## Reducing Software Security Risk Through an Integrated Approach 

**Reducing Software Security Risk Through an Integrated Approach**** **

**David Gilliam, John Powell, Josef Sherif, & Tom Wolfe**
**California Institute of Technology,**
**Jet Propulsion Laboratory**
**Matt Bishop**** **
**University of California at Davis**

**California Institute of Technology, Jet Propulsion Lab****  **

## NASA RTOP: 

- Reducing Software Security Risk

**NOTE:  **
**This research was carried out at the Jet Propulsion Laboratory, California Institute of Technology, under a contract with the National Aeronautics and Space Administration. **
**The work was sponsored by the NASA Office of Safety and Mission Assurance under the Software Assurance Research Program lead by the NASA Software IV&V Facility. **
**This activity is managed locally at JPL through the Assurance and Technology Program Office.**** **

## Current Collaborators

**David Gilliam – Principle Investigator **
**	****	****Network and Computer Security, JPL**
**John Powell – Research Engineer **
**	****	****Quality Assurance, JPL**
**Josef Sherif – Research Engineer**
**	****	****Network and Computer Security, JPL**
**Tom Wolfe – Research Engineer**
**	****	****Network and Computer Security, JPL**
**Matt Bishop –Professor of Computer Science **
**	****	****University of California at Davis**

## Introduction

**Research Goal**
**The instrument contents**
**Software Security Checklist**
**Integration of the instrument contents**
**Model checking**
**The Flexible Modeling Framework (FMF)**
**FMF components and combinations**
**Rapid model updating**

## Research Goal

**Reduce security risk to the computing environment by preventing and/or mitigating vulnerabilities and exposures through the software life cycle process**
**Develop a Software Security Assessment Instrument (SSAI)**
**Five foci**
**Software Security Checklist (SSC)**
**Model-based security specification and validation approach (MBV)**
**Flexible Modeling Framework Instrument (FMF)**
**Vulnerability Matrix (VMatrix)**
**Software property-based testing tool (PBT) **
**List of Security Assessment Tools (SAT)**

**Notes:**
Vulnerabilities are internal weaknesses in the code that can be exploited
Exposures are external interfaces that are susceptible to intrusions
Specification, development, implementation, operations, maintenance

## Software Security Checklist (SSC)

**NASA NPG 2210**
**External Release of Software**
**Software Security Checklist**
**Two phases**
**Phase 1: Provide instrument to verify external release of NASA software does not present a security risk to NASA and its partners**
**Phase 2:  Provide instrument to integrate security as a formal approach to the software life cycle**

## Software Security Checklist (cont.)

**Phase 1**
**Checklist for use prior to external release of software**
**Concerns include the following:**
**HR information**
**Operational processes**
**Internal processes**
**Sensitive IP addresses**
**Crypto Certificates and Keys**
**Embedded userids and passwords**
**Document describing purpose and use of the checklist**

## Software Security Checklist (cont.)

**Proposed procedure for using the checklist**
**Examples for automating (as much as possible) software checking**
**Perl script for checking strings with IP addresses**
**Perl script for checking dangerous subroutines**
**gets**
**fgets**

## Software Security Checklist (cont.)

**Phase 2**
**Determine scope of Phase 2**
**Analyze and prioritize what items are of concern**
**Cost of life cycle (Risk cost grows exponentially throughout software life cycle)**
**Cost of where problems occur**
**Security risk analysis**
**Determine and prioritize most effective solutions for addressing the concerns**
**Need for software security for architect?**

## Software Security Checklist (cont.)

**Develop Checklists for use through the software life cycle process**
**Develop Document describing purpose and use of the checklists**
**Develop or Provide list of Tools/Instruments that can assist in automation of checks**
**Provide Recommendations and lessons learned for software security architecture**

## Instrument Contents Integration

- Each part of the instrument supports the other parts
- VMatrix provides known vulnerability properties to PBT
- PBT provides newly discovered code vulnerabilities to the Vmatrix property set and code level verification feedback to MBV
- MBV provides newly discovered vulnerabilities scenarios to the Vmatrix property set and early lifecycle verification results to PBT for tracability purposes

## The Flexible Modeling Framework (FMF) 

- The Flexible Modeling Framework (FMF)

## Model Checking  (MC)

**FMF uses MC as its core technology**
**Exhaustive search **
**Verification of temporal logic properties**
**MC limited by an exponential state space explosion**
** *****	****m**n** s.t.** **m=val_range, n=|vars|*
*	**Can MC still be useful when the system is large?*

## FMF Components and Combinations

**FMF models the system (S) as a series of small model components (c***i**** *****| 1 ******** *****i***** ******** n) which are model checked**
**	**({c1, c2, c3, ... c*n*} = S) /\ (ci  S)
**FMF model checks component combinations **
**	****(C**k** | (C**k** ******** S) /\ (1 ******** |C**k**| ******** m) where the state space of C**m+1** is beyond memory thresholds    **

## Model Component Combination Tree (MCCT)

**MCCT level *****l***** = {C****k ****| (| C****k****| = n-*****l *****)***** *****/\***** *****(*****n***** = |S|)}**
**MCCT root node (level 0) – full system of n components**
**MCCT leaf nodes (level n-(n-1)) – single components**
**State space explosion threshold separates the explicit and implicit portions of the MCCT **
**Explicit portion – **<Ck, VV = 0||2, CR = 1>** **
**known property verification knowledge from MC results **
**Implicit portion – **<Ck, VV = (0,2), CR = (0,1)>
**derived verification knowledge from explicit portion of MCCT**

## A Simple Example

**CR = 1**

- Explicit MCCT

- Implicit MCCT

**0 < CR < 1**

**CR****i**** = 1 – *****p *********

**CR****i+1**** = CR****i**** – *****p *********

**CR = 1 ********

**CR = 1 ********

## Potential Follow-On Work

**Training in use of security assessment tools in the software development and maintenance life-cycle**
**Development of re-composable model sub-components**
**Develop capability for easy storage and access of a library of common network security model components and past verification results**
**Develop a programmer interface to assist users with generating properties for input into the tools**

## Potential Follow-On Work (cont.)

**Enhancing and augmenting the toolset**
**Port the code to run on different operating systems in a run-time environment**
**Include additional programming and scripting languages that the Tester’s Assistant tool can slice for vulnerabilities**
**Augment the toolset by incorporating or developing additional tools**
**Develop a graphical user interface front-end checklist and decision tree to assist in building the Model to be verified**
**Develop an interface into the AART Tool**

## Summary

**Growth of NASA’s network aware software applications and collaborative work increase risk to NASA environment**
**Risk will continue to increase as collaboration increases**
**Software Security Assessment Instrument for use in the software development and maintenance lifecycle**

## Summary (Cont.)

**Assessment Instrument composed of three tools and reports:**
**Vulnerability Matrix**
**Tester’s Assistant**
**Flexible Modeling Framework**
**Tools can be used collectively or individually**
**There is a potential for wider application of the instrument beyond assessment of security of software**

## David Gilliam

**JPL**
**400 Oak Grove Dr., MS 144-210**
**Pasadena, CA 91109**
**Phone:  (818) 354-0900****	****	****FAX: (818) 393-1377**
**Email:  david.p.gilliam@jpl.nasa.gov**
**Website:  http://security.jpl.nasa.gov/rssr/**
**John Powell**
**MS 125-233**
**Phone:  (818) 393-1377****	**
**Email:****	****john.d.powell@jpl.nasa.gov**

***FOR MORE INFO...***

## Backup Slides

## Slide 23

## Slide 24

## The Flexible Modeling Framework (FMF) – Part 1

## The Flexible Modeling Framework (FMF) – Part 2

## Heuristic VV and CR Propagation

**CR = 1**

- Explicit MCCT

- Implicit MCCT

**0 < CR < 1**

**CR****i**** = 1 – *****p *********

**CR****i+1**** = CR****i**** – *****p *********

**CR = 1 ********

**CR = 1 ********

## Heuristic Propagation

**Verification Values (VV) – degree to which a property holds or does not hold (0 – 2)**
**Confidence Rating (CR) – degree of certainty that the VV is correct (0 – 1)**
**Why 2 heuristic values instead of 1?**
**VV=1, CR=.99 – Confident inconclusiveness**
**Known information is highly contradictory**
**Variable model component resolution is unlikely to help**
**VV=1, CR=.01 – Inconclusive due to heuristics**
**Heuristic propagation’s prediction accuracy is degrading**
**Variable model component resolution is more likely to help**

## Heuristic VV and CR Propagation

**CR = 1**

- Explicit MCCT

- Implicit MCCT

**0 < CR < 1**

**CR****i**** = 1 – *****p *********

**CR****i+1**** = CR****i**** – *****p *********

**CR = 1 ********

**CR = 1 ********

## Variable Component Resolution

**Trading less abstract model components for more abstract ones.**
**Increased ability to analyze interaction of more model component**
**Decreased detail about the behavior of some model components**
**Used to Cope with State Space Explosion**
**	**
**	***Do Model Component resolution versions occur as a side effect of model updates?*

## Rapid Model Updating

**FMF benefits software early in its lifecycle**
**Earlier Discovery of Software Errors**
**Correction is easier / better / less expensive**
**FMF must adapt to early lifecycle events**
**Rapidly changing requirements and designs**
**Varying / Increasing levels of detail defined for different parts of the system.**
*How can traditional model development for MC be enhanced to cope with volatile systems?*

## The Flexible Modeling Framework (FMF) – Part 3

**Heuristic Propagation of Results **

**Collection of Model Components **

**Model Checker **

**Component Combiner **

- Each Individual Component

- Unique Component Combinations

**If Combination State Space is too Large**

- No

- Yes

**MCCT**

**Implicit**

**Explicit**

**Updated Component ******

**Combinations Containing ******