No Room for Doubt – Why Security Testing is Essential for your External Attack Surface

Behind the scenes, most external attack surface management (EASM) products rely solely on basic reconnaissance technologies for asset discovery and risk detection.

Unfortunately, this approach isn’t just a nice, simple way to understand exposure and risk; it’s actually risky, problematic, noisy, and painful.

Let’s look at why.

First, what is reconnaissance, and how is it used in EASM platforms?

From an attacker’s perspective, reconnaissance or “recon” is just the passive or active investigation used to build a profile of a target. 

Passive recon uses indirect techniques to build a target profile, making it exceedingly difficult to trace and thus heavily used by attackers. An EASM may use passive recon to expand an organization’s domain name (called DNS enumeration) to build a list of records. This provides insight into the external attack surface since the list of records leads to a list of IPs, illustrated in Figure 1.

Figure 1. Passive recon builds a list of domains in use by the target organization

Active recon techniques go one step further. Active recon interacts once with an asset, stopping after it initiates (but does not complete) a connection on a specific port (for example, port 25 for SMTP), as illustrated in Figure 2. Attackers use active recon carefully; since it is a direct interaction with a target, there is the risk of detection. An EASM uses active recon to scan the IP ranges uncovered using passive recon.

Figure 2. Active recon builds a list of exposed assets found inside the domains found by passive recon

Most EASMs stop at reconnaissance because it provides just enough information to an end consumer to justify their claim to an “attacker perspective.” Unfortunately, the incomplete and low-confidence data forces IT security teams to manually filter out noise, quantify risk, prioritize issues, and build the context required for remediation.

The external attack surface is no place for low-confidence data

Humans have a tendency to place unwarranted value on information that is presented to them numerically. This phenomenon is called false precision: people assume that if something is presented as counted or calculated, it is also likely to be accurate and complete.

Unfortunately, nothing could be further from the truth. Especially for EASMs that rely on recon as the sole means to discover assets and uncover risk.

Here is why:

• Passive recon only looks where it is told, often through seed information (domains and IP ranges). This leaves vast quantities of assets undiscovered.
• Active recon involves direct interaction with a target, often in the form of banner grabbing, which is a system’s presentation of the software it is running. Unfortunately, banners can be incomplete or incorrect due to misconfiguration or system instability.
• Because port scanners are unable to validate vulnerabilities, CVEs mapped from software versions (CPEs) are simply assumed to be present. This introduces inaccuracy (e.g., a patch may not be reflected in the banner) and noise (as much as 70% false positives according to our internal research).

As a result, the information presented in these EASMs are best effort due to the underlying technologies. Despite the lists and dashboards, the incomplete asset inventories and lack of accurate risk evaluation leave IT security teams bombarded with low-confidence, low-precision CVEs.

Clearly, reconnaissance is a good starting point for EASM, but it doesn’t go far enough to understand the risks to the external attack surface. For true confidence in risk assessment, organizations must incorporate active security testing. 

Why security testing is essential for the external attack surface

Security testing is very different from reconnaissance. Unlike recon, security testing establishes a full connection with an asset and runs payload-based tests to understand the success of a specific objective.

Payload is a way to describe a list of instructions and data sent to the target. A payload includes matching conditions, commands, expected responses, and more. 

Figure 3. Example payload used in active testing

Active testing uncovers the broadest range of risks with the highest confidence. 

Five areas where security testing is non-negotiable

Security testing answers the most critical external risk questions, like: 

• Does the asset expose sensitive data? 
• Are specific HTTP requests exploitable?
• Is the patched web application susceptible to an injection attack? 
• Is the application protected by a web application firewall (WAF)? 
• How easy is it to access the exposure? 

And more.

Five areas where active security testing is required are:

• Testing web applications/DAST
• Uncovering exposed sensitive data
• Reducing false positives
• Prioritizing issues accurately
• Validating remediation efforts

These are non-negotiable for organizations pursuing an elevated understanding of risk and efficient use of IT security staff. All are provided using active security testing. None are available within EASM solutions that rely on passive recon and active recon techniques.

Legacy approaches to security testing isn’t enough for the external attack surface

Dynamic application security testing (DAST) may be the most important use case for security testing your external attack surface. But legacy approaches to applying DAST to exposed web applications break most vulnerability scanners and even some dedicated DAST. Why?

Application testing requires a full connection and repeated interaction with an asset. Due to the potential impact on production systems, this means:

• Decision on which application to test and how deep to test
• Scheduling/maintenance windows (even for non-production environments)
• Careful monitoring of asset resources during testing
• Hardware/software/virtual machine installation, configuration, management 

This adds up to considerable time and expense, not only from a licensing perspective but also from security staff time. To fully understand external exposure, DAST needs to be performed repeatedly, across all web applications, ideally on a bi-weekly basis. 

CyCognito: EASM with integrated security testing

CyCognito’s purpose-built security testing engine is a module within its EASM platform. This is “black box security testing” at its best and removes the blockers normally associated with security testing at scale.

• Security testing is performed continuously across a dynamically maintained external asset inventory, including assets owned by subsidiaries and 3rd parties.
• Integration with the CyCognito discovery engine ensures that the CyCognito security testing engine has the entire attack surface and full context on every asset. Testing pre-work is automatic; for example, all URLs/services are captured per web app as context.
• Payloads are developed based on asset context. For example, DAST payloads are only applied to web applications. Joomla and WordPress vulnerability and misconfiguration tests run on CMS environments. Some tests are run on all assets, for example, data exposure.
• CyCognito’s network of over 60,000 nodes spread over 100 countries delivers payloads to the targeted asset. Individual tests are distributed across multiple test nodes from multiple IP addresses, regions, and types, to obfuscate the interaction. Whitelisting, input, and configuration are not required.
• Resource impact levels are monitored carefully, including both load (“bandwidth”) and depth (the number of interactions, etc.), even for basic user actions, e.g. fetching a homepage. CyCognito tests are unauthenticated (also called non-credentialed); at no time do CyCognito active tests modify or compromise a customer asset.

No EASM product today matches the level of control and visibility delivered by the CyCognito platform.

Case Study – “If it has an input field, we want a WAF in front of it”

One of CyCognito’s clients, a large B2C retail vendor, relies heavily on online web purchases. CyCognito’s security testing/DAST enables their team to immediately identify web applications without a web application firewall deployed. This allows the team to proactively reduce risk.

Figure 4. WAF detection using CyCognito

API detection is another example. The growth in B2B communication via API has created new threat vectors. Understanding whether their exposed web application contains an API endpoint is critical to understanding external risk and effectively streamlines the team’s work.

Figure 5. API detection with CyCognito

Find out more about CyCognito security testing your full asset inventory

CyCognito takes the burden and costs out of managing security testing; recon and security tests are completed automatically, at scale, using CyCognito’s enterprise-grade testing infrastructure. 

Customers of CyCognito Automated Security Testing (AST) have this testing information already available. Simply navigate to the Risks page from the home menu to see the results.

If you are not a CyCognito customer and want to find out more about how we can help enable automated security testing across your full external attack surface, please contact us at [email protected].