Using web reconnaissance platforms to monitor your attack surface or run investigations can be time-consuming, especially when we’re looking to understand what happened at a point in time in the past. These platforms do sometimes provide a view on all the past collected data included in a paid subscription, but navigating and interpreting the information can be a challenge.
In our approach to provide a comprehensive external attack surface view behind a single pane of glass, we’ve therefore included in Flare, an overlay on that host/port data to help users quickly understand, filter, and gain insights from the entire history of a host.
When you receive an alert concerning a host, you can get a quick understanding of past risks and issues relating to it, without leaving the platform. This reduces the time required to triage and remediate the alert. An incident requiring you to investigate past events will also be more efficient with the Flare data being readily available to match and correlate past host activity.
Let’s now dive into a use case example on how this new feature could be used in daily cybersecurity operations.
Integrate the world’s easiest to use and most comprehensive cybercrime database into your security program in 30 minutes.
Web Reconnaissance Platform Integration – Use Case
On a busy Tuesday morning, a systems administrator opens a new port on a public server, reachable by a public IP address. Without Flare, this would have been invisible to the security team, but the team now receives an alert for a newly opened SSH port on a host related to their organization. An analyst jumps in the Flare platform and notices that the host has no other current open ports, but that 3 months ago, the same port 22 had been open for 4 hours.
The analyst reviews past incidents in his incident management platform and the past date then, immediately ties the server to a precise individual inside the organization. He reaches out to the employee, asking if the desired port opening was part of a planned activity. The system administrator realizes that a mistake had been made and that the port had been open on the wrong server. He immediately closes the port, before a malicious actor gets enough time to access the server. The security analyst closes the incident and can get back to his regular operations.
