Cloud Security Best Practices: Vulnerability Scanning

Vulnerability scanning is an important practice within cloud security. I addressed this practice in the “7 Cloud Security Best Practices” blog post. This post expands on the practice of vulnerability scanning and management for the IT security team tasked with the responsibility of dealing with an external cloud infrastructure.

This post identifies critical considerations that go into choosing a Cloud Service Provider (CSP) that is cooperative with vulnerability scanning.

The Dilemma for CSPs and Customers Who Want to Scan

IT security professionals understand the challenge of allowing external system scans. For internal network defense, security admins must block external scans to prohibit information gathering from bots and black hat hackers. This step keeps unwanted scans from gathering critical system info about operating systems, system devices, and other technical details. As a security pro, how do you think a CSP feels about permitting external scans performed on their cloud infrastructure?

In the blog post “Vulnerability Scanning and Clouds: An Attempt to Move the Dialog On…“, Craig Balding explains the logic behind the CSP’s stance against scanning and he proposes a reasonable solution for both parties involved. He elucidates how a “blanket ban on legitimate scanning activity by customers…undermines security assurance processes [and makes] regulatory compliance impossible”. But how do the two parties achieve compromise, especially when the same challenges that come with vulnerability scanning, are amplified when scanning a shared cloud infrastructure?

For example, scans can affect outages if the “scanning policy includes Denial of Service checks or the scanning engine is configured with ‘aggressive settings'” enabled. Security admins supporting the cloud infrastructure may face difficulties distinguishing between legitimate and illegitimate scans. As Balding points out, “even if a scan originates from a customer owned network, this does not necessarily mean it is authorized”.

Above all else, scanning may result in significant performance issues for your organizational members and other customers connecting to the shared infrastructure.

Balding believes the CSP and customer can arrive at a solution through the “mix of provider open-mindedness, policy, process, technology and contact” regarding scanning scope and times, source IP addresses, processes, and tools used.

Internal IT security teams should not arrive at this stage of compromise with the CSP after becoming customers. Prior research proves critical to successful a relationship where vulnerability scanning is neither prohibited altogether nor freely executed by the customer.

Outline the Considerations to Choose a CSP Open to Vulnerability Scanning

The above section identified a number of factors to consider before choosing a CSP. Customers are responsible for initiating the conversation about scanning with the CSP. This step should not entail a quick reference to the Terms of Service agreement section about vulnerability scanning. But this should evolve into an ongoing conversation and communication between the points-of-contact responsible for vulnerability management on both sides.

Before agreeing to terms with the CSP, security teams should discuss and agree upon:

• Scanning Scope: In the blog post referenced above, Balding explains how “picking and choosing which pieces of your hosted infrastructure to scan is a slippery slope to selective exposure if not handled with care”. Make the CSP clearly explain what you can and cannot scan of the shared cloud infrastructure.
• Source IP Addresses: The source IP address designated to execute the scan must be known by the CSP.
• Scanning Tools: What tools are permitted by the CSP?
• Scanning Duration and Times: Due to traffic and performance factors, customers are only allowed to perform scans during a specific time.

Do you have experience with vulnerability scanning? Then you should understand the difficulties that accompany vulnerability management, even with scanning an external cloud infrastructure.

The major obstacle managing data from cloud scans

The main challenge entails managing the high amount of raw data collected by the scans. The challenges come with analyzing low and high risk vulnerabilities, identifying and filtering out false-negatives and false-positives, and prioritizing threats for remediation.

Part of the solution for effective, automated, and smarter data management, comes with the scanning tool. Test different scanners, commercial and free, and compare the results. When testing the scanners, consider how they prioritize the risks associated with the exposed vulnerabilities. Does the scanner prioritize based on the Common Vulnerability Scoring System (CVSS)?

Scanners solely dependent on the CVSS run into issues. First of all, “only 2.4% of vulnerabilities in the National Vulnerability Database have actual attacks logged in the Symantec Threat Exchange”. Also, “only 27 of the possible 8,000 vulnerabilities released over two years were actually included” in the top exploit tool-kits in attacks. Despite the CVSS’ attempt to better account for modern vulnerabilities, it falls short.

Whatever data security teams gather after scanning the cloud infrastructure, they must immediately communicate the findings to the appropriate contacts at the CSP. Two way communication is critical to successful vulnerability management when dealing with an external cloud infrastructure. Data management and prioritization is one area of concern when overseeing vulnerability scanning. Ideally, tools provide accurate and automated processes for sorting vulnerability data.

Two tools to research include the Google Cloud Security Scanner and Nessus Cloud. Nessus is a proven software tool for vulnerability scanning. The Google scanner is free, but only available to customers of the Google Cloud Platform.