Qualys Connector


Benefits


Qualys is a scanning tool that allows organizations to identify vulnerabilities and other risks across their various IT assets.

This connector streamlines the assessment of vulnerability management controls by empowering your audit team to fetch vulnerability scan reports and other evidence in a single click. Auditors can pull data directly from Qualys without having to rely on the company's infosec or IT professional to provide it.

This eliminates the time auditors spend waiting on control owners to fulfill evidence requests, and it eliminates the hassle of chasing down requests. As an added bonus, it also removes the burden on control owners to fulfill evidence requests manually, since your audit team can now bypass them completely.

Overview


The integration provides two types of Qualys evidence fetchers.

The ZenGRC Host List Detection fetchers are meant to be a wrapper around API endpoints that retrieve normalized data from scans. Users can create as many of these as they want and can specify several parameters with each.

The second supports more custom use cases by allowing you to specify any endpoint and parameters, and it requires a little more effort to set up.

By setting up this connector between Qualys and ZenGRC your organization will be able to do the following:

  • Create evidence fetchers to import Qualys data for audits.
  • Use imported data to show effective vulnerability management.
  • Quickly add “simple” fetchers to pull recent scan reports from provided IPs.
  • Configure “advanced” fetchers to define custom API calls.
  • Utilize username/password-based API authentication.

IMPORTANT

If your company is using the private cloud platform of Qualys, then inbound/outbound traffic must be allowed through your firewall through whitelisting IP addresses. For additional information, please review IP Whitelisting.

Making the Qualys Connection


Setting up the connection requires a one-time collaboration between you and your organization's Qualys administrator. Information you need to add to ZenGRC includes the following:

  • Qualys API server URL.
  • Qualys username and password.

The API user must have "Scanner" role or higher in for ZenGRC to have access scan reports. For more information on Qualys API roles and permissions, refer to the Qualys API User Guide

Locating Your API Server URL

The API server URL depends on where your Qualys account is located and was provided when the account was set up.

The following shows the URL that corresponds to the platform where your organization's account is located:

TIP

The link starting with https:// needs to be entered in the Qualys API Server URL field as described in the next section.

Connecting ZenGRC with Qualys

To set up the connection, complete the following steps:

  1. Access the selected ZenGRC connector by following the instructions at Introduction to ZenConnect.
  2. In the Qualys API Server URL text box, enter the API server URL that corresponds to your Qualys platform. Instructions for finding this are in the previous section.

  3. Add the username and password used to log into Qualys in the Qualys username and Qualys password fields respectively.



  4. Click Next.

  5. The page displays with your connection information, buttons to disconnect and options to add new fetchers.

Creating Host List Detection Import Fetchers


Many Qualys customers use an API endpoint that allows for retrieval of normalized data from all scans. The ZenGRC Host List Detection fetchers are meant to be a wrapper around these endpoints, and users can create as many of these as they want while specifying parameters. You can specify the format of the file attachment as well as define filters limiting results included in the file.

The graphic below is from the Qualys documentation and shows the relationship between the scans, database, filters and results.

To add a new Host List Detection Import fetcher, complete the following steps:

  1. After setting the connectionadditional options display on that page to create a new fetcher.

  2. Click +Add new fetcher. The page defaults to the Host List Detection Import Fetcher tab.

  3. Complete fields by utilizing definitions in the next documentation section.
  4. When the fields are complete, click Create.
  5. The fetchers are now ready to add to controls and requests. Working with Fetchers, Controls, and Requests.


Field Definitions


TIP

The Qualys guide referenced in the definitions below can be found in the API documentation on the Qualys website.


The following provides definitions of the fields to utilize when creating a new fetcher:

  • Name: Text box. This is required on all fetcher types because it is the way users identify fetchers when associating them with controls and executing them.
  • Asset Groups: Multi-select list. The options are populated with asset groups that you have defined in your Qualys instance. One or more asset groups can be selected as filters for the Host List Detection API call. If multiple are selected, they are handled using "or" logic detections so that the results will match any of the asset groups. For more details, refer to the ag_ids parameter in the Qualys API guide.
  • Dynamic Search Lists: Single-select list. The options are populated with custom searches that you have defined in your Qualys instance. Any of them can be leveraged as a filter for the Host List Detection API call. For more details, refer to the search_list_ids parameter in the Qualys API guide. 
  • Format: Single-select list (CSV, XML). This list determines the format of the file returned by the API (and attached to the ZenGRC Request). We expect most customers to opt for XML because it is easier to parse the hierarchical structure. For more details, refer to the output_format parameter in the Qualys API guide. 
  • Vulnerability Status: Multi-select list. If no value is specified, then items in a Fixed status will be excluded by default. For more details, refer to the status parameter in the Qualys API guide
  • Severities: Multi-select. This filter shows only vulnerabilities with specified severities. For more details, refer to the severities parameter in the Qualys API guide.
  • Running Kernels: Single-select list (1,2,3,4) that determines whether to include/exclude vulnerability data associated with running and non-running Linux kernels. This provides a way of filtering based on exploitability. For more details, refer to the arf_kernel_filter parameter in the Qualys API guide.
  • IP Addresses: Text box. One or more IPs can be specified by using comma separation. You can also specify a range of IPs by using a hyphen (e.i. 10.10.10.1-10.10.10.100). For more details, refer to the ids parameter in the Qualys API guide.
  • Max Days Since Last Scanned: Integer. This limits data to hosts that have been scanned. For more details, refer to the max_days_since_last_vm_scan parameter in the Qualys API guide.
  • Parameters: Text box. This allows ZenGRC administrators to specify additional filters in JSON format. Note that all parameters are processed using "and" logic (i.e. only vulnerabilities that meet all specified filters will be included in the result). 

Creating Custom Fetchers


The Qualys connector allows configuration of custom fetchers by entering Qualys API endpoint URLs and target parameters in JSON format. This fetcher type allows for more flexibility in defining the specific evidence you wish to pull from Qualys, but it also requires the ZenGRC administrator to be familiar with the Qualys API.

For additional information, please refer to API documentation on the Qualys website.

To create a custom fetcher, complete the following steps:

  1. After setting the connectionadditional options display on that page to create a new fetcher.

  2. Click +Add new fetcher, and select the Custom fetcher tab.

  3. Add a descriptive name in the Name field.

  4. Information for the Method and Endpoint fields depends on your objective and can be obtained from the Qualys API documentation. The Parameters text box allows you to specify additional filters in JSON format.



  5. Click Create.
  6. These fetchers are now ready to add to controls and requests. Please see Working with Fetchers, Controls, and Requests.

Adding Evidence Fetchers to Controls and Requests


After a fetcher pulls data into ZenGRC, the information must be attached and mapped to a control. Then it can be added to a request. For more information on this process, please review the following documentation - Working with Fetchers, Controls, and Requests.

In addition, please watch the ZenGRC Qualys Demonstration for an overview of its functionality.

List of Controls Supported by Vulnerability Scan Report Fetchers


ZenGRC integrates with several vulnerability scanner applications, such as Qualys, to streamline the assessment of controls that require you to demonstrate that a VM program is in place and running effectively. The following is a list of controls that could be validated by reviewing scan reports fetched into your ZenGRC instance after establishing the connection with the vulnerability management tool of your choice:

Framework

Code

Control Name

Description

SOC2 2017

CC7.1

System Operations 

To meet its objectives, the entity uses detection and monitoring procedures to identify:

(1) changes to configurations that result in the introduction of new vulnerabilities, and 

(2) susceptibilities to newly discovered vulnerabilities.

The following points of focus, specifically related to all engagements using the trust services criteria, highlight important characteristics relating to this criterion:

Uses defined Configuration Standards - Management has defined configuration standards. 

Monitors Infrastructure and Software - The entity monitors infrastructure and software for noncompliance with the standards, which could threaten the achievement of the entity's objectives Implements.

Change-Detection Mechanisms - The IT system includes a change-detection mechanism (for example, file integrity monitoring tools) to alert personnel to unauthorized modifications of critical system files, configuration files, or content files.

Detects Unknown or Unauthorized Components - Procedures are in place to detect the introduction of unknown or unauthorized components.

Conducts Vulnerability Scans - The entity conducts vulnerability scans designed to identify potential vulnerabilities or misconfigurations on a periodic basis and after any significant change in the environment and takes action to remediate identified deficiencies on a timely basis.

CIS CSC v6.1

4.1

Continuous Vulnerability Assessment and Remediation

Run automated vulnerability scanning tools against all systems on the network on a weekly or more frequent basis and deliver prioritized lists of the most critical vulnerabilities to each responsible system administrator along with risk scores that compare the effectiveness of system administrators and departments in reducing risk. Use a SCAP-validated vulnerability scanner that looks for both code-based vulnerabilities (such as those described by Common Vulnerabilities and Exposures entries) and configuration-based vulnerabilities (as enumerated by the Common Configuration Enumeration Project).

CIS CSC v7

3.1

Continuous Vulnerability Management

Establish standard secure configurations of your operating systems and software applications. Standardized images should represent hardened versions of the underlying operating system and the applications installed on the system. These images should be validated and refreshed on a regular basis to update their security configuration in light of recent vulnerabilities and attack vectors.

CIS CSC v7

3.2

Continuous Vulnerability Management

Follow strict configuration management, building a secure image that is used to build all new systems that are deployed in the enterprise. Any existing system that becomes compromised should be re-imaged with the secure build. Regular updates or exceptions to this image should be integrated into the organization’s change management processes. Images should be created for workstations, servers, and other system types used by the organization.

CIS CSC v7

9.3

Limitation and Control of Network Ports, Protocols, and Services

Perform automated port scans on a regular basis against all key servers and compared to a known effective baseline. If a change that is not listed on the organization’s approved baseline is discovered, an alert should be generated and reviewed.

CIS CSC v7

12.2

Boundary Defense

On DMZ networks, configure monitoring systems (which may be built in to the IDS sensors or deployed as a separate technology) to record at least packet header information, and preferably full packet header and payloads of the traffic destined for or passing through the network border. This traffic should be sent to a properly configured Security Information Event Management (SIEM) or log analytics system so that events can be correlated from all devices on the network.

CS CCM v3.0.1

IVS-05

Management - Vulnerability Management

Implementers shall ensure that the security vulnerability assessment tools or services accommodate the virtualization technologies used (e.g. virtualization aware).

NIST 800r4

RA-5

Vulnerability Scanning

The organization:
- Scans for vulnerabilities in the information system and hosted applications [Assignment: organization-defined frequency and/or randomly in accordance with organization-defined process] and when new vulnerabilities potentially affecting the system/applications are identified and reported;
- Employs vulnerability scanning tools and techniques that facilitate interoperability among tools and automate parts of the vulnerability management process by using standards for:
- Enumerating platforms, software flaws, and improper configurations;
- Formatting checklists and test procedures; and
- Measuring vulnerability impact;
- Analyzes vulnerability scan reports and results from security control assessments;
- Remediates legitimate vulnerabilities [Assignment: organization-defined response times] in accordance with an organizational assessment of risk; and
- Shares information obtained from the vulnerability scanning process and security control assessments with [Assignment: organization-defined personnel or roles] to help eliminate similar vulnerabilities in other information systems (i.e., systemic weaknesses or deficiencies.

NIST800-171r1

3.11.2

Risk Assessment

Scan for vulnerabilities in organizational systems and applications periodically and when new vulnerabilities affecting those systems and applications are identified.

NIST800-171r1

3.11.3

Risk Assessment

Remediate vulnerabilities in accordance with assessments of risk.

NIST CSF v1.1

DE.CM-8

Security Continuous Monitoring

Vulnerability scans are performed.

OWASP Top 10 (2017)

A6

Security Misconfigurations

Security misconfiguration is the most commonly seen issue. This is commonly a result of insecure default configurations, incomplete or ad hoc configurations, open cloud storage, misconfigured HTTP headers, and verbose error messages containing sensitive information. Not only must all operating systems, frameworks, libraries, and applications be securely configured, but they must be patched and upgraded in a timely fashion.

OWASP Top 10 (2017)

A9

Using Components with Known Vulnerabilities

Components, such as libraries, frameworks, and other software modules, run with the same privileges as the application. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications and APIs using components with known vulnerabilities may undermine application defenses and enable various attacks and impacts.

PCI DSS v3.2.1

11.2

Network Vulnerability Scans

Run internal and external network vulnerability scans at least quarterly and after any significant change in the network (such as new system component installations, changes in network topology, firewall rule modifications, product upgrades).

Note: Multiple scan reports can be combined for the quarterly scan process to show that all systems were scanned and all applicable vulnerabilities have been addressed. Additional documentation may be required to verify non-remediated vulnerabilities are in the process of being addressed.


 For initial PCI DSS compliance, it is not required that four quarters of passing scans be completed if the assessor verifies 

1) the most recent scan result was a passing scan,

 2) the entity has documented policies and procedures requiring quarterly scanning, and 

3) vulnerabilities noted in the scan results have been corrected as shown in a re-scan(s). For subsequent years after the initial PCI DSS review, four quarters of passing scans must have occurred. 

PCI DSS v3.2.1

11.2.1

Internal Vulnerability Scans

11.2.1 Perform quarterly internal vulnerability scans. Address vulnerabilities and perform rescans to verify all “high risk" vulnerabilities are resolved in accordance with the entity's vulnerability ranking (per Requirement 6.1). Scans must be performed by qualified personnel.

PCI DSS v3.2.1

11.2.2

External Vulnerability Scans

11.2.2 Perform quarterly external vulnerability scans, via an Approved Scanning Vendor (ASV) approved by the Payment Card Industry Security Standards Council (PCI SSC). Perform rescans as needed, until passing scans are achieved. 

  Note: Quarterly external vulnerability scans must be performed by an Approved Scanning Vendor (ASV), approved by the Payment Card Industry Security Standards Council (PCI SSC).  Refer to the ASV Program Guide published on the PCI SSC website for scan customer responsibilities, scan preparation, etc."

PCI DSS v3.2.1

11.2.3

Internal & External Vulnerability Scans after Changes

11.2.3 Perform internal and external scans, and rescans as needed, after any significant change. Scans must be performed by qualified personnel.

SWIFT CSF (2019)

2.7

Vulnerability Scanning

Identify known vulnerabilities within the local SWIFT environment by implementing a regular vulnerability scanning process and act upon results.

FedRAMP (Mod)

RA-5

Vulnerability Scanning

The organization:
a. Scans for vulnerabilities in the information system and hosted applications [FedRAMP Assignment: monthly operating system/infrastructure; monthly web applications and databases] and when new vulnerabilities potentially affecting the system/applications are identified and reported;
RA-5 (a) Additional FedRAMP Requirements and Guidance; an accredited independent assessor scans operating systems/infrastructure, web applications, and databases once annually.
b. Employs vulnerability scanning tools and techniques that facilitate interoperability among tools and automate parts of the vulnerability management process by using standards for:
1. Enumerating platforms, software flaws, and improper configurations;
2. Formatting checklists and test procedures; and
3. Measuring vulnerability impact;
c. Analyzes vulnerability scan reports and results from security control assessments;
d. Remediates legitimate vulnerabilities; [FedRAMP Assignment: high-risk vulnerabilities mitigated within thirty (30) days from date of discovery; moderate risk vulnerabilities mitigated within ninety (90) days from date of discovery], in accordance with an organizational assessment of risk; and
e. Shares information obtained from the vulnerability scanning process and security control assessments with [Assignment: organization-defined personnel or roles] to help eliminate similar vulnerabilities in other information systems (i.e., systemic weaknesses or deficiencies).


RA-5 (e) Additional FedRAMP Requirements and Guidance: to include the Risk Executive; for JAB authorizations to include FedRAMP Common Vulnerability Scoring System (CVSS). Related controls: CA-2, CA-7, CM-4, CM-6, RA-2, RA-3, SA-11, SI-2.

References: NIST Special Publications 800-40, 800-70, 800-115; Web: http://cwe.mitre.org, http://nvd.nist.gov.

FFIEC 

Category 17

Threat and Vulnerability Detection

Independent testing (including penetration testing and vulnerability scanning) is conducted according to the risk assessment for external- facing systems and the internal network. (FFIEC Information Security Booklet, page 61)

Mitre ATT&CK 

M1016

Vulnerability Scanning

Vulnerability scanning is used to find potentially exploitable software vulnerabilities to remediate them.

HIPPA 

164.308(a)(1)(ii)(A)

Risk Management

Conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information held by the covered entity or business associate.


© 2021 Copyright Reciprocity, Inc.
https://reciprocity.com