Information Security Today Home

New Books

The Security Risk Assessment Handbook: A Complete Guide for Performing Security Risk Assessments, Second Edition
Practical Risk Management for the CIO
FISMA Principles and Best Practices: Beyond Compliance
Security Patch Management ISBN: 9781439824993
Mobile Device Security: A Comprehensive Guide to Securing Your Information in a Moving World

Security Patch Management: Getting Started

Felicia Nicastro

Over the past year, organizations have taken various steps to improve the way they install patches in their environment. In some cases, organizations may have had a patch management process in place. In other situations, patches were installed on an ad hoc basis. Regardless of the state they were in, and given the enormous impact of exploits in recent history, organizations are scrambling to organize their patch management processes so they are not as exposed to future exploitations.

While a future chapter will provide a detailed description of putting the patch management process in place, this section aims to provide some initial insight into getting started. First, the organization must determine who will own the process, meaning who will ensure that it is established appropriately. The group to which ownership is assigned is also held responsible for ensuring the process is being followed properly, as defined. The next step in getting started is for an organization to fully understand that patch management requires an equal combination of people, processes, and technology.

While organizations typically use the combination of some or all three of these pieces, everyone involved must also understand the seriousness of the patch management process. Everyone needs to buy into the process, and, once it is in place, the organization needs to implement a mechanism to measure its success. During the patch management planning and implementation phases, the organization should provide to executive management a business plan, which will provide management with a return on security investment (ROSI) for implementing the process. The organization should also establish a mechanism to measure the ongoing success of the process itself. The final part of the next-steps section provides some additional background on the patch management process and how to get started.

Who Owns the Process?
One of the first questions an organization needs to sort out is where the patch management process will reside in the organization. That is, who will own the process? If the organization has already established a patch management process and is looking to modify it, or if the organization is looking to implement a new process, this question must be answered before anything can proceed. Depending on the size of the organization, multiple departments and groups may play direct and indirect roles in the patch management process.

Because patch management really overlays multiple groups, departments, and locations, it is best to have the process owned by a centrally located unit that is responsible for regular communication with the rest of the organization. To be more specific, patch management affects each group, department, and location that has systems that are chosen for inclusion in the process. Therefore, a centralized group that can have an impact on all of these groups must be chosen to own the process.

Figure 1.1 shows an example of the old way and the new way that a security group would report to management. In the old way, and even in a lot of organizations today, it is common to see the security group report to the director of technology. As more and more organizations are moving toward a better overall security posture, they are seeing the need to expand this group into a separately staffed and funded group. The bottom portion of Figure 1.1 shows the new way an organization is established; it has the security group reporting to the director of security. This allows the security group to drive the overall security posture within the organization and gain the executive management support required to do so effectively. This organizational structure is used as the overall reference throughout the book when any examples or details are provided about the overall organizational structure.

Figure 1.1 The old way vs. the new way.

While examples and suggestions for deviations are provided, using the same structure throughout will assist the organization in tailoring the process to meet its own needs. If the organization has not established this separately staffed and funded group, an immediate recommendation would be to do so to ensure that the patch management process receives the support it needs-not only from executive management but also from the other groups involved in the process. This applies to the entire security posture of the organization, not just for the purposes of implementing a patch management process.

Before the recommendation on who should own the patch management process is provided, an explanation of what the group must be ready to do should be described. First, let us take a step back and provide some insight into what is going to be explained in grave detail later. For any patch management process to be successful, regardless of the size of the organization, a security committee must be established that is ultimately responsible for overseeing the process and ensuring each patch has gone through this course of action appropriately. This committee does not have ownership of the process; instead, it consists of individuals from other groups. A separate, established, formal group will have the ultimate ownership of the process and will lead the effort to establish the patch management process in the organization. The group that has ownership of the process must have a level of communication with all the groups that will be affected.

The group with ownership of the process must have a clear understanding of its internal roles and responsibilities, not just currently but also as the process moves forward. The group that obtains ownership must have the resources and manpower required to ensure that the process functions as it was defined. If any discrepancies are identified, this group report to the director of technology. As more and more organizations are moving toward a better overall security posture, they are seeing the need to expand this group into a separately staffed and funded group. The bottom portion of Figure 1.1 shows the new way an organization is established; it has the security group reporting to the director of security. This allows the security group to drive the overall security posture within the organization and gain the executive management support required to do so effectively. This organizational structure is used as the overall reference throughout the book when any examples or details are provided about the overall organizational structure.

While examples and suggestions for deviations are provided, using the same structure throughout will assist the organization in tailoring the process to meet its own needs. If the organization has not established this separately staffed and funded group, an immediate recommendation would be to do so to ensure that the patch management process receives the support it needs-not only from executive management but also from the other groups involved in the process. This applies to the entire security posture of the organization, not just for the purposes of implementing a patch management process.

Before the recommendation on who should own the patch management process is provided, an explanation of what the group must be ready to do should be described. First, let us take a step back and provide some insight into what is going to be explained in grave detail later. For any patch management process to be successful, regardless of the size of the organization, a security committee must be established that is ultimately responsible for overseeing the process and ensuring each patch has gone through this course of action appropriately. This committee does not have ownership of the process; instead, it consists of individuals from other groups. A separate, established, formal group will have the ultimate ownership of the process and will lead the effort to establish the patch management process in the organization.

The group that has ownership of the process must have a level of communication with all the groups that will be affected. The group with ownership of the process must have a clear understanding of its internal roles and responsibilities, not just currently but also as the process moves forward. The group that obtains ownership must have the resources and manpower required to ensure that the process functions as it was defined. The group that obtains ownership must have the resources and manpower required to ensure that the process functions as it was defined.

If any discrepancies are identified, this group will bring these to the attention of the security committee to ensure that the process is reviewed and revised as necessary to eliminate these questions. Because the patch management process will eventually become an established, standard operating procedure, the group identified to own the process must have assured future stability. A group that will be dismembered cannot be used. A temporary group must not be established to own the process only for the purpose of establishing it in the organization and then to be disbanded once the process is in production. The group must be in place today and moving forward.

The ownership is determined through various means. Chances are that the organization will want to assign ownership to the group having the least amount of responsibilities. This decision is not recom-mended. It should be owned by the group that is most capable and that has the most overall security-based impact on the organization. The group must be able to drive the process and to gain the executive support required to sustain it. The operations group should not own patch management, even though it is part of operations and the patch will affect its systems. This group is responsible for the systems that will be included in the patch management process; therefore, it is responsible for ensuring that these vulnerable systems are patched appropriately. It is the "fox watching the henhouse" scenario. The ownership group should not have responsibility for the systems that will be included in the process, because this will influence the decisions on whether to deploy the patch on vulnerable systems.

Other vectors into patch management include IT, the operations group, and the network operations center (NOC). Putting the ownership of the patch management process on any of these three groups brings back the "fox and the henhouse" situation once again. The security group is the driving force in putting a patch management process in place. The security group has the overall responsibility of ensuring that the entire organization is protected against threats, risks, and vulnerabilities. A patch is a method to mitigate against a known vulnerability; therefore, it is a security measure that must be implemented to make certain that the organization maintains the confidentiality, integrity, and availability of all organizational assets.

The security group is then the group that should have ownership of the patch management process-regardless of the size of the organization. Even if a security group is minimal in size or if the organization does not warrant a large security group, additional staff may be required to offset some of the group's current responsibilities. Any additional measures, such as manpower, must be put in place prior to establishing the process within the organization's environment..

People, Process, and Technology
People, process, and technology are all common aspects to any management process implemented within an organization. The three aspects can be thought of as gears, all required to work together to accomplish the task successfully. They must also be aligned properly within the organization when it comes to the patch management process. Of course, this can be applied to all the processes within an organization and not just to patch management. An explanation of each of these aspects is required to provide background on what each entails.

The people aspect is self-explanatory; it is the individuals responsible for confirming that a task has been completed. They may be management providing the support required to ensure that the process is established and adhered to properly by all individuals required. The operational personnel provide input and guidance into the process. They may be the ones driving the process or seeing the need to create one. The operational personnel may provide the rest of the group with guidance on how the process should be designed or some of the requirements that the process must meet. The technical personnel are the ones who may complete an actual task. They may be the ones following the procedures established within the process, such as deploying the patch to the vulnerable systems. People come into play at various intervals within a process through the ownership, establishment, and day-to-day operations of the process itself.

The process aspect is the predefined and documented procedures that make up the process itself. The process defines what the organization is trying to achieve and what it must do to achieve its goal. Some procedures also roll up into the process; they are the detailed steps that must be taken to complete a course of action that is ultimately a part of the overall process. This then becomes part of the policy, process, and procedure documents that an organization creates. The policy provides a high-level overview of what the organization is achieving; in this case, patch management. By including the roles and responsibilities in patch management, the process depicts how the organization will complete it. The procedures then provide the detailed steps that must be taken to ensure that what the policy and process are dictating is completed within the organization.

Technology provides assistance in the completion of the task at hand. It supports the process, enabling people to finish the task in a timely and effective manner. The technology aspect is the tool the organization uses to achieve its task as it is defined in the process. Technology can include something as simple as a server that provides authentication for remote users ranging to a network management console that gives the operations group the up-to-date status of the organization's infrastructure. In the area of patch management, technology can assist the organization in many different areas, including notification of patches as they are released from a third-party vendor or the actual deployment of the patches onto vulnerable systems. Technology can play a role in the patch management process in various areas, although it does not always take care of the overall patch management problem.

In some instances, organizations look toward people to complete a task, and, for various reasons, the accurate completion of this task is not possible because there is no process or technology to support it. For example, if an organization requires that backups be completed on its critical servers on a nightly basis, the personnel responsible for these servers may be expected to complete the backup steps. Nevertheless, if a process is not defined and documented, these personnel may not know how to back up the systems properly. They may be backing up the wrong drives on the server each evening, skipping over the more critical drives.

Without a predefined and documented process, the staff will not fully understand how to complete this task on a nightly basis. Maybe the servers do not have a tape drive connected directly to them. How will the data be transferred from the hard drive to the tape for storage and, potentially, restoration? A level of technology must be implemented to provide the operations staff with the tools required to carry out this task. Perhaps a removable tape drive will be used, or perhaps there is a backup tape library that multiple servers use to store multiple backups. Regardless of the technology that will be used, a tool will be required to complete these backups according to the schedule. While this is a simplistic example, it is easy to understand why the combination of people, processes, and technology must be used when implementing an operational-based process. Once these three aspects are aligned, they come together to provide the total solution.

This same mind-set holds true for patch management. It is through the healthy combination of people, process, and technology that a patch management process can be established within an organization. With these three aspects in place, the patch management process can accurately, efficiently, and effectively protect the organization by deploying the appropriate patches to vulnerable systems. Now that the importance of all three aspects has been detailed, one additional item must be noted. This is the overriding importance of the process aspect. Having the people and technology to complete a task, like patch management, for example, are critical to its success.

However, without a solid predefined and documented process, patch management cannot be successful. Even with a staff of 20 people and a solid tool to deploy the patches, the process must be accurately defined to ensure that it can be properly completed. With the rush for organizations to address patching issues today, the tendency is to look toward technology to assist in easing the pain. Often, it is only after an organization realizes that it is not combating patch management appropriately, even with the tools deployed, that it reviews and attempts to redesign the process.

Establishing a patch management process and putting it in place are not easy tasks to accomplish. Still to be considered is the step of communicating the process to the appropriate staff and getting the message out to the user community about their responsibilities in ensuring vulnerable systems are patched appropriately. An entire chapter is dedicated to putting the patch management process in place. Here we align the people, process, and technology required for success. Completing the task of establishing the patch management process accurately will not only improve the operational flow of updating vulnerable systems but will also reduce operational costs for deploying patches within an organization's responsible environment. Any organization that takes a proactive approach to patch management will operate at a lower cost than an organization that waits to react to an exploit, which affects an unpatched system.

Measuring Success
Once the patch management process is in place within an organization, a mechanism for measuring the success of the process should be defined. An organization needs to track and maintain status reports on the number of systems susceptible to a vulnerability versus the number of systems patched and the number of systems unpatched. This arms the organization with the information required to determine how successful the patch management process has been. This should be done on an ongoing basis. While it may not be feasible to measure the success with each instance of the process or with each patch deployed, it needs to be done regularly and in a predefined manner.

When the organization assigns the roles and responsibilities for the patch management process, the security committee will be defined. It will receive the summarized report containing the status of each be successful. Even with a staff of 20 people and a solid tool to deploy the patches, the process must be accurately defined to ensure that it can be properly completed. With the rush for organizations to address patching issues today, the tendency is to look toward technology to assist in easing the pain. Often, it is only after an organization real-izes that it is not combating patch management appropriately, even with the tools deployed, that it reviews and attempts to redesign the process.

There is also an exception process explained in a future chapter. This provides an organization with an alternative to implementing the patch if the department or business unit decides it is unnecessary. Based on the previous example, if five systems have been given an exception and then in 3 weeks' time the patch management process is 100% complete for that patch, this is a great achievement, and the organization should consider the patch management process successful. Of course, the more systems that are vulnerable will increase the chance of systems not being patched.

Another example would be if 400 desktops are susceptible to a vulnerability and need to be patched. This patch is given a priority level of urgent, and all desktops need to be patched within a minimum time frame of 1 week and a maximum time frame of two weeks. The tracking method would be used to measure how many desktops have been patched, with a report provided to the security committee each week. If the report at the end of Week 1 shows that only 100 desktops have been updated, the staff is left with 300 to be completed during Week 2. If only 150 desktops can be patched in Week 2, then there are still 150 vulnerable desktops left wide open within the environment. In the case of desktops, there should be only a rare exception to updating the system, especially if standard builds are deployed on these desktops. Therefore, at the end of two weeks, the organization should see a 100% completion rate.

In this example, however, 37.5% (i.e., 150) of the desktops still needed to be updated. While 62.5% have been patched, the organization must determine the appropriate percentage that must be achieved within the defined time frames. At a minimum, 75% of the vulnerable systems must be patched in the established time frame, with outstanding systems to be patched within the next 5 days. This can put additional pressure on the group responsible for deploying the patch, but it also holds them accountable for ensuring that the process is being followed accurately.

If an issue has come about that prevents the organization from meeting these time frames, the patch management process should be reevaluated to determine what the achievable time frames should be. If it is not the process but instead the groups or departments within the organization that are causing systems to remain unpatched, then the importance of complying with this process must be communicated down to these groups by executive management. If they are not going to be held accountable for making certain that their vulnerable systems are patched, the company may take drastic measures, such as placing them on a completely different network segment, to ensure that the remainder of the organization is protected.

Next Steps
There is a common set of terms discussed when talking about patch management. Are we addressing vulnerabilities, patches, or exploits? The answer is clear: patch management is about the patches. The vulnerability within an operating system, application, or piece of software drives the need for the vendor to issue a patch. The vendor, in turn, releases the patch to the user community, explaining that it eliminates a known vulnerability within its software or product. Hackers turn this vulnerability into an exploit by using it to cause malicious activity. Of course, exploits are not always released for every patch. If that were the case, organizations would have deployed a patch management process years ago. The fact is that these exploits are becoming more common and damaging as time goes on, forcing organizations to establish this process now.

It is the effect the exploit has on the organization when it is released into the wild that drives the organization to establish the process. Therefore, organizations must protect themselves from the threat of an exploit by deploying all patches that affect systems within their infrastructure. For the purpose of this book, patches, vulnerabilities, and exploits are seen as three different entities, each having their own function and purpose. The reader will get a clear understanding of the differences among the three in the following chapters. Sometimes, there are also workarounds (or fixes) that are released in place of a patch to protect an organization from a particular vulnerability. We discuss patches only, not workarounds. However, workarounds can be deployed through the organization by following the patch management process. So, regardless of whether a patch or workaround has been released to address a vulnerability, either will follow the organization's patch management process to offer protection from the exploit that is soon to follow.


About the Author
From Security Patch Management by Felicia Nicastro. New York: Auerbach Publications, 2011.

 
Subscribe to Information Security Today





Powered by VerticalResponse

Share This Article


© Copyright 2011 Auerbach Publications