During the internet's infancy, threats generally targeted a large, random audience. "Script kiddies" and "crackers" were the main culprits and their motivation stemmed from boredom to their need for recognition among their peers, writes Christopher Afre, CISSP. Generally, organisations mitigated these types of threats using traditional security best practices (e.g. firewalls, anti-malware, patching). If a threat materialised, the IT department was responsible for responding. In a time when these threats merely caused downtime for organisations, this type of response was adequate.
Today, threats are more sophisticated and the perpetrators are different. More organisations are connected to the internet and provide their customers and partners with access to their systems. Some of these systems likely contain customer or classified information. Further, many countries have enacted breach notification laws. Organisations now face professionals, organised crime, nation states and insiders executing specific and effective attacks. While the primary motivation is money, attacks can be driven by industrial espionage or cyber terrorism. Traditional security best practices are no longer the silver bullet against this new breed of threat. These changes in the threat landscape require organisations to review their incident response abilities and develop a formalised process by which they can identify, contain, eradicate and recover from incidents.
Should a threat materialise, an organisation may have experienced an incident - but what was accessed, what is the extent of the breach, how should you respond, do you need to notify any customers? What happens if you identify the perpetrators and seek legal action? These are all questions that an incident response programme should answer. "Should" is the key word. Too many organisations rely on the fact that they have an incident response programme rather than assessing if it actually works. Testing your incident response programme is as important, if not more, than the programme itself.
The evolution of the threat landscape in conjunction with our increasing reliance on technology has resulted in a structural change for incident response. While the IT department will always play an integral role in any response activity, its role has changed to a supportive one. Today's incidents can affect multiple business units, range widely in scope and severity, and require very different levels of response. To address this complexity, organisations are developing incident response teams. Their purpose is to respond to incidents, prevent incidents from further impacting an organisation's business objectives, and recover affected services. While team composition varies across organisations and industries, teams generally consist of personnel from senior management, IT, physical security, legal, HR, and public relations. However, member involvement in incident response should be based on the nature and scope of an incident, as some incidents do not require everyone's involvement.
Organisations should prepare for a threat landscape that will continue to evolve; however, the basics of incident response will always develop around the same framework: having the ability to identify, contain, eradicate and recover from incidents. The main differentiating factor is the extent to which you develop your incident response; do you perform this function internally, do you outsource a portion of it, or all of it? Organisations should base this on the abilities of their personnel and the extent to which they experience incidents.
It is no longer a question of whether you will experience an incident, but rather when. You need to drive this home to senior management because incident response requires what every other organisational objective requires - their buy-in.
Christopher Afre, CISSP, ISSAP, specialises in risk management in information security, working within the financial services sector.
This was first published in September 2011