In the past few columns I discussed the basic steps needed to develop business-continuity and disaster-recovery plans. How are those different from incident handling? You can say a disaster that adversely affects your ability to continue operations is an "incident." But lets step back a bit and look at other types of incidents that can affect the way you do business, those that are not as "severe" as typical disasters -- earthquakes,...
floods or power outages -- but can still disrupt your business.
Incident handling is an action plan for dealing with anything that can disrupt the way you do business. Some examples include hacker intrusions, denial-of-service attacks, cyber theft and other security-related events. Like the business-continuity plan, incident handling involves having the proper procedures in place so that you know what to do in the event an incident occurs. Using an earthquake as an example, perhaps the method of handing this incident is to call the business-continuity plan into action.
How do you define an incident?
The best explanation I've seen comes from SANS, which states, "an incident is an adverse event in an information system, and/or network, or the threat of occurrence of such an event." An incident implies some form of harm or the attempt to do harm.
Assume someone is trying to hack in to your Web server. What now? How should you respond to this incident? Sit back and let the person try? Turn off the Web servers? Call 911? There are actually many options you can exercise for this incident, and we will address some of the steps you can take in future articles. But for now, lets focus on the infrastructure you need to have in place to handle incidents. This is called the incident-response plan.
In the book Surviving Security, author Mandy Andress highlights the steps needed to build an incident-response plan of attack. They include the following:
* Define policies. Before anything else, you need to define the incident-response policies. Those policies are the procedures you need to follow, whom to contact and the tools to use when investigating an incident.
* Select a Computer Security Incident Response (CSIR) leader. That person will be responsible for managing the rest of the CSIR team. He will also be the focal point for all of the decisions needed during an incident.
* Select the CSIR team members. This team usually consists of three to five individuals from various departments, including security, IT, legal and management.
* Determine whom to contact. Depending on the incident, you may need to contact outside support companies or even federal authorities. For instance, if your company is part of the federal government and someone is trying to break in to the system, federal agencies such as the FBI need to be contacted.
* Describe actions to take. This is where the specific details come into play. Taking the above example of a hacker trying to break in, perhaps the action to take is to let the intruder try to break in while you collect the data. That data could be used to prosecute the hacker when caught.
When the actual incident occurs, you should do the following:
- Identify the incident. Verify that an incident has really happened (not a false alarm).
- Contain the incident. Secure the area, back up the system or, if needed, disconnect the system from the network (in the case of a hacker attack, for instance).
- Decide if contacting legal authorities is needed. Check with the legal department or local/state/federal laws.
- Create a log of everything that happens. That log could be used to trace the events at a later date or as evidence in a court trial. It can also be used to learn from the incident.
- Create a report of the incident. Use the log as a starting point. Use the report to conduct "lessons learned" and to determine if the procedures need to be changed.
Sooner or later an incident will occur. Without proper planning not only will the incident take you by surprise, but you also will not be prepared to handle it correctly. Developing an incident response plan is an excellent way to have a procedure in place to handle possible events that can disrupt your business operations.About the author
Mark Edmead, CISSP, has more than 22 years' experience in software development, product development and network systems security. He is co-author of the book Windows NT: Performance, Monitoring and Tuning published by McMillan Press. In addition, he has written numerous articles for technical publications and is currently writing a book on Internet security certifications.