In one of my past lives, before cyber security came along, I was a hostage negotiator.
To give you an idea of just how long ago, during my training we were negotiating (through an interpreter) with “terrorists” who were holding “hostages” in a (very real) airliner, surrounded by (also very real) armed police, parked just off one of the (very busy) runways at London’s Heathrow Airport.
Unexpectedly, I had an up close and personal experience of being very, very close to a BA Concorde taking off at dusk, on full afterburners. I’m not sure that my hearing has been the same ever since!
Many people will have formed their view of hostage negotiating from watching movies, such as Dog Day Afternoon (my favourite), The Negotiator, and Inside Job, but in reality the art of negotiation is much less driven by a charismatic individual with a good haircut and a worrying appetite for risk and rule-breaking, and is much more of a disciplined team sport.
I have been asked many times, is there any similarity between the worlds of hostage negotiation and cyber security and – having given this some considered thought – the answer is yes.
So, here are my top two similarities:
1) Both rely on a strategy and an agreed risk appetite
In a complex and protracted hostage negotiation a Negotiator Co-ordinator who will be part of the Command Team determining the strategy & approach to resolving the incident will be appointed (I was one). On occasions, such as terrorist incidents, there can be political interest (which can affect the risk appetite), and the involvement of other agencies such as military special forces (which brings whole new dimensions of risk).
The job of the Negotiator Co-ordinator is firstly to be part of the Command Team to advise on how negotiation can support the overall incident resolution strategy and – once this has been agreed upon – to determine and execute a negotiation strategy.
As the incident unfolds, the strategy may have to evolve, and negotiation may be kept going to buy time whilst other options are made ready.
In organisations where cyber security works well the CIO or CISO will play an active part in determining the overall organisational strategy. They will advise on how effective security can be a business enabler, and determe what constraints are necessary to achieve the level of security needed to meet the organisation’s risk appetite, bearing in mind legislation and regulation. They are then accountable for the delivery of various aspects of that strategy.
Unfortunately, in my experience it rarely happens like this. More often, the CIO or CISO do not have a seat at the table where strategy is developed and are often tasked with somehow creating an “appropriate” level of security, reactively, as in: after decisions have been made. This often leads to conflict, particularly in organisations embracing “agile” software development, where the very “agile” nature of the methodology can conflict with the stated organisation’s risk appetite and be almost impossible to secure.
Worse, in many cases there simply isn’t an agreed risk appetite, or simply a blanket statement which is meant to cover all aspects of an organisation from R&D (by definition high) to Audit (by convention low).
In either case, things work more smoothly, and with a greater chance of success if the Co-ordinator / CIO / CISO is an active and continuing part of the decision-making function.
2) Success is not achieved in isolation and works best when exercised
A peacefully negotiated outcome is always the aim of any negotiation, but contingencies always need to be made for a situation where negotiation is not possible or fails. These contingencies will always involve a host of other agencies, each of whom needs to understand their role in a hostage taking incident, and how they will interact with the other agencies present.
A critical factor is absolute clarity about which organisation and which person in that organisation is in overall command of the incident, whilst having cognisance of the power vested in stakeholder groups. So, for example, the person in charge of a hostage taking incident (most likely a cop) can do most things, but deploying the SAS requires Ministerial approval (as I found out the hard way on an exercise).
Responding to a major cyber security incident will involve many internal teams (e.g. IT, Comms, Legal), may well have Board oversight, and will probably involve external specialists. In addition, regulators, law enforcement, the media, customers, and investors (to name a few) will need to be kept up to date.
This is far from easy, and there are many high-profile examples in major corporations of where it has gone wrong, particularly when it comes to communication strategy.
The simple answer, reinforced by governments around the world, is that this works much better if there is an Incident Response plan (worryingly many organisations, even surprisingly big ones fail at this), and works even better if said plan is exercised regularly (very few organisations actually engage in Incident Response simulations).
I have run many such exercises, and – spoiler alert – will often tell the key individuals everyone else looks up to for decisions, they are 30 minutes into a 12 hour flight, therefore out of play for the first 11 hours. Whilst this has never made me popular, it does tend to highlight how well decision making can work (or often not) in the absence of key players.
Just as in a hostage negotiation, roles and responsibilities need to be clearly defined for cyber security to deal with a crisis. Who can call in the SAS (or more likely turn off a company’s Internet connection?) if the need arises.
One final note: whilst I had a very cool “Hostage Negotiator” baseball hat – for the very essential purpose of not being shot by friendly fire – I have yet to see a cyber security equivalent!