| INCIDENT RESPONSE
In recent years, the information security industry has created a tool of some kind or other to address the security concerns of pretty much every single component in an information flow path--from network and application firewalls to antimalware, and from traffic monitoring to log management. In spite of all these tools and layered defenses, security breaches and incidents are part of doing business in the linked-up world. Yet, incident response remains a very manual process that is rife with inaccuracies and inefficiencies, unless you can afford highly prized consultants or even more expensive forensics tools.
Typically, the best companies have done to improve their incident response plans is to update the documentation to add some industry best practice steps and perform a table-top testing exercise on a semi-regular basis. IR teams often have to scramble during a virus outbreak or a TJX-type incident to figure out what happened and how to get things back to normal. Also, they need to be concerned about collecting and preserving the evidence in an acceptable format for further investigation. Mandiant, a trusted name in the incident response services arena, has created Mandiant Intelligent Response (MIR) an appliance that will automate most of the time-consuming tasks.
MIR is an agent-based client/server architecture, with controllers to initiate the collection of information from agents on suspect machines (currently only for Windows; *nix coming soon). The administration console software is the primary interface for managing all incidents from collection of evidence to analysis and examination, and, finally, presentation in a useful format.
The controller is a powerful Intel appliance with hardened Linux and other open-source components, such as Apache and postgresql database. It comes equipped with two TB of storage in a RAID-5 array, which is plenty for storing snapshots of entire memory and even disk images for more than a few machines. All communication is initiated by the controller, so the placement of the appliance to any firewalls in between it and agents on target machines is crucial. Agents can also be run in local acquisition mode, wherein results can be stored locally on the hard drive or removable media and manually imported into the controller for analysis. This can be very useful in cases where the agents have not been installed previously or in circumstances where there is no network connectivity between the controller and the agent.
Setting up the appliance for the first time on the network is not as simple as many other appliances with similar architectures. Although the documentation is comprehensive and walks through each step, customers will find that using the professional installation services option is highly beneficial. After the basic network and user account configuration, the installation process requires creating agent installation sets, including generating and exporting SSL certificates for the controller and the agents to communicate securely. It also requires making sure that the discovery file used by the agents to find the controller during initial registration has the correct IP address. Finally, the MIR console is installed on administrator workstations to manage the agents, audit scripts, analysis jobs, results, and incident notes.
In most cases, the IR team faces a stiff challenge collecting critical information like running processes, network ports, suspected files, and memory and disk images as quickly as possible while preserving the integrity of the data. Most companies keep a collection of open-source IR and forensics tools or just use the commands/tools available with the operating system. MIR automates this process without compromising the evidence.
To run a data collection audit before, during, or after an incident, the administrator has to create a new audit script by dragging and dropping the target host(s) from the asset list into the input pane and selecting the audit modules from a dropdown menu to be executed. These modules include; Acquire File (API or Raw), Acquire Memory or entire Disk image, Listing of Files (API or Raw), Process (API or Raw), Services, Network ports or even the Registry hive.
Using Raw modules is recommended way for incidents that may involve law enforcement and can have legal implications. They preserve the date and time stamps, and, in more cases than not, find more information than API modules.
[The API module uses whatever Windows APIs are available to make a particular system call and is limited by the security restrictions that apply to API calls. Raw modules (files and registry) read the MFT (Master File Table), interpret the file code for a particular file or registry key it is looking for and acquires a copy directly from the file system.]
The results viewer pane shows the overall progress of the jobs and the result files as they are being populated. Tabbed browsing makes it easier to open multiple windows for configuring jobs and viewing results simultaneously.
Depending on the audit modules selected and the power available, audit jobs can take anywhere from a couple minutes to more than an hour. Any issues experienced by the agent during data collection are recorded and reported in a separate file. After the evidence has been collected, IR teams can run one of four analyses: time skew, time line, document difference, or document intersection.
Individual records can be labeled with a custom string for future reference without having to search the results again. IR teams will appreciate the ability to add notes that can contain links to search results or entire documents.
One of the best things about MIR as opposed to other commercial products in this space is the open format and easy integration with pretty much any open source forensic tool. For example, disk images stored on the controller can be exported in a standard dd format, and memory images can be exported in windbg format, the universal choice for many memory analysis tools. All the audit and analysis result documents are stored in an easily understandable XML schema that can be directly viewed in any XML editor, including MS Excel 2007.
Although MIR 1.0 takes a huge first step towards automating incident response, there are a few usability and operational issues typical of 1.0 releases. For example, you have to drag and drop each host for an audit, and there's no warning of inadvertent duplicate host entries before running the audit twice on the same host. Errors and warning messages are believed to be caused by conflicts with certain Microsoft patches.. (Mandiant says MIR 1.1, expected to be released this month, should address these issues.)
MIR stores all evidence in Advanced Forensic Format (AFF), an open and extensible file format designed to store disk images and associated metadata. It is considered an acceptable format for chain-of-custody for digital evidence.
The controller indexes audits, case notes, and object metadata for fast, and accurate searches by the very well-engineered search function, which accepts single words, phrases and regular expressions.
The case notes are editable documents that can be used for note-taking, report writing, and linking to other information stored in MIR, allowing you to quickly reference host audits, analysis results, etc. Case notes use a WYSIWIG hypertext editor with all the basic features of a typical word processor. The notes can be exported into multiple formats, including XML. MIR also allows sharing of case notes among IRT team members with appropriate privileges.
Testing methodology: MIR 1.0 was evaluated in a test lab with a few Windows XP and Windows 2003 machines. The test covered the network based acquisition as well as local acquisition modes.