Introduction
There are several ways of classifying vulnerabilities. Classification by “Software Development Lifecycle (SDLC) Phase strives to provide attack and vulnerabilities when they are introduced in the software life cycle” (Meunier, n.d, pp. 2-3).
Software development has six phases, and hackers can introduce threats at any point. In some cases, vulnerabilities may result from the failure of the algorithm in the design phase. It could also take place due to failure in the implementation procedures. Hence, attackers can introduce vulnerabilities at any phase in these processes of the software development life cycle.
Another classification of vulnerability class refers to “design, implementation and configuration vulnerabilities” (Meunier, n.d, p. 2). Vulnerabilities that result from configuration do not have major impacts. They occur during operation and maintenance. Engineers can easily fix them if they review the design and implementation stages.
Main body
Operation and maintenance phases could introduce vulnerabilities in different ways during the software development life cycle. Any vulnerability that attackers introduce in the software during operations becomes an “issue of configuration. However, some forms of vulnerabilities may occur due to “interactions with an unexpected or changing environment, including other installed software and operating system version, kernel modules and libraries, or unexpected or virtual hardware” (Meunier, n.d, p. 3).
Some forms of vulnerabilities take place during “system maintenance, particularly when fixing bugs or improving functionalities of software” (Meunier, n.d, p. 3).
Software development life cycle has provided five classes of main vulnerabilities as “analysis, design, implementation, deployment, and maintenance” (Meunier, n.d, p. 3).
Organizations have used secure software life cycle techniques and tools to protect against some of the specific types of attacks and vulnerabilities. The most effective approach, which organizations have used, is ‘closing the door’ (Internet Security Systems, Inc., 2005, p. 3). In this context, the software developer who brought vulnerabilities in the system must address the problem by issuing an effective solution that must eliminate the vulnerability. However, the challenge is that end users may not gain access to the released patch immediately. Meanwhile, the vulnerabilities would continue with massive damages. The use of patches could be time-consuming while other available approaches may be effective. This approach works in the maintenance phase of software development.
Another approach is shielding the vulnerability. This aims at eliminating the vulnerabilities. Hence, one may not wait for the vulnerability to cause damage before reacting. In this case, the developer will block the attack from taking place during the software development life cycle. Vendors have the ability to prevent all potential exploits before even classifying or knowing all about the exploit. This is an effective approach because it is not reactive, but rather a proactive approach of dealing with vulnerabilities in the product development life cycle.
Finally, some organizations react to threats or exploits. They must identify the vulnerability and then write its signature. This method is a reactive approach for managing vulnerabilities, which could only be “effective from the time the signature is first added to the antivirus signature database until the patch (to “close the door”) can be applied” (Internet Security Systems, Inc., 2005, p. 4).
While organizations have used secure software life cycle techniques to manage vulnerabilities, they still experience vulnerabilities, which could cause severe damages. On the other hand, other organizations have managed to reduce vulnerability exploits through various techniques. For instance, Microsoft has developed Microsoft Security Development Lifecycle (SDL). The SDL is a technique that Microsoft uses to “reduce the number and severity of vulnerabilities in its products” (Swigart and Campbell, 2009, p. 1). This indicates that many firms have serious challenges with software vulnerabilities. As a result, they must constantly work on new possibilities of dealing with vulnerabilities in their products. In fact, Microsoft shows that approaches to vulnerabilities in software development have evolved because they must review SDL twice a year.
Organizations must focus on secure software development processes in order to reduce cases of vulnerabilities. This is what Microsoft aims to achieve through its SDL approach. Software vendors should upgrade their approaches to reducing vulnerabilities and incorporate “new best practices in a timely fashion, while keeping the rate of change low enough that product teams can stay in sync with their models for reducing vulnerabilities” (Swigart and Campbell, 2009, p. 1).
Conclusion
Software developers should also review their products against what security researchers have used in their systems to discover new vulnerabilities. In this respect, they must work hard to discover software vulnerabilities from the source code before hackers do so. Source code can allow researchers to understand behaviors and determine the present vulnerabilities.
Researchers and developers should also conduct “fuzz testing or stress testing” in order to discover vulnerabilities.
References
Internet Security Systems, Inc. (2005). The Lifecycle of a Vulnerability – An ISS Whitepaper. Atlanta, GA: ISS.
Meunier, P. (n.d). Classes of Vulnerabilities and Attacks. Web.
Swigart, S., and Campbell, S. (2009). Evolution of the Microsoft Security Development Lifecycle. SDL Series Article, (7), 1-8.