Gaining organizational effectiveness
The four key organizational governance steps to maximizing the value that is delivered by Patch are as follows:
- Develop a dedicated change management process. See Change management.
- Define distinct roles and responsibilities. See RACI chart.
- Validate cross-functional alignment. See Organizational alignment.
- Track operational maturity. See Operational metrics.
Develop a tailored, dedicated change management process for patch management, taking into account the new capabilities provided by Tanium.
- Update SLAs with elevated expectations, from patch identification to patch deployment. For example, if you are an organization that typically patches critical OS vulnerabilities within 15 days with legacy tooling, transition to a five-day SLA.
- Identify internal and external dependencies to your patch management process (example: contractors who are responsible for a subset of IT estate).
- Designate change or maintenance windows for various patch management scenarios (example: emergency patching versus general maintenance patching).
- Create a Tanium steering group (TSG) for patching activities, to expedite reviews and approvals of processes that align with SLAs.
A RACI chart identifies the team or resource who is Responsible, Accountable, Consulted, and Informed, and serves as a guideline to describe the key activities across the security, risk/compliance, and operations teams. Every organization has specific business processes and IT organization demands. The following table represents Tanium’s point of view for how organizations should align functional resources against patch management. Use the following table as a baseline example.
|Task||IT Security||IT Operations||IT Risk/Compliance||Executive||Rationale|
Standard patch notification
|I||A/R||I||-||Standard patch cycles, such as Patch Tuesday, are owned by the operations team and have predefined notifications so that the security and risk/compliance teams are informed.|
Zero-day/threat intel notification
|A/R||I||I||C||Zero-days have a high security impact. The security team is accountable for informing the operations and risk/compliance teams, and consulting with the executive team.|
Vulnerability scan patch notification
See Vulnerability scan patch workflow (click image to enlarge).
|A||I||R||C||The risk/compliance team identifies vulnerabilities based on tooling and notifies the security team. The security team is accountable and informs the operations team of the known threat.|
|Risk exposure scan||C||C||A/R||I||The risk/compliance team owns the tools that run the scan to understand risk and consults with the security and operations teams.|
|Deploy patches to test environment for user acceptance testing (UAT)||I||A/R||I||-||The operations team informs the security and risk/compliance teams when patching is completed so they can verify results.|
|Verification of remediation in test environment||C||C||A/R||-||The risk/compliance team owns the tools to verify that the systems are no longer vulnerable, and consults with the security and operations teams on the results.|
|Deploy patches to production environment||I||A/R||I||-||The operations team informs the security and risk/compliance teams when patching is completed so they can verify the results.|
|Verification of remediation in production environment||C||C||A/R||-||The risk/compliance team owns the tools to verify that the systems are no longer vulnerable, and consults with the security and operations teams on the results.|
|Track actions taken and escalation requests||C||A||R||I||The risk/compliance team is responsible for the vulnerabilities in the environment, informs the executive team, and consults with the security team. The operations team is accountable for taking any actions based on the escalation.|
|Reporting metrics/dashboard of remediation||A||A/R||I||I||The operations team is responsible and accountable for remediation reporting, consults with the security team on any questions, and informs the risk/compliance and executive team.|
|Reporting metrics/dashboard of risk||C||C||A/R||I||The risk/compliance team is responsible and accountable for risk reporting, consults with the security and operations teams on any questions, and informs the executive team.|
Successful organizations use Tanium across functional silos as a common platform for high-fidelity endpoint data and unified endpoint management. Tanium provides a common data schema that enables security, operations, and risk/compliance teams to assure that they are acting on a common set of facts that are delivered by a unified platform.
In the absence of cross-functional alignment, functional silos often spend time and effort in litigating data quality instead of making decisions to improve patch management.
Managing a patching program successfully includes operationalization of the technology and measuring success through key benchmarking metrics. The four key processes to measure and guide operational maturity of your Tanium Patch program are as follows:
|Usage||How and when Tanium Patch is used in your organization|
|Automation||How automated Tanium Patch is, across endpoints|
|Functional integration||How integrated Tanium Patch is, across IT security, IT operations, and IT risk/compliance teams|
|Reporting||How automated Tanium Patch is and who the audience of patch reporting is|
Benchmark metrics for Windows and Linux endpoints
In addition to the key patch processes, the four key benchmark metrics that align to the operational maturity of the Tanium Patch program to achieve maximum value and success are as follows:
|Executive Metrics||Patch Coverage||Endpoints Missing Critical or Important Patches Released Over 30 Days Ago||Workstations - Mean Time to Patch1||Servers - Mean Time to Patch|
|Description||Number of endpoints in each of these categories:
||Percentage of endpoints that are missing critical or important patches released more than 30 days ago.||
Average number of days between patch release date and patch application for workstations. Application includes installing the patch and restarting the workstation, if required.
Calculation only considers installed patches and excludes missing patches.
|Average number of days between patch release date and patch application for servers. Application includes installing the patch and restarting the workstation, if required.|
|Instrumentation||Number of endpoints with a patch scan age less than three days divided by total endpoints that are supported by Patch.||Number of endpoints that require critical or important patches that were released over 30 days ago divided by the number of endpoints with a scan configuration.||
Number of days it takes for workstations to be fully patched and restarted after a patch is released, divided by the number of patches installed by Tanium.
Calculation excludes patches installed by means other than Tanium Patch.
|Number of days it takes for servers to be fully patched and restarted after a patch is released, divided by the number of patches installed by Tanium.|
|Why this metric matters||If you are not scanning all endpoints, then you are at risk. That risk must be highlighted and mitigated through other means (example: network isolation).||The sooner you know about an endpoint having an outstanding patch, the sooner you can deploy the patch or mitigate the risk until the patch is available.||If it takes you too long to deploy a patch and validate that it was applied, then you are at risk of being exploited by the vulnerabilities that are addressed by that patch.||If it takes you too long to deploy a patch and validate that it was applied, then you are at risk of being exploited by the vulnerabilities that are addressed by that patch.|
|1 For Windows endpoints, the Mean Time to Patch sensor uses the OS installation date rather than patch release date for patches released before the OS was installed.|
Use the following table to determine the maturity level for Tanium Patch in your organization.
|Process||Usage||Patch configured||Patch used by exception (zero day or subset of environment)||Patch used to audit efficacy of legacy tooling||Patch used as default tooling for patch management; Legacy tooling used to audit patch efficacy||Patch used as default tooling for patch management|
|Automation||Manual||Manual||Partially automated (>50% of patch deployment process automated)||Partially automated (>75% of patch deployment process automated)||Fully automated (>90% of patch deployment process automated)|
|Functional integration||Functionally siloed||Consult with or take direction from peers in enterprise vulnerability management, and threat management||Consult with or provide direction for peers in enterprise vulnerability management, threat management, and asset management||Connect, Trends, and Asset integrated into enterprise vulnerability management, threat management, and asset management tools||Connect, Trends, and Asset integrated into enterprise vulnerability management, threat management, and asset management tools|
|Reporting||Manual; Reporting for Operators only||Manual; Reporting for Operators and peer group only||Automated; Reporting for Operators and peer group only||Automated; Reporting tailored to stakeholders ranging from Operator to Executive||Automated; Reporting tailored to stakeholders ranging from Operator to Executive|
|(Windows and Linux) Metrics||Patch Coverage||< 93%||93-94%||95-96%||97-98%||99-100%|
|Endpoints Missing Critical or Important Patches Released Over 30 Days Ago||> 15%||11-15%||6-10%||2-5%||0-1%|
|Workstations - Mean Time to Patch||> 30 days||26-30 days||21-25 days||15-20 days||0-14 days|
|Servers - Mean Time to Patch||> 60 days||46-60 days||31-45 days||21-30 days||0-20 days|
Last updated: 5/30/2023 3:24 PM | Feedback