The deployer role refers to the individual or organization responsible for the fielded systems that use or otherwise depend on products with vulnerabilities.
Deployers include the following:
Deployers typically must take some action in response to a vulnerability in a product they've deployed. Most often this means deploying a patch, but it can also involve the application of security controls, such as reconfiguring defensive systems, adding monitoring or detection rules, or applying mitigations.
Automation of the deployment process increases the efficiency of the deployer's response at the same time it decreases the duration of the risk posed by vulnerable systems.
Although the deployer role is primarily concerned with Vulnerability Management practices that sit downstream of CVD, it's worth spending a few moments to understand how it fits in with CVD.
A deployer's vulnerability response process usually involves the following sequence of stages:
We cover each of these in more detail below.
In order to take action, a deployer must know about the vulnerability and have sufficient information to act on. Most often this information originates from the product vendor. However, since not all vulnerability reports are coordinated with the vendor for disclosure, vulnerability information can arrive from other sources as well.
Deployers should be on the lookout for and pay attention to:
Deployers have many responsibilities beyond deploying patches. As a result, they need to prioritize their work and integrate patch deployment into their normal operations cycle. That might mean testing, scheduling out-of-band fixes, or planning for scheduled maintenance windows. Just as vendors need to triage reports in order to prioritize patch development appropriately, deployers must decide which patches and mitigations to deploy and when to deploy them. The deployer's workload often makes it difficult to patch all the things as quickly as they would like.
Testing prior to deployment is important if either of the following conditions is true:
In environments with efficient automated deployment and rollback capabilities, it may not be as necessary to test as heavily. But that's often an ideal scenario that few deployers find themselves in. Staged deployments or rollouts can be a significant help here—where some portion of the affected systems are updated to confirm the fix prior to wider rollout—allowing deployers to balance patch deployment with the risk of negative side effects.
Deployers have many options when it comes to planning to deploy a patch or mitigation. Highly automated environments can dramatically shorten the time required to complete these stages, but the functions described here will usually still occur regardless of the deployer's automated patching capability.
Planning for a patch deployment requires two major steps:
Obviously, it is important to actually carry out the deployment of the mitigation or fix. Automated patch deployment tools can make this process quite efficient. Regardless of the degree of automation of patch deployment, recurring or continuous monitoring for vulnerabilities can help measure the success of the deployment effort.
< 3.3. Vendor | 3.5. Coordinator > |