Bolstering Security by Combining Patch Management with Risk Management

With the recent barrage of attacks on computer software by viruses and worms, it has become increasingly evident that the software organizations employ is insecure. As organizations move almost every aspect of their business to computing environments, the need for reliable and secure software has become paramount. All too often, however, security is lackingin the software that vendors release and this lack of security is the source for most information security breaches. In light of this lack ofsecurity, this paper examines the causes of security flaws and attempts to combine two existing methodologies in order to bolster an organization's defenses against security breaches that result from these flaws.

In the past, most security breaches took place at the servers and firewalls facing the Internet (Nicastro, 2003). As a result, most security efforts focused primarily on hardware. Over time, however, the types of threats and the potential risks both increased and changed to such a degree that organizations can no longer assume that they are secure behind a firewall. Today, viruses and worms can be delivered by various means, suchas through emails and their attachments, effectively bypassing the
protection provided by firewalls (Nicastro, 2003). Additionally, these viruses and worms can search for exploitable flaws on a variety of systems and can be automatically executed (Nicastro, 2003).

To understand why software flaws have become so prolific, one only needs to look into the mindset of the developers of the flawed software. From there, one can see that the flaws are the result of business-driven pressures. Scott Berinato (2003) sheds some light on these pressures, indicating that the vendors view time-to-market as having a higher priority than security. As such, he feels that vendors will continue to ship flawed code as long as they can. Deadlines imposed by vendor schedules cause
developers to work fast while under the continual pressure to add more features (Berinato, 2003). Berinato (2003) relates an old adage among developers that states, "When it comes to software, you can pick only two of three: speed to market, number of features, or level of quality" (para. 13). As a result, the third option is rarely chosen "since, of course, software is so easily repaired later, by someone else" (Berinato, 2003, para. 13).

According to an SEI study, the vast majority of software vulnerabilities result from ten common flaws. These include parameters that were not validated, broken access control, broken session and account management, and cross-site scripting flaws. Others include command injection flaws, error-handling problems, insecure cryptography, remote administration flaws, and server misconfigurations. The most common flaw, however, is that of the buffer overflow (Berinato, 2003). In fact, a
prominent database vendor estimates that 80% of its flaws are the result of buffer overflows. If it were able to eliminate the cost of patching these flaws, the vendor estimates a savings of $12 million per month on average (Austin & Darby, 2003). Thompson and Chase (2003) agree, arguing that if the software running on systems were more secure, the need for patching could be reduced or perhaps even eliminated. Unfortunately, history indicates that as long as dealing with security in code threatens a deadline, the need for patching will remain.


Research Questions


The following questions were posed in an effort to guide the research.

What are the causes for software security deficiencies?

Are the current methods of patch management sufficient as a solution for
these software security deficiencies?

Are there strategies that organizations can adopt to mitigate the risks
associated with these software security deficiencies?


1 Hypothesis

As a result of the security flaws in software, organizations should take a proactive and calculated approach toward securing their systems, one that no longer relies solely on firewalls or the security provided by the software vendors. By adopting a combined strategy of rigorous patch management and risk management practices, organizations can minimize the risks posed by software deficiencies. One solution is not entirely effective.

2 Methodology

To gain an understanding about the mitigation of risks regarding software flaws, research was conducted and consisted of a literature search for several topics in the realm of security and patch management. The topics of software coding deficiencies, patch management, patch management deficiencies, and risk management as applied to information technology were researched.

Much of the current literature dealing with software and patching deficiencies can be found in trade publications, whereas both academic journals and trade publications have provided much of the treatment on risk management. Few publications, however, have looked solely at the role risk management plays regarding the patching of software flaws. Most literature treats risk management in a broader sense, applying it to the information technology field as a whole.

Research Results

2.1 Patch Management Deficiencies

Patching arose as a reactive measure to repair software flaws. It is the predominant way in which organizations combat the threat posed by exploitable software flaws. Historically, however, patching has not always been the panacea for these flaws. Research indicates that the patch management process is cumbersome and requires diligence on the part of those charged with the duties of patching. According to Robinson (2003),the inability to deal with the cumbersome nature of patching has resulted in the overwhelming majority of security breaches in today's computing
environment.

The problems associated with patching begin at the moment of a security vulnerability disclosure. When a vulnerability is disclosed over the Internet, a race begins between the hackers and those trying to patch their systems (Berinato, 2003). "Disclosure basically gives hackers an attack map," says Gary McGraw, CTO of Cigital (Berinato, 2003, para. 24). Nicastro (2003) concurs, stating that the publicity a flaw receives across the Internet increases the risk that hackers could attempt to use the knowledge from the disclosure to compromise vulnerable systems.

Making patches available for these vulnerable systems does not necessarily eliminate the risks of exploits. According to Robinson (2003), patches may not be identified and installed in time to prevent attacks. In addition, some systems may go unpatched during a large-scale patch deployment. Coupled with defective patches that either fail to close vulnerabilities or create new ones, organizations face serious consequences should an exploit occur. These range from cleanup costs to legal liabilities for loss or corruption of data. Organizations may also face a loss of revenue due to outages and possible a loss in consumer confidence (Robinson, 2003).

Violino and Berinato agree that the current state of patch management is untenable for those applying the patches. Violino (2003) points out that patches are generally issued "in a way that's convenient for the supplier but not necessarily for the user" (p. 80). He adds, "There isn't really an integrated, one-size-fits-all tool for patch management" (Violino, 2003, p. 81). Berinato (2003) expands on this notion by stating
that "there's nothing standard about the patch infrastructure or managing the onslaught of patches" (para. 41). He notes that patches lack a standard naming convention, a standard installation procedure, and that there is little record keeping regarding the patch process. Yet, even with all of its flaws, the only way to repair flawed software after it is released is through patches (Berinato, 2003).


3. Case Study: The Slammer Worm


According to Berinato (2003), "Slammer neatly demonstrates everything that is wrong with manufacturing software patches" (para. 23). Echoing McGraw and Nicastro on the notion of disclosure, Berinato (2003) states, "everything about the SQL Slammer was old. It was an old hack that exploited an old vulnerability on an old target, Microsoft software" (p. 60). He indicates that the patch existed six months before the exploits, but "it was so kludgy to install that the patch needed a patch" (Berinato,2003, p. 60).

The Slammer worm was small in terms of computer code size, but enormous in terms of the havoc it unleashed. The 376 bytes of code that made up Slammer fit inside a single data packet that was broadcast across the Internet in January 2003 (Berinato, 2003). It was designed to infect unpatched Microsoft SQL Servers and MSDE, a piece of client software embedded into approximately 130 third-party applications (Berinato, 2003). Once it infected a single server, it generated a random set of IP addresses
upon which it would try to infect. Once it infected another server, the process repeated itself, with each new infection generating new IP addresses to infect (Berinato, 2003). At the height of its efforts, Slammer was scanning approximately 55 million servers per second, reaching this point only three minutes after the initial infection. After ten minutes, it is estimated that Slammer had infected 90% of all possible vulnerable SQL Servers (Berinato, 2003). Some of the more high profile
results included the taking down of the Finnish telephone service and over 13,000 Bank of America ATMs (Austin & Darby, 2003). In the midst of such a large-scale failure of patch management, Berinato finds an element of good in the Slammer worm events by stating,

There won't be a formal announcement of the fact, and no one
really planned it this way, but Slammer has become something of a
turning point. The fury of its 10-minute conflagration and the
ensuing comedy of a gaggle of firefighters untangling their
hoses, rushing out to the scene and finding that the building
burnt down left enough of an impression to convince many that
patching, as currently practiced, really doesn't work (para.
46).

Indeed, Slammer appears to have become a turning point for the industry, causing industry analysts to consider the role of risk management as a potential force in the software security area.

4 Risk Management and Information Technology

To gain a perspective on why some analysts are turning to risk management, it helps to have an understanding of the fundamental concepts of risk management and how they apply to information technology. From there, one can see the how risk management concepts can guide those dealing with software flaws.

Risk is defined as the "net negative impact of the exercise of a vulnerability, considering both the probability and the impact of the occurrence" (Stoneburner et al., 2001, p. 1). Strauss and Stummer (2002) concur, declaring that the "two essential characteristics of risk are the probability of occurrence and the magnitude of the damage" (p. 252). Risk management, therefore, is the "process of identifying risk, assessing risk, and taking steps to reduce risk to an acceptable level" (Stoneburner et al., 2001, p. 1).

Siegel et al. (2002) defines the risk management process as a "cycle of assessment, mitigation, insurance, detection, and remediation" (p. 34). Assessment involves the conducting of a comprehensive evaluation of security, which aids in determining the tools necessary for mitigation. Stoneburner (2001) adds that the risk assessment performed should enable an organization to determine the extent of the potential for threats and risks associated with an information technology system. The outputs of the process should enable management to identify the appropriate measures for the reduction or possible elimination of risk in the mitigation process.

One of the principle ways to measure risk during the assessment is to develop a risk scale and a risk-level matrix. Multiplying the ratings assigned for threat probability and the threat impact derives this matrix (Stoneburner, 2001).

Applying the risk scale and risk-level matrix allows an organization to easily determine which risks should be given priority and develop mitigation strategies to avoid such risks. It is the responsibility of the organization to determine the values it places in these tables regarding the threat likelihood.

During risk mitigation, Stoneburner (2001) holds that information technology managers are responsible for using the "least-cost approach" and should "implement the most appropriate controls to decrease mission risk to an acceptable level, with minimal adverse impact on the organization's resources and mission" (p. 27). Mitigation consists of the steps an organization takes to reduce risk, limit the possibility of incidents, and limit the impacts of breaches that do occur (Siegel et al., 2002). Shouldbreaches occur, insurance procured by an organization acts as a risk transfer mechanism, reducing any negative impact through finances and indemnifying if damage is detected. Such detection involves consistent and constant monitoring as a proactive means of discovering vulnerabilities and remediation is the response to any vulnerability that are discovered (Siegel et al., 2002).

According to Stoneburner (2001), the main goal of any risk management process for an organization is the protection of the organization and its ability to carry out its mission. Managers need to decide which risks are likely to materialize and which could cause the most harm, spending money where it will be most beneficial. In addition, technicians should not be making the decisions at this level. Instead, the general managers, who tend have more experience with risk management, should be the ones who "assess the business value of their information assets, determine the
likelihood they they'll be compromised, and then tailor a set of risk abatement processes to particular vulnerabilities" (Austin & Darby, 2003, p. 3).

4.2 Risk Management and Patch Management

Performing such risk analysis on software vulnerabilities is exactly what led Peter Tippett, Vice Chairman and CTO of Tru Secure, to declare, "With patching, we're picking the worst possible risk-reduction model there is" (Berinato, 2003, para. 56). Based on data he collected over twelve years, Tippett concludes that only 2% of vulnerabilities ever result in exploits. In fact, he claims, "more than half of Microsoft's 72 major vulnerabilities last year will never affect anyone ever" (Berinato, 2003, para. 56). As a result, Tippett suggests that organizations should improve their security policies, lock down unused ports on their firewalls, and pay
third party companies to "figure out which patches are necessary and which ones you can ignore" (Berinato, 2003, para. 56). In effect, he is making the case for a strong risk management process at the patching level.

Tippett is not alone in his opinion that patch management can be made more tenable through the application of risk management. In fact, Chad Robinson, in his CSO Analyst Report for the Robert Francis Group, states that information technology executives should evaluate services offered by providers that identify and deploy patches. He argues that the executives should evaluate these vendor solutions "to determine whether it would be possible to mitigate the cost associated with patching vulnerable systems without sacrificing response times to vendor alerts or thoroughness in identifying required patches" (Robinson, 2003, para. 4).

Robinson, however, does not off-load the entire risk management process to third parties. He leaves this to the information technology executives, much in the same way as Austin and Darby. These executives are charged with the responsibility to develop a matrix similar to that presented by Stoneburner. The matrix should be used to profile each software package employed by the organization and their sensitivity to vulnerabilities. The matrix should include the risk to the business should
a breach occur, the allowable periods of downtime for patching, and the risk vulnerability at each level (Robinson, 2003).

From this matrix, one can see the similarities to the matrix offered by Stoneburner. Although it is structurally different, it effectively adapts the notions of low, medium, and high and applies it to patch management accordingly. In addition, it provides timeframes during which the patching should take place.

Robinson (2003) provides an additional matrix that applies to patch management procedures. Such a matrix clearly identifies the procedures with the corresponding
owner of each. This matrix includes a notification column as well. Robinson feels that no one step should be considered complete without written notification. Such notification provides a means of identifying the events of the patching process and resolves the lack of documentation raised by Berinato.

The ultimate goal of applying risk management to the process of patch management is to define which servers are most important to the organization and to use the matrices to determine the schedule in which these servers are patched, while minimizing the cost and time to complete the process of patching (Robinson, 2003).

Discussion

With each new patch release, the notion that software is insecure becomes increasingly evident. Research indicates that poor coding practices are the main cause of software security deficiencies. To combat these deficiencies, the practice of patch management has been developed, but has seen mixed success. The research conducted on issues of patch management revealed that patch management, as currently implemented and practiced, is not sufficient as a solution for software deficiencies due to its cumbersome nature.

In an attempt to discover if standard risk management methodologies could bolster security defenses, it was hypothesized that risk management practices could allow an organization to minimize the risks posed by software security deficiencies when paired with patch management. The data gathered supports the hypothesis, in that, risk management practices can be combined with patch management policies to form a security strategy for organizations. Robinson's CSO Analyst Report effectively outlines such a strategy and, on these terms, the hypothesis can be accepted. In effect,introducing risk management to the patch management process makes good
business sense, effectively eliminating Berinato's "comedy of a gaggle of
firefighters" by providing structure. It does not protect an organization, however, as it merely serves to bring the process under control. Essentially, the introduction of a combined approach decreases or defers the patch management workload for those who must patch the systems.

Conducting further analysis, however, illustrates that the nature of software deficiencies makes any patch management process untenable on a practical level and reveals the limitations of such an approach. As an illustration of these limitations, consider the Slammer worm's affect on MSDE applications. Applying the risk management approach suggested by Robinson calls for the immediate patching of critical servers with high-risk levels, such as SQL Servers. This practice, however, would not have
prevented Slammer infections within an organization due to the vulnerabilities of the MSDE engine. As noted, this engine is embedded into desktop applications, and as such, would not have been immediately patched in accordance with Robinson's Sample Business Application Patching Matrix. As "Medium-Business Risk" systems, desktop products would have remained unpatched for several hours at best, providing a wealth of time for Slammer infections. Due to Slammer's self-replicating nature and its ability to generate network traffic, the organization would feel the effects of such
an infection almost immediately.

This presents an opportunity for further research regarding the creation of these software deficiencies. If the combination of patch management and risk management cannot resolve the issue of software deficiencies in a reactive fashion, then perhaps the responsibility to prevent such flaws should fall on the developers themselves. Research could be conducted to understand the pressures developers face and perhaps
develop ways to reduce the number of coding errors that result in software flaws.

The software that vendors ship is riddled with flaws that are the result of insecure code developed under intense pressure. In light of this, it was hypothesized that the combined approach of patch management and risk management could provide a means for an organization to protect itself. Ultimately, the hypothesis must be rejected on the basis of its inability to address the software deficiencies at a practical level. While the application of risk management to patch management does lend structure
to the process of patch management, it does not appropriate any additional security defenses by reducing risk for an organization.


References

Austin, R & Darby, C. (2003). The Myth of Secure Computing. Harvard Business Review, 1-7.

Berinato, S. (2003, May 15). The Bugs Stop Here. CIO, 60-68.

Berinato, S. (2003, August). Patch and Pray. CSO. Retrieved September 25, 2003, from
http://www.csoonline.com/opinion/links/1556.html.

Nicastro, F. (2003, November). Security Patch Management. Security Management
Practices, 5-18.

Robinson, C. (2003, October). Patch Deployment Best Practices in the Enterprise. CSO.


Retrieved October 25, 2003, from http://www.csoonline.com/analyst/report1837.html.


Siegel, C., Sagalow, T., & Serritella, P. (2002, September). Security Patch Management. Security Management Practices, 33-49.


Stoneburner, G., Goguen, A., & Feringa, A. (2001). Risk Management Guide
for Information


Technology Systems. Washington, DC. (NIST No. SP 800-30).


Strauss, C. & Stummer, C. (2002). Multiobjective Decision Support In IT-Risk Management.


International Journal of Information Technology and Decision Making. 1, 251-268.


Thompson, H., & Chase, S. (2003). Red-Team Application Security Testing. Dr. Dobb's
Journal, 28(11), 18-25.


Violino, B. (2003, August 1). Patching Things Up. CIO, 79-82.