In VR: When would you use SLAs rather than Remediation Targets

[LeslieC]

Hello,

We have the API integration with Rapid 7's InsightVM and are ready to set timelines on vulnerability remediation. We have  4-5 tiers for remediation timelines and I'm trying to determine if we should use SLAs or Remediation Targets. It seems like Remediation Targets are easier to set up, but we can get more granular with SLAs. Also, we already use Vulnerability Groups/Remediation Tasks to assign these to CI Support group. This is who we'd want the notifications to go to, but I don't see this option for Remediation Targets. 

Does anyone have any best practices or use cases for either SLAs or Remediation Tasks?

Thanks,

Leslie 

[Eliz Skogquist]

The solution works the same for Remediation Targets, 3 years later.

[chrismcdevi]

An important point to consider is that SLAs usually have a human component behind them. There is an "issue" that a human is waiting to be solved. When I think of Vulnerabilities, there is not a human behind the scenes waiting for this to be addressed so they can get on with whatever they are doing before the issue comes up. The second interesting thing is that humans are desensitized to urgency if they are overrun with stuff like SLAs. SLAs create a lot of unnecessary noise unless they are reserved for very select critical events.
If you think about it, there is zero difference between an RTD and an SLA if leaders don't take action. At the scale of VR, leaders must rely on RTD by reviewing their dashboards and determining how things are going. I think that MBWA is a very, very, very important job for leaders. I see many organizations try to have SN "manage" their employees' behavior through complex workflows, SLAs, and notifications.
Reserve the SLA for mission-critical events that involve humans.
Has my guidance changed on RTDs vs. SLAs? Nope. If anything, it is now leaning more towards RTD and having leaders review their dashboards and understand what is happening on the floor of their organizations.

[OlafNg]

Hello Chris, we are currently considering using SLAs instead of RTR because we want to exclude weekend days in the calculation. From our point the only way to use RTR and exclude weekend days is by customizing the script include for the RT calculation but we would like to avoid this solution. 

With SLA definitions we can select schedules where weekend days are excluded. Would you also consider SLAs to be the best way to implement this? 

[Eliz Skogquist]

OOB RTs assign on VIs and roll up to VULs.  SLAs only work on Task tables, so will be limited to VULs, as the VI table doesn't extend from Task.  Targets are commonly set in alignment with compliance requirements.  Curious, do they exclude weekends?  It's possible you aren't building against them, which is allowing you this leeway.  Could you simply add the weekend count (+2/week) to the duration you are considering in the RTR?

[OlafNg]

Hi Eliz,

yes correct, our compliance requirements or rather or group guideline excludes weekends. 

Unfortunately simply adding the weekend count to the duration would not work because this would depend on the specific day the VI was created and would also require a scripting solution.