Contents


How to collect data with BigFix Query

Conduct a real-time investigation on your deployment

Comments

BigFix® customers are medium- and large- sized companies that use the product to manage mostly software and security of a certain amount of computers (that amount may vary from dozens to tens of thousands). Many of these customers requested a way to quickly collect information from their environments because BigFix has not been natively built to provide high response times, but rather, persistence and effectiveness. In the first quarter of 2016, the BigFix Rome development team worked on a solution that was able to fulfill these requests; this solution is BigFix Query.

Prerequisites

In order to understand the content of this article in its integrity, the following prerequisite knowledge is required:

  • Basic understanding of BigFix components, like the CLI and the console.
  • How to trigger REST APIs.
  • Basic understanding of the Relevance Language that is used by BigFix to determine contents and behaviors.

Overview

IBM BigFix is a suite of products that provides a fast and intuitive solution for compliance, endpoint, and security management and allows organizations to see and manage physical and virtual endpoints through a single infrastructure, a single console, and a single type of agent.

IBM BigFix provides the following capabilities:

  • A single intelligent agent for continuous endpoint self-assessment and policy enforcement.
  • Real-time visibility and control from a single management console.
  • Management of hundreds of thousands of endpoints regardless of location, connection type, or status.
  • Targeting of specific actions to an exact type of endpoint configuration or user type.
  • Management of complexity and cost reduction, which increases accuracy and boosts productivity.
  • Patch management, software distribution, and OS deployment.
  • Support for heterogeneous platforms.
  • Automatic endpoint assessment and vulnerability remediation according to the National Institute of Standards and Technology (NIST) standards.
  • Real-time protection from malware and other vulnerabilities.
  • Server automation.

This large portfolio is guaranteed by a scalable infrastructure, which is based on three main components: clients, relays, and the root server. An example of what a typical BigFix infrastructure looks like is illustrated in Figure 1.

Figure 1. Example of a BigFix infrastructure
Screen capture of a BigFix infrastructure
Screen capture of a BigFix infrastructure

BigFix is able to determine which targets the content applies to (or which computers need that content) by using Relevance Expressions. Relevance Expressions are part of the content definition and their scope is to interrogate the hardware and software properties of your managed clients to ensure that a patch or a maintenance activity, for example, is applied to only those computers that need it, and to no others. Relevance Expressions are written in a human-readable proprietary language, called Relevance Language.

Relevance Expressions can trigger different behaviors, such as:

  1. Fixlets®
    • When a certain fixlet is relevant, it means that the computer is out-of-compliance with a policy rule. When the fixlet is relevant, you can run the actions that are contained in the fixlet definition to remediate the issue. After the actions run, the relevance is evaluated again to check whether the vulnerability is fixed.
  2. Tasks
    • A relevant task indicates that the computer has a violation of a configuration standard or requirement or that it must run maintenance activities. Actions that are contained in the task definition can be run to remediate the issue. After all of the steps of the actions are complete, the task is marked as not relevant on the computer and the Relevance Expression will not evaluate again.
  3. Analysis
    • An item that periodically runs property queries, according to its query intervals, sends the results back to the server. The results then display on the BigFix console.

BigFix Query

Quicker results and more flexibility

BigFix Query is a new feature of the IBM BigFix portfolio that will give customers the opportunity to retrieve quickly any kind of information that is related to their computers, such as hardware and software inventory, system vulnerabilities, files, and paths.

Before the introduction of BigFix Query, customers who wanted to collect data from their computers had to create and run an analysis with a process that took minutes or even hours of time; this would consume a large amount of space in the database. BigFix Query, instead, provides answers in a much shorter amount of time and without a persistent storage of data in the database due to the volatility of the request.

With BigFix Query, customers can gather data at a much quicker speed, thanks to the following:

  • The notification mechanism.
  • The fact that queries use a new communication channel that don't interfere with the normal channel that is used for analyses.
  • Fixlets and all other reports.
  • The fact that queries are not evaluated on the client by the main evaluation loop.

For a visual diagram of all of these characteristics, see Figure 2.

Submitting queries

BigFix Query allows users to submit "queries," which consist of a series of Relevance Expressions that indicate what data needs to be retrieved from clients, which clients are targeted to return this data, and if a certain client is applicable (or not) to provide an answer.

Here is the process for submitting queries:

  1. Users start with the WebUI and the REST API interface that allow to submit queries and visualize the collected results.
  2. Users can submit queries and visualize collected results through the Web UI and the REST API interface.
  3. When the user submits a new query, the server generates a signed document that contains all of the information that is related to the query, including the assigned ID.
  4. Depending on the topology of the environment, the server then notifies clients and relays that a new question needs to process. Such notification includes the query ID and the operator who submitted the query.
  5. Clients receive a UDP message while relays are notified through an HTTP connection.
  6. Clients and relays will then download the full query payload, which includes the query itself, its applicability, and targeting conditions. Relays keep query information in memory in a proper cache; when the maximum size of the cache is reached, the relay will start discarding old queries. Clearly, queries are lost if the relay is stopped.

After you submit a query

Upon the reception of a new query, the client starts a new instance of "QnA" (which, until now, was used to locally "test" relevance expressions) to evaluate the query. This co-process has predefined constraints of CPU consumption, running time, and idle time.

  1. Once the query processes, QnA transmits the produced results to the client and remains idle for a determined, customizable amount of time in order to prevent the cost of CPU for starting it again for new queries.
  2. The client produces a report that contains the results of the query and sends it to the assigned relay. The relay keeps these reports in another memory cache and sends them back to the server in a prioritized way. When this happens, reports are deleted from the memory cache of the relay, in order to make room for potential other incoming reports.
  3. When reports come back to the server, they are written in the database by the FillDB component so that they will be available for the user through the Web UI or through the proper REST API. Also, the FillDB component processes query reports in parallel with the other reports.

The whole process is outlined in detail below in Figure 2 and Figure 3.

Figure 2. BigFix Query flow from the UI to clients
Screen capture of BigFix Query flow from the UI to clients
Screen capture of BigFix Query flow from the UI to clients
Figure 3. BigFix Query flow from clients to the UI
Screen capture of BigFix Query flow from clients to the UI
Screen capture of BigFix Query flow from clients to the UI

REST APIs

Again, BigFix Query is available on the Web UI and through REST APIs. In particular, there are three REST APIs where BigFix Query is available:

  1. api/clientquery
  2. api/clientquery/{id}
  3. api/clientqueryresults/{id}

api/clientquery

api/clientquery is a POST request that can be used to submit a new query to the server. Input parameters for this API must be included in a XML file like the one in Figure 4.

Figure 4. Input parameters for api/clientquery
Input parameters for api/clientquery
Input parameters for api/clientquery

The input parameters for api/clientquery are:

  • ApplicabilityRelevance - States if the query is applicable or not for each targeted client. It must always be specified by using "true" in the case that targeting is done in a different way (see below).
  • QueryText - The query that indicates the content to be retrieved from each targeted client.
  • Targeting – An optional series of nodes that indicates which computers are targeted by the query. Computers can be targeted by using the following nodes:
    • ComputerID – Specifies each computers' numeral unique identifier.
    • ComputerName – Specifies each computers' hostname.
    • CustomRelevance – A single Relevance Expression that is evaluated by clients.
    • ComputerGroup – a BigFix container of computers, which is identified through the following nodes:
      • Name – The name of the computer group.
      • SiteName – The name of the BigFix site to which the computer group belongs.

Once the query is submitted to the server, a numeral ID is returned that can be used to retrieve the results of the query.

api/clientquery/{id}

api/clientquery/{id} is a GET request that can be used to retrieve information about a previously submitted query by using its ID (see Figure 5).

Figure 5. Example of an output returned by api/clientquery/57
Example of an output returned by                     api/clientquery/57
Example of an output returned by api/clientquery/57

api/clientqueryresults/{id}

api/clientqueryresults/{id} is a GET request that can be used to retrieve the results of a previously submitted query by using its ID (see Figure 6).

Figure 6. Example of an output returned by api/clientqueryresults/57
Example of an output returned by                     api/clientqueryresults/57
Example of an output returned by api/clientqueryresults/57

Some parameters can be passed as input to this API, such as:

  • Filter to retrieve only results that contain a desired phrase.
  • Stats=1 to also retrieve statistics, such as how many clients that provide results and how many results were provided for the query.
  • Output="json" to retrieve results in JSON format instead of XML.
  • Starts=X and count=K to retrieve K results, beginning from the X-th one.

BigFix Query and operators

BigFix Query is integrated with BigFix operators and roles: master and non-master operators. Master operators are allowed to execute queries by default; non-master operators are not and they must have the "Can Submit Queries" permission that is properly set through the BigFix Console at the operator or role level (see Figure 7). Without this permission, operators won’t be able to submit queries to the server.

Figure 7. BigFix Query permission set for a nonmaster operator
BigFix Query permission set for a nonmaster                     operator
BigFix Query permission set for a nonmaster operator

Use case scenario: Run a query to detect a security exposure

Let's look at how BigFix Query is used by a master operator so he can ensure the security of the computers that he manages.

As we can see in Figure 8, our environment consists of a few computers that are running both Windows® and Linux® operating systems. Requirements for this scenario are:

  • Two or more computers running RHEL operating systems.
  • A BigFix 9.5.2 infrastructure.
  • The BigFix server license must be entitled for the following applications:
    • Lifecycle Management or Security and Compliance in order to be able to submit queries.
    • Patch Management in order to be able to submit fixlets to repair security issues or apply system updates.
  • A BigFix console installed on a Windows computer that should be able to reach the BigFix server over the network.
Figure 8. Computers of our sample environment
Computers of our sample environment
Computers of our sample environment

CVE-2016-080, also known as DROWN, is a new OpenSSL vulnerability that was discovered in March 2016. This vulnerability allows potential attackers to decrypt RSA cipher texts through the Bleichenbacher RSA padding Oracle® attack. (Red Hat fixed it with a patch that updates OpenSSL package to the version 1.0.1e-42.)

We will use this vulnerability as an example in this scenario. As we have OpenSSL already installed on our computers, we leverage BigFix Query REST APIs to check whehter there is a security breach.

1. First, we use the BigFix CLI to log in to the BigFix Server by using our master operator credentials (see Figure 9).

Figure 9. Login phase by using BigFix CLI
Login phase by using BigFix CLI
Login phase by using BigFix CLI

2. We submit a query by targeting our Linux machines to retrieve the version of the OpenSSL libraries that is currently installed on these computers (see Figure 10 and Figure 11).

Figure 10. Input parameters for our query
Input parameters for our query
Input parameters for our query
Figure 11. Output for api/clientquery
Output for api/clientquery
Output for api/clientquery

3. We can retrieve information about the query through the /api/clientquery API.

Figure 12. Output for api/clientquery/63
Output for api/clientquery/63
Output for api/clientquery/63

4. After a short wait (here we have to reiterate the API call until we get some results), we trigger the REST API to see the results of the query (see Figure 13).

Figure 13. Output for api/clientqueryresults/63
Output for api/clientqueryresults/63
Output for api/clientqueryresults/63

5. The results show that two computers are vulnerable to DROWN. So, we are going to submit proper fixlets, for RHEL6 and RHEL7, to remediate this issue (see Figure 14 and Figure 15). These fixlets are, respectively, contained in two different BigFix sites that are part of the Patch Management application: "Patches for RHEL 6 Native Tools" and "Patches for RHEL 7."

Figure 14. OpenSSL security update fixlet for RHEL6
OpenSSL security update fixlet for RHEL6
OpenSSL security update fixlet for RHEL6
Figure 15. OpenSSL security update fixlet for RHEL7
OpenSSL security update fixlet for RHEL7
OpenSSL security update fixlet for RHEL7

6. Actions were deployed successfully to vulnerable machines (see Figure 16).

Figure 16. Successful actions related to OpenSLL fixlets
Successful actions related to OpenSLL fixlets
Successful actions related to OpenSLL fixlets

7. Let's run the query again in order to verify that the vulnerability is no longer present in our environment.

8. As we can see in Figure 17, the vulnerability is now gone. For both the discovery and the verification, the running time of the query was a matter of seconds.

Figure 17. Outputs for api/clientquery and api/clientqueryresults/64
Outputs for api/clientquery and                     api/clientqueryresults/64
Outputs for api/clientquery and api/clientqueryresults/64

Conclusion

BigFix Query is a game-changing feature for the BigFix solution because it provides a more immediate way to collect real-time information, which is highly requested in the market. This article described briefly the BigFix solution, how BigFix works, and how BigFix Query fits in with all of the components. Finally, it shows a typical use case, where BigFix Queryis leveraged for performing vulnerability investigation.


Downloadable resources


Comments

Sign in or register to add and subscribe to comments.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Security
ArticleID=1033308
ArticleTitle=How to collect data with BigFix Query
publish-date=06172016