Rapid Automated Response

Abstract

By utilizing two open source tools it is possible to, at least partially, mimic the functions of automated incident containment and response. Previously these functions could only be achieved using commercial software with varying price points, usually worth thousands of dollars. The goal of the project presented in this paper is to create a free alternative. This report includes research about why it is important to automate the incident response process, and an explanation of the two tools, Snort IDS and Google’s GRR Rapid Response, used to provide the solution.

GRR and Snort work together very well, and by implementing this Rapid Automated Response project in a network, it is possible add another dimension to network monitoring and data collection. This project provides the ability to automatically collect client information when an event occurs. For example if an employee is under investigation and they access information they should not have access to, this system could trigger a response to that event. The response could vary from collecting all the browser history for that user, or collect all the recently run programs, opened files and much more. The actions are easily customizable with a little basic knowledge of the way Snort and GRR work. The result is a robust and flexible system to help speed up reaction times and gather information.

Introduction

The problem with this current solution is the amount of time between the detection of the threat and when the incident response team has collected the required information. For example, an early attack on December 25th, 1994 targeting Tsutomu Shimomura, a well-known information security expert, took 16 seconds to exploit and gain administrative access on one of his computers (Hawrylkiw). Those 16 seconds are faster than anyone sitting at the computer could have discovered and then reacted to the threat. However 16 seconds is a very long time for an automated system to react to the same scenario. Currently the average time to even detect a breach is 18 days (Verizon).

Project description

The goal of this project is to build an active automated incident response (IR) system out of freely available and open source tools. Currently most tools allow for monitoring security threats or assisting with the examination post-breach, but not both. There are a few exceptions to this with the availability of commercial tools. By making such resources available it might be possible to increase the response time and the amount of information available to an examiner, which in turn will lead to a quicker examination and understanding of the event that took place.

Results

The Rapid Automated Response (RAR) also uses a client-server model. The clients send alerts to the server which processes them and initiates requests for information. The server also receives the information back.

After GRR Rapid Response and Snort were setup and functioning, work began on receiving alerts from Snort. The piece of the project responsible for this is the RAR Client, written in Python, which monitors the fast.alert log from snort for new alerts. When a new alert is generated the client will parse the information (source IP, destination IP, time stamp, Snort type and ID) and decide if it is part of earlier connection or incident, or if it is a new connection. This is done by inspecting the source and destination information of the alert, along with the timestamp information. The client will do a lookup in the local system’s ARP table for the MAC address corresponding to the suspect client’s IP. If there is not an entry, the client will ping the suspect IP to generate an ARP entry and then recheck the ARP table.

Instead of using the standard community rules that can be downloaded I wrote a single rule. This rule fires when the content of the packet contains “google.com”; it has a generic ID of 1001.

alert tcp $EXTERNAL_NET any -> any any (msg:"Access To Google"; content:"google.com"; nocase; offset:12; classtype: web-application-activity; sid:1001; rev:1;)

If the alert is not a duplicate then it takes the information and sends it to the server in plaintext using pipes (“|”) to delimit the different data types. The client will also test if the connection to the server is open; if it isn’t it will error out.

New Alert
2014/04/23-14:32:33.439355|FROM|10.1.0.89|00:0c:29:1d:5d:f1|[1:1001:1] Access To Google|2
The server refused our connection

Once the RAR Server receives an alert it decodes the message (which has data types delimited with pipes (“|”)). The server will then do a query through GRR for the computer associated with the MAC address found by the client. The query will also return the computer’s last known IP address, users that have logged into the computer, the first time it was seen by GRR, the last time it was rebooted, the operating system and the hostname. Further information can be requested using different API calls. The RAR server will then confirm that the IP address matches the IP address of the suspect client that triggered the alert; this is to try to prevent false positives and the waste of processing time.

Project experience

The results for this project, currently, are not to my standards. I ran into numerous road blocks while trying to develop a fairly complicated system. Despite these road blocks I feel like I have made significant progress towards this project, so much that I would like to continue working on this as I feel as though it could be a good contribution to the GRR development community.

90 percent of this goal has been obtained. I have written both a client and server in python to send and receive alerts with the necessary information to perform actions with the GRR API. With this information my server is able to validate the IP address and gather host information about the client. However, I have run into an issue with obtaining appropriate permission to run a flow to request browser history information. I am still currently working on figuring out a way to run this API request. I worked with developers to get client integration working with the API; they have been very responsive so I may reach out to them once again for assistance.

I will continue to develop this project and work with the GRR community further once I graduate. My current code has been posted on GitHub even though it is not as impressive as I had hoped it would be at this point. At some point in the future I plan on making it known I am working on this publically once I complete the core functionality. This will be a major step for me, because although I am not a programmer by trade, I think this project will contribute quite a bit to the open source incident response community.