Article Preview
Top1. Introduction
Software security is a complex, evolving problem that can be significantly improved by integrating security requirements into the early stages of software development rather than correcting security flaws after release (Allen, Barnum, Ellison, McGraw, & Mead, 2008). However, traditional software development life cycle (SDLC) processes tend to focus attention on functional requirements leaving non-functional requirements, such as security, as an aside or afterthought. This results in security requirements that are added later (McGraw, 2005) in the development cycle or worse, after the product has been released in response to security events, market response, or regulatory demands.
There are several reasons for the reactionary response to software security. First, software engineers have a difficulty in building secure software due to a lack of software security awareness, training and education (Viega, 2005). Additionally, decisions about security may simply have been made based on the technology and capabilities available at the time the system was developed (i.e., early infrastructure systems). Finally, project cost constraints may focus resources on delivering functional requirements over non-functional requirements, such as security. Regardless of the reasons for this reactionary response to security, both software engineers and business stakeholders are becoming increasingly aware of software security needs.
Recent news reports of highly publicized data breaches have increased general awareness of the need to integrate security into software during development. In response, legislation at the state and federal level has also been increasing as the need for privacy and security becomes apparent. Such increased legislation is evidenced by the fact that nearly all states have enacted either security1, or data breach2 notification legislation. In general, software engineers have reacted to increased public awareness and legislative pressures by adding security mechanisms to existing systems on an ad hoc basis to mitigate risk. While subsequent mechanism based mitigation is a useful (and sometimes necessary) approach when addressing new, evolving, or previously unknown security risks, the approach often results in isolated, add-on countermeasures that are not cohesively integrated into the resulting system and its design. Money and time may be lost as software engineers work to prevent additional bugs as they retrofit existing systems with added security mechanisms.
However, if the security risk existed prior to development, then a security requirement could have addressed the risk by building security into the system from the start. In this case, implementing security mechanisms does not address the core problem that security requirements need to be integrated into software from the start, not mitigated later. The emerging field of security requirements engineering (SRE) seeks to address the special needs of integrating security requirements into the software development process.