A security policy is a description of how an organization defines a secure computing environment. It is a collection of rules that define appropriate and inappropriate behavior. Once an organization deploys controls to govern behavior, it’s helpful to devise a method to measure how effective the controls are. All activity in a computing environment is made up of individual events. An event is any observable occurrence within a computer or network. An event could be a user logging on, an application server connecting to a database server, an authentication server rejecting a password, or an antivirus scanner reporting a suspected virus. Any event that results in a violation of your security policy, or poses an imminent threat to your security policy, is an incident.

The first step in responding to an incident is to recognize that an incident has occurred. Many incidents go unnoticed because no one is looking for them. It’s common to review OS and application software log files after a major incident, such as data loss or a system failure. In some cases, there is evidence of smaller incidents leading up to the big event. Many organizations lack the procedures to identify incidents early. Like any persistent problem, identifying incidents in a timely fashion can help contain any damage and prevent further damage.

The adage, “An ounce of prevention is worth a pound of cure,” applies to incidents. The best way to avoid handling incidents is to prevent them. Securing computers and network devices is better than dealing with security incidents. The only exception is when the cost of the controls is more than the loss you would incur if an incident did happen. Microsoft has a lot to say about handling incidents for Windows environments and recommends pursuing prevention first. According to Microsoft’s recommendations, these strategies can help any organization minimize the number and impact of security incidents:

• Develop, maintain, and enforce a clear security policy that management supports and promotes. A security policy defines incidents and behavior that lead to incidents.

• Conduct routine vulnerability assessments to discover vulnerabilities that could lead to incidents.

• Ensure all computers and network devices have the latest available patches installed.

• Train all computer system users on acceptable and unacceptable behavior. Establish frequent and visible security awareness reminders. Use both physical and virtual methods to notify and remind users.

• Enforce strong passwords throughout your environment.

• Frequently monitor network traffic, system performance, and all available log files to identify any incidents or unusual events. The first logs you’d likely analyze would be logs from your intrusion detection system or intrusion prevention system.

• Ensure you have a solid business continuity plan (BCP) and disaster recovery plan (DRP) that you test at least annually. A serious incident will likely require that you enact one or both of these plans.

• Create a computer security incident response team (CSIRT). The CSIRT is a team organized to respond to incidents.

All of the suggestions in the previous list are really just elements of good security. These are things you should be doing already to maintain a secure environment. The last suggestion, create a CSIRT, is specific to handling incidents. This is the team of people who will respond to any incidents. There are six separate steps to handling incidents. Understanding and following all six steps will help you avoid many incidents and prepare your CSIRT to handle the ones that do occur. TABLE 13-1 lists the six steps for handling incidents.

The most important aspect of properly handling incidents is preparing to do it right. Once you understand what it takes to respond well to security incidents and have your CSIRT in place, you are ready to begin developing your response plan.