Tips for Avoiding Compliance Gaps and Unmanaged Risk in Internal Scanning Practices

As a Network Security Consultant and QSA, I frequently review internal scanning practices and approaches during network vulnerability scanning engagements and PCI assessments. There are a number of common mistakes with scanners that almost always lead to compliance gaps and unmanaged risk. Avoiding these mistakes is relatively simple.

The following tips are intended to help verify internal scanning systems are effective, do not contain obvious compliance gaps and remain free of avoidable unmanaged risks.

Avoiding Compliance Gaps

1. Include all in-scope system components and their subnets as scan targets. Failure to scan all in-scope systems is the most common compliance gap.

2. Include all IPs on the in-scope system components as a scan target.

3. Verify host discovery is adequately detecting assets. To do this, alter TCP ping and other discovery settings as necessary to ensure the detection is complete. Periodically, audit the inventory manually to verify assets are not being missed.

4. Scan all 65K TCP ports and as many UDP ports as are known to commonly exist within the standard configuration of the systems begin scanned.

5. Remediate all vulnerabilities with CVSS Base scores of 4.0 or higher.

6. Review any false-positive supporting evidence and related close/ignore tickets at least quarterly, and track all changes using your organization’s change control process.

7. Re-run scans after technical remediation, and retain clean quarterly internal scan report summaries and technical reports for submission to your QSA.

8. Remember, scans are NOT penetration tests! Network and application layer penetration testing must be conducted at least annually. High-risk findings must be remediated, and successful completion of the fixes must be verified. Also, while the topic is being visited, ALWAYS finalize the formal definition of scope beforehand. If you fail to include all assets in the penetration tests, it invalidates the report.

9. Make sure external scans are completed by an Approved Scan Vendor (ASV). Passing results must be attested to by the ASV at least once a quarter.

While all of the information in this post has relevance to compliance, successful efforts to execute internal scans have to start somewhere. Focus on avoiding the most common compliance gaps first. Then, as your process matures, begin addressing the other items below to begin fully leveraging your internal scanning and eliminating previously unmanaged risks.

Avoiding Unmanaged Risk

1. Utilize hardened, purpose-built appliances for scanning. Or, harden scanning servers, then disable firewall rules in place for the scanner when scanning is not taking place.

2. Ensure scanning systems are configured based upon a documented system configuration standard that addresses common PCI requirements (for risk management).

3. Synchronize time on scanner systems, and include them in centralized log collection processes. Is a scan or an attack coming from your scanner if no scan is running?

4. Ensure scan results are able to demonstrate removal of unnecessary protocols and services.

  • Permit access to the VLANs where the targeted in-scope system components reside by placing appliances in the same VLANs when feasible.
  • If firewalls are present between the scanner and the targeted in-scope system, include full-permit IP statements from the scanner IPs to the in-scope subnets.
  • Ensure host firewalls do not obstruct scanning. Include full-permit IP statements from scanner IPs.
  • Compare the open ports and services found by the scanner to the ports and services allowed by the firewall for business purposes. Scrutinize any services that are listening but not allowed by a firewall rule. (These are either isolated to the local VLAN, or they are simply unnecessary.)
  • If permit IP is not possible on the host or network firewall, include, at minimum, the scanning appliance in each firewall rule. No traffic should be permitted from any IP unless it is also permitted from the scanner. Include the scanner IP in every group and/or permit statement.
  • Always make certain the IP source addresses assigned to scanners are under the direct control of the network infrastructure that is administered from inside the secured cardholder data zone.

5. Manually review all assigned IP’s on every targeted in-scope system during initial setup of scans for the component and after significant changes. 

  • Scan administrators must ensure each and every IP bound to the targeted in-scope system is scanned. 
  • Services frequently use bindings that only target one IP. Therefore, scanning every single IP on the targeted in-scope system is the only way to get a complete and accurate scan.
  • Start by reviewing all in-scope routers, switches and firewalls. Then move on to servers.

6. Scan all 65535 TCP ports in a safe manner. 

  • Overly aggressive port request timing or use of SYN-only scanning can cause issues from targeted system outages to missed open ports. Missing open ports are common if the traffic is too aggressive and is being statefully inspected. 
  • If open ports show up as closed, it causes a massive number of false-negatives because vulnerability scans will skip over the service.
  • Always review open port results on a significant sample of systems (at least one of each system component type) compared to the open ports shown in the scan report.

7. Consider all 65535 UDP ports. Establish processes to ensure open UDP ports are not missed by comparing periodic system configuration reviews to documented baselines.

  • Manage UDP port scanning with great care. Open UDP ports that are not caught by the scanner will result in vast quantities of unmanaged risk.
  • Using a scan vendor’s “common UDP ports” list is very helpful for scanning performance. However, it is really only acceptable if the port configuration is updated based upon your environment to include every UDP port that is open on your system components.
  • If a port is added, and you don’t review this frequently or scan all 65K ports, how will you know? 
  • Pick your poison! Monitor your netstat information for listening UDP ports very carefully or scan all 65K ports.

8. Scan all IP protocols - not just TCP and UDP. Frequently, services on systems have IP protocol layer IP stack bindings (ESP, AH, GRE, etc.). These listeners are just as likely to contain vulnerabilities as TCP- and UDP-based listeners.

9. Verify IPv6 is disabled on all targeted in-scope system components, or ensure IPv6 is completely addressed in the scanning methodology used.

10. Audit scanner traffic with host and network IDS/IDP systems, but NEVER block scanner traffic, which results in false-negatives. Consider constructing the alert structure so it is able to factor in the scanning schedule. Note: Many SIEM solutions are able to provide favorable logic to achieve the proper balance between scanning and alerting.

11. Set up full administrative privileges on the targeted in-scope systems for use by the scanners. Setting up full privileges on targeted systems ensures full transparency.

  • Lack of privileges on the in-scope targeted systems can result in a few false-positives.
  • Lack of privileges on the in-scope targeted systems will result in numerous false-negatives.
  • Reports that include fully authenticated scan results are not currently required to demonstrate compliance but should be used internally for managing risk and improving system configuration standards.

12. Fully document the internal scanning compliance report generation process to ensure there is no confusion about what is or is not included in each report type that’s generated.

13. Identify the root cause inside the vulnerability management process and system configuration standards, and remediate those as well. Once the vulnerability management process is shored up, our clients are amazed at how many vulnerabilities  they are able to find and remediate on their own that a scanning solution would normally miss. This is an example where the sum is greater than the parts.

Every year countless entities are breached, and the statistics behind their breach are compiled into breach analysis reports distributed throughout the industry. It’s quite common for the root cause of a breach to link to a vulnerability that’s easily detected by a properly configured internal scanner. 

Unfortunately, many times the scanners simply weren’t scanning everything in the cardholder data environment, or were not properly configured inside the breached entity.  

Exclusions: 

This article is not intended to be an end-all reference on internal and external scanning.  Following the guidance provided will increase the likelihood of compliant scanning-related processes compared to approaching scanning blindly. However, there are no guarantees.   

Every environment is slightly different, and your individual mileage may vary. 

This article is not intended to help remediate the vulnerabilities identified by scanners.   Sometimes forensics teams find a smoking gun - scan reports that show the issue was identified well before the entity was breached.  Even the most accurate vulnerability scan data will not help an organization if they do not act upon it.  Note:  The longer a risk goes un-remediated, the more likely a breach is to occur.

Resources: 

Stan Hoffman from the PCI Compliance Practice at Fishnet Security and Michael Guhl from Fishnet Security’s Approved Scan Vendor (ASV) Practice contributed information for this article.