Sep 23, 2019
Network scanners have been around for quite a while, with Qualys developing the first network scanner in 1999. Today, they’re still going strong; Qualys, Tenable and Rapid7, all offer powerful network scanners. Since the onset of scanning in the late 1990s, network scanners haven’t changed much. Of course, there has been an evolution in the number of scanners available and their capabilities over the years; they are now capable of greater breadth in gathering data from multiple vantage points and providing more sophisticated analysis.
However, network scanners are falling behind the times in their ability to detect vulnerabilities, especially in cloud environments. Here’s what to do about it.
Network scanners were designed to assess computers, networks, or applications for known weaknesses. Broadly speaking, there are two types of network scanners:
When they were first developed, network scanners were a very good option to assess vulnerabilities in on-prem environments. They enabled scanning of the entire network via a single simple integration and they were very straightforward to set up in physical environments.
A common strategy in security is to look for “choke points”, or a single point at which all incoming and outgoing network traffic is funneled. Networks connect many endpoints, so instead of deploying an agent on each, one by one, you could simply do it on a per-network basis.
But, how do they scale today?
Unauthenticated scanners attempt to mimic the behavior of an attacker, exploring a network or networked system for vulnerabilities that do not require logging in as an authorized user. These scans allow visibility into what a malicious hacker could access without acquiring login credentials or posing as a trusted user.
Unauthenticated scanners ultimately take the “black box” approach, by testing an application’s defenses and design from the outside-in without disrupting the network. This is very limiting, especially when compared to a more knowledgeable white box approach, deployed by agents and authenticated scanners. While popular, unauthenticated network scanners have three serious drawbacks when used in the cloud:
Vulnerability scanning can wreak havoc in your network and can be seriously disruptive to network services and vital business applications.
To mitigate this risk, it is important to earmark the level of risk you are willing to tolerate. Security teams need to aim for a sweet spot between detecting all possible vulnerabilities in a network and disrupting the environment. Since scanning needs to run on a continuous basis, to deploy scanners you need to make sure you’re OK with a certain level of risk. Remember that while you might be playing it safe, attackers are most likely not, which puts defenders at a disadvantage.
Unauthenticated scanners can examine only publicly visible information (either easily accessible and/or based on hints) and are unable to provide detailed and contextual information about assets.
For example, if you have a website called, mydomain.com/email_campaign, which is not crawlable (linked) from the main website, the network scanner won’t scan it as it won’t know it is there – unless it is manually configured; no organization can really make sure it is manually configured that way. This leaves many organizations exposed to domain hijacking attacks.
Scanners can often get stuck in flows that a real attacker wouldn’t. In many cases, there are measures in place, such as CAPTCHA, which can easily prevent any automatic mechanism (including scanners) from registering. However, these techniques won’t have any effect on a human who tries to attack the same system.
For example, we found a critical vulnerability on a customer’s website, which occurred in a section of the website that is only accessible to registered users. This part of the site is where a registered user triggered a vulnerability which led to the breached system.
Since registration is free (which is true for most web sites), attackers could easily register to the web site in order to try to penetrate it. The scanner missed this critical vulnerability because it could not pass the registration stage.
To secure all your assets in the cloud, you need to make sure your scanners can reach all networks and assets. They need to be able to poke holes in your firewalls, both at the organizational level and per each individual asset.
This is both time consuming, and in many cases, a security issue in and of itself, since the ports needed for authenticated scanning are the ones that are usually exploited. This means that it’s impossible for them to go across NATs, and they cannot see inside containers.
Network scanners made sense in the pre-cloud era, when creating a new network was a “project” that took a lot of time, required effort from cross-functional teams, and involved buying hardware. Back in the day, organizations only had a few (or a few dozen for large enterprises) networks. But in the cloud era, networks are created dynamically, scaled up and down without the need for buying hardware. Enterprises often have hundreds of virtual networks, and containers are scaled up and down all the time, exacerbating the issue even further.
Scanners only provide a partial solution to cloud security; they have “blind spots” and either don’t see all cloud assets or can’t analyze assets in-depth. Securing the cloud requires complete visibility into compromised resources, vulnerable software, and misconfigurations without the cost, complexity, and limitations of agents and network scanners.
That is where Orca Security comes in. Orca delivers instantaneous, scalable, hassle and impact-free full-stack visibility so you can: