Slicing and dicing your external attack surface data can yield valuable insights to help you strengthen your overall security strategy. But you can’t effectively analyze this data manually or with a legacy tool. Learn how Tenable.asm can help you mine this data quickly and precisely.
As we outlined in our recent post Visibility of the Unknown, it’s crucial for organizations to have an external attack surface management (EASM) strategy, especially in order to conduct effective exposure management. Today, we’re going to explain why you need the ability to slice and dice your external attack surface mapping data in order to obtain actionable insights to guide your security strategy.
Analyzing external attack surface data is critical
Slicing and dicing external attack surface data can be extremely useful for a variety of security and compliance teams and for many use cases.
- Teams focused on IT modernization can find troves of information about asset version information of infrastructure.
- Security teams can gain insights and visibility into vulnerabilities and misconfigurations.
- Compliance teams can check on policy violations, licensing status of products and more.
Let’s walk through some simple examples of how analyzing your external attack surface data can shed valuable insights into your security posture. This is not a comprehensive list, for two reasons. There are too many columns of data and too many ways to slice the data, and also use cases are equally as numerous. Everything is based on what hypothesis you are attempting to solve.
- SSL/TLS expiration / SSL/TLS error: Both these columns allow companies to identify assets that are broken or misconfigured due to either self-signed certificates, old certificates, or otherwise broken certificate chains. Why are these assets still up if you have to click through errors to even reach them? Should they be fixed or removed?
- SSL/TLS fingerprint / JARM hash: An interesting feature is to turn on fingerprints, render them on a dashboard and see how many assets have the same fingerprint. If they do, then you know that if one of them is compromised all other assets need to have their SSL/TLS certificates revoked and re-issued. This capability is very handy in cases of vulnerabilities impacting cryptographic software, such as the notorious Hearbleed bug in the OpenSSL cryptographic library, disclosed in 2014.
- Login: Pages that indicate they either are a login page or are linking to a login page are usually very important to the company compared to brochureware landing pages with no login functionality.
- Response header name / Response header value / Response security header name / Response security header value: Being able to interrogate specific HTTP headers is useful to find misconfigurations, outdated assets, security issues and so on. For instance, wouldn’t it be nice to know which assets had been labeled “unsafe” with regard to Content Security Policy (CSP) headers? Why has the organization decided it is a good idea to allow unsafe inline JavaScript? Is there an exception for this? Why is it there?
- Response code: Unless you see 200, 300 and maybe 401 response codes, generally speaking there is usually a problem. If the web server is saying “there’s no content here,” then why does it exist? Should it still be there? If it’s responding with an error, why does the error exist? Is someone investigating that asset?
- HTML / document title: If you are trying to find something, like a reference to single sign-on, or pages that hyperlink to your AUP/ToS pages, or say that they are default Apache/IIS installs that haven’t been configured, HTML is usually the fastest path to get there since hyperlinks are found within HTML.
- Record types: It’s useful to know, for example, that a record type is an A record vs an AAAA record because the reason one user can see the content and another can’t see it might have everything to do with the fact that they aren’t able to connect to IPv6 from their house, while another user can. You may also decide your company is disinterested in pointer (PTR) records since normal users are unlikely to ever utilize them, while other companies might want PTR records to identify old assets that were believed to be removed or misconfigurations at a service provider level.
- ASNs (autonomous system numbers )/ country: You may find that when you render your ASNs on a dashboard you are hosted in a lot more locations than you originally thought. Why do you have 54 assets in a war zone?
- Common platform enumeration (CPE) / CVEs / revocation block-lists (RBLs) / CVSSv3 scores / CVSSv3 vectors: Why do 400 of your assets have vulnerabilities? Why are you, for instance, using four versions of WordPress, some of which are likely to have an unpatched vulnerability? Without knowing which version is current, it is usually safe to say that two or more versions in production typically mean that some or maybe even all of them aren’t up to date.
As you can see there are an enormous number of use cases even in just this small set of the more than 150 different columns of data, not to mention many of the columns of data are actually nested. For instance RBLs contain 400 different RBL lists under one column of data. So we’ve just offered a peek at the treasure trove of insights you can derive from analyzing your external attack surface metadata.
How Tenable.asm can help
As with any complex system, such as the internet (and it indeed is a very complex system at that) there are many ways to think about and categorize this data so that you can draw conclusions from it.
Categorization and level of data is exactly what we provide for your external attack surface. So, as a security leader, you can ask questions like: “Why are 12% of my cloud external assets based in APAC?” With the numerous types and categorizations that Tenable.asm provides, you can make better informed decisions based on your data.
These data sources, and more, are all within your control; just select the information you want to see across your external assets for additional information and context.
To gather the metadata effectively, you need many sources. For EASM systems to be effective, they must be powered by a series of “apps” connected to the EASM system on the backend that run different functions or ask for different slices of data from the asset. The reason these apps exist is that the apps access network devices in different ways or through different subsystems/data feeds.
Here are examples of apps that provide contextual metadata:
- Whois - gives ownership attribution information when available with things like administrative contact name, administrative contact email, and more. This single app comprises 26 columns of data.
- IPGeo - gives things like location of the asset by city, country, latitude, longitude, ASN information, and more. This app comprises 11 columns of data.
- Portscan - gives open ports, service information, CPE information, CVEs, etc ... This app comprises 7 columns of data.
Now, let's say you could manually or programmatically compile all of your external metadata from these sources listed above. With even a small sample of apps, it’s clear that the number of ways to slice the dataset becomes a factorial problem. For example, Whois at 26 columns of data, IPGeo at 11 and Portscan at 7 = 26*11*7 = 2,002 combinations. Once you add in the rest of the columns it’s an astronomically large number of possibilities.
Not to mention many of the columns allow querying by subtext. For instance, you can ask a question of the HTML on the homepage of the asset to the effect of: “Do any of my assets contain the text ‘administrator’?” Or: “Do any of my assets contain the name of our old branding ‘XYZ’?” That may never be a question that any EASM vendor’s pre-built insights would know to ask ahead of time because it is so specific to your use case. But by being extremely flexible, Tenable.asm allows for a wide variety of use cases.
For instance, let’s say you are looking for BigIP load balancers from F5 in your inventory. There is no one place that is ‘safe’ to look for an F5 fingerprint because there are a lot of things that might obscure normal fingerprinting techniques. You may find that some fingerprinting uses the “Server” HTTP header, but many F5 devices are configured to hide the “Server” header. So what are you to do?
Tenable.asm gives you multiple ways to find these assets. You might find them in services information (stemming from CPE fingerprinting), or in response header names, or in values of other HTTP headers like cookies, or in portscan banner information. If the signature is missing in one or more of these columns of data, you can still have a chance of finding otherwise hidden F5 devices by using Tenable.asm’s multiple fingerprinting techniques.
In closing, Tenable.asm allows you to perform ad-hoc, granular slicing and dicing of your external attack surface data, so you can mine valuable insights from it and apply them to your security strategy.
If you have questions or want to see a demo of Tenable.asm, which is part of the Tenable One Exposure Management Platform, visit our product page.
