When we first moved to BigFix for patching our customers (We are multi-tenant), we hired a third party company to help us build our reporting portal. However, we canceled that arrangement because they told us the queries needed to get the data we wanted would be 10s of thousands of API calls. (Almost 100k calls).
However, what I am looking for today should be easy, but I have no experience in gathering this data using API. Can someone tell me if it would be easy to get this data?
1 - How do we get a list of Remediated Fixlets for each computer?
2 - How do we get a list of Relevant Fixlets for each computer?
We would need both of those queries to contain the Computer ID. If possible, we would like it to contain one of our custom properties (Used to identify which customer the computer belongs to (CustID)).
Please provide additional information about the information you want to get back:
Operating System (choose one): Amazon Linux, CentOS, Mac OS X, Oracle Linux, Red Hat Enterprise Linux, SUSE Linux Enterprise, Ubuntu, Windows.
Category: Bug Fix, Enhancement, Security.
Severity: Critical, Important, Moderate, Low, Unspecified.
Content Type: OS Updates, OS Application Updates, 3rd Party Updates.
To which Reporting System you are going to send the data?
Ok, I will provide that information as an example but we basically want it all, or most of it, and a custom property called CustID.
OS=Windows
Category=Security (Actually āSecurity Updateā
Severity=Anything not blank or āUnspecifiedā
Content Type=all of those, OS Updates, OS Application Updates, 3rd Party Updates
The reporting system will be one of our in house portals built by our developers.
Basically, we want what is similar to this web report data, but for all security patches, which we can only get to by clicking on links, from what we can tell. This only gives us data on one patch at a time.
Here we go ā you can use the relevance query below to get remediated fixlets for each computer. Since the data volume can be large, weāve scoped it to our specific needs (you can adjust it further as required). This version focuses on Windows Servers only, and Iāve also updated the filter to target machines where the custom property custID contains "12345"
(name of computer of it as string | "Not Reported", name of fixlet of it as string | "Not Reported") of (results (elements of item 0 of it, elements of item 1 of it)) whose (remediated flag of it AND now - last became relevant of it < 90 * day) of (set of (bes computers whose (operating system of it as string as lowercase starts with "win20" as lowercase AND (exists (value of result from (bes property "CustID") of it) whose (it as lowercase contains "12345" as lowercase)))), set of ((bes fixlets) whose ( (name of site of it as string as lowercase = "Enterprise Security" as lowercase OR name of site of it as string as lowercase = "win2012esu" as lowercase) AND name of it as string as lowercase starts with "ms" as lowercase)) )
Again, since the data set can be quite large, Iāve applied some filters to narrow it down. Modify these filters based on your specific requirements.
(id of it as string | "N/A", name of it as string | "N/A", source release date of it as string | "N/A", source severity of it as string | "N/A", source severity of it as string | "N/A") of elements of set of Fixlets of (results (item 0 of it, item 1 of it)) whose (relevant flag of it) of (elements of item 0 of it, elements of item 1 of it) of (set of bes computers whose (now - last report time of it < 7 * day AND (exists (value of result from (bes property "CustID") of it) whose (it as lowercase contains "12345" as lowercase))), set of bes fixlets whose (applicable computer count of it > 0 AND (name of site of it as string as lowercase = "Enterprise Security" as lowercase OR name of site of it as string as lowercase = "win2012esu" as lowercase) AND name of it as string as lowercase starts with "ms" as lowercase AND name of it as string as lowercase does not contain "Corrupt" as lowercase AND name of it as string as lowercase does not contain "Superseded" as lowercase))
Nope buddy, no issues have been reported in the org so far. Initially, there were some doubts regarding the Linux patches, but after checking the BESClient logs, everything was clear. Thatās allāno actual issues.
Thanks for all of that. It is not working, yet. No results is what I am getting. So give me a little time and I will tweak it a little and see if I can get it to work.
unique values of (
(name of computer of it | "No Computer Name") & "~" & (display source id of fixlet of it | "No Source ID") & "~" &
(preceding text of first " - KB" of display name of fixlet of it | "No Display Name") & "~" &
(following text of first ", " of preceding text of first " -" of (first became relevant of it as string)| "") & "~" &
(if relevant flag of it then "vulnerable~will be patched" else if remediated flag of it then "patched~" &
(following text of first ", " of preceding text of first " -" of (last became nonrelevant of it as string) | "") else "")
)
of results of bes fixlets whose (category of it is "Security Update" and name of it contains "Windows Server" and type of it is "Fixlet")
Ah, yes, thatās an edge case. The āfirst became relevantā, ālast became relevantā, āfirst became nonrelevantā, and ālast became nonrelevantā are only valid in Web Reports or through API query, itās not present in the Console session.
A fixlet might become relevant multiple times; suppose a patch is uninstalled, or Office is removed & reinstalled.
These session relevances allow you to check the oldest, and most recent, times a patch was detected (first became relevant), installed (first became nonrelevant); and the most recent time it was detected (last became relevant) and patched (last became nonrelevant). These are all Time results. We do not provide a method to track every time a fixlet was detected or remediated, only the first time and the last time for each.
The ānormalā case is that the first & last times are the same, for a fixlet that was detected (and potentially remediated) only one time. But these can be used in some creative ways, like having a relevance based on some particular user account logging on, or some application running, that causes the relevance to toggle between relevant & not relevant.
