Cyber Software Assurance Secure Coding Applications to Include

Cyber Software Assurance – Secure Coding Applications to Include the use of Static and Dynamic Analysis DAU Cybersecurity Enterprise Team Tim Denman, CISSP tim. denman@dau. mil 256 -922 -8174 Roy E. Wilson, CISSP, CEH, SEC + roy. wilson@dau. mil 240 -895 -7328 DAU Acquisition Training Symposium, 3 April 2018

Bottom Line Up Front (BLUF) Secure Code Development, Analysis, & Test 1. 2. 3. Resources are out there PM responsibility to ensure execution Performed as part of system security engineering

Cybersecurity Coding Challenge CYBER WAR

Cybersecurity in the Defense Acquisition System Sw. A is essential for successful mission accomplishment with today’s SW intensive weapon systems “Cyber protection measures for mission-critical functions and critical components must, at a minimum, include software assurance, hardware assurance, …” DODI 5000. 02

System Security Engineering (SSE) 24 System Engineering Design Considerations (DCs) 7 System Security Engineering DCs Affordability Anti-Tamper (AT) Corrosion Prevention and Control Defense Exportabilty Features (DEF) Environment, Safety, and Occupational Health Software Assurance (Sw. A) System Security Producibility, Quality and Manufacturing Readiness Reliability & Maintainability Other System Engineering Reference: Defense Acquisition Guidebook, https: //www. dau. mil/tools/dag Hardware Assurance (Hw. A) Cybersecurity Supply Chain Risk Management (SCRM) Other Security (OPSEC, INFOSEC, PERSEC, COMSEC) 5

Sw. A and the SDLC Software Assurance is a part of SE focused on eliminating vulnerabilities Sw. A Trades A ASR Criticality Analysis Threat Vulnerability Analysis SRR RFP Sw. A Countermeasures Test Coverage Eliminate Design Flaws SFR PDR Assured Arch & Design Penetration Test Monitor Threats / Attacks Discover & Fix Operational Vulnerabilities Maintain SW Full Rate Production Decision Review C B Technology Maturation & Risk Reduction Materiel AOA Solution Analysis Code Inspection Developmental RFP Release Decision Point Requirements Authority Review MDD Secure Coding Practices Design Inspection Design Principles Engineering & Manufacturing Development CDR TRR Identify Code Flaws Production and Deployment OTRR IOT&E SVR Identify Test Gaps Secure Code Improved Test Suites Vulnerability Root Cause Operations & Support IOC FOC Effective Threat Response Fewer Process Vulnerability Software Assurance spans the entire system lifecycle Cyber Situational Awareness Cyber Resilient Systems

Sw. A in Systems Engineering System Survivability KPP Continuous Monitoring Sw. A Stakeholders System Authorization Decision Blue/Red Team Assessment Sw. A in the RFP Static/Dynamic Code Security Assessment Security Architecture and Design TSN/SCRM Systems Security Analysis (Information, CPI, CC) Ref: ISO/IEC/IEEE 15288, Systems and Software Engineering- System Lifecycle Processes, 15 May 15 Secure Code Practices 7

Secure Coding Practices 1. Model threats. Use threat modeling and develop threat mitigation strategies that are implemented in design, code, and test cases [Swiderski, 2009]. 2. Define security requirements. Identify and document security requirements early in the development life cycle and make sure that subsequent development artifacts are evaluated for compliance with those requirements. 3. Architect and design for security policies. Create a software architecture and design your software to implement and enforce security policies. For example, if your system requires different privileges at different times, consider dividing the system into distinct intercommunicating subsystems, each with an appropriate privilege set. 4. Keep it simple. Keep the design as simple and small as possible [Jerome H. Saltzer, 1974][Jerome H Saltzer, 1975]. Complex designs increase the likelihood that errors will be made in their implementation, configuration, and use. 5. Default deny. Base access decisions on permission rather than exclusion. This means that, by default, access is denied and the protection scheme identifies conditions under which access is permitted [Jerome H. Saltzer, 1974][Jerome H Saltzer, 1975]. 6. Adhere to the principle of least privilege. Every process should execute with the least set of privileges necessary to complete the job. [Jerome H. Saltzer, 1974][Jerome H Saltzer, 1975] Reference https: //www. securecoding. cert. org/confluence/display/seccode/Top+10+Secure+Coding+Practices

Secure Coding Practices (cont’d) 7. 8. Sanitize data sent to other systems. Sanitize all data passed to complex subsystems such as command shells, relational databases, and (COTS) components. Practice defense in depth. Manage risk with multiple defensive strategies, so that if one layer of defense turns out to be inadequate, another layer of defense can prevent a security flaw from becoming an exploitable vulnerability and/or limit the consequences of a successful exploit. 9. Validate input from all untrusted data sources. 10. Adopt a secure coding standard. 11. Heed compiler warnings. Compile code using the highest warning level available for your compiler and eliminate warnings by modifying the code. Use static and dynamic analysis tools to detect and eliminate additional security flaws. 12. Use effective quality assurance techniques. Good quality assurance techniques can be effective in identifying and eliminating vulnerabilities. Fuzz testing, penetration testing, and source code audits should all be incorporated as part of an effective quality assurance program. Independent security reviews can lead to more secure systems. Reference https: //www. securecoding. cert. org/confluence/display/seccode/Top+10+Secure+Coding+Practices

Analysis Classes Static analysis examines the system without executing it and can be applied to design representations, source code, binaries, and bytecode. Tools include attack modeling, source code analyzers, obfuscated code detection, bytecode or binary disassembly, human review/inspection, origin analysis, digital signature verification, configuration checking, permission manifest analysis, development/sustainment version control, deliberate obfuscation, rebuild and compare, and formal methods. Dynamic analysis examines the system execution, giving it specific inputs and examining results and/or outputs. Tools and techniques include network scanner, network sniffer, network vulnerability scanner, host-based vulnerability scanner, fuzz tester, framework-based fuzzer, negative testing, digital forensics, intrusion detection systems/intrusion prevention systems, automated monitored execution, forced path execution, firewall, man-in-the middle attack tool, debugger, and fault injection. Hybrid analysis applies to the tight integration of static and dynamic analysis approaches. Reference: SOAR 10

Analysis Tools • • Use a combination of tools. Static analysis and dynamic analysis are complementary Origin analysis should be used whenever third-party components are present. Use interactive security testing and hybrid tools if needed to get the most coverage. 11

Tools, Tools t ho gs Re F i n d. Bu AFIC A g T s C Code. Sonar IS LS AS K y f T 5 i I t. 0 N r O o Srv. Man M F Driver. Max e m r a d n e G y t i E R r I e W P I v FCIV R o T C 12

Tool Type Summary Secure Development Practices Attack Modeling Warning flags Source code quality analyzer Source code weakness analyzer Quality analyzer Bytecode weakness analyzer Binary weakness analyzer Inter-application flow analyzer Binary/bytecode simple extractor Focused manual spot check Manual code review Inspections Generated code inspection Configuration checker Permission manifest analyzer Host-based vulnerability scanner Host application interface scanner Web application vulnerability scanner Web services scanner Database scanner Fuzz tester Negative testing Test coverage analyzer Hardening tools/scripts Type Static Static Static Static Dynamic Dynamic Hybrid Grouping Requirements Source Code Analyzers Binary/bytecode Binary/bytecode Human review Application-type-specific vulnerability scanner 13

Software Secure Coding and Testing Resources

Where can I go for additional information?

SW & HW Assurance Resources jfac. navy. mil Cited in DODI 5000. 02

Sw. A Resources DRAFT

Sw. A Resources Resource State-of-the-Art Resources (SOAR) for Software Vulnerability Detection, Test, and Evaluation [Wheeler, 2016] Building Security In Maturity Model (BSIMM) [Mc. Graw, 2017] Cyber. Security Engineering: A Practical Approach [Mead, 2016] SAFECode (https: //safecode. org) Intellipedia at Intelink (https: //intellipedia. intellink. gov) Description A publication by the Institute for Defense Analyses (IDA) that contains a large volume of information on the types of tools available and contextual factors on how they can affect security. A study of existing software security initiatives sponsored by the Department of Homeland Security. It collects the state of professional practice, but does not recommend specific practices. A book in the SEI Series on Software Engineering. This publication provides a reference and tutorial on a broad range of assurance issues and practices. An industry group “dedicated to increasing trust in information and communications technology products and services through the advancement of effective software assurance methods. ” A collection of wikis available to individuals with appropriate clearances. These online resources contain information on various software assurance topics relevant to Do. D developers and contractors.

Secure Coding Resources – Detailed List Secure Coding Resources Compiled by the CECOM Software Assurance (Sw. A) Team 1. DISA Application Security and Development Security Technical Implementation Guide (APPSEC STIG): http: //iasecontent. disa. mil/stigs/zip/Aug 2016/U_ASD_V 4 R 1_STIG. zip 2. NIST Special Publication 800 -160: http: //nvlpubs. nist. gov/nistpubs/Special. Publications/NIST. SP. 800160. pdf 3. Department of Homeland Security US-CERT Build Security In: https: //www. us-cert. gov/bsi 4. NIST National Vulnerability Database Version 2. 2 : https: //nvd. nist. gov/ 5. Korn and Bash Shell Programming Standards and Guidelines: http: //www. nws. noaa. gov/oh/hrl/developers_docs/Korn_and_Bash_Shell_Standards. pdf 6. Vetting the Security of Mobile Applications: http: //nvlpubs. nist. gov/nistpubs/specialpublications/nist. sp. 800 -163. pdf 7. CERT ISO/IEC Standards: http: //www. cert. org/secure-coding/standards/index. cfm

Secure Coding Resources – Detailed List (Cont’d) 8. Common Vulnerabilities and Exposures: https: //cve. mitre. org/ 9. Common Weakness Enumeration : http: //cwe. mitre. org/ 10. CERT Secure Coding Standards : https: //www. securecoding. cert. org/confluence/display/seccode/SEI+CERT+Coding+Standards a. C – CERT C Secure Coding Standard : https: //www. securecoding. cert. org/confluence/display/c/SEI+CERT+C+Coding+Standard b. C++ – Secure Coding Standard: https: //www. securecoding. cert. org/confluence/pages/viewpage. action? page. Id=637 c. Java – CERT Oracle Secure Coding Standard for Java : https: //www. securecoding. cert. org/confluence/display/java/SEI+CERT+Oracle+Coding+Standard +for+Java d. Perl – CERT Perl Secure Coding Standard : https: //www. securecoding. cert. org/confluence/display/perl/SEI+CERT+Perl+Coding+Standard e. Android – Secure Coding Standard: https: //www. securecoding. cert. org/confluence/display/android/Android+Secure+Coding+Standard

Secure Coding Resources – Detailed List (Cont’d) 11. Open Web Application Security Project (OWASP): https: //www. owasp. org/ a. PHP – OWASP PHP Security Cheat Sheet : https: //www. owasp. org/index. php/PHP_Security_Cheat_Sheet b. OWASP Secure Coding Practices : https: //www. owasp. org/images/0/08/OWASP_SCP_Quick_Reference_Guide_v 2. pdf c. REST Security Cheat Sheet: https: //www. owasp. org/index. php/REST_Security_Cheat_Sheet d. Ruby on Rails Cheatsheet: https: //www. owasp. org/index. php/Ruby_on_Rails_Cheatsheet e. HTML 5 Security Cheat Sheet: https: //www. owasp. org/index. php/HTML 5_Security_Cheat_Sheet f. Cold. Fusion Security Resources: https: //www. owasp. org/index. php/Cold. Fusion_Security_Resources 12. Mobile – OWASP Android/i. OS Secure Coding Practices : a. https: //www. owasp. org/images/f/fe/MASVS_v 0. 9. 3. pdf b. https: //b-mueller. gitbooks. io/owasp-mobile-security-testing-guide/content/ (Work in progress, finished version Q 3 2017) c. https: //www. owasp. org/index. php/OWASP_Mobile_Security_Testing_Guide#tab=Main (Checklist at bottom for Android and i. OS specific security assessments) 13. Python – OWASP Python Security website : http: //www. pythonsecurity. org/

Secure Coding Resources – Detailed List (Cont’d) 14. Berkeley Secure Coding Practice Guidelines : https: //security. berkeley. edu/secure-coding-practiceguidelines 15. Mcafee White Paper “Secure Coding for Android Applications”: https: //www. mcafee. com/us/resources/white-papers/foundstone/wp-secure-coding-androidapplications. pdf 16. NET Framework 4. 7, 4. 6, and 4. 5 “Secure Coding Guidelines”: https: //msdn. microsoft. com/enus/library/8 a 3 x 2 b 7 f(v=vs. 110). aspx 17. C# Coding Conventions: https: //msdn. microsoft. com/en-us/library/ff 926074. aspx 18. “Secure Coding Guidelines for Java SE” (8): http: //www. oracle. com/technetwork/java/seccodeguide 139067. html 19. XML Secure Coding Paper: http: //resources. infosecinstitute. com/xml-secure-coding/ 20. Java. Script Best Practices: https: //www. w 3. org/wiki/Java. Script_best_practices 21. Fedora Security Team “Secure Ruby Development Guide”: https: //docs. fedoraproject. org/en. US/Fedora_Security_Team/1/pdf/Secure_Ruby_Development_Guide/Fedora_Security_Team-1 Secure_Ruby_Development_Guide-en-US. pdf 22. Web. App. Sec/Secure Coding Guidelines: https: //wiki. mozilla. org/Web. App. Sec/Secure_Coding_Guidelines

Summary Secure Code Development, Analysis, & Test 1. 2. 3. Resources are out there PM responsibility to ensure execution Performed as part of system security engineering Guidance and Tools are Available 23

Closing You’ve heard “bake it in” is the right approach to Cybersecurity and System Security Engineering 24

Closing But, until we make Software Assurance part of the software development and engineering community’s DNA, we will only have inconsistent results at best. 25