SOFTWARE ASSURANCE – SECURITY THROUGHOUT THE LIFECYCLE
Just as Hacker 101 set the stage for the importance of Secure Coding, both the Hacker 101 and Secure Coding classes were designed to lead into the final class on Software Assurance titled Secure Software Design, Lifecycle and Testing. The goal for the week was to introduce the concept of Software Assurance and the lifecycle activities which support it. Secure software design, architecture and development processes as well as testing are at the heart of software assurance. Software assurance is defined as the level of confidence that software functions as intended and is free of vulnerabilities, either intentionally or unintentionally designed or inserted as part of the software, throughout the life cycle”. 5,6 Software Assurance has been around for over a decade in industry. Guidance exists in our DoD instructions and is mandated by congressional National Defense Authorization Acts (NDAA). DoD instruction 5200.44 for Trusted Systems and Networks5 states that software assurance will be used throughout the lifecycle to manage risk of key systems. NDAA FY136 and subsequent NDAAs state that software assurance will be implemented for the entire lifecycle for trusted defense systems. Software assurance is the security component of Software Engineering. Testing activities and tools can only find a small portion of the weaknesses and vulnerabilities in our DoD systems. Security software itself has been noted to introduce 1/3 of the vulnerabilities7. Therefore, it lies with the software developers and validators themselves to fundamentally understand the tenants of secure software development, lifecycle processes, and tools in order to best protect and defend ourselves from attacks. The benefit from developers tackling this issue now is to be able to experiment with, inform and select activities that fit well into their current processes. These experiences could support their program manager’s requirement to prove how they utilize software assurance on their programs.
This class touched upon secure software development lifecycle models and their components, secure coding recommendations for each phase of the lifecycle, password security and software security testing. As each one of these topics could support a class unto themselves, they were introduced with examples to show their importance and overall place in the lifecycle.
Lifecycle Models, Activities & Recommendations
First, the class introduced the notion of secure software development lifecycle models such as Gary McGraw’s Touchpoints, Build Security In Maturity Model (BSIMM), Microsoft’s Security Development Lifecycle (SDL) and OWASP’s Open Software Assurance Maturity Model (Open SAMM). The class noted examples from the Microsoft SDL that covered the requirements and design phases. Additional examples for the design, implementation, distribution, installation, operation and maintenance and retirement activities were also covered. Each of these topics could require their own separate training so the topics were introduced with resources and examples so that the students were aware of them and their part in the secure development lifecycle. The requirements portion included security requirements, risk analysis and prioritization based on impact and likelihood. The design portion included design, development and test requirements. Recommendations included items such as keeping the code simple so that it is harder to inject malicious code or unintentionally insecure code, using standard libraries instead of creating your own (security by obscurity doesn’t work), breaking down components into smaller modules to reduce the scope of privileges each had available, and using Application Program Interfaces (API) with pre-defined statements to control user input. Design activities included analyzing the attack surface to review settings, open ports, services and accounts for security as well as threat modeling to break down the system into components and data flows to identify areas an attacker could target. The Implementation phase mentioned items such as not turning off compiler warnings. Distribution touched on sending the key and crypto checksum separately for additional security. Installation noted configuration choices to support security and removing unneeded components. Operation and Maintenance noted that updates need to be given the same rigor as the initial development. Retirement was mentioned as an issue because backward compatibility supports flaws from past versions.