Patch management is a crucial part of enterprise security defenses, but should security teams be in charge of it? Charles Kao explains how to make patching programs successful.
For most organizations, patching can be a daunting task that has many speed bumps and feels very unrewarding. In fact, more often than not, executives are blindsided, and they may not know the importance of patching until an unforeseen security event results in financial implications.
According to the National Vulnerability Database, there were a total of 4,313 counts of high vulnerabilities in 2017 compared to 2,470 in 2016, and a total of 8,897 counts of medium vulnerabilities in 2017 compared to 3,357 in 2016. That is almost a 126% increase for high and medium vulnerabilities combined, and there are no signs of it slowing down. No wonder organizations continue to struggle with their patch management programs and are often unsuccessful at preventing attackers from penetrating their systems.
Despite those struggles, security teams shouldn't be responsible for pushing out patches, because the information security team already has a full plate of responsibilities. They are responsible for monitoring the threat landscape, hunting down those threats, and even responding to and defending against them. Oftentimes, it takes a good amount of effort to consume, digest, process and even prioritize remediation efforts based on the risk to the organization. If security teams are also responsible for pushing out patches, then who is left to defend the castle?
It is easy to say the security team is the right team to do this work because they have a better understanding of the threats that are relevant to the organization, and that they should be responsible for patch management programs. Although those things may be true, the approach is highly inefficient, ineffective and will most likely incur overhead and financial costs to the organization.
Ingredients for patch management programs
To have an effective and successful patch management program, security teams should not be responsible for pushing out patches; instead, IT operations teams and system administrators should run the patch program. In addition, patching needs to be prioritized with efficient, yet defined procedures and standards.
If security teams are also responsible for pushing out patches, then who is left to defend the castle?
With that being said, you will need to have at least three ingredients for this to happen, including:
patch management governance;
defined roles and responsibilities; and
an asset risk classification matrix.
Let's first start with patch management governance, as this includes a thorough understanding of the systems, applications, business processes and data, as well as a robust asset management tool that will automatically discover assets on the network. This step includes defining a patching schedule based on vulnerability severity, developing standard secure configurations for each of the systems, and a clear process for rapid testing and deployment. These data points are then digested and mapped to discovered vulnerabilities to prioritize risk.
Next, roles and responsibilities need to be branched out across the organization. You need to have a scouter, who identifies and dissects new threats in real-time; a hunter, who hunts for vulnerabilities relevant to the organization; a planner, who strategize the most effective way to test, deploy and roll back patches; an executor, who is responsible for patch deployment; and a stamper, who validates that patching was deployed successfully. Depending on your organization's size and culture, some employees may have multiple roles.
The next step is to map the asset risk classification matrix to your patching schedule. Because not all systems are treated or created equal, the risk level may be different depending on the system's attributes. System attributes include applications, criticality of business processes, data and location.
A well thought-out plan takes each of the attributes and assigns it a risk weight. For example, a critical business process should be weighted more than a noncritical business process. Confidential data should be weighted more than public data. The asset risk classification matrix is the total risk weight of the system scaled based on the organization's risk appetite. See an example below.
one to three is low;
four to seven is medium; and
eight to 10 is high.
Based on the asset risk classification, if a system is assigned a low risk and a high vulnerability, it may not be a priority for the executor team to push out patches compared to a system with high risk and high vulnerability.
Conclusion
We may wish that there was a magical button that our patch management programs could use to identify, test, deploy and validate all the relevant patches and roll back bad patches. However, the closest thing to this type of button is a program that is well-defined, thought out and mature.
Security patching can definitely be one of the most challenging tasks for IT operations teams; however, if proper patch management governance is defined with asset risk classification, and roles and responsibilities are branched out, assigned to the correct team and are supported by the business, then the work of patching will only get easier as the program continues to mature.
