Tackling Software Security: An Increasing Threat
Addressing application security solely as an operational issue doesn't work. Attackers are increasingly motivated by financial gain and have been learning how to exploit software for several decades. The same is not true for software engineers, and that needs to change.
Wed, July 30, 2008
CIO — 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.
