This month Guidance Software will release its Automated Incident Response Suite, add-on software that runs on top of the company’s EnCase Enterprise forensic product. A demonstration of AIRS beta code suggests that the automation will help a junior-level investigator who needs to be presented with just enough information to make an escalation decision. But veteran IDS and incident-response folks may become frustrated with the limited view of information provided.
This month Guidance Software will release its Automated Incident Response Suite, add-on software that runs on top of the company’s EnCase Enterprise forensic product, which monitors intrusion-detection system events and performs automated incident response tasks based on the nature of these events.
We saw a demonstration of AIRS beta code and found that the automation will help a junior-level investigator who needs to be presented with just enough information to make an escalation decision. However, veteran IDS and incident-response folks may become frustrated with the limited view of information provided.
The base functionality – referred to as “taking a snapshot” – is a subset of what can be accomplished with the Enterprise Sweep feature in EnCase Enterprise. Security administrators define thresholds and filters on IDS events that triggers AIRS to automatically take a snapshot of the target system. In its first iteration, AIRS will support Internet Security Systems’ Site Protector and the open source program, Snort .
An important detail of the AIRS system is that the information gathered via an AIRS snapshot is a subset of that gathered by EnCase Enterprise’s Enterprise Sweep. The benefit of AIRS lies in its automation and Web presentation, not in the depth of data gathered. When the profiles are being built, EnCase Enterprise users will feel comfortable, as the screens look similar, but there aren’t as many snapshot modules from which to choose.
The administrator must specifically define what information will be collected via an AIRS snapshot before the snapshot is taken, as AIRS does not dynamically determine what to gather. Different profiles can be built for event severity levels defined by the IDS vendor. In addition, the administrator has the ability to configure the profile explicitly to the system and its configuration. For example, Windows-specific modules would not be enabled in the snapshot profile for a Linux system.
The work underlying this process is completed via two EnScripts (scripted programs in Guidance Software parlance). The first queries the IDS database (currently supported database formats are MySQL, Postgres, and MS SQL databases with Oracle ties on the company’s road map) via Open Database Connecitivity. Currently AIRS can use Secure Shell and SSL for encrypted connections between it and the IDS database. Once the IDS event data has been retrieved, the first EnScript populates a separate EnCase database on the AIRS server. The second AIRS EnScript monitors the EnCase database and triggers the snapshots as needed. The snapshot results then are presented via a Web-based interface to the administrator.
Filtering is arguably the most important aspect of this tool because many corporate IDS environments can generate hundreds of thousands, if not millions, of IDS events each day. The trick is in setting up the AIRS filters. If these are not properly configured, AIRS could automatically query any number of systems in the EnCase monitored network, creating a huge amount of traffic on the network and mass amounts of data to sift through.
There are several filtering criteria, such as “Alert Name Contains,” “Destination Address” and “Sensor Name Contains.” The number of events also can be used to threshold by the source event, destination event and/or time.
The default filters should be suitable for basic IDS integration, but advanced tuning will probably require custom-built filters. Building a custom filter is quite similar to building a Condition in the EnCase Enterprise parent program, which is not very intuitive. IDS veterans who are comfortable with tuning their IDS configurations could become frustrated with the filter-creation process.
Once AIRS is installed and configured, the results are viewable via Webserver running on the AIRS server. This Web-based user interface is markedly different than the console-based EnCase GUI, but it is easy to navigate. As snapshots are taken, Web links are created for each system, and the user can drill down to investigate. Because the information gathered is not as extensive as an Enterprise Sweep, it presents rather well in a Web form. The user can peruse port and process information (same data you’d see in Examiner), module results, as well as a subset of the IDS event data. This provides a quick glimpse into the event, but AIRS does not provide the full capabilities of the IDS event console. For example, to get a view of the raw packet data you’ll need to tap into the IDS console. Further, as there is no integration with EE’s Examiner GUI, to initiate a “real” investigation of the target system, you’ll need to fire up Examiner, do an “Enterprise Sweep” and start digging.
In all, the AIRS product is a good idea, and as it grows to be more capable, it should become even more attractive. We’d like to see the ability to seamlessly move from the AIRS interface to Examiner GUI, which could be difficult as one is Web-based and the other a dedicated GUI. Once it’s been established (via AIRS) that an investigation is necessary, it would make sense to move right into that phase without changing applications.
Return to EnCase Clear Choice Test
