Issue:
The mapping of external Network Address Translations (NATs) to internal infrastructure can be challenging for defenders. Oftentimes requiring complex data joins across multiple disparate logging resources. This gap of visibility presents itself when investigating threat signatures that hit external NATs and are routed to underlying infrastructure. In most cases just knowing if the underlying infrastructure is Microsoft or Linux based can eliminate the need for a full investigation or eliminate the need to escalate an alert to tier 2 or tier 3 SOC team leaders.
Solution:
Censys Attack Surface Management (ASM) can provide comprehensive visibility into your external facing IT infrastructure. This increased visibility and situational awareness can decrease alert triage time and increase alert processing standardization for network based alerts.
Scenario:
A critical or high priority alert is received by a Security Operations Center (SOC) Analyst for triage and validation. The clock starts, it’s investigation time! Every second counts when front-line cyber defenders are triaging alerts.
Example Alert Signature:
(Critical Alert)
Firewall detected exploit signature {signature} at IP/Host(External load balanced NAT IP address / Domain)
The alert is presented to analysts via a SIEM. The analyst researches the CVE/Signature and gathers key bits of information. Armed with the context of the exploit signature, namely the basic question of what type of system is potentially vulnerable, the analyst is now ready to evaluate the target of the alerted threat signature. Within the alert’s body is the external NAT/load balanced IP and or domain name. At this point the analyst is just trying to confirm or deny basic questions. Is this threat signature even capable of impacting this host? What version or versions of software are impacted? Does the exploit target Microsoft servers, Linux based infrastructure, or a specific CMS application/version? These are basic but time-consuming questions to answer when manually evaluating load balanced infrastructure.
Without Censys ASM the analyst would need to pivot out of their internal toolsets and SIEM to manually evaluate the IP/Domain that the threat signature was observed targeting. Ensuring analysts are able to process alerts within their standard toolsets is important for overall SOC process standardization. As it increases the consistency and quality of analysts’ decision making.
How Can Censys ASM Help?
With daily scans and host information we can not only fingerprint your edge client, like F5 Big-IP, we can also fingerprint the underlying load balanced server infrastructure.
Example of ASM “Host Information” for a typical F5 BIG-IP NATd and Load Balanced IP. Censys scans are picking up underlying Microsoft Servers. Vital data points for the SOC Analayst’s network alert investigation.
Example ASM Host Information:
A quick review of Censys ASM data informs our SOC analyst that this host’s underlying infrastructure is Microsoft based. Turns out our example alert exploit is only designed for certain versions of Linux. The analyst is able to confidently document their steps for reaching their conclusion. Alert closed!
CMS fingerprints are also important data points when triaging exploit signatures observed by your firewall and will also be displayed if observed.
A 60-second pivot in Censys ASM data can save your team time. Manually this process could take 10-15 minutes. Not only that, the quality of review by analysts is increased with use of known standard sources of truth.
To take this concept a step further Censys ASM data can be integrated in SIEM/SOAR solutions where this data would automatically enrich the firewall exploit signature alert. Alert received, enriched with Censys ASM data, alert triaged, alert closed. Analyst blows smoke from the end of their mouse and takes a sip of coffee before moving on to the next alert.
