Understanding the Datalake
The Armor data lake is a centralized repository for storing Armor collected data. With regards to vulnerabilities, the data lake contains all the data for every report created for an environment and all the historical data from when the reports are run. This can be a lot of data so narrowing down the scope of information is critical to making sense of it all.
Accessing the Datalake
Users can access the datalake in two ways:
Data Presentation
Data consists of documents stored in the datalake. Each document contains all the data related to that particular rule and resource. Below are examples of the table and JSON views:
The schema for these documents is based on Elastic Common Schema, please refer to the below links for the details and explanation of the fields:
Vulnerability schema - https://www.elastic.co/guide/en/ecs/1.5/ecs-vulnerability.html
Custom Fields:
- vulnerability.published - the date an entry for the vulnerability was given a CVE
- vulnerability.results - the criteria used to determine the presence of the vulnerability
- vulnerability.cve - contains a link to the vulnerability's entry in the CVE database
- vulnerability.solution - provides instructions, if any exist, for remediating the vulnerability
- vulnerability.status - lists New if it is the first time a vulnerability is detected by a scan; Active if the vulnerability was been detected by two or more scans; Fixed if the vulnerability was detected in the previous scan but the most recent scan shows it as fixed; and Re-Opened if the vulnerability was verified fixed previously but is no longer so
- vulnerability.first_found - the date of the first scan in which the vulnerability was detected for a given server
- vulnerability.last_found - the date of the most recent scan in which the vulnerability was detected for a given server
- vulnerability.discovery - indicates whether the vulnerability was discovered through remote and/or authenticated scanning
- vulnerability.pci_flag - a flag that indicates whether the vulnerability must be fixed to pass PCI compliance
- vulnerability.patchable - contains a 1 if the vulnerability can be patched and a 0 if no patches currently exist for it
- vulnerability.last_modification - the date of the vulnerability attributes' (title, severity level, patch availability, CVSS scores, PCI relevance, etc.) last modification
- vulnerability.diagnosis - gives information about the technical details of the vulnerability, affected packages, severity scoring, and detection
- vulnerability.vulnerability_type - indicates whether the detection was a potential vulnerability (vulnerabilities that cannot be fully verified but have at least one necessary condition for the vulnerability) or a vulnerability (the vulnerability can be fully verified)
- vulnerability.consequences - provides information about the access an attacker who successfully exploits the vulnerability might gain
Helpful Fields for Searching the Datalake
Field | Filter By |
|---|---|
vulnerability.category | The type of system or architecture that the vulnerability affects. See https://qualysguard.qualys.com/qwebhelp/fo_portal/knowledgebase/vulnerability_categories.htm#P for a listing of potential categories |
vulnerability.severity | 1 through 5 |
host.hostname | the hostname of any servers in your account |
vulnerability.report_id | a scan ID that can be used to show only the vulnerabilities associated with a specific scan |
Adding a Filter
To add additional filters, click on the Add Filter Button.
Then set the field to one of the helpful fields above, select the operator, put in the value and hit save. The data is now filtered on a specific reportId, rPolicy or other field selected.
Viewing Datalake Aggregations
Please refer to Reports for custom aggregations, visualizations and custom reports.