Catching up...

Just trying to catch up a bit...

Matt's really clicking along down at F-Response.com...he's posted yet another example of using F-Response to access a running, live Exchange server, this time incorporating Nuix desktop. I've gotta say, if you don't know anything at all about F-Response, you're already late to the party. F-Response has completely changed the face of incident response, and its utility grows by leaps and bounds every day...not because Matt does anything like release an update, but because more people become familiar with it, use it, and see how absolutely fantastic it is as a tool.

Didier found out recently that theVigenere encryption used in the UserAssist keys in Window 7 are only to be used in the beta, and the "encryption" method for the final version is going to go back to good ol' ROT-13!

Lance Mueller posted recently about using a Perl module I wrote for parsing Windows Event Logs (.evt, NOT .evtx). I use this quite often myself, and the version of the module that Lance and Mark McKinnon mentioned is different from what's being included on the DVD that will ship with the second edition of Windows Forensic Analysis. I recently used one of the tools that comes with the evt2xls tools called evtrpt to give me the frequency of event records listing, as well as the date range of the records; this way, I could see if the Event Logs contained records within the date range. I also noticed that the Security Event Log was 512Kb, but there were no records...not surprising since RegRipper told me that auditing had been disabled.

Speaking of RegRipper, over on the ForensicIR blog, Hogfly posted about using RegRipper and some of the things he's used it to extract, such as user/group information, firewall configuration, etc. One of the things I am reminded of each time I use RegRipper is how powerful it really is, in part through its flexibility.

Moyix has posted code updates for the Registry modules he created, and over on ForensicZone, there's a post showing how to use the modules to decrypt the passwords extracted from a memory dump.

Speaking of memory, I ran across Gustavo Duarte's blog recently, and I'm STILL reading some of the posts! I have to say, the pictures drew me to it, but the content keeps me coming back!

For those interested in information about how time stamp data can be and is used in forensics, check out the TimeForensics site for some good papers.

Here's a great PDF that addresses issues with U3 devices.

RegRipper goes international!

RegRipper was highlighted recently in com!, a German computer magazine. The edition cover is here, and RegRipper is mentioned in the article entitled, "Die besten FBI-Utilities".

Can anyone provide an English translation of what they said about RegRipper? Danke!

In face of Conficker, the crowd...

...rushes to lynch MS.

Ugh. My inbox was hammered today (okay, truth be told...I got like 2 emails...) with the news that USCERT had found that MS's recommendations for disabling AutoRun/AutoPlay functionality, to protect systems in the face of Conficker infections, fell short and just didn't work.

So I was reading USCERT Alert TA09-020A this morning, and the first thing I noticed was that it was dated 20 Jan 2009. Interestingly enough, I'd blogged about this on 5 Dec 2008.

The next thing I noticed was that the Overview statement clearly said that MS's recommendations were "not fully effective", and then went on to describe why...and then buried way down at the bottom of the alert was the update (presumably from 21 Jan 2009) that mentions MS KB953252.

What's funny is that ComputerWorld jumped on the bandwagon...but the absence of any mention of the update to the USCERT alert was glaringly obvious.

This must be that Fog of War that my instructors always talked about...it looks to me as if in the battle against Conficker/Downadup, a bunch of the folks that should be helping and working together are content to point out each others faults. It's also interesting to me that while USCERT and ComputerWorld are busy pointing out MS's flaws, who's helping customers who should've patched against MS08-067 back in October or November? Oh, wait...that's folks like me... ;-)

Windows 7 Beta

It's probably kind of early to go posting about Windows 7...yes, the beta is out, but it will likely be a while before we start seeing widespread use of it. As an incident responder who deals primarily with corporations, I see a lot of XP and Windows 2003, but so far, no Vista.

So, like many, when the Windows 7 Ultimate Beta hit the streets, I started taking a look at it. As many would expect, and as Matthieu found out, things have changed in memory. Didier also found out that things changed with respect to how the UserAssist key entries are "encrypted"...rather than being ROT-13 encrypted, the value names are now Vigenere encrypted. Didier was able to determine the cipher key for his system; apparently, the same key is used across all installations!

Okay, let's hold up for just a second...why are these value names even encrypted? I mean, honestly, what's the point? Look at most of the value names, and no one knows what they mean when they aren't encrypted!

All right then...what were we talking about? Oh, yeah...so Didier did a fantastic job of figuring out what was going on with the new encryption scheme. He also figured out some of the new elements stored in the binary data. So using this information, I located some code on PerlMonks to decrypt strings using the Vigenere cipher; I then tweaked it to include handling special characters, numbers and letters that were capitalized. I added parsing of the data in the way that Didier described, and then logged into my Windows 7 Ultimate Beta VM and did some stuff (updated Defender, launched Solitaire, and opened a command prompt and ran ftp.exe). I then shut off the VM, pulled out the NTUSER.DAT and ran it through the new RegRipper plugin I'd just written, and got some really interesting stuff, a portion of which is shown below:

C:\Program Files\Windows Defender\MSASCui.exe
Last Run = 0
C:\Program Files\Internet Explorer\iexplore.exe
Last Run = Wed Jan 21 18:53:28 2009
C:\Program Files\Microsoft Games\solitaire\solitaire.exe
Last Run = Wed Jan 21 19:03:09 2009
C:\Windows\system32\cmd.exe
Last Run = Wed Jan 21 19:04:14 2009

This is just a partially-redacted (redaction much more effective than what either MS or Adobe has used in the past...) excerpt of the output, and I'll get with Didier to see about further testing and verification, but so far, so good, it seems.

One thing that hasn't changed is that F-Response works like a champ with Windows 7, as Matt found out and blogged about. Even access to physical memory works! Don't be the last on your block to get your copy of F-Response!

New and interesting things

A couple of very interesting things have come about lately; in particular, Brendan has released some new Volatility modules for extracting Registry hives from memory dumps! Very cool stuff! From his post, not only has Brendan done a fantastic job extracting the data, but he's looking ahead to integrating RegRipper into this in order to perform analysis!

Also, don't forget about Brendan's moddump.py and threadqueues.py modules!

Matt Shannon introduced me to Peter Mercer yesterday, and pointed me toward Intella, which looks like a fantastic product. Peter also mentioned the tool here (holy GUI, Batman!), and looking at it's capabilities, it's not just a PST/NSF file parser.

Over on the Security Ripcord blog, Don Weber has worked up a variant of Yara called "Scout Sniper"...if you know or have met Don, that makes complete and total sense. Don's some great work with the tool, you should definitely take a look.

In addition to Intella, I will be taking a look at a couple of other tools shortly. John Sawyer commented on one of my blog posts, which includes a press release from HBGary about their FastDump Pro tool that you should really take a look at.

WFA 2/e Status

I wanted to let everyone know that since October, I've been working on the second edition of this book, and I'm almost done with the initial rewrites. I'm finishing up chapter 4, Registry Analysis, now, and this is the last chapter that needs to go to the tech editor. Once this chapter has been sent off, I'll be going back to chapter 1 and addressing the tech editor's comments...the next stop is the publisher!

What's changed...a good deal of the original information is still in the book, but has been added to and in many cases expanded and brought up to date. For example, the binary structure of Registry hives and PE files haven't changed, so there's no reason to take any of that information out of the book...it's still pertinent. However, new tools are available, new techniques have been developed, and I've tried to highlight that in the additional information. In chapter 4, I focus primarily on RegRipper and rip.pl, rather than standalone scripts and tools. The standalone scripts and tools are still there, though...I moved them to another directory on the DVD.

I've also added two new chapters, not based on any specific requests, but rather upon things I've seen over time. Chapter 8 is "Tying It All Together", where I try to illustrate incidents I and others have responded to (in general terms, of course), and show how information from different chapters in the book get pulled together and correlated to create an overall picture of the incident or examination. Chapter 9 discusses getting a great deal of analysis capability out of freely available (in some cases, low cost) tools...the vast majority (albeit not all) of the tools discussed in this chapter were not brought up anywhere else in the book.

This time around, I've included more information about Vista, and while the recent release of Windows 7 Beta makes it too soon to really be included in the book, it does open the door for a third edition. ;-) Some other things that are on the DVD that accompanies the book (besides tools and other items referenced in the chapters) will be a number of PDFs I've written up over the past year or so to act as training manuals...each PDF addresses a single topic and is short enough to print out and take on a plane with you, or simply read at your leisure. I'm also including a document that shows, in detail, how to deploy F-Response EE remotely, and what physical memory from the remote system "looks like" to the analysis system.

From what the publisher tells me, this book should be out by May/June of this year, although it is already up on Amazon for pre-order.

Windows 7 Beta Registry

I've seen recently how folks have gotten access to the Windows 7 Beta for download from Microsoft, and being interested, I jumped right up on that bandwagon. I mean, from a forensic perspective, this "Jump List" thing is just going to be a gold mine for an analyst, much like RecentDocs and UserAssist keys have been since Windows 2000. Wikipedia has a nice write-up, and I look at all the great usability stuff that's talked about and all I can think of is "artifacts". ;-)

So, I took a look around to see if anyone was trying to install Windows 7 Beta into VMWare, and I ran across a Windows 7 Beta VM at TuxDistro. I fired up BitTorrent and downloaded the zipped archive, and then unzipped the VMDK file, and opened it in FTK Imager. Now, I saw a "Documents and Settings" directory, and a "Users" directory...so was this REALLY Windows 7?

Well, one question I heard a LOT when Vista came out was "what changed?" Was the Registry different enough that all of our current tools no longer worked? So, there's one way to find out! I dumped the hive files out of the VMDK file from their usual locations, including one called "Components". So I wanted to see if my tools worked, so I fired up rip.pl to see what I was working with:

C:\Perl\forensics\rr>rip.pl -r d:\cases\win7\software -p winnt_cv
Plugins Dir = C:\Perl\forensics\rr\plugins/
Launching winnt_cv v.20080609
WinNT_CV
Microsoft\Windows NT\CurrentVersion
LastWrite Time Fri Dec 12 18:26:31 2008 (UTC)

RegisteredOrganization :
CurrentVersion : 6.1
CurrentBuild : 6956
CurrentBuildNumber : 6956
SoftwareType : System
InstallationType : Client
EditionID : Ultimate
SystemRoot : C:\Windows
PathName : C:\Windows
ProductName : Windows 7 Ultimate
CurrentType : Multiprocessor Free
ProductId : 00428-015-8630506-70665
BuildLab : 6956.winmain.081122-1150
InstallDate : Fri Dec 12 20:52:50 2008 (UTC)
BuildLabEx : 6956.0.x86fre.winmain.081122-1150

Very cool! Not only do the tools seem to work just fine, but it looks as if the VMDK is a Windows 7 Beta VM. Very nice. Other plugins, such as samparse, seemed to work just fine, but parsing the UserAssist key in the NTUSER.DAT file was problematic...the "normal" GUID key didn't seem to be in the hive.

So, it would seem that the binary format of the Windows 7 (the Beta, anyway) Registry hive files has not changed. I'm sure that the content has, as keys have changed names and functionality, and values and ways of recording data have changed. However, as with the move from Windows 2000 to XP, there may simply be more opportunities for forensic analysts. I'll be interested to see who writes some of the first RegRipper plugins specific to Windows 7.

Got your YARA??

I ran across an interesting post yesterday on the Offensive Computing blog about YARA, a malware ID and classification framework. Interestingly enough, it ships for Linux, Windows, and as a version you can run via Python. The user manual that's available with YARA is short enough to be a quick read, and clear enough to give you a pretty good idea of how to get started using it.

Is anyone using it? How are you using it? The interesting thing is that YARA seems to use almost Snort-like rules for classifying files, which intuitively leads to some pretty incredible flexibility. For example, perhaps with some more detail as to where to look in files for some of these "signatures" and what different values can mean, YARA looks like a very good way to get one step ahead of AV products, even though we'd still be one step behind the malware itself. What a lot of folks are seeing these days is that their commercial grade AV products are capable of protecting themselves from variants A through F of a particular piece of malware, but then they get hit with variant G, or AB.

While YARA won't quarantine or delete the malware, it will help you classify it.

Another means of using YARA would be in conjuction with some of the new modules for Volatility that allow you to extract executable images from memory dumps. Extract the image, create a signature, and share it. You never know who else is using Volatility (or any of the other memory analysis tools) that may run across something similar.

Finally, I thought about perhaps turning YARA around and using it as means of going beyond file hashes. It's very hard to keep up with the latest versions of file hashes, particularly when so many things can change when MS releases patches. Using YARA, perhaps we can extend file signature analysis, and use this to perform data reduction...instead of asking for all "bad files" and relying on a perhaps incomplete list of rules, we could ask for all "good files" and then look at what's left over...

Thoughts?

Addendum: It looks like Jamie over at Mandiant is going to be doing something similar to Yara with Memoryze, by adding the ability to use Snort rules to detect malware in memory. Speaking of malware analysis, check out ZeroWine...this looks REALLY cool!

Solving problems with Perl

Many times, some problems just don't seem to have an obvious or easy solution. Take for instance some of the more recent malware to be seen, like Conficker (...and a rose by any other name would smell as sweet...)...it gets on your network, but initially isn't detected. That's because your AV product protects you from variants A through D, and what you've got on your network is a variant somewhere between F and P. Or let's just say you want to see if you do have something unusual on one of your systems. How would you do this?

Well, there are a number of ways you can do this, but if you look at the descriptions available for the Conficker malware, one of the commonalities you see is that it creates a Windows Service with a random name, which means that you can't just search for "Conficker" and hope to find it. Then the malware creates an ImagePath value that points to "svchost.exe -k netsvcs", which runs it when the system starts, but runs it as System level privileges. Also, note that a LOT of Services start this way, too. Then the malware creates a Parameters\ServiceDll value name that points to a randomly named DLL.

Interestingly, there's a number of bits of malware that use this same or a similar persistence mechanism. Okay, great. So, besides going to each machine individually, opening RegEdit, and clicking through the GUI, what do you do?

That's where Perl comes in! I ducked inside a telephone booth, pulled out my laptop and found some previously written code that accesses the live Registry in read-only mode. I then opened up one of my RegRipper plugins, grabbed a bit of already-written and -tested code, added it, shook it (one does NOT stir!), and presto! RegScan was born!

So here's what regscan does...you run it on your local system and it accesses the HKLM\System\CurrentControlSet\Services key, gets a list of subkeys, and then goes to each one and gets the LastWrite time, the ImagePath value (if there is one), the Parameters\ServiceDll value (if there is one), sorts everything by LastWrite time, and prints each Service entry on a single line with each element pipe ('|') separated. Okay, take a breath.

You run regscan like so:

C:\>regscan.pl

And you get a bunch of stuff like this:

Sat Jan 3 00:34:43 2009Z|WebClient|%SystemRoot%\system3\svchost.exe -k LocalService|%SystemRoot%\System32\webclnt.dll
Sat Jan 3 00:34:43 2009Z|winachsf|system32\DRIVERS\HSX_CNXT.sys||
Sat Jan 3 00:34:43 2009Z|Windows Workflow Foundation 3.0.0.0|||
Sat Jan 3 00:34:43 2009Z|winmgmt|%systemroot%\system32\svchost.exe -k netsvcs|%SystemRoot%\system32\wbem\WMIsvc.dll
Sat Jan 3 00:34:43 2009Z|Winsock||


Uh...okay. Well, this is command line, so to weed out some of the stuff you aren't interested in, you could type:

C:\>regscan.pl | find "svchost.exe -k netsvcs"

But wait...there's more! If you want to access remote systems (that you have admin access to, such as in your lab or in your corporate infrastructure), just type:

C:\>regscan.pl IP_address

...or...

C:\>regscan.pl System_name

Pretty cool, eh? And no, you don't need to have Perl running on the remote system. And yes, I've 'compiled' it into an EXE w/ Perl2Exe. And yes, it'll be included on the media that accompanies WFA 2/e. Oh, and it's also available for download at the RegRipper site, in the Downloads section. Enjoy!

Memory Collection and Analysis Tools

Recently, there was a post on the SANS Forensics blog about memory collection and analysis tools, but for some reason, it seems that folks are STILL having trouble with this process; I'm seeing posts in forums (forii??) saying that "...this tool doesn't work..." or "...that tool crashed when I tried to use it...". My suspicion is that the tools aren't being used correctly as folks may not understand their limitations.

Collection
I tend to separate collection and analysis...I've found that it's better to do each one right separately than it is to try to do both at the same time and split your resources.

XP/2003
There are a number of tools that allow for collection of physical memory on Windows XP and 2003 systems. The first and perhaps best known was a version of dd.exe modified by George M. Garner, Jr. This tool is no longer available, but it was used as the exemplar tool for collecting physical memory for the DFRWS 2005 Memory Challenge. Another tool is dcfldd.exe, written by Nick Harbour (currently with Mandiant). However, this blog post is one of several locations where it seems that someone's discovered that attempting to dump the \\.\PhysicalMemory object doesn't work, but dumping /dev/mem (yes, on Windows) appears to have an affect. Nigilant32 is a GUI-based tool that you can use to dump the contents of RAM, as well.

These tools are also available on the Helix CD. In addition, HBGary released their fastdump tool for dumping physical memory.

The delineation mark for the tools came with Windows 2003 SP1, as that's when MS removed user-mode access to the PhysicalMemory object. This, in turn, required a change in tools to collect physical memory.

2003 SP1 and Above
The tools used to collect the contents of physical memory for Windows 2003 SP1 and above (Vista) systems can also be used on XP and 2003 systems.

The first tool available to dump (and analyze) the contents of Physical Memory from Windows 2003 SP1 systems and above was the KntTools from George M. Garner, Jr. Then came ManTech's MDD, Matthieu Suiche's win32dd, GSI's winen (and winen64, for 64-bit systems), and Mandiant's Memoryze. All of these are great tools, but like any tool, each has it's strengths and weaknesses.

For example, right on the main page for the MDD tool, it states, "The software can copy up to 4 GB of memory to a file for later analysis." I'll leave it to smarter folks to tell you why, but I think that most tools have this same limitation. Matthieu's win32dd will dump memory in a raw, dd-style format as well as a crash dump-compatible format in case you'd like to use MS Debugger tools to analyze the dump. GSI's winen dumps memory in the EWF-style format (requires additional support for most tools to analyze). While most of the other tools download as an EXE, Memoryze downloads as an MSI file, and creates quite a footprint on the system.

One tool that must be mentioned here is F-Response. By itself, F-Response does not provide the capability to dump the contents of physical memory, but the most recent version of F-Response provides you with remote, read-only access to physical memory on Windows systems; you can then use tools like FTK Imager, or any other acquisition tool (dd.exe, dcfldd.exe, etc.) to acquire your memory dump. The figure I've posted here shows what physical memory on a remote system "looks like" on your investigation system...in this example, it shows up as \\.\PhysicalDrive2, and can be accessed by tools such as FTK Imager. Go here to see how to install F-Response EE remotely on Windows systems.

All of these tools work best if tested and deployed before an incident occurs, before the tool itself is actually needed. Tools such as mdd.exe and win32dd.exe can be deployed on CD or a thumb drive, and F-Response can be deployed remotely (even in stealth mode) over the network, allowing you to accelerate your response.

Note: I don't want to leave out hibernation files. While I don't recommend hibernating a system as the default process for collecting the contents of physical memory, there may be times when its the only option. For example, if a system already has a hibernation file on it, IMHO, I'd prefer to use that file for historical analysis, to establish or validate a timeline of activity on the system. However, if the system is capable of hibernating, there may be times when forcing the system to hibernate may be the only way to collect the contents of physical memory. You can use powercfg.exe to configure the system to hibernate, and then use run32dll.exe to force it to hibernate.

Analysis
There are some frameworks available that provide a means of analysis on memory dumps from several versions of Windows, such as Andreas's PTFinder Collection. Andreas's Perl scripts are primarily used to list processes (and pool tags) from within Windows memory dumps.

About the only tools I can think of that provide more than what Andreas's scripts provide for analyzing Windows 2000 memory dumps are my own scripts, which are still available on SourceForge, as well as on the Windows Forensic Analysis DVD (and they will be provided on the DVD with the second edition of WFA).

When it comes to analyzing memory dumps from Windows XP SP2 and 3 systems for an incident response perspective, the Volatility Framework is the way to go. Yes, I know it's CLI, requires Python (which is free), but to be honest, this framework gives you unprecedented access to the contents of the memory dump. I say "contents" because not only can you get things like the active process list and active network connections at the time of the dump, but you can also run a linear scan through the dump for exited processes and expired network connections. The DFRWS 2008 Rodeo includes a memory dump you can try this out on. The output of the various commands can be easily redirected to files, and then correlated using Perl or Python scripts (such as vol2html.pl).

Volatility includes the capability of working with hibernation files (incorporating Matthieu's work; note that Matthieu has also released a standalone hibernation shell, in alpha) and crash dump-format memory dumps, in addition to the raw, dd-style format dumps. Also, Volatility is extensible, and others have taken the opportunity to create modules that can be easily installed and used with the framework (ie, Jesse Kornblum's cryptoscan and suspicious modules, and Moyix's Windows message queue module).

Addendum: I've recently seen the release of additional plugins; malfind from MNIN Security, and moddump from Moyix. I've gotta take a look at and try these plugins...man, it's it AWESOME the way Volatility can be extended??

Note: This is one of those places where I have seen folks say, "It doesn't work." As of now, Volatility works on XP SP 2 and 3 memory dumps. Please feel free to try it on other memory dumps, but as a courtesy, please refrain from stating "it doesn't work" (most of us already know that), as well as asking "why doesn't it work?" Thanks!

Mandiant's Memoryze is an XML-based tool that started life as part of the Mandiant Intelligent Response (MIR) product, and will allow you to collect and analyze memory dumps from Windows XP, 2003, and Vista systems. To install Memoryze, download the MSI file and the installation wizard will guide you through the process. Memoryze ships with a number of batch files that make it a bit more user-friendly, and Mandiant also include the Audit Viewer, a wxPython-based GUI tool that makes viewing the output of Memoryze a bit easier. Posts on the M-unition blog that describe how to use and extend Memoryze.

Also, please feel free to use tools such as strings or grep to extract information from memory dump files. However, keep in mind that if these tools are run against the entire dump file, the information you find may be without context. However, using any of the available tools to dump process memory for a memory dump file, and then searching it using strings/grep will provide you with a modicum of context.

It wouldn't be fair of me not to note HBGary's Responder product. I had an opportunity to try out the Responder Pro product a while ago, and found it be very useful for malware analysis. I haven't had an opportunity to try the Field edition.

Characteristics of Effective Incident Response

The Need
There is a need for effective incident response, now more than ever. However, the key to incident response is incident preparedness. Responding without being prepared to respond correctly is what turns an incident into a major data breach and a major embarrassment.

Addendum: If you don't think incidents are going to happen, or that they aren't going to happen to you, take a look at this SecurityFix post from Brian Krebs. To be clear, the very first sentence says "reported"...which perhaps indicates a subset of what was actually detected.

There are three primary characteristics of effective incident response, and knowing and understanding these lead to being better prepared to respond to incidents:

1. Completeness of Data
When I am called to respond to an incident, there are four sources of data I will generally look for, to some degree, regardless of the type of incident:

- Network traffic captures
- Logs from network devices (firewalls, routers, etc.)
- Host-based volatile data
- Host-based non-volatile data

Now, you may not need data from every source for every incident, and the value of the data from these sources may vary depending upon the incident. In all the time I've been doing IR, in various capacities, I can't recall a single time when I've had all four sources of data available...in fact, in most cases, I'm lucky to get one, and it's a miracle to have two.

2. Accuracy of Data
How accurate the data is in many cases can depend upon what it is you're actually trying to do. For example, capturing portions of volatile memory using a batch file and third party tools (ie, tlist.exe, tcpvcon.exe, etc.) to get the list of active processes, network connections, etc., may be accurate enough for your needs. However, in other instances, collecting the full contents of physical memory may be the only means of achieving accuracy (and completeness) of data.

3. Temporal proximity
This is a term I borrowed from Aaron Walters (of Volatility fame), not because it's cool and Star Trek-y sounding, but because it makes perfect sense. The sooner you begin responding to an incident, the more complete and accurate data you're going to get, and your overall response is going to be more effective and lead to better remediation, etc.

Since this field is wrought with analogies, let's try this one...as a homeowner, do you have smoke detectors in your home? How about fire extinguishers? I do. How about insurance? When you called for your insurance, did the insurance company ask how far you are from the nearest hydrant? How about from the nearest fire department? Did you get a home inspection prior to purchasing your home? Is it up to code with respect to exits, etc? Do you know what to do in case of a grease fire in your kitchen?

So, your home is full of valuables, in particular, your family. If your home were to catch fire, what would you do? First off, how would you know? Then, once you knew, what would you do? Would you just wait until the house burned down to call the fire department?

Now, map your home to your network infrastructure, and a fire to a data breach. Where are your valuables? Do you have a detection mechanism? Are you able to respond immediately and correctly to a grease fire?

This example shows, in part, that temporal proximity plays an important role in incident response, but it also highlights the need for approaching it the right way, which may include training. So what does this mean for the coming year? Well, it should mean that training will be more important than ever. Think about it. If a small fire starts in your house, would you (a) wait for an hour, then call the fire department, (b) wait for the house to burn down completely, or (c) begin putting the fire out yourself immediately? With respect to computer security incidents, who is in a better position to respond immediately...the sysadmin who is currently logged into the console, or an responder such as myself who is 24-48 hrs away from being on-site? Not only is the sysadmin there, but she more than likely knows the systems and the architecture very well; an external responder such as myself is going to have to get up to speed on your architecture, and even then won't have all of the little nuances.

This is all fine and good, but as Lon Solomon is fond of saying, "so what?" The fact is that many organizations simply don't put any effort or resources into their response plan because they feel that there's no requirement to do so.

External Forces
I'm not going to make a prediction for the future, but the primary drivers for incident response in 2009 (and beyond) will continue to be external forces; specifically, legislative and regulatory compliance requirements. Why is that? Because they have to be. After all, most of us think that if someone is making a business out of storing and/or processing our sensitive (PII, PHI, PCI) data, then of course they'll do everything they can to protect and secure that data. I mean, why wouldn't they, right? After all, if a buddy wants you to hold $50 for him, or the ring he's going to present his bride at their wedding, then you're going to do everything you can to protect that data, right? For many of us, this is just what we think of as common sense, but that's sadly not the case with your sensitive data. Look here, or here. And things only start to change when some external forces come into play, and those forces are strong enough to act as the stimulus to cause that change...those external forces being legal (think CA SB-1386, etc.) or regulatory compliance (think HIPAA, Visa PCI, etc.) requirements.

First Post of 2009

Just a couple of things for my first post of 2009...

It seems that RegRipper is catching on, if this post about Enhancing RegRipper is any indication. I have some comments on the post, and the author has responded.

Christina has updated the eEvidence site again, just before the New Year...as always, there are some very promising links...

What 2009 holds...
Not resolutions or predictions, but for 2009, I'd like to do more development on RegRipper, as well as integrate all of my tools into a timeline framework, extending the work of others (Brian Carrier w/ TSK, Michael Cloppert w/ ex-tip, etc.)

Work is progressing on WFA 2/e...I'm currently finishing up chapter 3, and once I get that turned in to my editor, I'll try to get some rewrites done, but I still have one chapter...Registry Analysis...still left to do and get in for review.