Vulnerability Response - My experience so far
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
an hour ago
Vulnerability Response (VR) is a beast of an application; comprising of 4 different apps in one: VR, Application Vulnerability Response (AVR), Container Vulnerability Response (CVR), and Configuration Compliance (CC). Some of these ties to VR are relics from the initial release of a new app which can make troubleshooting tricky. For example, take Exceptions Management.
Exceptions are handled through an already seemingly archaic process that takes a while to figure out, the questionnaire (not a slight against ServiceNow you understand, just an observation), which is in itself a UI action which calls a dialog box that then utilizes an assessment table to map onto another assessment table and that is linked to the approvals table...now take a breath that was a lot of links. The issue I've faced specifically deals with the length of time to apply an exception for a Container Vulnerable Item (CVIT). Looking at the "duration" field in the Exceptions Management module for CVR, you can see it's value is one thing (let's say 12 months), but you want to set it to 15 months...no problem. You go in, change it, think you're done, except now here's where the fun begins. Not only does it squawk at you when you enter the new time, you can't even process where the issue stems from. After you dig some more, you come across the script includes (SI) - ExceptionSettingsAJAX, or VulnerabilityStateChangeManager, or QuestionnaireConfiguration, which all look like they potentially could make this issue happen. You can see the field "request_exception_beyond" (duration name) in these scripts, but you can also see the different VR tables, fun fun. Well, in this case, the value for the VR exceptions module was being read in the ExceptionSettingsAJAX SI instead of the CVR value and the reason was because an assumption was made (on ServiceNow's part) that the VR value trumps any other value, so we would've experienced it in AVR as well had that been configured at the time. They fixed the issue in a patch and so it works as intended now.
The moral of the story is that VR is massive, containing a vast amount of rules, scripts, jobs, and not all of them have been converted to the new architecture (which is reverting back to the old architecture with USEM, but that's a story for later). VR is the head, with CVR and AVR still acting as constituents in some ways, and CC is mostly independent and if there is a tie it's in a process that I haven't had the displeasure of encountering errors with (probably like remediation target rules or something). If you have an issue with VR, feel free to leave it below, and hopefully we can all learn from each other.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
49m ago
ahoy @PhillipC,
thanks for sharing your experience, however your text is very robust and difficult to read. Perhaps some formatting or breaking it into paragraphs/sections could make the reading a bit nicer. What do you think?
✂-----Cutting-out-the---✦AI-noise✦---All-replies-written-and-vouched-for-by-GlideFather---
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
26m ago - last edited 26m ago
Ahoy
I tried to make my post as simple as possible by including that example to help with understanding, but the topic is about how the subject matter is dense. I understand what you're saying with how it reads, that's something I've had difficulty with when it comes to my writing style. If I have some free time, I will try to remember to come back and format this.