Last updated at Mon, 15 Jul 2019 20:46:39 GMT
Have you ever had to recreate a query in InsightVM because your first attempt didn’t turn up the information you were looking for? If so, you’re not alone. In this blog, we’re going to explore the basics of how to make queries in our cloud-based vulnerability management solution, InsightVM to ensure we see the intended results.
Your guide to Scope, Query Parameters, and Operators
When creating queries in InsightVM, there are a few elements to keep in mind: Scope, Query Parameters, and Operators. What is the Scope we are trying to achieve? What Query Parameters are available? And how are the Operators going to affect our query results? These three elements are important because collectively they will affect the data we are trying to visualize or work with.
Here, Scope is defined as the entire breadth of our scanned asset data we would like to analyze. Query Parameters can come in two forms: asset-based or vulnerability-based. Depending on which data set we want to visualize, our options to query that data set will differ. Operators are special symbols that help us control and define how and what our Query Parameter should yield.
In order to achieve the right results, it’s always a good idea to dry-run our Scope. What do we mean by that? We mean, write it out in a sentence, think about it, and see whether the scope even makes sense. Trying to play with the query filters without knowing what we want will mean spending a lot of time spinning our wheels in the mud. Once we have a Scope written out, we can start looking for the right Query Parameters and Operators.
The following are a couple simple examples of a scope:
- All assets within a XYZ subnet with Adobe installed
- Windows Assets with WannaCry
- Linux assets with port 22 open
More often than not, we may end up using similar Query Parameters across multiple use cases, as our goal is to work smarter, not harder. How can we achieve this? Well, for one, when writing out our Scope, we can put it into the perspective of InsightVM: How will it find what we need? If we start our question/scope with, say, “All Assets” or only “Windows Servers,” what variable/Query Parameter might that map back to? How are these configured in InsightVM, and have they already been collected within InsightVM? Here, it’s helpful to think about tags and asset data.
Let’s query!
If we have the Scope and Query Parameters figured out before we type out a query, it will make it very easy to create it. Also, before actually creating a query, be sure to check out the full list of operators here.
To get started, click on this icon near the top-right corner of the screen from the Dashboard page:
All assets with a Risk Score over 50,000
We can take a look at a simple Scope such as, “All assets in my network with a Risk Score over 50,000.” As per our requirements, since we have our Scope, we need to identify Query Parameters. Let’s start with the easiest: the Risk Score. By clicking on the “Add Criteria” button and starting to type “risk score” in the white section, we should see a query parameter
asset.riskScore show up. We can then use the right operator as > or >=, followed by our last requirement of 50,000.
By only using one query parameter for the scope asset.riskScore >= 50000, our scope will be “All Assets with Risk Score Over 50,000.” By default, we have considered all assets—hence, when the asset.riskScore parameter is applied, that shows us the subset of assets with the Risk Score greater than 50,000.
All Windows assets with a Risk Score over 50,000
If we were to tweak our scope and wanted only “Windows Assets with a Risk Score Over 50,000,” we can do an AND logic on top of the existing query and start working the first half (for identifying the right scope of windows assets) of our modified Scope, “Windows assets with risk score over 50,000.” The order of our query might not matter, but the logic definitely does. This is why it’s best to try to frame our query in the way our scope was written out.
When searching for a Query Parameter for Windows operating systems, it may seem like we have found the parameter with os works best for us. But if we look carefully, we can see options such as the following:
osos.archos.descriptionos.familyos.productos.typeos.familyos.vendoros.version
Each of these will come with a few or all operators: Contains, Does not contain, Starts With, Ends with, =, !=, Is, Is Not, and Like. These will pull in information to help complete the query. As mentioned earlier, our goal is to work smarter, not harder. So, for simplicity, we will stick with the = operator for the scope in hand to get a better sense of how it affects our outcome. However, we are still left with the question of which Query Parameter we can choose here.
First, we have to narrow some of these down to get a better look at our operator and variable options. We will first take a look at os.version and os.arch.
The screenshots above show that using the operator =, we see the available variables in the drop-down on the right and notice that they get too specific for our scope. We can eliminate
os.version and os.arch as options to be our query parameter for this scope.
When looking into os.product as a potential parameter, we get variable options, as seen below:
It may seem okay to use “windows” as a wide scope for our parameter os.product so everything under Windows can be included, but let’s take a step back and look at our operator, =. This means it will “literally” match that, giving us the following:
By doing a literal (=) match, we get assets that may not have been fingerprinted correctly enough, but just enough so that InsightVM knows they are a Windows OS but does not yet know what flavor of it. Hence, those assets should not be in our scope, so we can eliminate that, too.
As seen in the screenshots below, when we use os.vendor, we can pick “microsoft” to get the following, which is in line with what we want: “All Windows systems.”
Before we pick our query parameters, we can look into remaining options of os.type and os.family to see whether they give us better variable options. Looking into os.type, we get options such as server and workstation as variables. Both are good, broad scopes as variable options.
In the case for os.type, we played around with the OR logic, as we are uncertain of exactly what type of Windows OS we are looking for. However, by choosing server, workstation, and general as our variables, we are able to create a broad enough scope using these variables for our query as os.type. The OR logic allows us to expand and reduce our scope very easily, had we chosen a narrower scope of “Only Windows server and workstations.”
As seen in the screenshots below, for os.family, we can see that our parameter and variable options seem broad enough for the scope we could possibly want. By choosing os.family=“windows”, we get the following, which is the exact result we got for os.vendor=“microsoft” for this specific scope.
Looking back at the results so far, we find that query parameters like os.vendor and os.family help us with identifying our desired scope for “All Windows assets.” We will leave os.type out of scope as it would be a better Query Parameter had our scope asked for “Only Windows Servers” or “Only Windows Workstations”. Since we are looking for a broader scope, we can settle on os.family or os.vendor.
Taking a look at os.vendor =”microsoft”, os.family= “windows”, we can try to complete our scope by adding the AND logic along with our risk score requirement to be above 50,000.
This gives us two different queries that we can work with to address our scope of “All Windows assets with a Risk Score of over 50,000”
os.family=“windows” AND asset.riskScore>=“50000”os.vendor=“microsoft” AND asset.riskScore>=“50000”
Sample queries
Now that we understand how to scope out and write a query using the right parameters and operators, we can take a look at other scopes that could be important for an organization to use and configure.
1. All external-facing assets with open SSH
Tag IN “external assets” AND service.port=”22”.
Note: In this example, we created a tag “external assets” that would be applied to assets that did not fall under the ranges, “10.0.0.0–10.255.255.255, 172.0.0.0–172.31.255.255, 192.168.0.0-192.168.255.255”, and used that as the first Query parameter for Scope of “all external assets.”
To confirm that the filtered asset has port 22 open, we can toggle over to the services tab to see the following:
2. All Windows assets with SMB vulnerabilities
os.family = “windows” AND vulnerability.title CONTAINS “SMB”.
Note: Since there may be many vulnerabilities associated with SMB, we chose to include a broad scope for our vulnerability title for SMB by using the operator CONTAINS.
And to confirm the vulnerabilities of these assets definitely have SMB in their title, we can toggle over to the Vulnerabilities tab to see the following:
3. Windows servers with critical severity vulnerabilities
os.type=”server” AND vulnerability.severity=”critical”
To confirm the severity of vulnerabilities of these assets is definitely critical, we can toggle over to the Vulnerabilities tab to see the following:
4. Windows workstations having vulnerabilities with CVSS score >= 7
os.type=”workstation” AND vulnerability.cvssScore>=7
To confirm the cvssScore of vulnerabilities of these assets are definitely above 7, we can toggle over to the Vulnerabilities tab to see the following:
Query pointers
Now that we have taken a look at some sample queries and a step-by-step explanation of how to make queries in InsightVM, here are some key pointers to keep in mind when creating your unique queries using the Query Builder:
- Map out to business, security goals and objectives to help in defining the Scope.
- Make sure authenticated scans have been performed, so the Query Parameters and Operators can pull in information from the best and most accurate information about assets collected from the scans/agents.
- Test out Operators that work best for the Scope before using them in the query.
Query away!
