Security Experts:

The Event Horizon: Examining Enterprise Security Blind Spots

Examining Gaps in Network Security

In Physics, the event horizon of a black hole is the point at which the black hole’s gravitational pull becomes so great that nothing can escape – not even light. In other words, the black hole’s event horizon is essentially a “point of no return” that, once crossed, can never be crossed in the reverse direction.

Anything that crosses the event horizon is destined to fall towards the center of the black hole. You are likely asking yourself what this has to do with information security, which is certainly a reasonable question. I hope to explain the relation in this post.

Recently, I was discussing the concept of gap analysis, specifically as it relates to network and endpoint visibility within an organization, with my friend and colleague, Anthony Spina. That discussion served as the inspiration for this piece, and for that, I thank Anthony.

Essentially, what we discussed was the concept of closely examining where “blind spots” in the data might exist – places where malicious activity can occur but where I do not have appropriate telemetry. In other words, as an event moves into, through, and out of the network, and onto and off of various different systems, where do I have visibility into that activity and where do I not have visibility into that activity? Let’s examine this concept in more depth.

In using the term event here, I am referring to one or more packets of data that correspond to and compose a specific activity on the network. That activity may be malicious, suspicious, or benign, or its true nature may be unknown.

Gap AnalysisSome simple, straightforward examples of events on a network include the transfer of a binary piece of code, the request and retrieval of a webpage, or the composition and sending of an email. As each of these events occurs, various different corresponding activities will occur on the network and on the endpoint.

Let’s examine some of those activities using the case of a malicious binary file download by an endpoint on the network as our working example. In this relatively simple use case, the following steps may occur (among others):

• A process on the endpoint will request the malicious binary file from a remote site (putting aside for now the question of why specifically that occurred so that we can focus on this example)

• The malicious binary will attempt to install itself on the endpoint and will likely add, delete, and modify various parameters on the endpoint

• If successful, the malicious binary will compromise the endpoint and may create one or more additional processes

• The compromised endpoint may request additional binaries, command and control instructions, or other resources

• The compromised endpoint may attempt to steal credentials or leverage those credentials to perform login activity to various resources, including but not limited to internal sites, Active Directory, and other systems on the network

• The compromised endpoint may use lateral movement to explore other systems, data, or resources of interest

• The compromised endpoint may obtain and stage data from other systems

• The compromised endpoint may exfiltrate the data that has been staged

Of course, this is just one simple, somewhat limited example for illustrative purposes. If we take a step back, we can see that each of these steps leaves a footprint in the sand. For each of the steps, depending on its nature, the footprint may be left in the network data, the endpoint data, and/or elsewhere (e.g., Active Directory log data).

Each time a footprint makes an impression in the sand, it presents us an opportunity to observe the event as it unfolds over time. If we don’t have any visibility at the relevant points within the organization, we will fail to observe the event entirely, making timely detection and response almost impossible.

If we have partial visibility at the relevant points within the organization, we may have trouble piecing together the complete narrative of what occurred. If we have complete visibility at the relevant points within the organization, we should be able to piece together the complete narrative of what occurred. This assumes, of course, that our collection and analysis infrastructure is significantly robust and scalable so as to facilitate this.

That brings me back to the concept of the event horizon. As an event moves into, through, and out of the network and onto and off of its various systems, there is a certain horizon of time during which it can be observed. That horizon is not infinite. What does it mean for an event to be observed? Essentially, it means that information from the event can still be recorded, or put another way, the information can still “escape” from the event horizon. After a certain amount of time, the event will have passed through our ability to observe it, and its existence becomes a historical occurrence. In other words, the event crosses its event horizon, after which time it is impossible to observe.

If we don’t take advantage of the opportunity to record the event before it crosses the event horizon, we can lose the ability to record the event entirely. There is a window of opportunity during which we want to ensure we do not have any gaps in visibility.

This is essentially the concept of gap analysis as it relates to network and endpoint visibility within an organization. An organization that keeps records of its security incidents should be able to study that data to understand the top ways in which it is generally becoming compromised. Those can be turned into case studies upon which gap analysis can be performed to understand where any blind spots may exist that would prevent complete visibility into those specific types of incidents.

The output of the gap analysis should be a series of findings (gaps) that can then be translated into actions that can be taken to reduce or eliminate those gaps in visibility. For example, an organization might find that portions of its network are unmonitored, or that it does not have the ability to monitor activity on the endpoint.

Thinking about the event horizon allows an organization to grapple with the finite time horizon during which it can observe an event. Performing a gap analysis to understand blind spots that may exist over the course of that time horizon can help an organization ensure that it maintains complete visibility into events. A productive gap analysis and subsequent follow on actions can help an organization observe and identify events of interest on the network before they disappear over the event horizon. Black holes don’t work very well for incident response and security operations.

view counter
Joshua Goldfarb (Twitter: @ananalytical) is currently Director of Product Management at F5. Previously, Josh served as VP, CTO - Emerging Technologies at FireEye and as Chief Security Officer for nPulse Technologies until its acquisition by FireEye. Prior to joining nPulse, Josh worked as an independent consultant, applying his analytical methodology to help enterprises build and enhance their network traffic analysis, security operations, and incident response capabilities to improve their information security postures. He has consulted and advised numerous clients in both the public and private sectors at strategic and tactical levels. Earlier in his career, Josh served as the Chief of Analysis for the United States Computer Emergency Readiness Team (US-CERT) where he built from the ground up and subsequently ran the network, endpoint, and malware analysis/forensics capabilities for US-CERT.