Tackling Software Security: An Increasing Threat

Generally, we think of security as an operational IT issue focused on defending our computers and networks from attackers and security breaches, or we think of information security concerned with protecting sensitive and personal information in digital form. But more and more, the lack of software (or application) security is becoming a greater source of vulnerability for many organizations.

As software and security professionals, we will never be able to get ahead of the game by addressing security solely as an operational issue. Attackers are creative, ingenious and increasingly motivated by financial gain. They have been learning how to exploit software for several decades; the same is not true for software engineers, and we need to change this.

The objective of software security is to build better, defect-free software. Typically software has many defects, and quite a few of these tend to be the source of security vulnerabilities that show up in our operational systems. Software developed with security in mind is more able to resist attack, and in the face of a successful attack, it’s better able to tolerate the attack and recover from it as quickly as possible.

Project managers responsible for software development need to carefully consider the knowledge, skills and competencies of their development team, their organizational culture’s tolerance (and attention span) for change and the degree to which sponsoring executives have bought in (a prerequisite for sustaining any improvement initiative). In some cases, it may be best to start with secure software coding and testing practices. These are the most mature, have a fair level of automated support and can demonstrate some early successes, providing visible benefits to help software security efforts gain support and build momentum. Recommended code and testing practices include:

• Training software developers to implement language-specific secure coding practices and ensuring their use;
• Performing source-code review using static analysis and other types of code-analysis tools;
• Understanding the differences between software security testing and traditional software testing, and reflecting these in the software test program;
• Conducting risk-based security testing that exercises common mistakes, suspected software weaknesses and implemented approaches for mitigating risks to make sure they work and cannot be circumvented.

On the other hand, secure software requirements, engineering, and architecture and design practices offer opportunities to address more substantive root cause issues early in the lifecycle that if left unaddressed will show up in code and test. Recommended requirements engineering and design practices include:

• Using a defined process for identifying and documenting security requirements that includes requirements elicitation, categorization and prioritization;
• Using techniques such as misuse/abuse cases, threat modeling and attack patterns to identify security threats. Attack patterns are a blueprint for creating an attack and include attack prerequisites, related vulnerabilities and the skills and resources required to execute the attack.
• Defining and using assurance cases to capture, communicate, demonstrate and validate desired levels of software security assurance based on defined properties;
• Performing an architectural risk analysis to assess the architecture and design’s ability to meet security requirements and resist, tolerate and recover from defined threats.

Regardless of where you start, the following practices are essential when developing software with security in mind:

• Select and integrate security practices (such as those described above) with your existing software development lifecycle and development process—during an acquisition or purchase, requirements specification, architecture, design, implementation, test and deployment. The objective of including security in a defined software development lifecycle is not to overhaul an existing process totally but to add well-defined security practices and security deliverables. Security needs to be tackled in the same way that software engineers address performance and reliability.
• Think like an attacker. In addition to considering what the software should do in terms of functions, features and capabilities, think about what the software should and should not do, and how the software can better resist, tolerate and recover when under attack.
• Keep in mind that security is a risk management issue. The highest areas of vulnerabilityand risk need to be assessed and mitigated during each lifecycle phase. Risks and their priorities will change as the software is designed, developed and deployed. The implementation of these risk management practices depends on the characteristics of the software. For example, risk analysis and assessment for an integrated system have different requirements than assessing risks for a commercial product or an infrastructure component.

Practice selection and tailoring are specific to each organization and each project based on the objectives, constraints and criticality of the software under development.

Julia H. Allen is a senior member of the technical staff within the CERT(r) Program at the Software Engineering Institute (SEI), a unit of Carnegie Mellon University in Pittsburgh. Allen is engaged in developing and transitioning executive outreach programs in enterprise security and governance as well as conducting research in software security and assurance.

Editor’s Note: This excerpt was printed with permission of Pearson Education from the book Software Security Engineering written by Allen, Julia H./ Barnum, Sean/ Ellison, Robert J./ McGraw, Gary/ Mead, Nancy R.