Changing the Face of IR

Major corporations handle our sensitive data...referred to as PII, PHI, PCI. Sometimes, they don't do such a great job of securing and protecting that data. The Dept of Veterans Affairs. TJX. World Bank. IMF. The list goes on. Data breaches happen...there's no question about that. If they didn't, guys and gals like me would be out of jobs.

Historically, the stimulus for change with respect to infosec (particularly with respect to IR) has been external to organizations. An attack or major breach stimulates some change, but its not long lived...once the panic wears off, executive management fails to see ROI from the resources that were suddenly (re: knee-jerk reaction) invested. According to Richard Bejtlich and others, there is no ROI from security...not directly anyway.

Legislation and regulation...with consequences...has a more lasting effect. Visa's PCI defines "compliance", which while not being what most of would consider "security", is at least a step in right direction. There are other regulatory/oversight bodies that provide their own guidelines...NCUA, HIPAA, etc. Section 748.2 of the NCUA Regulations provides guidance on "response programs". The PCI DSS (paragraph 12.9) provides compliance standards for an incident response plan.

Every organization with employees has a payroll process. Why? Well, without it, employees wouldn't get paid, and we all know that the CEO has to get paid, right? And oh, yeah...if you don't pay your employees, they don't come to work...you know where this one is heading. Many organizations have disaster recovery and business continuity plans, backup systems, etc. But why do some organizations not have computer security incident response plans, even when some regulatory body tells them that they need to have one?

Regulatory body definitions of "sensitive data" aside, what about corporations that loose intellectual property (IP)? Did you read this 12 Nov article in USAToday (additional commentary on the story at TaoSecurity)? Many organizations subsist primarily on their IP...remember Ira Winkler's Corporate Espionage?

The Verizon Business Security group put together some interesting statistics in their 2008 Data Breach Investigations Report; for example:

83% of attacks were not "highly difficult" (re: low-hanging fruit)
85% of attacks were opportunistic (re: "hey, look...someone left their keys in their car...")
87% of attacks could have been avoided with reasonable security controls
66% of breaches involved data the victim did not know was on the system

Perhaps one of the most interesting and revealing statistics was that reportedly 75% of breaches were not discovered by the victim. What this means is that data from within those organizations network infrastructure was compromised and exposed, and the breached organization had no idea until someone told them.

So, if its not enough that some regulatory oversight body requires you to have an incident response plan, how about the inevitability of an incident occurring? What's it gonna take for organizations to plan for an incident occurring, rather than reacting (poorly) after one has occurred? Oddly enough, any change in this regard with have nothing whatsoever to do with the victim "doing the right thing", and has everything to do with legislation and regulatory oversight.

IR Preparedness

As a responder, I often hear two reasons for folks calling for help after a breach has occurred (aside from the rather obvious one, that is) - the caller either wants to be sure that they're performing "due diligence", or they're interested in bringing in a disinterested third party to have a look at things.

Every now and then when I get a chance to sit back and reflect, something strikes me. Most often those things were right there in front of me all along, and I just never noticed them. Things like these reasons that people give me.

Take for example the reason of "due diligence". It occurs to me that if someone were really interested in performing due diligence, they would've called me before the incident occurred, to ensure that they were prepared to handle an incident. Closing the barn door and shutting the stall doors after the horse has left is not "due diligence".

What about the "disinterested third party"? If you call a consulting company to come help you contain and recover from an incident, the fact that you're paying them obviates the "disinterested" part of the description, doesn't it?

Many times, folks at an organization looking for assistance after an incident has been detected will say that they want an outside firm to handle the examination in case the issue ends up going to court. But what's the real difference between the victim organization performing the investigation and an outside firm doing so? The outside firm most often has a documented process, or at the very least documents what they did in their report.

The primary reason that consulting companies are called when an incident occurs is that the organization was simply unprepared for an incident. Regardless of legislative or regulatory requirements, they're simply unprepared.

This is not to say that when an incident occurs, you should not call someone for assistance. Rather, I'm reiterating my response from the SANS Forensic Summit panel when Rob Lee asked the panel members about response time to a call...my response was that the best time to call someone for help is before an incident occurs. At the very least, you can protect your organization by demonstrating due diligence.

Costs of not being prepared
Fines - legislative/regulatory oversight often comes with some kind of fine
Notification - writing and mailing letters is going to cost time and money
Charges - 20,000 Visa credit card numbers are exposed...who's going to pay for the cost of reissuing all of those credit cards? You get three guesses, and none of the answers are "Visa" or "the card holder". And two of your guesses don't count.
Suits - Civil suits have been brought against organizations as a result of a breach; just defending yourself is expensive

Something very important to remember about regulatory requirements is that in many cases, unless you're able to definitively identify the data that was exposed, you may have to notify on ALL data that could potentially have been exposed. So, if the database containing 6 million records was compromised, and you were not prepared for an incident, and you think that only 23,000 records were exposed...but you don't know for sure...guess how many people you're going to have to notify? You get three guesses, and the first two don't count.

Benefits of Incident Preparedness
Compliance - with legislative and regulatory requirements
Lower overall cost - the upfront cost of doing nothing is...nothing; in the long run, however, costs mount.
Confidence - from your Board of Directors and the consumer (b/c you're demonstrating "due diligence")

As long as we use IT assets to conduct business, and as long a people are part of the process, there will always be a need for incident response. Incidents are always going to occur, without question. The difference today (and tomorrow) is if you're going to be prepared for an incident...or not.

Yet another way to use RegRipper

The other day, John McCash sent me an email that said the following (posted with permission):

I figured out how to make Encase switch the current working directory for the viewer and like it. The command line "/c cd /d D:\regripper&rip -r [file] -f all&pause", using "C:\WINDOWS\system32\cmd.exe" as the application path, works just dandy in the file viewer configuration.

What John's done is launch rip.exe as an EnCase file viewer. Now, I'm not sure why you'd want to use "D:\regripper&rip", and to be honest, I usually don't use file viewers in EnCase, but hey, John, if that works for you, more power to ya! Git 'er done! ;-)

New Code Posted

I posted JT's deleted.zip code to the RegRipper site this morning...go to Downloads, click on RegRipper, and you'll see the zipped archive listed there. The forums are down at the moment so I'll post the simplest usage her...simply unzip the archive into a directory and use the command line:

C:\tools>deleted.pl path_to_hive_file

It's that easy.

Addendum: No, this is NOT a RegRipper plugin...this is JT's code which is completely separate from RegRipper.

Rootkit Detection For Free

During an engagement not long ago, the customer's IT staff had collected bits of the suspect network traffic, and then using the source IP address from the capture, located the system in question and ran "netstat -ano" on the system to prove that the traffic really did originate from that system. Task Manager and tasklist.exe also showed the process with the PID seen in the netstat output.

What does this have to do with rootkits? Well, for one...it proves that they didn't have one! I can't tell you the number of times someone's said to me, "I didn't see anything suspicious, so it must be a rootkit." Yeah, and if I turn my face toward the monitor and close my eyes, and don't see any unusual processes (or anything else for that matter), does that mean that there must be a rootkit on the system?

Well, all I can say is that the simplicity of that finding made it all the more awesome...

More Deleted Keys Goodness!

I was performing some analysis recently, and ran across some real analysis goodness.

First off, I was using my usual tools to parse and analyze Windows Event Logs, and was getting a warning that some of the logs were corrupted. First, the auditpol RegRipper plugin made it clear what was being audited and logged on the system I was analyzing, and then the evtrpt tool was providing me with statistics about the total number of event records, frequency of event IDs and sources, and the date range of all event records. All of this information can give an analyst considerable insight into the content of the Event Logs before I even open them. At that point, I used a modified version of evt2xls to parse the Event Logs into Excel spreadsheet format, and then performed my analysis. Note: EventID.net is an excellent resource to have handy when doing this sort of analysis, and well worth the annual subscription fee.

So, in the Security Event Log on one system, I saw that a user account had been used to create, modify (i.e., add that account to the Local Adminstrators group), and then delete that user account. Of course, the account had been deleted, but I found no other indications that the account had even existed (user profile, etc.), not even in the SAM Registry hive file. So I pulled out JT's code and ran it against the hive file, and presto! There was the deleted key, extracted from unallocated space within the hive file, and I two source of time data with which I could correlate the events.

In another Security Event Log, from another system, I could see where a user account was accessing the Service Control Manager on a system repeatedly, starting and stopping the PSExeSVC service. However, the System hive file from that host showed no indications of the service...until I ran JT's code on it! Again, I had timestamped data from the Event Log that I could then correlate with the LastWrite time from the deleted Registry key.

I have to say that JT did a great job with her code, which she put together as part of her master's thesis from the University of Liverpool. At her request, I will be posting her code to RegRipper.net, and including it in and along with the second edition of Windows Forensic Analysis.

While we're on the subject of the Registry, a good friend of mine contacted me last week with an issue. Apparently, he was working on an examination in which a key factor of the case was determining if and when the user had uninstalled Firefox. According to him, "...install and uninstall dates of programs are of great interest. This will also show destruction of evidence and add additional charges to cases. It also increases sentences sometime by 2x." To help him out, I wrote a plugin that would parse the default browser information from the Registry, but then I compiled the (as-yet-unreleased, still-private, not-even-in-beta) ripxp code, which he used, said that it worked like a champ!

All in all, this is very cool, truly awesome stuff! While this sort of thing doesn't solve every problem, it does add an entirely new capability to the analyst's toolkit, providing answers to new (and in some cases, as yet unasked) questions!