Static Remediation Target Date

sdescoteaux · ‎04-18-2023

Hi all - I need to set a static remediation target date for vulnerabilities published before a certain date. I have been using the 'last found' field to do this.

I realized that creating target rules with the last found field will move the target every time the VI is found again, which really doesn't make sense to me. To get around this, I have been updating the target days value for each rule every 7 days since we can all our assets once weekly.

Now I have realized that once my actual target date is reached, I won't be able to do this anymore.

Is anyone aware of anything I could do to get the remediation target date to to stop changing when using the 'last found' field in the rule, or a way that a remediation target date can be set to a static date?

Thanks in advance!!

Amit Gujarathi · ‎04-21-2023

Hi @sdescoteaux ,
I trust you are doing great.

Based on your use case, it seems like you need to set a static remediation target date for vulnerabilities that were published before a certain date. You've been using the 'last found' field to create target rules, but this method doesn't work as the target date changes every time the vulnerability is found again.

To avoid this issue, you've been updating the target days value for each rule every 7 days since you scan your assets once weekly. However, you've realized that once the actual target date is reached, this approach won't work anymore.

To address this, I would suggest creating a new field in the vulnerability record to hold the static remediation target date. You can then use this field to create target rules and avoid the issue of the target date changing every time the vulnerability is found again.

// Create a new field in the vulnerability table
var gr = new GlideRecord('vulnerability');
if (gr.isValid()) {
  gr.setValue('u_static_target_date', 'yyyy-MM-dd'); // Set the default value to your desired static target date
  gr.setDisplayValue('u_static_target_date', 'yyyy-MM-dd'); // Set the display value to the same date format
  gr.update();
}

Was this answer helpful?

Please consider marking it correct or helpful.

Your feedback helps us improve!

Thank you!

Regards,

Amit Gujrathi

View solution in original post

andy_ojha · ‎04-21-2023

Hey there - great observation.

Would agree that using a dynamic field, such as `Last found` to calculate the Remediation Target Date from, will lead to problems and is not a good approach.

Would suggest starting with a more static field, to "start the clock" if you will - on the Remediation Target calculation for each Vulnerable Item -> such as `Last opened` or `First found`; each of these will have a different impact that you need to consider:

Last opened - consider the scenario where a scanner reports the detected vuln as fixed, but later on reports it is re-opened or found vulnerable again -> this date field will increment forward every time a Vulnerable Item re-opens
First found - this would be more static that Last opened, as it wouldn't matter if a finding is closed -> re-opened - if the Vulnerable Item is in-flight (not remediated) - the Target Date always go back to the First found as reported by the scanner

Now you also mentioned factoring in the "published age" of the actual vulnerability itself, based on the vulnerability published date.

Have you considered using the Vulnerability 'Published Date' from the Vulnerability / Third-Party Entry table as part of your Vulnerable Item 'Risk scoring' calculations?

One thought would be to incorporate the Vulnerability age (of it being published - not the detection age) into your Risk Scoring, and possibly incorporate other inputs you see relevant such as the Severity from the vendor for that Vulnerability, exploit availability, etc.
This way, you begin prioritizing the detected vulnerabilities in your environment - using the age of the vulnerability (published date) as one of the input factors (this will set the Risk score, Risk rating - on each Vulnerable Item)
From there - let your Risk Score Calculator do the heavy lifting - and output a Risk score / Risk rating on each Vulnerable Item
In your Remediation Target Rules - you would consume the output of that and base your Remediation Target Rules purely by the Risk score / Risk rating (that already factors in the Vuln Published Age)

The above is just a thought to make your overall deployment a bit easier to manage - but it will depend on how you define risk in your environment, how you want to structure your reports, how to want to prioritize addressing vulns in your network, etc.

You could also look at using the Vulnerability Published Date in the Remediation Target Rules as well - would just suggest using a more static field to start the clock from on the Vulnerable Item (e.g. Last opened)...

Something like below would be an idea to look at and test with - if you opt to not include Vuln Age (Published) in your Risk scoring:

Amit Gujarathi · ‎04-21-2023