ABSTRACT

Within desktops alone, various facets must be considered when designing the patch management process. During the planning phase of putting the process in place, the organization must perform an assessment against the desktops, determining what types of desktops are currently being used. Four factors should be included when adding desktops to the patch management process: (1) the use of standard builds; (2) providing user awareness and training; (3) using a tool to aid the organization in deploying the patches to all the desktops; and (4) regular checks via scanning tools to ensure all desktops are patched appropriately. Closely related to desktops, but treated diŸerently when patching them, are remote users. Today there are a plethora of users who work remotely, in virtual environments, or out of the o®ce, and they must be patched as well. is is to ensure that they have been

patched with the latest releases prior to being permitted onto the organization’s internal network or on the Internet in general. In most cases, remote users work by using a laptop versus the standard desktop that is used on site. Because laptops are mobile, they can be taken and plugged in anywhere. e organization must determine how these will be patched to make certain that they are protecting the organization’s proprietary information as well as not endangering the network into which they are plugged. is holds true especially in the case of consultants, or virtual users who go from o®ce to o®ce, each connecting into another organization’s network. Servers themselves add another layer of complexity to the patch management process. ere are major factors to consider when determining which servers will be included in the patch management process and how the process will be designed to patch them appropriately. e diŸerent ³avors of operating systems within the organization must be considered, deciding which ones can be supported in the patch management process. For example, the organization may start with including only Microsoft-based servers in the process with a plan to add the UNIX® servers into the process at a later date. Similarly, an organization may choose to patch its externally facing servers prior to patching its internal servers to mitigate the risk of the vulnerability. Compliance requirements may dictate which systems get patched ›rst. For example, servers that fall under Payment Card Industry (PCI) compliance requirements may get patched ›rst to guarantee that the quarterly scans come back clean, with no outstanding vulnerabilities due to a lack of installed patches.