# Presentation: 904038

## Integrated Approach to Reducing Software Security Risk

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

## Acknowledgement

**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 – Principal Investigator, JPL
- John Powell –Software Engineer, JPL
- Matt Bishop – Associate Professor of Computer Science, University of California at Davis
- http://rssr.jpl.nasa.gov

## Agenda

- Goal
- Problem
- Software Security Assessment Instrument (SSAI)
- Current  and Future Goals

## Goal:  Secure Computing

- Secure Computing Environment
- Secure Systems
- Secure Data
- Reduce security risk to the computing environment by mitigating vulnerabilities in the software development and maintenance life cycles
- Provide an instrument and tools to help reduce vulnerabilities and exposures in software
- To aid in complying with security requirements and best practices

## Agenda

- Goal
- Problem
- Software Security Assessment Instrument (SSAI)
- Current  and Future Goals

## Problem

- Lack of Experts: Brooks –
- “No Silver Bullet” is still valid
- 	(IEEE Software Engineering, 1987)
- Poor Software Engineering
- Lack of Security Requirements
- Impacts design, coding, testing, . . .
- Cycle of Penetrate and Patch
- Web-Centric Applications Increasing
- Piecemeal Approach to Security Assurance

**BAD**

## Security Risk Perception

**Chicken Little:**
**“****The Sky is Falling!”**

**Alfred E. Newman**
**(MAD Magazine):**
**“****What, Me Worry?”**

## Agenda

- Goal
- Problem
- Software Security Assessment Instrument (SSAI)
- Current  and Future Goals

## Reducing Software Security Risk Through an Integrated Approach

## Model Checking & The Flexible Modeling Framework

**Modeling in FMF components is  more compatible with the software development process **
**MC of FMF components and combinations allows partial answers to otherwise intractable system state spaces**
**MC with FMF Benefits Software Early in its Lifecycle**
- Earlier Discovery of Software Errors
- Correction is easier / better / less expensive

## Model Checking & The Flexible Modeling Framework (Cont.)

**FMF Can Adapt to Early Life Cycle Events**
- Modular model design allows easy extension of existing models
- Multiple client scenarios for the server login example were quickly modeled and verified
- The various client scenarios allows extensive off-nominal verification with ease
- Rapidly changing requirements and designs
- Multiple design trade offs in login protocol were easily explored

## Model Checking: Flexible Modeling Framework (Cont.)

## Model Checking: Flexible Modeling Framework (Cont.)

**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**

**Heuristic Propagation of Results **

**Updated Component ******

**Combinations Containing ******

## Model Checking & The Flexible Modeling Framework(Cont.)

- Varying levels of detail were defined for different arbitrary system parts
- Multiple login failure propagation scenarios that are known but not formally defined for different systems using the login protocol
-  Model extensions are readily possible for many if not all of these scenarios
**These scenarios may be developed quickly and adapted at will**
**These extensions can be cross tested against all client scenarios and protocol design trades with little additional effort.**

## Server Login Model

- chan login = [0] of {short};
- chan accessed = [0] of {bit};
- short user_name = 0;
- short password = 0;
- bit accsd = 0;
- bit hash_complete = 0;
- proctype server(){
- do
**   ****::user_name == 0 && password == 0 -> login?user_name;**
**   ****::****user_name != 0 && password == 0 ->login?password;**
**   ****::user_name != 0 && password != 0 ->**
- 	do
- 	    ::user_name != password ->
- 	        if
- 	          **:: hash_complete == 0->**
**	****	****password = password * -1;**
**	****	****hash_complete = 1;**
- 	          **::hash_complete == 1->accessed!0; break;**
- 	        fi
- 	    **::user_name == password ->accessed!1; break;**
- 	od
- od }

**Obtain User Name**
**Obtain User Password**
**After User Name and Password Obtained**
**Use hash to transform password for verification**
**If verification fails then deny access**
**If verification succeeds then grant access**

## Client Login Models and Their Verification

- chan login = [0] of {**short**};
**...**
- active proctype good_client(){
- 	**short **usr_nm = 1;
- 	**short **pswd = -1;
- 	run server();
- 	login!usr_nm;
- 	login!pswd;
**	****accessed?accsd;**}

**Property of Interest**
**No access until hash verification is complete**
**accsd==0 ******** hash_complete==1 **
**Good Client **
**Correct Login**
- Hash verification correlates user and password before access
**Bad Client**
**Circumvents Login**
- Buffer handles data  range of –215 to 215-1 (short data type)
- -65535 overflows buffer
**Access granted before password  hash execution**
**Hash function ignored**

- chan login = [0] of {**short**};
**...**
- active proctype bad_client(){
- 	**short** usr_nm = 1;
- 	**short **pswd = -1;
- 	run server();
- 	login!usr_nm;
- 	login!**-65535**;
- 	accessed?accsd;}

## Property-Based Testing

- Property-based testing tool – Tester’s Assistant (Matt Bishop, UC Davis)
- Perform code slicing on applications for properties for a known set of vulnerabilities
- Test for vulnerabilities in code on the system or whenever the computing environment changes
- Initially, checks software developed in JAVA and C
- The goal is to have the tool check other programming and scripting languages as well (C++, Perl, ActiveX, etc.)

## Property-Based Testing (Cont.):  How It Works

- Property-Based Testing (Cont.):  How It Works

**Notes:**
This slide shows how property-based testing fits into the derivation of assurance. The figure on the left captures what assurance is about: given a knowledge of security and an accurate specification of the security model (which says what you are, and are not, allowed to do), you analyze the software to determine the level of assurance, or belief that the program does what it is supposed to do. The arrow going from the left to the right  shows that security properties, written in TASPEC, capture the idea of the security model The arrow goes to the “properties” box on the right, to emphasize the properties we test for are directly taken from the security properties of the model. We expect the code to honor these.
We next slice the program, or derive the smallest program equivalent to the original with respect to the stated properties. We then instrument and test this program, as described earlier. The testing either validates the properties or shows the do not hold. This helps us determine the level of assurance of the program, as captured by the arrow going from the right to the left.

## Tester’s Assistant Specifications

- No access until hash verified
- Obtain user’s name
- Obtain user’s password
- Is password correct? {
- 	Generate user’s password hash
- 	Compare user's password hash to hash stored for that user name
- 	If match, set UID to user's uid (granting access)
- 	If no match, set UID to ERROR (denying access)
- }
- If access granted {
- 	compare UID to the uid for which access is granted
- 	if match, all is well
- 	if no match, specification violated
- }

## Example C Code

- /* *get user name* */
- if (fgets(stdin, uname, sizeof(uname)–1) == NULL)
- 	return(FAILED);
- /* *get user password* */
- typedpwd = getpass(“Password: “);
- /* *now get information about user with that name* */
- if ((pw = getpwnam(uname)) != NULL){
- 	/* *generate user’s password hash* */
- 	hashtp = crypt(pw->pw_passwd, typedpwd);
- 	/* *compare this to stored hash; if match, grant access* */
- 	if (strcmp(pw->pw_passwd, hashtp) == 0){
- 		/* *match -- grant access* */
- 		setuid(pw->pw_uid);
- 		return(SUCCESS);
- 	}
- 	/* *didn’t match -- fall through to deny access* */
- }
- return(FAILED);

## TASPEC

- View process as sequence of states
- Care only about those related to properties
- State 1: name, hash, uid for user with login name obtained
- State 2: add in hash of password supplied by user
- State 3: add in equality of hash of password supplied by user *and* hash of user with login name
- State 3A (alternate expression of state 3): user has authenticated him/herself
- State 4: add in granting of access

## TASPEC Specification

- /* if assert, enter state 1 */
**location** **func** *getpwnam*(*name*) **result** *pwent*
- 	{ **assert** *user_password*(*name*, *pwent*->*pw_passwd*, *pwent*->*pw_uid*); }
- /* if assert, transition from state 1 to state 2 */
**location** **func** *crypt*(*password*,*salt*) **result** *encryptpwd*
- 	{ **assert** *password_entered*(*encryptpwd*); }
- /* if assert, transition from state 2 to state 3 */
**location** **func** *strcmp*(*s1*, *s2*) **result** 0
- 	{ **assert** *equals*(*s1*, *s2*); }
- /* if in state 3, transition to state 3A */
*password_entered*(*pwd1*) **and ***user_password*(*name*, *pwd2*, *uid*) **and** *equal*(*pwd1*, *pwd2*)
- 	{ **assert** *authenticated*(*uid*) ; }
- /* if assert, transition from state 3A to state 4 */
**location func** *setuid*(*uid*) **result **1
- 	{ **assert** *access_acquired*(*uid*); }
- /* invariant; must always hold */
*authenticated*(*uid*) **before** *access_acquired*(*uid*)

## C Code and States

- if (fgets(stdin, uname, sizeof(uname)–1) == NULL)
- 	return(FAILED);
- typedpwd = getpass(“Password: “);
- if ((pw = getpwnam(uname)) != NULL){
- 	/* *if here, enter state 1* */
- 	hashtp = crypt(pw->pw_passwd, typedpwd);
- 	/* *enter state 2* */
- 	if (strcmp(pw->pw_passwd, hashtp) == 0){
- 		/* *if here, enter state 3 and then 3A* */
- 		setuid(pw->pw_uid);
- 		/* *enter state 4* */
- 		return(SUCCESS);
- 	}
- }
- return(FAILED);

## Fed to Test Execution Monitor

**Good login**
- user_password(“me”, “xyz”, 917)
*In state 1*
- password_entered(“xyz”)
*In state 2*
- equals(“xyz”, “xyz”)
*In state 3*
- authenticated(917)
*In state 3A*
- access_acquired(917)
*In state 4*
***Invariant holds***

**Bad login, but access granted due to programming error**
- user_password(“me”, “xyz”, 917)
*In state 1*
- password_entered(“abc”)
*In state 2*
- equals(“abd”, “xyz”)
*Fails, so do not enter state 3*
- access_acquired(917)
*In state 4*
***Invariant fails as state 3A never entered, as invariant require***

## Software Security Checklist (SSC)

- Two Phases
- Phase 1:
- Provide instrument to integrate security as a formal approach to the software life cycle
- Requirements Driven
- Pre-Requirements
- Understand the Problem and Scope
- Requirements Gathering and Elicitation
- Be Aware of Applicable Requirements Documents
- Provide Trace to External Requirements Docs

## SSC (Cont.)

- Requirements Specification
- Design – Reviews
- Code –Inspection & Walkthroughs, Safe Routines, Bounds Checking, Access Control, etc.
- Testing – Property-Based Test, Fault Injection, et.al.
- Maintenance – Regression Test

## SSC (Cont.)

- Phase 2:
- External Release
- Release Process
- Areas for Protection:
- Protect People
- Protect ITAR and EAR
- Protect Trade Secrets – Patents
- Protect Organizational Resources
- Considerations
- Insecure Subsystem Calls
- Embedded IP Addresses or Phone Numbers

- Release Process

## SSAI Instrument

- Protection of Resources and Data
- Maintenance Costs Decrease
- Integrates with Other Formal Disciplines
- End-to-End Life Cycle
- 	Process

**GOOD**

## Agenda

- Goal
- Problem
- Software Security Assessment Instrument (SSAI)
- Current  and Future Goals

## Current and Future SSAI Goals

- Integrate with Deep Space Mission Systems (DSMS)
- SSL Verification
- Potential to Verify Space Communication Protocol Standard (SCPS) Implementations (i.e., IPN)
- Formal Verification and Testing of Patchlink JAVA Client
- Integrate with IT Security Risk Management Tool (Defect Detection and Prevention – DDP) for Software Life Cycle

## Current and Future SSAI Goals (Cont.)

- Future Development Needs
- Extend Modeling Framework to include Model Security Templates for Re-Use
- Extend PBT to Include More Languages (C++, C#, Perl Script, et.al.)
- Extend Use for the Space Communication Protocol Standard (SCPS) & the Interplanetary Network (IPN)

## Space Communication Protocol Standard (SCPS) & the Interplanetary Network (IPN)

## Current and Future SSAI Goals (Cont.)

- Extend and Maintain Security Assessment Tool (SAT) Web Site and Data
- Location for submission and evaluation of Security Assessment Tools
- Provide Pros and Cons and Uses of Tools with List of Alternatives
- Cooperative Effort Between JPL, UC Davis, and Citigal

## Current and Future SSAI Goals (Cont.)

- Develop Security Template for Risk Management Instrument
- Extend Defect Detection and Prevention Tool (DDP) to Include Security Template and Risk Mitigations
- Include Mitigation Tools
- Definition (NASA CRM Web Site):
- 	“The combination of the probability that a project or other enterprise will experience an undesired event with unacceptable consequences, impact, or severity.”

## Current and Future SSAI Goals (Cont.)

**Team Effort and Approach**

**Risk Management**

## Current and Future SSAI Goals (Cont.)

**DDP Tool**

**Notes:**
DDP will provide the ability to identify security risks, mitigations and level of residual risk. Security risks can be integrated in DDP with safety and reliability to provide an overall picture and how one area may impact another, how potential mitigations may impact other areas.

## David Gilliam				John Powell

- JPL					JPL
- 4800 Oak Grove Dr., MS 144-210		4800 Oak Grove Dr., MS 125-233
- Pasadena, CA 91109			Pasadena, CA 91109
- Phone:  (818) 354-0900			Phone:  (818) 393-1377
- Email:  _[david.p.gilliam@jpl.nasa.gov](mailto:david.p.gilliam@jpl.nasa.gov)_	Email:_[john.d.powell@jpl.nasa.gov](mailto:john.d.powell@jpl.nasa.gov)_
**	****	****Website:  **_[http://rssr.jpl.nasa.gov/](http://rssr.jpl.nasa.gov/)_** **
**Matt Bishop**
- Department of Computer Science
- University of California, Davis
- Davis, CA 95616
- Phone: (530) 752-8060
- Email: _[bishop@cs.ucdavis.edu](mailto:bishop@cs.ucdavis.edu)_
**	****	****Website: http://seclab.cs.ucdavis.edu/~bishop**

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

## Questions?

**BAD**

**GOOD**

## BACKUP SLIDES

## Risk & Risk Management

- Risk Management Has Several Foci
- Threats
- Mitigations
- Costs
- Residual Risk
- Scope
- Institution
- IT Resources
- Data
- Project
- Project IT Resources
- System / Software Development Life Cycle (SDLC)

**Notes:**
SDLC – Could result in loss of business and revenue (maybe – Not MS)

## Risk & Risk Management

- IT Security Risk Algorithm:
*   **Risk = impact * likelihood * frequency*

- Where:
*Impact = damage * recovery time*
*Likelihood = time to failure * ease*
* **Frequency = number / time*
*Hence:*
*Risk = impact * likelihood * frequency = *
*impact * likelihood * (ease * likelihood * impact) =*
*impact^2 * likelihood^2 * ease*

**Notes:**
Where:  Impact = damage * recovery time
Damage can be characterized as the criticality of the data and IT resources along with the degree and extent of their destruction or loss—that is, the criticality of the data and resources and the degree and extent of the loss or compromise.  Degree is the damage to a system or set of resources, with extent being the number of systems affected and/or amount of data compromised.  A key approach to decreasing risk is to adopt measures that reduce the damage should security attacks succeed in breaching defenses.
Recovery time is the length of time to recover needed data and IT resources from a compromise 
Likelihood = time to compromise
Likelihood is the potential for loss or compromise of CIA should the attack succeed. A key approach to decreasing risk is to adopt defenses that make attacks less likely to succeed (e.g., training users on selection of passwords so that it is less likely that password hacking will succeed in locating a valid password or applying security patches).
Time to compromise is the time before a potential vulnerability is exploited 
Frequency = number / time, where number = ease * likelihood * impact
Number is the number of events occurring over a time interval
The frequency of an exploit being perpetrated is based on three factors: how easy it is to originate an attack, how likely that attack is to succeed, and how much impact it will have if it does succeed – this combination reflects the malicious intent of would-be attackers. 
A consequence of this equation is that the factors of likelihood and impact occur twice in the overall formula: 
Risk = impact * likelihood * frequency = impact * likelihood * (ease * likelihood * impact) = impact^2 * likelihood^2 * ease

## Slide 43

|  | SAMPLE SOFTWARE SECRUITY CHECKLIST |
| --- | --- |
| 1 | Establish security metrics during software life cycle development and a security requirements trace matrix. |
| 2 | Determine stakeholders, and elicit and specify associated security requirements for each stakeholder |
| 3 | Determine context and potential usage of software product along with the operating environment and specify requisite security requirements |
| 4 | Make available to programmers, developers, reviewers and test teams the vulnerabilities and potential exposures associated with programming languages and operating systems before the architectural design phase. |
| 5 | Set up security parameters for resource access such as ftp service where anonymous ftp is allowed but with write only and no read or list to the incoming directory and read only for outgoing directory |
| 6 | Check for sources of software security risks such as inconsistencies in requirements and in design, reusable programs and other shrink-wrap software. |
| 7 | Avoid the use of unsafe routines such as gets and fgets in coding |
| 8 | Check the security of any middleware in the program. |
| 9 | Check for architectural-specific vulnerabilities and how data flows through the code. |
| 10 | Check for implementation-specific vulnerabilities such as Race Conditions, randomness problems and buffer overflows. |
| 11 | DO NOT allow programmer backdoors or unauthorized access paths that bypass security mechanisms. |
| 12 | Avoid storing secrets like passwords in the code or use weak encryption schemes |
| 13 | Identify all points in the source code where the program takes input from users. |
| 14 | Identify all points in the source code where the program takes input from another program or un-trusted source. |
| 15 | Investigate all sources from which input can enter the program such as GUI, network reads, etc. |
| 16 | Check API (Application Program Interfaces) calls for security. |
| 17 | Investigate secure connections.  Verify that they actually may are secure and connect as indicated to the systems to which they are intended to connect. |
| 18 | Investigate software built-in extensibility features. |
| 19 | Review software complexity and look for alternatives to reduce the complexity. |
| 20 | Investigate the security of the data when passed from application servers to databases. |
| 21 | Avoid default or other improper configurations that may open the door to attackers. |
| 22 | Default to “highest security” needed and require validation and approval for deviations. |
| 23 | Establish tools to be used for various stages of the life cycle that will be used for assessing security. |
| 24 | Perform security testing for unit and system integration |

## Phase 2 SSC Process

- Establish a Process for External Release
- Functional Areas
- Multi-Functions Can Be in Same Authority

## Sample Checklist for External Release

| 1.0 | Does the software include IP addresses and subnet ranges?
    1.1  If yes, are these IP addresses sensitive?
    1.2  Can these addresses be used to gain information that may pose a risk to the organization? |
| --- | --- |
| 2.0 | Does the software/program include Host names?
    2.1  If yes, are these host names sensitive?
    2.2  Does the release of these host names pose a risk to the organization? |
| 3.0 | Do settings exist that could allow bypass of other security controls?
    3.1  If yes, can any of these settings be modified or deleted?
    3.2  If settings can not be modified or deleted, would they pose a risk to the organization?
    3.3  If settings can be modified or deleted, would they pose a risk to the organization? |
| 4.0 | Is there any non-sensitive information in the software that can be used to probe secrets?
    4.1 If yes, can non-sensitive information be manipulated to expose sensitive information?
    4.2 Can non-sensitive data be altered and modified so as to pose risk? |
| 5.0 | Is there any Material that might expose company information such as Customer lists? 
      5.1 If yes, are Customers lists protected under a privacy policy?
      5.2 Does the release of Customers lists pose a risk?
      5.3 Does the release of Customers lists do harm to the customers? |
| 6.0 | Is any of the data restricted?
      6.1 If yes, is the data controlled by security mechanisms such as RBAC?
      6.2 If yes, are their security restrictions on the transfer of restricted data?
      6.3 Is the restricted data transmitted over open networks?
             6.3.1  Is the restricted data encrypted before transmission? |
| 7.0 | . . . |

**Sample Checklist for External Release**