In recent months, we have seen a perfect example of an incident that called for an emergency response. The sudden disappearance of Malaysia Airlines flight 370 makes us all wonder about the silence in the cockpit prior to the moment that the plane dropped off the radar.
In this era of constant communication, silence raises suspicion. However, there are times where general communication should not be the first response. One is in a life/death situation, such as an emergency aboard a failing airplane. Another example is in the case of a medical emergency, where the only communication is the rapid-fire response shared by the attending medical team.
In the field of computer security, a severe equipment failure or a security breach calls for the same rapid response without immediate communication outside of the responding team. Simply stated, communication comes later in the process. It is perfectly reasonable to expect more immediate communication, but when communication hinders the recovery effort, then the expectations either need to be reorganized, or the response team needs to be augmented.
In the field of aviation, we can draw upon a memorable incident to illustrate the point. At the moment when Captain Chesley ‘Sully’ Sullenberger knew his plane was in dire trouble and he made his legendary landing in the Hudson River, no more than eight words were shared: to the passengers, he said, “Brace for impact”, and the air traffic controllers were told, “We’ll be in the Hudson”. When interviewed about the mysterious silence of flight 370, Captain “Sully” echoed the same sentiment, indicating that communication is not the primary focus in a crisis.
Too often, when a computer security incident occurs, the responding team is interrupted with phone calls from the C-Level with the expectation of a ‘full report’, or worse, an exact time when things will be up and running again. Fortunately, virtualization and cloud technology have dramatically reduced down-time during a crisis, but the process of switching over to a redundant system is slowed if the phone is ringing with the expectation of an immediate explanation.
In an unrelated report of the missing Malaysia airliner, another analyst stated: “Aviate, navigate and, lastly, communicate is the mantra in such situations”. This makes a lot of sense, and I am sure that there are many more examples in other professions where the primary goal is to stabilize the situation before communicating every detail.
In the field of information security, the prevailing approach is similar: mitigate, remediate and then communicate. Because we are generally not dealing with life-and-death situations, we should wonder: Is there a way to move communication to a higher priority? I propose that we can do so in a way that would not only raise our professional posture, but also make us more respected as part of the business process.
We are all keenly aware that most executives are not computer scientists. They are outsiders to both our language and our process. This creates a greater communication delay, as we are required to first understand the problem ourselves, and then translate it into non-technical language. Think for a moment how you would explain the recently disclosed Heartbleed exploit to someone who does not understand what SSL means. Could you do that, and how effective would you be as you were mitigating or remediating the problem?
Examine your existing incident response team. Is there a junior member of your support team who is eager to learn more of the higher-level operations? Rather than send the junior member out to pick up coffee while the senior members of the team work on the problem, this is the perfect candidate to act as the on-the-spot reporter in the time of a crisis. Press that person into service as an incident recorder, translator and, possibly, communicator. A junior member will learn more about your systems and operations as a participant in the documentation of a crisis. This will augment the incident response team at no additional cost to the organization.
As part of your incident response plan, make it clear in advance to the C-level that in the time of an emergency, they are to resist the urge to ask for ‘the person in charge’ and trust the appointed contact to communicate the situation from the war room. Once the emergency is brought under control, you will then be able to communicate directly to the senior managers; however, if your reporter is effective, your follow-up will become more about how to prevent a future occurrence, because the remedial steps will have already been conveyed up the chain of command as they were occurring.
The appointment of an incident reporter adds the value by raising the junior member’s visibility to the C-suite, adding quicker situational awareness for those executives, and demonstrating your excellent leadership and management skills.
Neither a flight crew nor a medical team can have the luxury of an on-the-spot incident recorder, translator and communicator. We rely on black boxes and post-trauma incident reports to fill in those informational gaps. However, in the realm of information security, we can boost our profile and our value by better using the team that serves us in non-critical events.
Bob Covello is a 20-year technology veteran, security analyst and freelance writer with a passion for security topics. He is also a volunteer for various organizations focused on advocating for and advising others about staying safe and secure online.