question Filter out vulnerabilities from Qualys for non-running kernels in SecOps forum

Filter out vulnerabilities from Qualys for non-running kernels

User1234 — Thu, 12 Dec 2019 07:35:33 GMT

Hello,

How can I filter out vulnerabilities for non-running kernels in my data import from Qualys? Is there an attribute on the VIT, or do I have to not import them into ServiceNow at all?

Re: Filter out vulnerabilities from Qualys for non-running kernels

andy_ojha — Thu, 12 Dec 2019 17:22:39 GMT

Hey there,

This is a great question.

I believe you will need to actually filter these detections from being sent to ServiceNow from Qualys. Today, the Qualys Vulnerable Items (VIs) do not have this information, such that you could use a data point to de-prioritize Qualys VIs on inactive kernels.

Within the Qualys API, there are certain parameters that can be used to filter the detections returned to ServiceNow, with the context to exploitable / running kernels.

One thing to be aware of, you may see older documentation and community posts kicking around that reference a Qualys API parameter called <active_kernels_only>.

While this parameter still is functional today, Qualys has earmarked that this will be deprecated at some point in the future, in favor of a new Qualys API parameter called <arf_kernel_filter>.

This parameter will have an impact on the detections returned to ServiceNow, and if you check out the Qualys API docs, you will see two flavors of how this filter works -> "includes" and "excludes".

I would imagine that you would want to use the "excludes", so that your API requests say "hey Qualys, bring me back detections for <xyz> criteria, but exclude any detections found on non-running or non-exploitable kernels".

You can read more about the Qualys API filters here:
- https://www.qualys.com/docs/qualys-api-vmpc-user-guide.pdf

In ServiceNow, you will need to adjust the POST Message that is used to make API Requests to Qualys.

This involves, adding a new "HTTP Query Parameter", to call out this additional Qualys API filter (on top of Severity, Detection Updated Since, etc).

I would further research the Qualys API Parameter called <arf_kernel_filter>; to see what available options exist, and if any of these meet your requirement (such as Option 1, shown the screenshot below to exclude non-running / non-exploitable kernels). If Option 1 looks like it fits your requirements, I would then test this out to make sure it returns Qualys detections that you are expecting in a sub-prod ServiceNow instance -> or even a tool like Curl or Postman.

You may want to work with a seasoned ServiceNow developer or possibly create a HI Support Ticket for assistance if you are not comfortable with developing, backing up work, testing work, etc. on the ServiceNow platform.

You can find the Qualys Host Detection REST, POST Msg here:

https://<<YOUR_INSTNACE_NAME>>.service-now.com/nav_to.do?uri=%2Fsys_rest_message_fn.do%3Fsys_id%3Da9d2e1369f21120034c6b6a0942e70ed

Re: Filter out vulnerabilities from Qualys for non-running kernels

Eugene8 — Thu, 17 Sep 2020 06:59:47 GMT

I had the same question about filter out vulnerabilities from Qualys for non-running kernels and found this post. Has anyone tested the approach presented above? I think it not going to work. Imagine that you have a running kernel and it had some vulnerabilities. They are imported to ServiceNow. Then the kernel is upgraded and the initial kernel becomes "non-running". If you filter out all vulnerabilities for this kernel via the API, then the existing vulnerabilities in ServiceNow will never be marked as "non-running kernel" and I also assume that these vulnerabilities will never be closed in the system even if the old kernel will be removed from a system after some time.

Note that "non-running kernels" is only part of the problem. It would also be very helpful to have an opportunity to filter out vulnerabilities not exploitable by configuration (arf_config_filter) and on non-running services (arf_services_filter) if the risk of having these vulnerabilities is accepted by the organization.

Re: Filter out vulnerabilities from Qualys for non-running kernels

andy_ojha — Thu, 17 Sep 2020 20:22:49 GMT

The use-case you brought up is valid.

There is no expectation for Qualys to report these previously identified detections that were 'Active' on the running kernel (before a host's upgrade), are now 'Fixed' just because of the host was upgraded to a new active kernel (when using the `arf_kernel_filter`).

Nor is there an expectation for a Vulnerable Item to be marked as "non-running kernel" in that situation either.

A tool does exist, which can help address this type of issue within the current version of the Vulnerability Response product -> `closure of stale vulnerable items`.

We would depend on the 'Last found' date of the Vulnerable Item, to illustrate detections aging out
Once the 'Last found' date ages beyond a configurable threshold (e.g. 30d, 60d, 90d, etc.) - it can be inferred that these Vulnerable Item records are Stale, and should be Closed accordingly

There still might be the scenario of the same QID being found on the previously active kernel, and the new currently active kernel; and perhaps the "Result" varies between the two:

We should still expect to see the Vulnerable Item eventually age out and eventually Close
You may see on the Detections for that Vulnerable Item, the QID reported more than once with different "Proof" aka Qualys Result values

Even if Qualys supported "active kernels" in their scan options (which I don't believe is possible currently) - we'd still have this issue when Linux hosts get upgraded - but would rely on the Stale Record job as tool to address this.

Reference - Stale Vulnerable Item Configuration:

*Would require using Vulnerable Item 'Last_found' and not "Asset last scanned" - as there are two flavours for this configuration

https://docs.servicenow.com/bundle/newyork-security-management/page/product/vulnerability-response/task/vr-autoclosevi.html

Re: Filter out vulnerabilities from Qualys for non-running kernels

Eugene8 — Thu, 17 Sep 2020 21:12:54 GMT

First of all, thanks you very much for the response!

From my point of view, ServiceNow should implement OOTB support for arf_config_filter, arf_services_filter and arf_kernel_filter. This is very important. If all these parameters are set to 0, then it would be possible to see for VITs if kernel is old or current, if service is running or not, if vulnerability is exploitable by configuration or it is impossible to exploit it by design at all. Then the user can decide if these VITs should be deferred or not. Here is one more example: if we speak about vulnerabilities non exploitable by configuration, there is a large number of them inside Cisco iOS. It is easy to filter out these vulnerabilities in Qualys but this becomes a big issue in the ServiceNow VR. The module should help users to analyze and prioritize vulnerabilities and filtering out these categories is part of the prioritization if the corresponding risk is accepted by organization. But without this, the module creates a lot of extra work!

Also the point to wait until "Vulnerable Item eventually age out and eventually Close" is very unclear. When Linux kernel is upgraded, it is a normal practice to have a few old kernels available on a server. As a result, the scanner detects vulnerabilities on ALL the kernels (vulnerabilities on non-running kernels that are still Active but can be easily filtered out in Qualys reports). They will be marked as Fixed only when the old kernel is actually removed. arf_kernel_filter allows to see if the kernel is running or not. If arf_kernel_filter=1 is part of the API request, then as I mentioned above, "when the kernel is upgraded and the initial kernel becomes "non-running"... If you filter out all vulnerabilities for this kernel via the API, then the existing vulnerabilities in ServiceNow will never be closed". It is important for me to know if a kernel vulnerability is ServiceNow is something I have to fix or it is on the old kernel and I can ignore it and I do not see any way to do it in the module. Checking Proof is not very helpful as well: vulnerability can be closed on the latest kernel but not on the old one, so there will be only one detection record.

And by the way... I am not sure if this is a good idea to create a new detection record if Proof changes. Note that in some cases Proof contain dynamic objects (timestamp, for example) and different all the time. As a result, there a huge number of detection records for same vulnerability if an asset is scanned frequently.

Re: Filter out vulnerabilities from Qualys for non-running kernels

andy_ojha — Thu, 17 Sep 2020 22:42:20 GMT

You make a good point - even if we see the 'Last found' date, either at the Detection or at the Vulnerable Item ... For the upgraded Linux systems - it's necessary not just to include 0 on those parameters - you actually need the result of that parsed out and a displayable format. Adding 0 to the API requests for those "arf" parameters will only add <AFFECT_RUNNING_KERNEL> in the payload file, but this needs to be parsed out. Doing this custom isn't as trivial as one would think, as it involves modifying a core ServiceNow script include that you would have to maintain.

I still think using the feature that closes Stale Vulnerable Items is necessary - when their 'Last found' date ages out (to clear out the noise) - but you are right, for the scenario of upgraded *nix hosts as a use-case - you need the active kernel parsed out.

It is expected that older kernels would be kept around (though some might say its a potential risk, it is common practice), and with upgrades in mind for *nix hosts - folks will not see the full picture without knowing if the Detection (at a minimum) applies to an active running kernel.

The issue will be, when the upgrade occurs on a *nix host, but the older kernel is still kicking around - and you have Active Detections and Vulnerable Items for them:

They won't get Closed, and Qualys won't report them as Fixed
The happy-path would be, if they are found again - their 'Last found' date is updated and their ARK value is updated from 1 to 0 (True to False)
But I worry some may still hang out there, with their ARK set to 1 and their 'Last found' date never updated (which is potentially why you'd want the Stale Record Closure)

If you haven't already -> please upvote this Idea on the Community:

https://community.servicenow.com/community?id=view_idea&sysparm_idea_id=383a913b1bb80450a59033f2cd4bcb2c&sysparm_idea_table=x_snc_com_ideation_idea&sysparm_module_id=enhancement_requests

It's got a lot of attention already but your vote will help (basically asking for this to be a native feature in the product).

If you've got some evidence that Qualys [Results] are dynamically updated with the only difference being just a timestamp changing (and not remaining static for the given Qualys Detection) - I would recommend you create a ServiceNow HI Ticket to report that, as today that field is used to define a unique ServiceNow Detection (meaning, you will get a new ServiceNow Detection per unique Qualys Result among other criteria - like port, ip address, etc.) - and that would be a problem as it is technically creating duplicate ServiceNow Detections in the scenario you described.

Also - please review other Ideas and vote on the if you have not already, and create your own Ideas in the Idea Portal in the Vulnerability Response (Category) - we can see that your feedback is extremely valuable.

Thanks!

Re: Filter out vulnerabilities from Qualys for non-running kernels

Eugene8 — Mon, 21 Sep 2020 18:38:01 GMT

Andy,

Big thanks again for your detailed response. FYI - earlier we have already created a ticket about duplicate detection when Proof changes but my colleague did it again. The ticket number is CS4885425. Some examples are in the ticket as well.

Re: Filter out vulnerabilities from Qualys for non-running kernels

User1234 — Thu, 07 Jan 2021 11:04:14 GMT

Hi,

We are doing this approach at my organization, and you are entirely correct that a patched kernel will not be marked as patched, but will simply "linger" around as open, but no longer seen recently.

The solution we have chosen for this is to automatically close vulnerabilities that have not been seen for a certain amount of days. That will clean up these old kernels, although vulnerability reporting will not necessarily be 100% correct unless you also start reporting on vulnerabilities that have been e.g. seen the last 7 days.

https://docs.servicenow.com/bundle/paris-security-management/page/product/vulnerability-response/task/vr-autoclosevi.html

Re: Filter out vulnerabilities from Qualys for non-running kernels

kspaeth — Fri, 04 Mar 2022 16:15:53 GMT

Here is an article I posted with our company's solution to this issue as we struggled for years to find a solution that worked for us.

https://community.servicenow.com/community?id=community_article&sys_id=543e22591bc6051456b699b8bd4bcb51

Re: Filter out vulnerabilities from Qualys for non-running kernels

User179407 — Mon, 25 Apr 2022 16:42:20 GMT

Hello @./andy-b2poYQ==

I tried adding the arf_kernel_filter with value as "1" and now I get the below error.

I also want to add exclude_superceded_patches with value as "1" and get the same below error.

Error: Invalid response code 400 received from Qualys. Encountered process error running the integration.

Without this parameter being added it works fine.

Do I need to add any other parameter with this parameter in the API to support this ?

Thank you.

Re: Filter out vulnerabilities from Qualys for non-running kernels

Eugene8 — Tue, 26 Apr 2022 05:58:25 GMT

Hi. The information above is outdated. Now this functionality is implemented OOTB. What you need to do is to update your vulnerability response and qualys modules and enabled the API parameters in the Qualys integration config (setup assistant).

Re: Filter out vulnerabilities from Qualys for non-running kernels

Adam Peterson — Thu, 18 Jan 2024 19:38:26 GMT

I am not seeing this. Can you take a screenshot?

Re: Filter out vulnerabilities from Qualys for non-running kernels

Martin Dewit — Thu, 18 Jan 2024 19:55:46 GMT

The additional metadata is located at the bottom of the Host Detection Configuration within VR Setup Assistant > Scanner Integration. Link to docs: Import additional metadata from Qualys

Re: Filter out vulnerabilities from Qualys for non-running kernels

Adam Peterson — Thu, 18 Jan 2024 20:06:57 GMT

That is so weird. I don't see Setup Assistant in All > Vulnerability Response > Administration > Setup Assistant. I gave myself the role but still don't see it.

Re: Filter out vulnerabilities from Qualys for non-running kernels

Adam Peterson — Thu, 18 Jan 2024 20:11:31 GMT

I logged out and back in and I see it now. Thanks!