Gaining organizational effectiveness
The four key organizational governance steps to maximizing the value that is delivered by Comply are as follows:
- Develop a dedicated change management process. See Change management1.
- Define distinct roles and responsibilities. See RACI chart.
- Validate cross-functional alignment. See Organizational alignment.
- Track operational maturity. See Operational metrics.
1An organization's vulnerability management program intersects with change management governance to drive remediation activities. For example, when to run reports, implementation of remediation activities, such as patching activities, as well as functional work schedules, such as the follow the sun model, authorized maintenance windows, and change control activities.
Develop a tailored, dedicated change management process that aligns with the organizational vulnerability management program to enable patching and configuration changes for a streamlined process using Comply.
- Update SLAs and align activities to key resources for Comply, where applicable. See Comply maturity and RACI chart.
- Designate change or maintenance windows for various scenarios, where applicable. For example, set up third-party reporting technologies and integration with ticket systems, such as SIEM, Database Power BI, and Tableau.
Identify internal and external dependencies to the vulnerability management process. For example, achieve effective integrations with SIEM, Database Power BI, and Tableau with Comply.
- Create a Tanium steering group (TSG) for discovery activities to expedite reviews and approvals of processes that align with SLAs and vulnerability management processes, as applicable.
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 compliance and vulnerability management. Use the following table as a baseline example.
|Task||Security Team||Risk / Compliance Team||Operations Team||CISO||Rationale|
|Established Vulnerability Management Program||R/A||R/A||C||I||
Align to the organizational Vulnerability Management Program, which is used to make Comply implementation decisions such as report scheduling. For example, whether the schedules use the "follow the sun" model.
The organizational Vulnerability Management Program is also used to make decisions about remediation needs that are driven by data provided by Comply, such as:
|Report verification: define policy report frequency||I||I||I||R/A||Define policy report frequency in alignment with any regulatory requirements. Schedule reports in Comply to meet the frequency requirements.|
|Report verification: define report requirements (regulatory)||I||I||I||R/A||Define policy requirements in alignment with any regulatory requirements. Create reports in Comply to meet the policy requirements.|
|Operationalize report policies||R/A||I||I||C||Publish and distribute the report policies aligned to any regulatory requirements.|
|Execute report policies||I||R/A||I||I||After policies are created and published, execute the policies using Comply to define targets for reports, create compliance profiles, and identify a vulnerability baseline.|
|Implement configuration compliance reports||I||R/A||I||I||Implement the policies for the configuration compliance workflow by creating configuration compliance reports in Comply.|
|Implement vulnerability reports||I||R/A||I||I||Implement the policies for the vulnerability management workflow by creating vulnerability reports in Comply.|
|Conduct report: vulnerability scan, remote vulnerability scan, and configuration compliance scan||I||R/A||I||I||Run reports against identified targets based on policies.|
|Report validation: distribute, review, and take action on findings||I||R/A||I||C/I||Take the results from the report activities and distribute, review, and take action on the findings. After the risk report is completed, the CISO team will validate the risk report results to identify criticality to implement controls, where applicable.|
|Remediate findings: apply patches||I||I||R/A||I||Changes to mitigate or take action on identified risks. For example, use Tanium Patch to install a patch on an endpoint to fix a vulnerability.|
|Remediate findings: update software||I||I||R/A||I||Changes to mitigate or take action on identified. For example, use Tanium Patch to update software on an endpoint to fix a vulnerability.|
|Remediate findings: configuration changes||I||I||R/A||I||Changes to mitigate or take action on identified risks that will implement a change in the configuration of a specific endpoint or device. This change may be a permanent change from the temporary controls implemented or a new change based on risk report, such as using Tanium to quarantine a device or shutting down a device.|
|Evaluate and iterate on results||I||R/A||I||I||Operations and Security teams inform the Risk / Compliance Team that controls are applied so they can verify the results. Then, the workflow starts over to continually evaluate risk posture in security and vulnerability management.|
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 on how to improve configuration compliance and reduce vulnerabilities.
Managing compliance and vulnerability management programs 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 Comply program are as follows:
|Usage||how and when Tanium Comply is used in your organization, and is Tanium the sole tool or is it supplemented by other tools, such as a remote assessment tool for network devices.|
|Automation||how automated Tanium Comply is, and how well is it used in automation of other systems|
|Functional Integration||how integrated Tanium Comply is across IT security, IT operations, patch and software deployment, and Asset Management teams|
|Reporting||how is data from Tanium Comply used by people and systems within the organization|
In addition to the key compliance and vulnerability management programs, the key benchmark metric that aligns to the operational maturity of the Tanium Comply program to achieve maximum value and success is as follows:
|Executive Metrics||Comply Coverage||Endpoints with Critical or High Vulnerabilities|
The number of endpoints in each of these categories:
For steps to investigate endpoints that are categorized as Needs Attention or Unsupported, see Monitor and troubleshoot Comply Coverage.
For operating system and Tanium Client versions supported by Comply, see Requirements.
|Percentage of endpoints that have executed vulnerability reports which found at least 1 critical or high severity vulnerability.|
|Instrumentation||Uses the Comply - Coverage Status sensor to return the number of endpoints where Comply is optimal, needs attention, and is unsupported.||Number of endpoints that have had a vulnerability report which resulted in 1 or more critical or high severity vulnerabilities divided by the number of endpoints that have run a vulnerability report.|
|Why this metric matters||If you are not scanning all endpoints, then you are at risk.||If you have a significant number of endpoints with outstanding high or critical vulnerabilities, you are at greater risk.|
Use the following table to determine the maturity level for Tanium Comply in your organization.
|Process||Usage||Comply installed and configured. One or more users have access and are asking basic questions.||Third-party components uploaded and deployments created.||Configuration compliance and vulnerability reports configured.||Customized configuration compliance and vulnerability reports configured.||Custom benchmarks created and used for organizational reports. Custom vulnerability sources configured and in use. Ongoing maintenance of checks and standards.|
|Automation||Only manual, ad hoc reports in use.||Only manual, ad hoc reports in use.||Automated, recurring configuration compliance and vulnerability reports||Customized configuration compliance and vulnerability reports running. Documented compliance and vulnerability management life cycle with SLAs on mitigation time frames.||Configuration compliance and vulnerability risk data used as input to threat hunting activities by correlating risk data with security alerts to determine risk scoring for environment.|
|Functional integration||Comply installed, but no operationalization.||Trends boards imported.||Trends boards created to manage and track vulnerability reports.||Integration with third-party reporting technologies, integration with IT ticket systems, automated workflow with Tanium Patch for approval and deployment of patches, automated export into data repository/warehouse)||Integration with remediation process and capabilities.|
|Reporting||Manual; Reporting for Operators only through Comply||Manual; Export of recurring reports||Automated; Export through Tanium Connect||Automated; Third-party technologies reporting from Comply||Automated; Third-party technologies reporting from Comply|
|Metrics||Endpoints with Critical or High Vulnerabilities||>50%||<50%||<35%||>15%||<5%|
Last updated: 9/17/2020 12:53 PM | Feedback