|
Introduction
The value proposition of patch and vulnerability management is undeniable.
Unfortunately, it is equally undeniable that keeping up with the steady flow of new patches being released for both platforms and applications is a significant challenge for just about every IT organization on the planet. Given this situation, it is not surprising that the authors of SP 800-40: (a) identify the need for organizations to establish a comprehensive patch and vulnerability management program and associated processes; and (b) then go on to explicitly recommend that "organizations should use automated patch management tools to expedite the distribution of patches to systems".
It is with these recommendations in mind that this paper distills, from both SP 800-40 as well as other resources, the Top 10 requirements to consider when selecting and implementing a patch and vulnerability management solution.
Find Functions That Fit By Forming Foundation First
Of course, an underlying implication here is that achieving the absolute best results will depend on each organization first establishing its own set of policies, processes, and procedures for patch and vulnerability management. Only then can the following requirements be optimized to truly reflect the organization's actual needs.
Coverage
An automated patch and vulnerability management solution will provide little benefit unless it addresses a significant portion of an organization's software. This includes not only the various operating systems that are in use, but at a minimum the most common and critical business applications as well.
Architecture
The architecture of a patch and vulnerability management solution encompasses three aspects of how it is constructed and operates.
The first of these involves whether the solution uses software agents on each system being managed to facilitate the patch process. This approach generates relatively little network traffic and provides reliable coverage for transient systems such as laptops because it is "always on". In contrast, although it does not require the pre-deployment of software to each system, an agent-less architecture depends on periodic, network-based scanning and other remote techniques for subsequent administration.
Overall, both approaches have proven to be effective. However, as evidenced by most solutions in the market now supporting it at least to some degree, the agent-based option is increasingly believed to have an edge. This stems from its ability to provide better visibility and accuracy when establishing the status of a host while also involving fewer complications (e.g., not having to turn off a personal firewall or populate a scanner with the administrative rights for every system being managed).
Typically, a relatively "open" solution will be the preferred option since this conveys support for extensive customization and the ability to integrate with related network and security management products.
3 . Ease of Use and Flexibility
In part, this requirement covers the extent to which a solution's management interface is intuitive and navigable. In other words, how easy (or challenging) is initial implementation as well as ongoing operations. However, flexibility is critically important too. After all, this is the primary attribute that accounts for the ability to adapt to the specific elements and even quirks of a given organization's policies and processes. For example, an organization may decide that it wants all high criticality patches to bypass preceding steps and immediately be implemented, but only for a specific subset of high-profile servers.
|
