Saturday, March 03, 2012

Immediate Response

Having recently posted on counter-forensics, I wanted to use that as a means for illustrating the need for immediate response.  As discussed previously, one way to address the use of counter-forensics techniques or measures is by having knowledgeable analysts available.  Another way to address these measures, particularly when you include the activities of an operating system and it's applications over time as a counter-forensics measure, is through the use of immediate response, particularly by knowledgeable responders.  Immediate response is something I've thought about a lot, and feel strongly enough about that it consumes an entire chapter of WFAT3e

The use, and understanding, of counter-forensics measures is where an immediate response capability comes in...the sooner you detect and respond to something 'unusual', the more likely you are to be able to access and recover pertinent data.  Why is that?  Well, as we've said, computer systems are very active things, even when all we can see is a nice desktop with the mouse pointer just sitting there.  Of all of the systems, Windows are probably the most active, with a considerable amount of activity going on under the hood.  What this means is that anything that's deleted (cookies, Event Log records, files, etc.), and those sectors are available for re-allocation, will likely fall victim to the 'counter-forensics' measures "built into" the operating system.

What am I talking about?  Anyone remember Windows XP?  What happens, by default, every 24 hours on a Windows XP system?  A Restore Point is created...and that can be a LOT of new files being created and lot of previously unallocated sectors being consumed.  As new files are created, older ones may be deleted.  And then every three days, there's a limited defrag that runs.  Windows 7 is subject to similar activity...and in some cases, more so.  Windows 7 ships with a LOT of default Scheduled Tasks that do things like backup the main Registry hives every 10 days, consuming previously unallocated sectors.  When you edit MSOffice files, temporary copies of the files are created, consuming previously-unallocated sectors, and then the temp file is 'deleted' when you close the application.  As such, there's a lot that goes on on a Windows system that we don't even see or even think about.  How about Windows Updates?  Do you use iTunes or QuickTime?  When those applications are installed, a Scheduled Task is created to run on a regular basis to look for updates, and these can be installed automatically. 

As such, the key to a modern response capability, beyond having knowledgeable responders and analysts, is to maintain a proactive security posture the employs early detection and immediate response.  One way to achieve both is through the use of Carbon Black.  (For the sake of full disclosure, I should tell you that my employer is a Cb reseller, but anyone who's followed my blog or read my books knows that my endorsement of Cb predates my current employment.)  Cb is a tool that can be used to solve a lot of problems, but from the perspective of early detection and immediate response, it's invaluable.  From a detection perspective, once you have Cb up and running in your enterprise (before an incident occurs, hence 'proactive security'), you can issue queries on a regular basis that look for the execution of 'new' (haven't been seen before) applications.  Remember the counter-forensics techniques previously mentioned in this post?  The technique itself requires code to be run, meaning that something has to execute, something that Cb can detect and report on.  Or, you may detect an incident through other means...log monitoring, user notification, etc., and Cb can be used to quickly gather more information about the incident, allowing an analyst to drill down into things like parent processes (from where did the malware originate?), file modifications (which files did the malware write to?), etc.  Once IOCs have been identified, scoping can take place quickly, from a central location, allowing analysts to determine how many of the monitored systems are affected, and then execute immediate actions in response to the incident.

The alternative (and in many cases, currently employed) approach is to, once an event has been identified, provide incomplete information to senior management, so that they can begin shopping around for a consulting firm that provides response services.  While this is going on, we would hope that no one is doing anything on the systems (this isn't often the case) in question, but as we know, as time passes, things do happen all on their own.  When a response firm is finally selected, additional time is required for contract negotiations, the responders need to travel on-site, and then they need to begin working with you to understand your infrastructure and scope the incident...all while data is (potentially, probably, most likely) leaving your infrastructure.

Consider your organization subject to any compliance regulations or legislature?  Many that are have little choice in notification reporting...if you cannot explicitly show which records were exposed, you have to report on ALL records that were potentially exposed.  Which would you rather on the records that were exposed, or report on all records that may potentially have been exposed (because you don't know)? 

After all, "knowing is half the battle!"  Did you see what I did there, with the quote, and the "GI Joe" image?  This also serves another of the things that military folks are trained in is "immediate actions"...stuff that you're trained over and over in, so that when the situation arises for you to use that skill, your response is immediate and instinctual, based on muscle memory.  That same concept can be easily applied to the need for immediate incident response, as well.  Many security events can be quickly investigated and either deemed non-events, or escalated for a more thorough investigation.  Why is it that many organizations simply wipe a system on which suspicious activity has occurred, and reload the operating system?  Because it's the easiest thing to do...they have the installation media right there.  It's their "immediate action".  So, what if you were able to replace that with a new immediate action...pre-stage the necessary tools for dumping memory and acquiring an image, and providing the training so that it becomes easy to do? summary, on the surface, counter-forensics techniques may appear to pose significant challenges for analysts, but the fact is that many of those challenges can be overcome through early detection, and immediate response by knowledgeable analysts and responders.  The more pertinent information that is available to responders and analysts through early detection will significantly impact that immediate response, taking you from "something happened on a bunch of systems" to "this is what happened, and only these systems were affected", drastically reducing the impact of an incident to your infrastructure.


Dave Nelson said...

You're persistant support of Carbon Black is admirable however there are much better alternatives such as Triumfant. I'm huge fan of the creative diversity derived from new minds attacking security problems however, after analysis of CB, it falls well short of your many praises in offering a solution to the client space it's attempting to monitor. Yes I have used CB. No I don't have any affiliation with Triumfant. I think your readers deserve a more unbiased view of CB.

www triumfant com

H. Carvey said...


I've used Triumfant before, and based on that experience, I prefer Cb. I felt that as an incident responder, Triumfant provided too much extraneous information, the user interface was difficult to navigate and didn't provide me the information I needed in a clear, concise manner.

"... it falls well short of your many praises in offering a solution to the client space it's attempting to monitor.

Can you elaborate on this?


Anonymous said...

Sounds as if immediate response would lead to a rather high rate of false positives: if an immediate response team is called in for every dubious support desk case, or minor policy infraction (a non-standard USB device being connected, non-white listed software being run, single-occurrence AV alarms, etc.) No doubt such policy would catch the real crasckers, but ... at what cost? What rate of false positives to true bills?

It may be appropriate in situations where there is an extreme damage cost associated with a successful intrusion ... but in more normal cases the bill for for all these immediate response calls would be very difficult to defend.

H. Carvey said...


If employed in the manner that you've described, then yes, there would likely be high number of false positives. However, as I've mentioned previously in this blog, as well as in WFAT 3e, this immediate response capability is not something that you'd "call in", as it would be organic to your organization. Training, provided with the assistance of a trusted adviser and brought on by senior managements recognition of the threat environment, would inherently obviate many of the false positives you mention.

Also, I think that the reference to immediate response that you appear to apply in this case takes the term and function out of context with respect to the blog post. As I mentioned in the blog post, the need for an immediate response capability is due to the fact that the vast majority of organizations I, and others, have responded to have become aware of an incident and sat back and done nothing to help themselves. Essentially, they've found out that they may be bleeding and are waiting for a surgeon to assist them, instead of finding from where they're bleeding and taking immediate steps to assist themselves.

You're correct in your comment that this is not a capability that would be required for every little event that occurred within an organization. In the sense that you've described, you're correct that it just doesn't make sense...which is why I do not recommend that this capability be developed or employed in that manner.

Thank you for your insight.