Incident Response: It’s Not What it’s Cracked up to Be
Once again you can credit Paul Underwood, Emagined Security’s COO, for the inspiration for me to write this blog posting. Yesterday Paul sent me an email informing me hat he had recently received fraudulent email that claimed to have been sent by American Express. He contacted American Express, and because the perpetrator had poached a domain name, he also contacted Network Solutions to request that they remove the www-unu.com domain and suspend the account that created the domain name. Network Solutions did nothing and American Express did not respond, either.
I’ve never forget when the infamous cracker “Staccato” broke into so many systems at Berkeley Lab not all that many years ago. One host after another fell victim to Staccato’s attacks and there appeared to be no end in sight. In desperation, I called the US CERT to try to obtain some additionally information, but about 30 seconds after someone answered the phone, I realized I had made a big mistake. Whoever answered the phone obviously was having a bad day, and my phone call must have put her over the edge. After being asked each of a long series of questions (what is your name, what is your address, what is your phone number, where do you work, how long have you worked there, what is your position, and much more, this people skills-deficient staff member demanded that I say no more until she had recorded each of my answers to her satisfaction. When she finally got around to asking me what was wrong, I described the pattern of break-ins that had occurred. I quickly realized that she was not very technically proficient; I found myself having to explain very simple technical concepts (such as what the network file system is) to her. I soon realized that I was completely wasting my time and tried to gracefully break off the call. She replied that I had to stay on the line. I finally told her I had something else to do, said goodbye, and hung up. About five minutes later someone from the US CERT who must have found my number from caller ID called me back and in a very overbearing tone said that the US CERT was not through with me yet. This person persisted in asking me more questions. Not surprisingly, I obtained no useful information whatsoever, and although this person said he would get back to me concerning the information I had reported, I never even heard back from him or anyone else from this response team. Not surprisingly, I have never called the US CERT again.
When incident response teams initially emerged in the late 1980’s, expectations were very high. CERT/CC and the Department of Energy’s (DOE’s) Computer Incident Advisory Capability (CIAC) were the first two incident response teams, and many additional teams followed suit. Looking back, I realize that the early incident response teams did not really intervene in all that many incidents. Still, they served a useful purpose because they helped educate individuals, especially system administrators, about the necessity of learning about and patching vulnerabilities as well as how to systematically and efficiently respond to incidents. Additionally, someone could always call them for some help and advice. Today things are considerably different. People know a lot more about incident response policies and procedures, and many inhibiting factors (of which revealing sensitive information to people outside of one’s organization is one of the most important) keep people from wanting to report incidents to incident response team. Aware of this problem, numerous US government agencies have issued edicts requiring individuals in these agencies to report all incidents to their agency’s incident response team. What has resulted is almost too hilarious to believe—individuals tend to report myriads of worm and virus infections, while at the same time they withhold information about more serious incidents out of distrust of the incident response team or because of fear of being punished by their agency for having had a serious security breach.
Something is badly lacking in many of today’s incident response efforts. Incident response has to change. Organizations too often do not take security-related incidents seriously. People lose money. Companies lose money. Individuals have their identities stolen. This trend is bound to continue unless something changes. The impetus for change will either be mounting financial loss or legislation or perhaps both. Meanwhile, it has been over two days since Paul contacted American Express and Network Solutions, and he is still waiting for a response!