Vulnerability Response - Manage exceptions using GRC: Policy and Compliance

[Madhav Vemana]

Hello,

I have couple of questions related to exception process when we enable the setting of manage exceptions using GRC: Policy and Compliance within Vulnerability Response -> Administration -> Exception management.

1. It seems like out of the box, we won't be able to create Exception rules when we enable the setting of manage exceptions using GRC: policy and Compliance? Does anyone know the reason why OOTB doesn't allow the creation of exception rules?

2. Exception rules can be created to auto defer VIT's if we are using Vulnerability Response exception management process. How can we achieve same functionality using GRC exception process?

3. Once the exception is created for either VIT or Remediation task, it seems like selection of impacted controls is mandatory when the exception is in "Analyze" state. Does this mean we need to create entities (in IRM) for each and every CI present in the CMDB and generate controls for them so that these controls can be added as impacted controls for an exception? If anyone has experience dealing with similar use case, please share your thoughts. I feel like generating entities and controls for each CI in the CMDB is bit too much.

I would highly appreciate if anyone from SecOps product team provide their insights on the best practices of using Exception management functionality leveraging GRC: Policy and Compliance.

[Jitendra Diwak1]

Hi @Madhav Vemana,

Please find the below resolution:

The questions you have pertain to the configuration and functionality of Exception Management using GRC: Policy and Compliance in ServiceNow’s Vulnerability Response module. Let’s break down your questions one by one:

---

1. Why doesn’t ServiceNow allow the creation of exception rules out of the box when enabling GRC: Policy and Compliance in Vulnerability Response (VR)?

The reason ServiceNow does not allow the creation of exception rules out of the box (OOTB) when enabling the GRC: Policy and Compliance integration is that it introduces a different process model for managing exceptions. GRC is designed to integrate with your organization's policies, controls, and compliance needs, which are more formalized and governed by established frameworks. By enabling GRC for exception management, you are shifting from the simpler, more tactical Vulnerability Response exception process to a more complex and structured compliance-driven exception management process.

Essentially, GRC ties exception management to policy compliance and risk management, and so the creation of exception rules would need to be aligned with the established governance, which often involves the definition of risk thresholds, control applicability, and other compliance aspects. This requires proper configuration and approval workflows, which is why it's not a simple out-of-the-box setup for creating exceptions directly.

---

2. How can we achieve the same functionality (auto-deferring VITs) using GRC exception process?

In Vulnerability Response, auto-deferring Vulnerability Impacted Tasks (VITs) can be managed with Exception Rules, but when using the GRC exception management process, the setup is a bit more involved. Here’s how you can achieve similar functionality:

• Create an Exception in GRC: You would still need to create an exception request (using GRC: Policy and Compliance), and define the conditions or scenarios where an exception is needed.

• Automate Deferral through GRC: Instead of a direct VIT-based rule, you can automate the exception deferral in GRC by tying the exception approval or risk acceptance workflow to actions that defer the remediation tasks.

  • You may need to develop business rules or workflows that automatically trigger deferral of VITs based on the status of the exception in GRC.
  • The Vulnerability Management Process would need to be integrated with GRC in such a way that, once an exception is granted, the system automatically defers related VITs. This could involve setting approval conditions and defining automated actions on the VITs based on the exception's approval state.

This can be achieved through customization and workflow automation that communicates between Vulnerability Response and GRC, ensuring that when exceptions are granted for certain vulnerabilities, the VITs are automatically deferred or postponed.

---

3. Is it necessary to create entities and controls for each CI in the CMDB to add them as impacted controls for an exception?

You are correct to be concerned about the scale of creating controls for every CI in the CMDB. It does seem like a lot of work, and there is a better way to handle this:

• Impacted Controls in GRC: In the context of GRC, the idea of impacted controls is usually linked to a policy, compliance control, or risk management structure. You don't need to create a unique control for each CI, as that would be cumbersome.

• Instead, focus on defining broader controls related to the type of vulnerability or risk. For example, you can map vulnerabilities to a control that covers the impact on specific services or functional areas, rather than mapping each individual CI.

• Control Generation: You could potentially automate the generation of controls based on the categories or risk ratings associated with vulnerabilities, which would help reduce the need for one control per CI. You should work with your GRC team to align this with your control frameworks.

• If your CIs are organized in a service model, it might be possible to create controls for groups of related CIs, rather than for each individual CI. This would significantly reduce the manual effort involved.

---

Best Practices for Using Exception Management in ServiceNow with GRC: Policy and Compliance

• Define Exception Workflows Carefully: When leveraging GRC for exception management, ensure that workflows align with your governance and compliance requirements. The exception process should be a formalized decision-making process involving risk assessment and policy compliance checks.

• Integrate with Risk and Policy: Ensure that exceptions are linked to policies and controls that reflect your organization’s risk appetite and compliance requirements. Exception rules should not be created in isolation but should be integrated with your overall risk management framework.

• Use Control Groups and Categories: Instead of creating individual controls for each CI, leverage control groups and categories that can handle multiple CIs within the same context. This will scale much better.

• Automate Deferral and Approvals: As much as possible, automate the process of deferring tasks, granting exceptions, and triggering associated actions using business rules, workflows, or automated approvals within GRC.

• Risk-Based Exception Management: Use risk analysis to determine when an exception is needed, and make sure that the exceptions are justified within the risk management process. This will help in avoiding exceptions being granted too liberally or without adequate controls in place.

---

It might be helpful to work closely with your GRC implementation team to ensure that the exception management process is aligned with your organization’s policies and security goals while still being scalable and efficient.

If you need further clarification or examples, feel free to reach out!

Thanks

Jitendra

[arielgritti]

Thanks @Jitendra Diwak1 

So useful post. We're running this exact scenario currently. We've SecOps + GRC/IRM implemented and we're exploring how to achieve it due to the fact exception rules aren't longer available when you select to follow the GRC-managed for PE requests.

Is the customization/flow automation the only solution at the moment? Or are the "approval rules" under GRC Policy & Compliance enough to achieve the goal?

Thanks,

[Greg Stone]

I am also very interested in this capability.

[danielgarner]

Is there going to be a "fix" for this?

Step 2 doesn't have steps on configuration. And customization is a bit of a trigger word for developers. If there is linkage on the level of effort and roles required, that would be helpful.

We have been recommending to clients to leverage this function, especially with orgs that have IRM and SecOps. If this efficiency does not have a straightforward configuration or adjustment, we might have some unhappy customers going forward.