Preparing for the Worst

by Fred Avolio, President and Founder, Avolio Consulting, Inc.

Firewalls are ubiquitous. Host and network intrusion detection systems are commonplace. You may even be using commercial vulnerability scanning and penetration tools, or services. However, sooner or later the worst may happen. You will have a bona fide, "wanna-hide-til-it's-over," network or computer security incident. Don't you wish you had planned for it?

There are many reasons why we avoid planning for security incidents. In particular, we don't think it will happen to us. But it could. We don't think that we are an attractive or interesting a target. However, you may be vulnerable to the random penetration attempts that happen all the time. We don't' think we will ever need a plan. You hope. We believe that all of our employees are happy. Yeah, right. We think that it will be too much work. Not necessarily - read on.

In this short article, I will outline the main steps needed to put together an Incident Response Plan (IRP) and a Computer Security Incident Response Team (CSIRT).

The IRP

The Incident Response Plan is easy to frame out and only slightly more difficult to fill in. It should have some preliminary "boilerplate" information - the name and description of the enterprise, the scope of the Plan (enterprise-wide, division, or location), and a pointer to system-specific back-up and recovery procedures. The IRP should also contain "rules of engagement," some decision-making recommendations, and a description of the CSIRT including membership, duties, and procedures.

The Rules of Engagement

The "rules of engagement" spell how we define an incident or security event. For example, some organizations might consider a simple port scan an incident. Others get scanned every minute. Will you wait for web site defacement, or are there other indicators? These are important questions to answer when creating an IRP.

The CSIRT

The IRP also establishes the Computer Security Incident Response Team (CSIRT). The CSIRT membership should include a designated leader. This person is responsible for calling and planning the meetings. A good candidate is the ISSO, the CSO, or the IS or IT Security Program Manager. They should know something about security and IT. This person should not only have responsibility for information security, but more importantly, must have authority to enact security matters as approved by the rest of the team and senior management. Additional team members should include a liaison to the senior management team and one member from each of IT, security, human resources, public affairs, and legal.

The team's first order of business is to identify additional team members. CSIRT membership is by invitation only, based on organizational need and the particular role and expertise of the individual member. In addition to the list above, the team should add system and application specialists, system and network administrators, and software developers. IT team members control system access and repair damage. They also support evidence gathering. It may be obvious why we need computer and network security experts: they are the skilled practitioners. Under this category would be someone from your Managed Security Service Provider. You should leverage their expertise since they typically have deep experience in dealing with incidents on a daily basis.

At a corporate level, a lawyer on the team is helpful for understanding the laws pertaining to security incidents, and being a first liaison to law enforcement. The team member from HR understands and can protect employee rights, but also knows about the status of terminated, or soon to be terminated, employees. Finally, a specialist in dealing with the public should be the spokesperson to the press. It is important to note that some team members will be transient, and involved only when the incident touches on their areas of expertise.

The duties of the CSIRT - as described in the IRP- include:

Closing Thoughts

While the key issues of the IRP and CSIRT have been touched on, this is merely an overview. The process is more involved than I've described, but not any more complex. However, there are many potentially disastrous pitfalls organizations can fall into. Some organizations deny they need it. Other groups don't look deep enough and only end up patching a surface problem. Many companies throw too many people at incidents, and some too few. That is why planning is so important. The worst time to come up with a plan is during an attack. You need to work on your plans early. You need to form a team and start the process. You can start by speaking with your MSSP. They have a great deal of expertise and handle millions of events each day. After you have a plan in place, and before your next security incident, test the plan. Only then can you be confident that you'll achieve the best result, when the worst happens.

For more information on Incident Handling and Response go to:

www.sans.org www.giac.org www.avolio.com