The Chief Information Security Officer (CISO) gave his update to the group.
‘Someone accessed our user database with a set of compromised access credentials they obtained through phishing attacks. We think we’ve lost some PII and unhashed user login info. Unfortunately, it looks as though they also corrupted some of the logs in the SIEM and UEBA systems so we will struggle to work out what happened and identify malicious activity until we can reinstall the last stable instance of the database.’
As he finished, the CISO looked around the group, and received blank stares in return….
——
I don’t know about you, but as a crisis communicator, I’ve been forced to learn the nuances and details of all kinds of technicalities, FAST. Our role is to explain the intricacies of an event to a skeptical and worried public in a way that is clear and understandable, but also in a way that allows them to make appropriate decisions.
This has always been a challenge with anything technical but cybersecurity and data breach issues take this complexity to a whole new level. Therefore, to be effective as communicators, we need to stay up to date on technical issues but in addition to our own knowledge, we are reliant on subject matter experts. Unfortunately, this only works where we can communicate effectively with other teams which isn’t always the case.
And that’s the real subject of this article: how can we ensure that teams can communicate effectively when the subject at hand is very technical?
For example, we were recently engaged in a situation where we had three separate ‘war rooms’ set up to deal with a potential data breach. There was a legal war room, an IT war room, and a communications war room. We advocated for one single war room, coordinating and focusing all the activities associated with the response, but the company decided to set up the three teams with information shuttling between each room, virtually as well as physically.
This added a lot of procedural friction on top of something that was already complicated. But what it also did was hinder everyone’s understanding of what was happening. Worst of all, when teams did interact, we would have conversations like the one I recounted at the start of this article. The result: confusion.
One role that I had never thought about before became critically important in that situation. This was the go-between from the IT team who liaised with the other war rooms.
We nicknamed this person the ‘Risk Whisperer’.
In this case, the ‘whisperer’ was a cybersecurity expert who moved between the IT, legal and communications war rooms, explaining the technical response but in a way that everyone could understand. This ensured that everyone had the information they needed for their own decision-making and that teams could coordinate more effectively. This was highly effective and overcame many of the other issues we had running three separate teams.
That success caused me to think about the risk whisperer role in more detail and try to define it more specifically.
In my mind, the whisperer is a subject matter expert who has a deep understanding of the technical issues but can translate all of the specialist jargon and complex concepts into layman’s speech. Their role is to explain to other teams what is happening and the potential consequences of the event in a way that they can understand and use for their own planning purposes. In turn, the whisperer also takes the issues and concerns of other teams back to the technical team so they understand the wider response.
It is important that we remember everyone has their own jargon. So while we might be comfortable as communicators talking about stakeholders, issues versus incidents and deciding if we should conduct a down-the-line or face-to-face interview, others will be baffled by these terms.
This highlights that every team needs their own whisperer but not everyone will be suited to this role so I identified four key characteristics that you should look for when you choose a risk whisperer.
The first thing is that the person has to be a true subject matter expert. They have to have the credentials, the knowledge and really understand the topic at hand. Although this article uses the example of cybersecurity, there are many other highly complex issues such as food safety, health care delivery, financial regulations or infectious disease.
However, although the start point is selecting a real subject matter expert, that’s not all that is required.
The second requirement is that the whisperer has to have the ability and patience to explain complex, multi-layered issues in a simple, clear way which is still technically accurate. That links directly back to their subject matter expertise and I believe that those who truly understand something are the people that can really explain it best. But this need for technical accuracy is also important because the whisper’s role is not to dumb things down or gloss over the facts as other technical experts will still hear and read what the organization says about the event. Rather, their job is to explain things in a way that both the layperson and expert will understand what is happening.
Remember to not overlook the need for patience, especially in a crisis. People will quickly become frustrated trying to explain things to people who ‘just don’t get it’, particularly where time is tight. The risk whisperer may have to repeat the same thing to different teams over and over but a little patience, and taking the time to ensure that everyone understands the situation, can be the difference between the success or failure of the response.
The third thing that the whisperer needs is the confidence and force of personality to ensure that their perspective is heard and understood. Everyone will have an opinion about what critical information to share versus what is merely background. But there may be points which appear mundane to the layperson which are still technically relevant to the situation. The risk whisperer needs to ensure that these critical points aren’t cut from any messaging so that external subject matter experts still hear what they need to hear.
The fourth and final characteristic is that the person needs to be a good presenter themselves. When you think about an effective ‘talking head’ on television explaining a complex topic, they understand the very small window they have to explain something complicated. They will be adept at creating the right 8-20 second ‘sound bite’ as they’re answering the interviewer’s questions. Even if they aren’t called upon to show up on TV, the risk whisperer needs to be able to present information clearly and in bite-sized pieces (or in the case of cyber, byte-sized pieces) which will be easier to consume and understand.
Many subject matter experts have spent their whole career building their knowledge and expertise but without these other characteristics of patience, confidence and an ability to present, they won’t be an effective risk whisperer.
So the next time you are a crisis situation that has significant complexities, whether these are IT-related, legal matters, concern food safety or deep-water drilling, identify who is going to be the risk whisperer as early as possible. And remember, we have our own communications jargon and technicalities so make sure you practice what you preach.
——
The CISO’s deputy saw the blank stares and smiled. She looked at her boss who gave her a nod before she turned to the group.
‘OK. Let me put that in a different way. So what happened was that someone posing as an employee sent emails to staff to try to get them to reveal sensitive personal details. It looks as though they were able to get enough information on one person to recreate their ID and password to access the user database. It looks like they have downloaded a lot of personal information such as names, addresses, and emails along with these users’ login IDs and passwords. This data was not encrypted so everything they have is readable in plain text.”
She paused and seeing the team nodding in understanding, continued.
“We have two systems we use to monitor activity. The SIEM monitors our own IT system and the UEBA tracks user activity. Both are designed to detect unusual behavior but it looks as though the attackers have interfered with these systems too so we can’t identify what is normal versus abnormal behavior at the moment. We have a backup of these system logs which we know is unaffected and we will be reinstalling that later today which will allow us to start monitoring the system again.’
This time, instead of blank stares of confusion, the CISO and deputy saw that the communications team’s thoughts were already turning to how they were going to address these issues with customers and the public.
