1. CCSDS - Darmstadt SW Security
NASA’s IV&V Program
Safety and Mission Assurance (SMA) Office
Information Assurance/Cybersecurity Support
CCSDS - Darmstadt
SW Security
11/10/15
Brandon Bailey

2. Introduction Some security posture factors
NASA’s Mission is to put things into space and the air and the security posture of mission assets MUST be a priority
Historically security within NASA was thought of as an IT function (web sites/servers, , workstation patching, etc.)
Threat landscape has shifted and NASA is a TARGET of various threat actors (Script Kiddies, Hackers, Advanced Persistent Threat (APT), Nation States, etc.)
Attack surface has expanded – Networks interconnected!!
Some security posture factors
Network Layer (Routers, Firewalls, etc.)
Computer Network Defense (IPS/IDS, Sensors, Continuous Monitoring, etc.)
Industrial Control Systems (ICS)
Software Security (COTS, FOSS, Custom, etc.)

3. Reducing the SW Risk
NASA knows that software is one of many vulnerabilities that could adversely impact Mission Operations
Levying requirements from the top (NPR 2810 , B)
Software vulnerabilities or “defects” are arguably preventable in most cases
During custom code development
Secure Development
Rigorous SwA (Project and IV&V)
Awareness, Training, Tooling (i.e. SCP)
Software supply chain
COTS and Open Source (i.e. Origin Analysis)
Once introduced in operation – then what?
Penetration Testing
Vulnerability Assessments

4. Secure Development Utilize Best Practices – some examples below
Coding Standards (Ex. CERT C, C++ or JAVA Stds)
Integrate tools into development environment
Code Analyzers (i.e. Klockwork, Fortify, CodeSonar, Sonatype, BlackDuck, etc.)
Defense in Depth
Training
Secure Coding Tutorial
Defensive Programming (search in SATERN)
Codiscope

5. SwA – Assuring Security
Update SwA Standard and Handbook (in work)
Provide awareness/training to SwA personnel
Educate on importance of SW security (this briefing is a start!)
SwA personnel can leverage the same training as developers (i.e. SCP)
In order to “assure” it, you must understand it!
Utilize information on Secure Coding Portal (more to come on this!)
Not a clipboard exercise – SwA needs to use tools or ensure tools are being used to ensure SW is secure
Tools have latest security signatures and integrate industry’s best practices
Dynamic & static code analysis as well as binary analysis (i.e. identifying CWEs/CVEs)
Verify and validate project is accounting for security during requirements, testing, etc.
Ex: Security Requirement Traceability Matrix (SRTM), Whitebox/Blackbox Testing, Negative Testing, PenTesting, etc.

6. Secure Coding Portal (SCP) Background
Recognizing the need to counteract the threat of exploitation of custom developed software
A single touch point for NASA
developers was established to learn
how to develop code securely
Utilizes existing NASA Engineering
Network (NEN) infrastructure
Initial deployment is behind NASA firewall
Partnerships established with experts
CMU-SEI
Robert Seacord (Author of CERT C Std.)
Safari Books Online (custom secure coding tutorial)
Launched July 20, 2015
Volume One of Newsletter Distributed
Custom Secure Coding Tutorial Deployed
Contact for additional information

7. Secure Coding Portal Content
Secure Coding Discussion Forum – providing a friendly environment to discuss all aspects of Secure Coding with fellow engineers and experts
Vulnerability Updates – containing information about the latest software vulnerabilities and any insight into what systems, or types of systems, could be affected along with how to detect and mitigate these vulnerabilities
Vulnerability Newsletter will also be distributed directly to stakeholders
Tools – containing information about tools utilized by NASA for security analysis of software, including references, available training, and any relative insight/lessons learned from NASA practitioners
Links – containing references to security standards, documentation, and information
Top 25 CWEs – using CWSS to classify Top 25 CWEs for ground and flight
Tutorial – custom made tutorial by secure coding experts
Ask an Expert – providing the ability for any community member to request assistance from field experts

8. SCP Future Work Continue to develop newsletters
Vulnerability research across IV&V project to see what common vulnerabilities are being made
Providing a list of vulnerabilities that resides in commonly used third party software (COTS/FOSS )
Making the information available to decision makers so they can make Risk Informed Decisions
Offer “Free” Open Source Vulnerability Scanning to agency
Use IV&V’s toolset (BlackDuck, Sonatype, and OWASP Dependency Check) to run project’s binaries and source code
Perform additional research on Mitre’s CWE list to ensure our categorization of Flight and Ground CWEs are current/correct
If desired we can use the database tool we created to generate CWE lists for Web Apps, Deep Space, Low Earth, etc.
Videos for SCP
Video “tours” of SCP
Webinars for SCP
Training videos of setting up tools, using tools, etc. that are recommended on Tools Page
Build off work being funded by OSMA for hosting code security tools in the “cloud” – more tools, more VMs etc.
Infuse feedback from user communities (SwA WG, SWG, etc.)
Map NIST controls to mission software and/or B and 2810
Will help tie software being developed and hosted on accredited systems to appropriate NIST controls
Translate the guidance from NIST for supply chain down to the mission developer level

9. Origin Analysis
From Institute for Defense Analyses (IDA) SOAR Report – “Origin analyzers are tools that analyze source code, bytecode, or binary code to determine their origins (e.g., pedigree and version).”
NASA is beginning to invest in Origin Analysis to reduce the software supply chain risk
Initial roll out was/is during vulnerability assessments (i.e. BT-VAP)
Next step is to provide scanning as a service as a part of the Secure Coding Portal – performed by SCP team
Ultimate goal is to deploy origin analysis tools to NASA cloud for consumption by development organizations
Tools being used
Sonatype (auditor version)
Black Duck HUB – Note: Newer product similar but different from Black Duck Suite
OWASP Dependency Check
Work being performed to automate and consolidate report creation from all three tools

10. Recommendations for NASA Missions
To prevent future deployments of vulnerable code
Developers and SwA personnel participate in secure code training
Institute static source code and binary analysis to assist in identifying weaknesses (i.e. Developers, SwA, or IV&V)
Developers should perform software evaluations throughout the software development lifecycle to address potential security vulnerabilities early in the process
SwA should assure this is happening!
Factor of 10 in cost savings finding issues early
Use research from NSA’s CAS and Institute for Defense Analyses to establish a blend of tools that will provide the most value
Spreadsheet -

11. BACKUP SLIDES

12. Developers must…
…securely code to ensure the Technical Controls maintain the system’s security posture.
…securely code to implement the Security Controls identified in the SSP
…securely code to NASA-specific requirements, procedures and
recommendations that augment NIST guidance.
ITS-HBK
System and Information Integrity
ITS-HBK A
Access Control
ITS-HBK A
Access Control: Managed Elevated Privileges (EP)
ITS-HBK
Audit and Accountability
ITS-HBK
Identification and Authentication
ITS-HBK
System and Communications Protection
Back

13. Developers must…
…securely code to mitigate software security defects.
…adhere to the plans to mitigate security risks.
…implement risk mitigations in software to enable mission security.
…responsibly evaluate and consciously mitigate the risks of using sourced software.
…securely code to address all Use Cases when establishing access controls.
…use Static Code Analysis.
…have software V&V’d.
Back

14. DRAFT Requirements Not Final!!!
… may need a clearance to review certain docs. Long lead time!!
… SSP won’t segregate software from system. Focus on controls that affect SW
… “compliance” to their own security plan. Assure SW Supply Chain!
DRAFT Requirements
Not Final!!!
…SW security risks/mitigations are identified in PPP
… assure security requirements are identified and followed through implementation
… SW security isn’t a snapshot in time. Threats/Vulnerabilities are evolving and must be continually mitigated
<< see next slide >>
… assure HW supply chain

15. SA must…
…assure secure SW development practices are being followed
…assure their PPP identifies and mitigates SW security risks.
…assure the implementation of the risk mitigations in SW
…assure SW supply chain. Use tools when possible!
…assure SW addresses all Use Cases when establishing access controls.
…assure Static Code Analysis is performed -- best way to identify vulnerability in code
…assure they are V&Ving their risk implementations
Back