Gaining organizational effectiveness

The four key organizational governance steps to maximizing the value that is delivered by Patch are as follows:

Change management

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.

RACI chart

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

See Standard patch workflow.

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

See Zero-day patch workflow.

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.

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.
Figure  1:  Standard patch workflow
Figure  2:  Zero-day patch workflow
Figure  3:  Vulnerability scan patch workflow

Organizational alignment

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.

Operational metrics

Patch maturity

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:

Process Description
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

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 Patch Servers - Mean Time to Patch
Description Number of endpoints in each of these categories:
  • Optimal: Endpoints where Patch is operational
  • Needs Attention: Endpoints that do not have the Patch tools installed, are not targeted by a profile, or do not have a supported version of the Tanium Client installed
  • Unsupported: Endpoints with an operating system version that is not supported by Patch
Percentage of endpoints that are missing critical or important patches released more than 30 days ago. Average number of days between patch release and patch installation for workstations. Average number of days between patch release and patch installation for servers.
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. The time it takes for 95% of workstations to be fully patched and restarted, based on the start of the patching cycle (example: Patch Tuesday for Windows endpoints). The time it takes for 95% of servers to be fully patched and restarted, based on the start of the patching cycle (example: Patch Tuesday for Windows endpoints).
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.

Use the following table to determine the maturity level for Tanium Patch in your organization.

    Level 1
(Needs improvement)
Level 2
(Below average)
Level 3
(Average)
Level 4
(Above average)
Level 5
(Optimized)
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
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