Getting a Handle on Incidents

Anyone who has spent time defending a computer network from intruders and attackers knows that no matter how good the defenses, successful attacks on IT infrastructure are inevitable. Consequently, a company must have an incident-response program that will minimize the impact of any breach.

Let’s look first at some of the key components of an incident-handling program, and then at what a company should consider in setting up its own program. 

Key Components

Every company will need to establish an incident-handling team to implement the program and every company will want to follow generally the same steps for incident-handling, including detection, alert analysis, communication, tactical action, and after-action analysis. Of course, some elements of the program may vary depending on the type of organization and its size, level of automation, and sophistication. 

The team. The incident-response team needs to be ready to respond at a moment’s notice. It’s important to note that this team is not just a group of engineers and technicians. The following types of people should be considered for inclusion in the incident-response team.

• System administrators and network engineers to handle emergency changes
• Security operations center staff to review the suspicious activity to help identify incidents
• Legal representative to handle any legal issues related to the incident, such as a breach of contract caused by service failure
• Human resources representative to handle personnel issues (for example, the termination of an employee who has caused an incident)
• Public relations representative to determine whether to report to the press and what should be reported
• Incident-response manager to coordinate the effort

 If in-house staff do not have all of the requisite skills, the company may want to include a consultant who has experience performing enterprise-architecture design or business-impact analyses, as well as information-security expertise, a strong understanding of operations environment workflow, and good communication skills. The person should be capable of conducting a business-impact analysis, the results of which can be used to develop appropriately detailed, IT-environment-related incident-handling policies and procedures.

Training. Training for the team is a continuous process. Staff recently assigned incident-response responsibilities must be trained on the incident-response policies and procedures and be given follow-up training to account for changes to policies and procedures. Generally, incidents do not occur every day; therefore, even experienced staff should have refresher training sessions so that their knowledge is up to date and their skills do not atrophy.

Detection. The team must have a means of monitoring systems for signs of unusual activity or new vulnerabilities. Detection of unusual activity is usually heavily reliant on monitoring technologies deployed in the production environment, such as intrusion detection, scripts that monitor login attempts, and controls embedded in applications.

Incident-handling teams also use network scanning tools and research alerts from groups such as the CERT/CC or Security Focus to keep abreast of new types of attacks and vulnerabilities.

Alert analysis. Often the unusual activity or new vulnerabilities uncovered in the detection process turn out to be false alarms. The cause of each alert must, therefore, be analyzed. During the analysis process, the potential incident and corresponding evidence should be reviewed to determine whether or not an actual incident has been identified, and the scope and type of damage that the incident has caused or could cause if not dealt with quickly.

As a part of the incident-handling program, a company will need to have a history of past events in a database or spreadsheet. This information will be used to collect metrics on the effectiveness of the program and will also assist the team in uncovering long-term trends.

While the actual data to be collected will vary depending on the organization and the tools available, the following list describes the some examples of data to capture.

• Incident date and time
• List of business processes affected and how they were affected
• Computer system(s) name and/or numbers affected
• Type of incident (data compromise, virus incident, denial-of-service attack)
• Steps taken to prevent the reoccurrence of similar type of incident
• Who was notified about the incident
• Time spent handling the incident

The team should avoid using free text in the history database or spreadsheet. Structured, searchable text will greatly increase the value of the history database.