Perl-Fu: Regexp log file processing

Remember that with Perl the key benefit is the ability to easily implement almost any kind of input/output processing system one might need or conceive, without the need for a lot of code or time in development.  When you are faced with massive amounts of data and a small amount of analytical time, this agility is critical.  I will not be teaching regular expression syntax but there are countless primers and resources on the web for this, and they almost universally apply to languages/interpreters other than Perl, including our favorite command line tool, grep.  Consider the following code:

# Creates user-specific files from a single log file based on the field “User=”
$logfile = $ARGV[0];
open(LOG, "<$logfile") or die "Usage: <filename>\n";
print "Processing $logfile...\n";
while (<LOG>) {
 if (/User\=(\w+)/i) {
 open (USERFILE, ">>$1.$logfile.log");
 print USERFILE $_;
 close USERFILE;
close LOG;

It accepts a log file at the command line (e.g. “ logfile.20090511”) and for each time the string “User=” appears in the file it will initially create and then append to a new log file all the original log entries specific to that username.  For example, if my username in these logs were “mworman”, a file would be created named mworman.logfile20090511.log.  This new file would contain every instance of “User=mworman” as well as any words/strings that appears after it, for every line in the original log file.  I’ve now accomplished multiple things at once:

  • I’ve calculated the unique number of usernames in the file, i.e. the number of new files created.
  • I’ve created a re-usable, “greppable” file for each user, allowing me to perform calculations for any subset of them.  For example I can immediately see which users had the most/least activity based on file sizes, I can use “diff” to compare any subset, etc.
  • I’ve ensured date synchronization between the original log file and the new set of files by re-using the date.  When grinding data down from the petabyte and terabyte levels to something more manageable, this kind of thing becomes really important for maintaining your sanity as well as the integrity of your analysis.
  • I can reuse this code for patterns other than “User=” simply by altering the regular expression.

It may not look like much, but this little script is very useful and is something I wrote to separate the User fields in the logs of a Symantec appliance into a set of user-specific activity files.  Other than the regular expression in the IF statement, this script is very similar to the one I posted a few weeks back.  While one reader correctly pointed out that that script could have been replaced with single grep command (and in most cases, depending on your command line powers this is always possible but not always practical or wise), this script is just as simple but far more powerful and extensible for analytical purposes.  Again, the matching pattern (“User=”) could literally be changed on the fly to any regular expression, including

  • IP addresses:


  • Visa Credit Card Numbers:


  • Valid Social Security Numbers:

(^(?!000)([0-6]\d{2}|7([0-6]\d|7[012]))([ -]?)(?!00)\d\d\3(?!0000)\d{4}$)

What else can we do?  The sky is the limit, folks.  Does the input to this process have to be a static text file?  No, in fact I have a similar script  (barely twice the size of this one) that scans a given list of IP addresses/hostnames and generates a text file with the hostname->Windows username pairs for each system with a currently logged on user (this uses a Perl NetBIOS module available from, your best one-stop repository for Perl development).

Adding simple TCP/IP functionality to scripts like this starts to move us into the area of “banner grabbing” and network scanning, and sure enough, many popular network scanners (e.g. Nessus) began as glorified Perl scripts that iterated pattern matching across lists of network hosts or subnets.

Once you get the basics of Perl and regular expressions down, a trip to will show you just how much re-usable code is out there: modules for everything from Windows to Samba to UNIX to things like

“Provides an interface for turning the front LED on Apple laptops running Linux on and off. The user needs to open /dev/adb and print either ON or OFF to it to turn the led on and off, respectively.”

Whether or not turning the LED on Apple laptops is a forensic necessity is an exercise left to the reader.  Or, maybe someone now sees Perl as an instrument they can use to access and analyze devices in ways they hadn’t thought possible before.  The sky is the limit folks.

A gracious thanks to GCFA Rod Caudle who just reminded me of the the BEST tool for regular expression development (which is really an art of it’s own) I have ever used.  RegexCoach is a tool someone introduced to me years ago and it is priceless for playing with regexps and tweaking them to get the right one you are looking for.  It includes the ability to provide test strings to ensure your regexp matches and will sytax-color portions of the test string that do match, etc, greatly speeding up development time.  Having easily spent more time figuring out complex regular expressions than actually writing Perl code wrapping them, I couldn’t plug this utility enough even though I’d forgotten about it the last ten years or so.   Thanks Rod!

Mike Worman, GCFA Gold #124, GCIA Gold #282, is an incident response, forensics, and information security subject matter expert for an international telecommunications carrier.  He holds a BS in Computer Systems Engineering from the University of Massachusetts, an MS in Information Assurance from Norwich University, and is CISSP-certified.

Forensics and Perl-Fu: Reducing Data and Cleaning Up Log Files

By: Mike Worman

Perl’s simplicity and its raw power may seem paradoxical but this is simply a clever ruse. There is a lot going on behind the scenes when using Perl, which has often been described as the scripting language that attempts to figure out exactly what the developer wants in as little code as possible…and it usually succeeds. Even when it doesn’t, another possible approach is usually immediately apparent. Never forget the Perl motto: TIMTOWTDI!

My pieces won’t dwell on the deeper mysteries of Perl which are way beyond the scope of our blog (or my own brain). My intention is to start small and illustrate how I have been using Perl to meet some very puzzling challenges over the course of my career. Before we start, keep in mind there will always be people that can do what I am doing in a single, complex set of shell commands or command line Perl (using –e). These articles are not for you but if there is an interest in more advanced command line stuff, please let me know.

Consider the following code which is a basic wrapper script I wrote called When dealing with log files, especially large ones, you occasionally run into the “this log file is full of blank lines” problem. The following snippet simply opens a file given on the command line (e.g., C:\ test.txt) or exits with a proper usage message (“Usage: <filename>) if no such file exists. It then opens a second, new file with the name of the first, with “.cleaned.txt” appended. Then, for each line in the old file, it rewrites that same line into the new, clean file, as long as that line is not simply a blank line (signified by a single newline character, “\n”). Finally, the script closes both the old and the new files, ensuring synchronization with the file system.

# Removes blank lines from text logs

open INPUT_FILE, “<$ARGV[0]” or die “Usage: <filename>\n”;
open OUTPUT_FILE, “>$ARGV[0].cleaned.txt”;
while ($line = <INPUT_FILE>) { print OUTPUT_FILE $line unless ($line eq “\n”); }

It may not look like much but I have used very similar code to clean hundreds of cluttered, malformed, and otherwise borked log files full of whitespace and extra lines since the 1990s. For some reason Cisco log files seem to come to mind most prevalently. This script (which works both in Linux and Windows) can form the basis of almost any data processing program you can think up. Instead of creating a new file without blank lines, you could create a new file that contains only certain columns, or certain characters, or certain patterns of characters (regexps) from the old file. To some people this will seem like old hat, but others may see the ramifications. This script can pull a few bits of useful data out of a 1TB file otherwise filled with junk, such as newlines or whitespace. Whitespace in log file processing is a REAL PROBLEM for analytics, especially when that data is moved around in different import/export functions such as those found in Microsoft Excel. The popular “strings” program works in a similar fashion: if I have a 1TB file of binary data, how can I pull out things that resemble ASCII, stuff that a human can actually read and comprehend?

The answer is by going through the file, line by line, attempting to match patterns (regular expressions) that look like ASCII in the same way the short script above goes through a file line by line and builds a brand new file, skipping over lines of data that are not useful or wanted. While the conditional above ($line eq “\n”) is not a standard Perl regular expression, it does the same job: it defines what we want to discard from our working set.

The basic premise here is (and Perl is by no means an exclusive solution to these problems, just a powerful one) that when dealing with very large sets of data, before you even begin analytics you should ask yourself two questions: “Do I need all this data to solve my problems”, and “If not, how can I reduce the size of my working set?”. How these questions are answered can mean worlds of difference in forensics and IR, from whether or not you have the time to complete lengthy keyword searches to whether or not you can afford enough disk space to store the data at all. You will hopefully find, as I have, that Perl is a key solution in dealing with both questions. Perl can help you use data you already have more effectively, and it can help you reduce/modify your data set into a more practical form. More practical translates into faster and more timely searching, faster transfer from point A to point B, less storage requirements, and ultimately, less burnout among IR and forensics professionals.

Mike Worman, GCFA Gold #124, GCIA Gold #282, is an incident response, forensics, and information security subject matter expert for an international telecommunications carrier.  He holds a BS in Computer Systems Engineering from the University of Massachusetts, an MS in Information Assurance from Norwich University, and is CISSP-certified.

Forensics and Perl-Fu

By Michael Worman

Ah Perl. Mysterious and maddening, it lies at the heart of the Internet as well as a million Ways to Do It. I discovered Perl in the mid 90s, before PHP and a lot of the other newfangled dynamic languages for web content. Javascript was a toy back then, and Java barely ran on anything. Graphics and pictures on web browsers were a new thing.

Perl is magical; for any forensic analyst, incident responder, or network ninja, the magic is in its raw ability to rapidly develop systems for processing text in an agile and intuitive manner. Some say that, unlike C++ and Java, learning and using basic Perl is as easy as learning a few words of conversational Spanish or French. This is no accident, as Perl’s inventor Larry Wall is a linguist as well as the creator of one of the world’s most prolific software development platforms. Perl is made to flow from conception to implementation with the minimal amount of overhead. It also happens to have one of the best regular expression interfaces ever invented.

Perl and forensics are an unmistakable perfect fit. Combining a powerful data parser with the ability to rapidly create glue logic between input and output streams, learning and mastering Perl can allow you to pull off some neat tricks.  

  • Using Perl, I was once able to turn a 1.5 Terabyte-per-day data stream into quickly searchable 20MB compressed files, also reducing data storage requirements by 1000% and search times by 10,000%.
  • I once used Perl to create a recursive SNMP-based Perl program that could search an infrastructure of hundreds of network elements (switches/routers) for specific MAC addresses and cached IP information.
  • By continuing to use Perl, one can begin to master (and implement in code) regular expressions, the most fundamental computer function upon which all keyword searching techniques are based.

Indeed, just as Netcat is known as “the Swiss Army Knife of TCP/IP”, Perl is regarded as “the Swiss Army chainsaw of scripting languages”.

You don’t have to be a programmer to learn Perl, but it helps. Perl is without a doubt one of the most approachable of all programming and scripting languages, because of the simplicity with which it meets the immediate needs of the novice developer who just wants “Something Done”. The basics of Perl required to open, analyze, and close files can be taught in a day, as can the basics of writing regular expressions.

Why do we need to understand things like Perl, regexps, and command-line text processing? Because even in today’s environment of integrated software suites and flashy marketing, it is really things like Perl and expression matching and command line basics that fuel most real digital forensics laboratories. At the heart of systems like Encase, FTK, and others are the regular expressions that Perl helped introduce to the Internet. Digging into Perl can be intimidating and so my upcoming articles will be primarily introductory pieces on the (very) basics of Perl and how to “munge” data in ways of interest to forensics or IR professional.

Perl can be found on almost any UNIX or Linux platform.  Learning Perl from the O’Reilly series is a great starter, Programming Perl is considered the canonical “bible” of the language. For Windows users who don’t know where to start, I strongly recommend the free developer kit available from ActiveState.

Mike Worman, GCFA Gold #124, GCIA Gold #282, is an incident response, forensics, and information security subject matter expert for an international telecommunications carrier.  He holds a BS in Computer Systems Engineering from the University of Massachusetts, an MS in Information Assurance from Norwich University, and is CISSP-certified.

Information Ordnance: Logic Bombs, Forensics, and the Tragical History of Roger Duronio

Given the ongoing investigation at Fannie Mae, it seems appropriate to start waxing philosophical a bit on some recent evolutionary changes in the digital forensics world. While it is true a majority of forensics cases revolve around suspected wrongdoing involving a computer (e.g. fraud), using computers and code as weapons themselves crosses into the realm of information warfare. Yet forensic analysts and incident response experts will have to continue to straddle both of these realms in the new millennium, as both fields continue to evolve and in many respects, converge.

I have seen the devastating results of logic bomb “detonation” up close, and I can assure everyone that carefully prepared information weapons are far more damaging than almost any single Trojan, spyware infection, phishing attack, or virus outbreak one might encounter. This makes it all the more important for our community to be able to understand, identify, isolate, and yes, in some cases maybe even disarm such automatons. In most cases, however, our role will probably be to respond, assess, and report on the damage and determine its cause. Before anyone dismisses this as a fancy “blue sky” exercise or pontification of FUD, simply consider the case of Roger Duronio of New Jersey. In a stunning act of malicious insider sabotage and with both vengeful and financial motives, Roger brought a financial behemoth to its knees on March 4th, 2002.

As those were my days in private investigation, I had the humbling opportunity to be intimately involved in this case. The situation was eerily similar to the Fannie Mae near-disaster, the only difference being that Roger’s device detonated on time and caused unbelievable financial losses in the blink of an eye (around 3 million dollars to regain functionality), followed by incidental losses over the course of years which were never reported by UBS/PW (I’m sure some folks here could guesstimate the final bill). Forensic analysts from multiple agencies and institutions became involved and my task was to review the weight of the state’s pending case as well as Roger’s potential defense.

I had a chance to review the source code of Roger’s logic bomb and hard drives affected by it. The weapon was simple and elegant (a KISS practitioner would have been proud), contained around 50 lines of C code, and it had the benefit of a flawless delivery system (rsync or something similar) to distribute it. The code’s simplicity allowed one to clearly see why it was a dangerous: a single, lethal system command (rm) wrapped tightly, like a digital pipe bomb, in a short series of nested loops. With the standard recursive option set (-r) and the failsafe disabled (-f), it was pointed at the UNIX root (“/”), the heart of the file system. With significantly privileged access to a vast majority of the UBS Paine Webber financial network, Roger used a series of work and personal systems to distribute and then hide several thousand copies of his sabotage device on a cold winter’s night in 2001, just before the New Year, while most of the UBS/PW IT staff was out enjoying the company holidays. For months the nested loops on these devices cycled, first through a month counter, a day counter, an hour counter, and finally a minute counter, ever closer to the 3/4/02 9:30am ET trigger date when those thousands of payloads executed simultaneously. The effect to UBS/PW was, borrowing the words of General Curtis LeMay, to “bomb them into the Stone Age”. For more than a day UBS Paine Webber, a financial giant without the aid of most of its UNIX back end infrastructure, was forced to trade and operate using paper and pen. While I was never at the digital “Ground Zero” at UBS/PW, I was asked to look at the “bodies” and the remnants of the discharged “weapon”. Ultimately I was asked to look at state’s evidence pointing to Duronio, which ultimately led to his conviction in 2006. Even after the trial, and probably to this very day, UBS/PW and its spin-offs continue to realize business losses (i.e. dollars) from the event in 2002 due to unavailable data and unrestored systems.  Interestingly, here’s what one of Duronio’s defense attorneys had to say:

“Chris Adams, Duronio’s defense attorney and a partner at Walder, Hayden & Brogan in Roseland, N.J., says his client isn’t to blame for what he called the “unsophisticated and sophomoric” code that, he added, was most likely planted as a prank.”

While IANAL, I think can safely say to Mr. Adams that YANAFE (You Are Not A Forensics Expert). The code was neither unsophisticated nor sophomoric and was indeed clearly designed for an explicit purpose: to systematically and recursively destroy the filesystems of thousands of UNIX big iron servers precisely at the start of stock exchange trading in New York on March 4th 2002. Mr. Duronio’s defense may have had more success were it not for the fact that he placed orders for over $20,000 shorting UBS/PW stock, eleven days prior to the attack. While we examine the logic bomb, our brothers in arms in forensic accounting and securities investigation would tell you this is the real smoking gun. The US Attorney for New Jersey agreed that both items were enough to proceed to a grand jury, and rest as they say is…precedent.

The Fannie Mae case is the exception and hardly the rule, as others have noted. A vast majority of us will probably end up cleaning up the bodies and examining discharged ordnance rather than catching this kind of thing. Police ballistics laboratories are never wanting of bullets or handguns to examine, and I imagine we are all on the verge of a similar paradigm shift in the digital realm. The challenge remains with IT and security organizations to limit privilege and carefully control access to systems and resources in an efficient yet compartmentalized fashion. If the events of 9/11 illustrated the potential for a small band of fighters to knock out a disproportionally large infrastructure in 21st century America, the Roger Duronio case is without a doubt the corollary for our field. Several thousand victims snuffed out in both cases due to a failure of proactive due diligence and in the chaos of the ensuing reactive response. This is the fate that Fannie Mae avoided, apparently by pure chance. Few cautionary tales are as good as this one.

Hal’s post on change controls illustrates one way we can potentially catch insider malicious code, but sadly when the elements of poorly controlled access and authorization factor in, and the crucial security element of least privilege is ignored, the security game is already over and you’ve lost. The most damaging information saboteurs already know the internals of your networks and ways to circumvent business processes that aren’t truly secure. Even change controls cannot stop the rogue system administrator with privileged access to “everything”, as in the case with Roger, if other failsafe methods aren’t in use. This is asymmetric information warfare at its clearest: one, small threat who can still reach the heel of Achilles.

To end, I’ll give a few lessons that the bloody tale of Roger Duronio impressed upon a once more naive analyst:

  • Know how IT privileges (access and authorization) are assigned and revoked in your organization. Be able to audit and review this easily.
  • Least privilege is not a “nice to have” but instead should be the foundation of all system access employees are granted.  People must start with no privileges and be assigned the ones they need to do their immediate job, rather than be given full access in the name of convenience.  Even senior UNIX administrators like Mr. Duronio do not need immediate root access to 2000 of your most critical systems.
  • Ensure your organization is able to revoke IT privileges in a push-button, “nuclear option” fashion, because such privileges are not only administrative matter but a tactical one as well. It is far better to revoke and re-enable than to wait and regret the decision to terminate access.
  • Even if all of these elements are assured (and I can’t stress this enough), take threats made in the office seriously.

Whether it is an employee joking to come in on Monday with an AK-47 or threatening to crash IT systems, do not take co-worker threats in the workplace lightly. Duronio became an instant suspect after the event because of witnesses who testified that he was highly disgruntled and disruptive at UBS/PW before finally resigning a few months prior to the attack (but not before planting his Doomsday Machine). When we take threats lightly from people who are already inside our perimeter, we are often one single point of failure away from events like 9/11, Columbine, and UBS/PW.

Mike Worman, GCFA Gold #124, GCIA Gold #282, is an incident response, forensics, and information security subject matter expert for a international telecommunications carrier.  He holds a BS in Computer Systems Engineering from the University of Massachusetts, an MS in Information Assurance from Norwich University, and is CISSP-certified.

When Encountering Safeguard Easy’s Boot-time Authentication Lockout…

Full disk encryption is great for security, but encrypting data carries with it some incidental risk. Forgotten or otherwise unknown encryption passphrases and keys can lead to serious consequences in many situations. In forensics and incident response we use and encounter encryption all the time, and accessing encrypted data in a timely fashion can be critical. I’d like to share a trick I learned while dealing with a “bricked” encrypted device utilizing SafeGuard Easy (“SGE”) from Utimaco Software, a fairly common full disk encryption solution.

Safeguard Easy offers a powerful full disk encryption tool, including a built in user management system and a post-BIOS, pre-OS boot-time authentication option with what seems to be a form of exponential backoff timer to prevent brute-force username/password guessing. Incorrectly entering a boot-time passphrase just a handful of times will cause a cumulative timeout between allowed attempts…this timeout continues to double (approx.) with each incorrect attempt. Anyone who has attempted multiple passphrases when booting a Safeguard Easy encrypted system will quickly notice delays of a few seconds, then minutes, and eventually hour+ timeouts between allowed attempts. Rebooting or cold booting has no effect on this timer, which persists indefinitely. After as few as five or six incorrect attempts an SGE device becomes quite inaccessible. Even users with valid username/password combinations (including administrators!) can no longer attempt to access the operating system.

I was stuck once with an SGE system that was in exactly this poor state, waiting more than an hour between each allowed attempt. Even with the correct username and password available, any attempt to boot the OS was fruitless. After some Googling, a search through the Utimaco Knowledgebase, and some trial and error, I was able to find a solution to my problem. Utimaco provides a valuable method for Safeguard administrators to bypass normal boot-time authentication limits and lockouts.

Utimaco offers Bootable Rescue Image files for every version of the product through their website’s Support pages. These BRIs are a set of floppy images and .ISO files that can be used to create bootable media that bypass whatever boot-time security settings are in place. When booting my “brick” with the appropriate .ISO image for that version (image files are specific right down to major and minor version number and they will not work if there is a conflict), I was presented with a similar process for entering a boot-time passphrase, except that now there was no lockout, and no growing timeouts. Armed with this, I was able to successfully authenticate within a reasonable amount of time. Authenticating via BRI as a valid user will allow booting straight to the operating system, and authenticating as Safeguard Administrator will allow complete removal of the encryption product without booting the OS. Hopefully this little “Easter Egg” will help save someone else some time and frustration.

Mike Worman, GCFA Gold #124, GCIA Gold #282, is an incident response, forensics, and information security subject matter expert for a major international telecommunications carrier.  He holds a BS in Computer Systems Engineering from the University of Massachusetts, an MS in Information Assurance from Norwich University, and is CISSP certified.

Organizational Forensics: Navigating the Enterprise Outside the Lab


“Gentlemen, you are about to enter the most fascinating sphere of police work: the world of forensic medicine.”

I am just old enough to remember that long before shows like CSI became pop culture, there was the great Quincy, M.E. Those dramatic words (and who can forget the sudden retching of one poor novice officer during an autopsy in the opening credits) may have started many of us on the path to a forensics career.  The grandfather of all television dramas about real forensic work (in Quincy’s case, forensic coroner) is a classic and inspired most of what we see today in one form or another, in particular the fascination with medical forensics and pathology. The essential difference, though, is that in today’s dramas forensics is viewed as exciting and fast-paced, with solid support and lightning-fast conclusions at every turn; a case solved every episode because everything in the forensics process moves that quickly. Quincy, M.E. worked in times when applications of forensic science was (by the standards of most outside the field, particularly police detectives and administrators!) boring work, a way to file documentation about the deceased in Quincy’s particular situation. Quincy, though, was never content with sitting in the lab. He was compelled to go outside the lab to get the whole story, and in that respect he became one of pop culture’s first forensics icons, imitated again and again in today’s programming.

How achingly familiar does Quincy’s modus operandi seem to the rest of us?

(From,_M.E.) :

Many of the episodes follow this formula:

  • Somebody dies, seemingly by natural causes.
  • Quincy notices something that causes him to suspect foul play.
  • He then changes roles from medical examiner to detective.
  • Quincy’s boss gets upset, believing that Quincy is seeing evidence that doesn’t exist and that Quincy should work on routine cases. The police get their feathers ruffled as he “shoulders-in” on their territory as well.
  • He argues quite loudly with some bureaucratic individual impeding the case.
  • Quincy solves the murder.

Quite simply, if only forensics were as smooth sailing as CSI would have us believe, when it comes to truly being able to navigate the murky waters of any large organization in an effort to establish and document facts. Those with shiny badges might have more success…but even they will tell you that the truth is stranger than fiction. Bureaucracy is a fact of life in business or government, so creating tools for navigating it effectively can be a very valuable forensic resource.

So what tools are available? Quincy helped teach me that thinking outside of the box (or in our case, the lab) is sometimes the only way to truly assess the facts of a situation. Patience, tenacity, hard work, and even the strongest analytical skills can take you so far before you get into the almost certain “Loud Argument” phase when the real world of organizational dynamics is factored in. The solution for Quincy, sometimes missed by newcomers to the field, is good old intelligence gathered when he put his other ”hat” on (that of gumshoe detective). Had he not done this, every episode would have begun and ended with him filing paperwork, leaving a killer at-large.

Organizational intelligence (a component of business intelligence) can be a critical factor in enterprise forensics, because nothing is more important in applications of forensic science than being current, being aware, and staying within the confines of forensic validity relevant to your specific environment. In a large environment this task is particularly daunting, and combined with a digital workplace these elements are at risk of changing every day.  Being able to acquire, analyze, and categorize information about your organization and its various elements is crucial to navigating it in a forensic manner.  Even the best forensic analysts would be remiss to think that their role in an organization is solely in the lab. Knowing your organization outside the lab, including the nuances of its business model, political structure, and “flow”, is as critical to enterprise forensics as mastering the internals of any operating system or hardware platform. Even more important is knowing where particular talent, subject matter expertise, and strong leadership can be found within the organization.  Without such an approach, even the most skilled forensic analysts may never get a chance to review the data they seek.  It is far, far more efficient and cost effective to do this in a proactive manner, but there will always be times when reactive intelligence gathering is your only option.  Either way, failure to collect at least some intelligence as it pertains to the organizational, structural, or political environment surrounding data can seriously hamstring any investigation.

  • Spend significant time on the continual process of mapping out your organization from top to bottom, in useful terms correlating to solutions for specific issues/challenges that you’re likely to encounter. Focus on functional responsibilities and roles, and less on the “organizational chart” view.  Map out true responsibility for applications, infrastructure, processes, and so forth.
  • Don’t just create a Point of Contact list…check it often and update it regularly. Organizations change over time, staff changes shift responsibilities, and in any incident response or forensics situation, time is limited.
  • When not working a case, invest your cycles in networking, getting to know the work and routines of other departments, business units, locations, etc. Almost every organization has an internal “Intranet” site, but how many of us really take the time to dig into it and learn about what everyone else does with their day? Even for a massive organization with hundreds of thousands of people, you can learn a lot in a short time by setting aside some time for internal research or better, by introducing yourself ahead of time to people and stakeholders who you may have to call on for help when a case warrants it.
  • Frankly, unless required by policy or job, no one deserves to be included, copied on, or involved in a forensic investigation by default. There are, however, plenty of people who want to watch your investigation as if it were indeed a CSI episode. Avoid sending information to people that are not directly involved in the legal, security, or other relevant processes in your organization (or other organizations that you might be less than familiar with). This will help to minimize the amount of friction that can sometimes occur in an investigation. You can do this by proactively mapping out which contacts to call, for what, and how. The alternative of “casting a net” for information or response during an active investigation or incident can sometimes cause interruptions that can be avoided by a bit of proactive elbow rubbing.

By performing this (yes, sometimes daily and to a few people, boring) collection of organizational intelligence in addition to focusing on our technical skills, and by getting out of the lab to get our hands dirty in the “real world” of people, processes, policy, and politics, you can strengthen your investigations in ways that software tools and SANS training can’t. You may still run into the “Loud Argument” phase with certain people, but hopefully you can have that before the incident and not during it.  Knowing the layers of your organization, its key players and decision makers (not just those within Security or Legal) and especially knowing the location of potential barriers and pitfalls will help you route around them, especially when handling time-sensitive investigative matters.

Mike Worman, GCFA Gold #124, also holds GCIA and CISSP certifications and an MsIA degree.