Peer Inside The Tangled Web

Most enterprises do a reasonably good job monitoring their edges, or at the very least logging network transactions traversing those edges these days.  What's interesting though is that most enterprises have almost no visibility (or interest for that matter) to understand what's happening in the interior of their networks.  I have found there to be great value in peering inside the tangled web that is an enterprise network.

There are several data sources that can prove extremely valuable for monitoring the interior of a network:

1. Interior firewall logs
2. DNS logs
3. Network flow data (netflow)

Allow me to illustrate with two examples I commonly see.  The first example deals with detection an infected system, while the second example deals with tracing back an indicator of compromise (IOC) to an endpoint (infected) system.

First, let's consider the example where an enterprise monitors proxy logs and DPI (Deep Packet Inspection) at the edge.  Let's say that a client endpoint was re-directed via a drive-by re-direct attack (e.g., Blackhole Exploit Kit), downloaded, and was subsequently infected by a malicious executable.  Further, let's say that the malicious executable that was downloaded is not proxy aware.  If we miss the executable download (which happens somewhat regularly, even in an enterprise that is monitored 24x7), then our proxy and DPI will likely be of little help to us in detecting the artifacts of intrusion.  This is because of two main reasons:

1. The malicious code is not proxy aware, and thus its callback/C&C (command and control) attempts will most likely be blocked by an interior firewall.
2. The infected system will likely attempt domain name lookups for callback/C&C domain names.  Even if these domain name requests resolve (they don't always resolve, i.e., in cases where the domain name has been taken down), there will no subsequent HTTP request (remember, it was blocked by an interior firewall).  Because of this, there will be no detectable footprint in the proxy log.  In the DPI data, the DNS request will be co-mingled with the millions of other DNS requests and will show as coming from an enterprise DNS server.  This makes detection and endpoint identification nearly impossible.

I believe we can now see the value in retaining, monitoring, and analyzing the three data types I've identified above:

1. Interior firewall logs will allow us to detect attempts to connect to callback/C&C sites that have been blocked/denied.
2. DNS logs will allow us to identify endpoints requesting suspicious/malicious domain names.
3. Netflow data will allow us to very quickly identify other systems that may be exhibiting the same suspicious/malicious behavior.

 Consider a second example as well.  Let's assume that an indicator of compromise (IOC) has been detected leaving and/or entering the edge of the enterprise network.  What needs to happen first and foremost is endpoint identification.  How many endpoints are infected?  Where are they located?  When did the activity begin?  What was the infection vector?  In the modern enterprise, with many layers of NATing and firewalls, the right logging is key here.  Without it, tracing back the infection to the endpoint(s) will be nearly impossible.  None of the preceding questions can be answered before endpoint identification is completed successfully.

Hopefully this hard earned advice is helpful to all.