From firewalls, to passwords, to encryption on one hand, to PCI DSS, ISO 27002 and SAS70 audits on the other, we often assume that all is well in IT as long as we have covered the security and compliance basics. The general perception is that the businesses suffering losses resulting from security breaches are run by people who do not follow such practices.
It is one thing to be proactive, but you still have to prepare for the reactive side of security - for the things you have overlooked.
If your business were to experience a hack attack or some type of data breach, do you feel confident that everything would be taken in stride? Would your incident response team swoop in on the scene to stop the bleeding? What about your customer service personnel - are they prepared to handle the ensuing flood of phone calls? Will your PR team be able to stand in front of a television camera and provide sound answers to the media ferrets' questions? You can throw all the best security controls in the world at your information systems, but it is virtually guaranteed that there is something, somewhere, waiting to be exploited. What is your response plan?
You may be thinking "we don't have an incident response plan." If so, don't feel bad - you are not alone. Many organizations barely have any semblance of a disaster recovery plan much less formal incident response procedures. Interestingly, I had two recent conversations with business colleagues about incident response. One person is well-versed in disaster recovery and business continuity and the other in IT compliance. When I broached the subject of incident response, both asked "What's that?" No doubt, some remarkable insight into the visibility and understanding of incident response. So, just what is incident response?
At a high level, incident response is the formal process of responding to computer security breaches. In the same spirit as disaster recovery and business continuity, incident response procedures involve the who, what, when, where and how when an external hack or internal breach occurs. It not only involves system recovery and restoration, but also breach analysis and formal forensics investigations. Incident response can be seen as your business flight plan for when things go awry, providing guidance on what to do when you need it most.
Captain Chesley Sullenberger, who safely landed the packed U.S. Airways flight 1549 into the Hudson River in January 2009, said "I didn't have time to learn what I needed to know...I had to have done hard work for decades for tens of thousands of hours to prepare for that moment." Incident response is exactly that - advance preparation for a situation where you won't have time to learn as you go along.
It can be argued that incident response is a component of business continuity and such procedures could easily integrate with the business's overall business continuity plan. When you look at the essence of computer security incidents or breaches you have:
1. a stimulus, such as a hacker or malicious insider;
2. an outcome, such as a vulnerability being exploited; and
3. a business consequence, such as the exposure of sensitive records.
Situations requiring the invocation of disaster recovery and business continuity plans are no different. The gravity of the situation becomes clear when looking at real-world security incidents. Take, for instance, these recent security breaches listed on the Chronology of Data Breaches site:
- An employee at a community college had a USB drive stolen from his car, resulting in the exposure of names and Social Security numbers of more than 10,000 current or former students and employees.
- Bank storage bins containing paper waiting to be shredded were stolen, resulting in the exposure of countless sensitive customer records.
- A hacker gained access to the credit card transaction communications stream between a pub and its credit card processing company, resulting in credit card number exposure and subsequent illegal usage for someone's ill-gotten gains.
- Confidential information on 4,500 students was posted on a publicly-accessible area of a university's Web site for months, resulting in life-long exposure of personal information.
How would your organization handle these situations? Do you have procedures in place to respond rather than react? Do key people involved understand their roles and their responsibilities? Does management realize that most states have breach notification laws, requiring businesses to contact customers when a breach has occurred or is suspected?
Security incidents can result from technical weaknesses in computer system configurations and poorly-written Web applications. Operational weaknesses, such as improper system maintenance, lack of training and poor change management are worthy contributors as well. The reality is you have to look beyond recovering from physical disasters. Rather than computer system attacks being an afterthought, they have to be considered in advance.If there is one thing that can be changed to improve this situation over time it is to get - and keep - management involved. Help them understand the issues, relate how security incidents will impact the business, and - most importantly - show that reasonable risk management can only be achieved by planning ahead. As with most things in business, you have to think long-term.