10.2 Incident handling requirements

As with all of our policies, we need to look at the business drivers. Before you make any decisions on incident handling, you need to look at the service level requirements of what you are protecting. Your service level agreement (SLA) will work hand in hand with incident handling and disaster recovery. If you have an SLA that your web server will be up from 8 A.M. to 5 P.M. on weekdays, do you really need to have an incident response team ready to pounce on a problem 24 hours a day, seven days a week? Balance the needs and definitions of your incident response team to that of your SLA's. (If you want to learn more on SLAs, check out this article in CEO Magazine. It is old but good: http://www.cio.com/archive/111598_sla.html.) Also, if you run a business that truly needs 100% up time, you may need to have several sites worldwide as "hot sites." This would be linked into an automated system that pushes your users over to a "working" site. Again, the strategy needs to match the needs of the business and the SLA's.

The incident handling policy should also have some high-level definition of monitoring requirements. There are several different methods that you can use to monitor your security. This information should be fed back into the process that identifies the countermeasures for your site. You can have a real-time system that launches some type of automatic response based on a particular attack. Or you can have low-tech systems that beep when a certain threshold is reached. Or really low-tech someone notices that the server is down. The policy should not dictate which tool to use, but instead, define the requirements needed to meet the strategy. For example, "In the event that a server is down, an out-of-band alert will notify an administrator within 15 minutes."

In this example, you may select some simple system that checks the server every five minutes looking for an HTTP status code of "200." If that code is not returned after two tries, the server is considered "down." In that case, the administrator is alerted. A generic incident handling policy should have the following components (not in any particular order):

A reporting system: This system will provide updates and support for the number of incidents. Based on the severity of the incidents, this information will be sent to the Security Officer, then to the CIO, and then to the CEO. This reporting will provide awareness for security incidents within the company.
An analysis system: This system will "handle" each incident. The components of the analysis system include the following:
- Evaluation: What is the scope of the incident?
- Initial response and notification: What should be done and who is to be notified?
- Legal: What are the legal ramifications involved?
- Communication: This is different from notification. Communication is updating the employees or general public. In some cases, due to customer confidence issues, you cannot report the incident to the general public. (This is a real issue with banks.)
- Reporting: If the incident has a significant financial impact, then you will need to report the incident to local law enforcement and to the FBI. Also report/check with CERT.
- Documentation: Keep track of the incident through logs and reports. Documentation should also be used to generate feedback into the corporate security policies, which can generate a permanent fix or a change in policy.