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 this...is 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 do...report 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 purpose...one 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?
So...in 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.
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 this...is 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 do...report 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 purpose...one 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?So...in 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.