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.