Imagine this scenario: Your website has been down for the past ten minutes and the techies, rightly I must add, are scurrying around trying to identify the root cause. Given the limited tools (due to the budget cuts announced last year), they have limited visibility into the origins, the method of attack.
Eventually, one techie shouts: "This is a massive DDoS attack! A distributed denial of service attack and that your site is being attacked by hundreds of thousands of zombie machines! Panic!"
“Get everyone on the bridge! Now!” barks the head of operations and you, the CISO and or the CIO and every man and woman worth a title jumps on the bridge along with the techies. Let’s not forget the outsourcers. Multiple accents, time zones, and people are all clashing trying to stop a zombie DDoS attack.
“Oh, by the way, I can access the site now, its back up,” says one of the techies on the call.
In the meantime, while the drama of the DDoS was playing out, the interim CFO tried to call the IT manager to report an incident on her machine. She had clicked on a link in an email and there was an explosion of several internet explorer windows. She could not close them fast enough.
More on incident response
- Security Think Tank: Planning key to incident response
- Security Think Tank: Incident response – prepare, test, and test again
- Security Think Tank: Three steps to effective incident response
- Security Think Tank: The dos and don’ts of a good incident response plan
- Security Think Tank: Ready for your data breach moment?
- Security Think Tank: Key elements of an incident response plan
- Security Think Tank: Minor failings can trigger major data breaches
But the IT manager had told her he would call her back because he was busy with a major DDoS incident affecting the front-end website. The interim CFO did not push him, surely the DDoS was more important than her internet browser behaving badly.
In the end, the CFO just restarted her machine. Problem solved.
This is a common setup in many organisations and something that I have seen many times. Okay, it is not common to see a DDoS and the CFO’s laptop misbehaving but I am trying to make a very important point - hear me out.
Most incident plans and the creators behind them are still living in the static and visual age. What do I mean by that? The impact of a DDoS can be seen by all, your customers, your employees, your shareholders! It is totally natural to ply all resources into its resolution.
The interim CFO’s issue is a singular non-impact incident that is nothing but an irritant affecting a single individual.
Here is what happened next:
The interim CFO’s laptop had experienced a targeted attack by an ideological group of cyber activists. The irritating windows that kept cropping up was a purposeful design of the malware that this group had purchased from the dark underbelly of cyberspace.
The malware was installed and had dialled back home informing the buyers that it was ready for the next set of commands. To cut the story short, the cyber hacktivists infected the chief marketing officer’s laptop, where they hit “gold” in the form of a list of the half a million customers personal information including name, address, date of birth etc. They stole the data and published it on the internet for everybody to see
The company was not only fined by the regulators, but also named and shamed by the media affecting its brand reputation and eventually its share price.
So what should a CIRP or Cyber incident response plan contain?
The organisation creating the plan, must start by acknowledging that:
- A cyber attack is imminent and it is not the size and visible impact of an attack that should drive the plan. The smallest of incidents can have the biggest of impacts.
- The attack may be too complex to fully understand or feel its immediate impact.
- The need for “Info Sharing” mitigation is the first and most effective line of defence.
Most importantly: The CEO, senior executives and the board of large organisations must understand that they will fall victim to a cyber attack. In addition, the organisation’s C-suite must be responsible for managing a cyber incident rather than sysadmin and helpdesk.
Although the heading refers to what must be in an incident plan, I am going to take a different approach for now by arguing that there are some things that must never be considered in a CIRP or Cyber Incident Response Plan. These are:
- A DR approach: Do not include, copy or plagiarise a DR plan. A cyber incident is not similar to a disaster in many cases.
- A list of attack scenarios: Do not create an impossible list of all possible attack scenarios that are then compiled into a tome that no one ever reads.
- Save the planet: Do not write and print 500-page documents that detail the steps for remediation.
- Process a DOS: Carrying on from point number three, untested processes end up creating a denial of service. Think about it, do not create and expect staff to follow untested useless processes, especially during or just after a cyber attack.
- Skill you NOT: Do not expect anyone to Google a skill at 03:00 in the morning. Enough said.
Executives: Step up to the plate
One reason most plans fail could be because of the lack of executive support and understanding. It is becoming evident that most executives and senior management are unable and unaware of how to respond to the growing threat of cyber incidents.
There is no-one advising or guiding senior executives on how to develop these capabilities to make cyber incident response work.
There needs to be a cyber incident response programme (CIRP) for executives that enables them to understand and deal with the threat of cyber attacks.
Amar Singh is chair of ISACA UK Security Advisory Group
This was first published in July 2014