Pages

Friday, February 22, 2019

Aperture

If you follow me on Twitter or LinkedIn, you will very likely have seen me mention "aperture" more than a few times.  My use of the term has been in reference to digital analysis work (DFIR), as well as to the production and use of threat intelligence, particularly pursuant to, or with respect to, DFIR work.

What is "aperture"?  What am I referring to when I say, "aperture"? A definition I found online states that an aperture is "a space through which light passes in an optical or photographic instrument". In the context that I'm using the term, the "space" is a lens shaped and polished by our own individual experiences, and the "light" is the data that we have available.  How we interpret an event is based on what we know about the event (the data), applied to and filtered through the lens our own experiences.

To illustrate "aperture" by example, most of my background has been in DFIR work.  As a consultant, I was usually deployed after (sometimes quite a while after...) a breach had occurred, and I usually had host-based data with which to work.  The data that I did have available was heavily dependent upon a number of factors, including (but not limited to) the version of the OS, how long it had been since the actual breach had occurred, actions admins had taken, etc.  All of this is to say that for the most part, I did not have access to time stamped process creation data, nor to real-time telemetry of any kind.  I may have had artifacts of files that existed on the system at one time, or artifacts left behind by an application being executed, but what I did not have was the full, complete sequence of commands run by the bad actor.  I may have had access to historical data of some kind (i.e., Registry data, VSCs, etc.), but for the most part, my aperture was limited to what was available in the image.

As my career evolved into targeted threat hunting and response, my aperture widened a bit.  Sometimes, a response engagement was based on something detected through monitoring (process creation events, etc.) of the customer's network.  As such, we would have access to quite a bit of information about the malicious actor's activities, via endpoint telemetry collected through monitoring.  Other times, my response started by deploying an endpoint solution, which means that the only historical data available prior to the customer's call was logs and whatever was still available on the endpoints.

However, in other instances, the monitoring infrastructure was not created or enabled until after the customer called us.  Following the call, the monitoring infrastructure would be deployed, and the aperture was still limited; however, by deploying a sensor or agent, we were able to widen that aperture a bit.

Another example of aperture can be seen in the annual trend reports that we see published by security companies.  Not long ago, a friend of mine was at a company where about 90% of the work they did was PFI work; they did a lot of payment card industry (PCI) breach investigations.  In this example, the data that they had available was predominantly based on the PCI cases, interpreted through the analysis and experiences of the individual analysts.

We all have our own aperture; OSINT/Intel, EDR monitoring (via a SOC or MSS function), and DFIR all have their own aperture, based on the nature of the specific business model followed by each function, and their customer base.

Consider this example...OSINT tells us that a particular threat actor or group is targeting a specific vertical.  DFIR response to an engagement may show evidence that certain documents or information was collected, archived, and exfil'd.  However, very often, actors will encrypt the archives with a password, so while we may be able to determine the exfil mechanism (place the files on a web server, download them with a normal "GET" request, then delete them...), we may not be able to open the files to see exactly what was taken.  Having an EDR solution in place will show us a great deal about what the actor did, where they went within the infrastructure, what they took, and the password they used to encrypt the archives.

So what?  Why, or how, is aperture important?

For one, we have to acknowledge that we may not have a complete view of the incident or intrusion.  For example, if you're developing a "profile" of a threat group based on OSINT, which may include public reporting produced by others, you're going to have a much different view than that intrusion being actively monitored through the use of EDR technology.  The same is true for an after-the-fact DFIR engagement, particular one that did not benefit from the use of EDR technology (actor is long gone...).

Aperture is also important to keep in mind when we're viewing available information, such as blog posts, reports, etc.  Some are very clear on the aperture; "..we saw this once, on one customer's infrastructure..."; here's a great example from Carbon Black.  With the annual reports that company's publish, we have to keep aperture in mind, as well.  For example, a number of years ago, a friend of mind worked at a company where a majority of the work they did was PFI response investigations; keeping that in mind, what they shared in their annual report was cast in a different light.  In that sense, the report clearly didn't cover even a small minority of the available connected systems, and those engagements that were discussed were, for the most part, somewhat specific.

As we engage and develop our understanding, this is something to keep in mind. 

No comments:

Post a Comment