As we step through the assessment activities, we'll also discuss best practices so that when you're ready to develop your operational security project plan, you'll have the information you need to develop a solid incident response plan. Before we head into the details, let's take a quick look at the history of incident response.This will give you a bit of perspective and it's a great (geeky) conversation starter at tech conventions and high school reunions.
In 1988, an "Internet worm" hit a lot of computers then connected to the Internet. While 1988 may seem like the Stone Age of the Internet, that first attack disabled a large percentage of those 60,000 computers. In response to that incident, the Computer Emergency Response Team (CERT) was formed. CERT was chartered to be a single, trusted point of contact for computer emergency response data; to act as a clearinghouse for trusted information. In 1995, according to the CERT website, there were 171 vulnerabilities reported to CERT. In 2005, there were 5,990 vulnerabilities reported. If the remainder of 2006 tracks with first quarter results, CERT will log over 6,388 reported vulnerabilities. Clearly, we are on an unfortunate upward trajectory.
Those 60,000 computers connected to the Internet pale in comparison to the some-200 million hosts now estimated to be connected to the Internet. It's no surprise, then, that the volume of vulnerabilities reported has increased significantly. Today, there are numerous resources available to anyone who wants to form a security response team and there are also various organizations including the Forum of Incident Response and Security Teams (FIRST) and the TERENA-sponsored TF-CSIRT, a task force for the collaboration of incident response teams in Europe. If you're interested in these topics, visit the CERT site at www.cert.org.
Most organizations don't plan for incident response until after they've had their first incident. This leaves most organizations without even basic knowledge about their network status, such as:
■ Not knowing if, for how long, or to what degree the network has been breached
■ Not knowing what information has been stolen, modified or corrupted by the breach and the criticality/sensitivity of that information
■ Not knowing what method(s) the intruder(s) used to gain access to the network
■ Not knowing how to stop a breach in progress
■ Not knowing who should respond and in what manner
■ Not knowing who has the authority to respond
■ Not knowing who to contact regarding the breach (executives, legal counsel, law enforcement)
These problems are amplified by companies with offices in multiple locations, whether domestic or international. Without a clearly defined plan in place, you're putting your company's future at risk. Many companies hold mistaken beliefs about forming an incident handling team. The reasons run the gamut, but here are a few common attitudes that get some companies in trouble:
■ It's too intimidating; ignore it and it will go away.
■ Just take care of problems as they arise.
■ Our firewall keeps us safe.
■ It's too much money to spend on something as non-strategic as the network.
■ Dave's pretty good with computers, he'll handle it.
Clearly, being in a state of denial doesn't fix the problem, so part of your job is to advocate for the creation and support of an incident response team.This should be one of the major components of your IT operational security project plan, so let's take a look at the details of what that type of team should do and how to form one.
Was this article helpful?
What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.