Communicating is our hardest job

 

Communicating with one another effectively is the hardest thing most people have to do in the workplace. This may seem counterintuitive - we’re born knowing how to communicate and much of human growth to adulthood involves refining ever more complex ways of expressing ourselves. But people are still, on average, remarkably error-prone.


In 2006, researchers Justin Kruger and Nicholas Epley designed a set of experiments to see how well we communicate over email. One experiment centered on individuals who know one another intimately. In this experiment, participants were given a list of 10 topics and asked to write two statements about each one. Half of the statements were to be serious and the other half sarcastic. Senders e-mailed the statements to another participant, who attempted to identify which sentences were intended to be sarcastic and which were not. The senders then predicted the receivers’ accuracy.


While 78% of the senders were confident the message would be understood, only 56% of the recipients actually correctly classified the tone of the email. Worse, the recipients thought they were understanding properly 90% of the time! Among people who don’t know one another well, the success rates will likely be lower.

Talk more, chat/email less


As the experiments linked above suggest, having trouble communicating isn’t just a thing that happens in large groups. Even in one-to-one communication with individuals we know well we can misunderstand one another. Language barriers, cultural differences, and local slang that means one thing in America but has the opposite meaning in Australia are all things I have observed cause friction in the workplace. Mistakes often increase when you’re under stress, which applies often in DFIR (Digital Forensic & Incident Response) teams. 


Email and Chat tools are necessary for most teams these days, small or large. Their utility grows as a team becomes distributed geographically because timezone and work-hour differences make it more difficult to find times when two people are free to communicate in real time. In these teams, the asynchronous nature of chat/email can be an advantage. However, we too often use them well past their limits and when a face-to-face or at least video-to-video chat would be a superior option. These unproductive conversations often go unrecognized until well after frustration or anger have set in. Despite both being very effective communicators, my former manager and I struggled to understand each other in chats. We eventually had to agree in advance that if we didn’t understand one another by the first 5 minutes of a chat, we would just use Google Meet instead.


In addition to cultural and social differences, people have evolved over millions of years to take into account many subvocal, visual, and audio cues to fill in the gaps mere words leave behind. Many experts believe that between 70 and 93 percent of the messages we communicate to one another are non-verbal. No amount of careful phrasing in chats or emails can really replicate those signals. My advice: If you are emailing or chatting with someone and you’ve had more than a short back-and-forth without coming to an understanding, just bail on the written form and agree to have a video chat or phone conversation.


There are plenty of circumstances where a well-considered document or longer written-form communication (like this one you are reading now!) are a great way to get many points across in an organized way. I don’t mean to discount the value of the written word or minimize the experiences of folks who are more comfortable communicating in written forms than on video chats or in person. But I do mean to say that even for folks who communicate better in writing, there are many types of conversations that are still better performed in as close to a real-time manner and with as many visual cues as possible. Often you can bridge the gaps with creative use of summaries of conversations, keeping meeting notes docs, etc.

Large teams need more formal communications too


As an organization grows and matures, the teams need to move beyond the ad-hoc communications and “I know a person” individual connections that a small organization often uses to quickly problem-solve. These relationships where both participants know one another and have a high degree of trust already tend to be replaced over time by larger pools of people who may not connect with one another often, or at all. Communication professionalization then needs to become more of a focus, because larger or more complex teams will involve people with broader and more varying viewpoints and styles of communicating. In addition, the messages we need to send can become increasingly complex and stressful for both the sender and recipient!


A diverse and large group of partner and stakeholder teams won’t naturally understand some of the normally-unstated context that responders take for granted. Memes that would ordinarily land with perfect precision in a small team can cause upset and controversy in a larger and more culturally hetrogenious groups. For example, an incident “Codename” that seemed perfectly innocuous in one region and was handed over to another region whose responders were appalled at the disrespectful codename.


For all those reasons and more, a professional team will need to put more effort into making sure the message and the medium match the audience. 

Communicating during incidents


Communications during incidents are the peak time when small miscommunications can add up to big problems, and where effective communication becomes the most critical.


Operational Chats vs Executive Updates: It is important to keep executives and other stakeholders (e.g, PR, Comms, Legal, Finance, etc.) informed of ongoing incidents. There may be obligations that an organization has to meet that are much more intimately understood by those parties - for example, SEC reporting rules.


It’s usually not a great idea to have one big, single chat room for everyone. People who aren’t versed in the investigative process can get lost in the details and start urgently requesting answers to questions whose time hasn’t yet come. The investigators will be directly pulled into answering those instead of following objectives set by the incident leads. A best practice here is to ensure that operational channels stay operational - but to do that, a formal executive notification channel needs to be established and attended to. Often this takes the form of an email thread regularly updated (for example, every 4 hours by the incident commander) but for faster-running incidents you may want to create a separate chat room just for the incident leads and stakeholders, and stick to updates and Q&A in that channel.


Ensure formal stakeholders get frequent updates. It’s not enough just to establish a channel for executive updates. If you aren’t regularly updating it and keeping people informed, the channel isn’t doing any good, and questions will be coming at your team from unexpected directions, unexpected people, and at very inconvenient times. Whatever cadence you set needs to be adhered to, even if the latest update is nothing more than “we are continuing to investigate and expect more potential results by $time”.


Templates are a highly useful tool for giving your team a reminder of what sorts of information are expected by which audiences - but don’t go too far and start making rigorous ones that must be filled out a certain way or with specific information, or your templates may become more of a burden than an assistive tool. For things like incident codenames, even having a neutral convention may not be enough to limit harm from culture collisions - you might need to pre-calculate a set of codenames and approve of them in advance before using them. For one example of a formalized method of templating communications to reduce stress and increase accuracy, see the “S.A.L.U.T.E. report” method.


Be more formal about OpSec. DFIR practitioners are used to working with operational security (OpSec) at the core of our work. Keeping information tightly controlled during an incident helps us ensure that attackers who might be listening don’t get tipped off, that information doesn’t widely spread until we are sure the information is correct, and that parties not involved in the incident don’t begin doing their own investigations that interfere with the DFIR team. Keep in mind though that OpSec may be far less second-nature to the partners you need to work with. If you’re inviting others into the incident it is best to specifically write down what the expectations are for how people will handle information. Include information about who approves of sharing things, how to obtain that approval, and how to share information within the incident. This goes hand-in-hand with Templates, above: A “Operational Security guide for Incidents” guide that is easy to hand people during a major response can be a huge time saver and smooth communications.

More general communications tips


Even in less stressful, day-to-day situations, there are a number of communications missteps that response team members can make. Here’s some things to watch out for before, during, and after incidents.


Combat Gap-Filling. For thousands of years, humans looked at the night sky and saw patterns in the stars. The shapes of the stars became mighty hunters chasing stags across the sky. They became the silhouettes of the gods dancing, or giant cats in the sky with detailed background stories explaining their lives.


When people have gaps in their understanding, they will try to fill those gaps. It’s only too human that sometimes people will make up information that seems to tie the gaps together. When this happens during your incident, misinformation spreads. One way to combat this is to try to be as complete as possible when relaying information. This may conflict a bit with OpSec (above) but a proper balance usually includes completely explaining to incident participants your specific OpSec expectations and why they’re important to maintain. What will happen if someone spills information early?


The most important information I have seen Incident Commanders forget to pass on is why the team is doing a particular thing. While it’s great to tell a set of engineers that you need logs from X system and you need them by Y time, it’s also really helpful to tell them the purpose of your request: “We are trying to validate whether the attackers might have done Z.” You’ll often find that when you go the extra mile to include the why behind your request, these experts in the system can think of new and better ways to determine the answers than you. One good example of including situational awareness in communications comes from the US Military’s “Five Paragraph Order” structure - see page 7 of the PDF.


Don’t make people guess! Eliminate acronyms and pronouns from your vocabulary when in “Incident mode”. One of the ways in which our brain tricks us while writing communications is that we have the direct context, fully in our heads, about which actor is which in a sentence. Consider this statement: “The VRP reporter notified our security team that the vulnerability is a critical RCE. They’ve tested an exploit and it works perfectly.


In that sentence, who has tested the exploit? Is the VRP reporter claiming that they have done so, or are you claiming that your VRP team has tested one internally and validated the researcher’s findings?  A more clear rephrase would be “The VRP reporter notified our security team that the vulnerability is a critical RCE. The VRP team tested an exploit which works perfectly.” In both incident and non-incident communications, I often take a moment before sending a chat or email, look at anywhere that I’ve used an indirect pronoun, and consider whether the communication would still read well and would be more clear if I removed the pronoun and replaced it with something more specific. 


Don’t hedge - be explicit and factual.  I often see communications pointed toward stakeholders with a position of more power than the communicator - e.g. legal leads, executives, etc. - where the speaker is afraid of being wrong. They’ll couch their communications in weasel words or hedges, such as “We believe that…” or “The actor seems to have…”. When you need to convey uncertainty, try to convey it in specific ways. For example, “The logs indicate that the actor attempted to X. We are not yet confident they succeeded, and need to finish analyzing Y logs to be sure.” Intelligence agencies have become very adept at using the “Analytic Confidence” scale to be exacting about uncertainty when needed.


People work like TCP, not UDP.  The majority of the burden of communications is typically on the person trying to send information, because only that person is capable of knowing what needs to be communicated and verifying if the recipient accurately understands it. However, the recipient isn’t off the hook. People don’t work like UDP, where you broadcast a message at the target and assume everything is fine. People work more like TCP - you often need to send your message and then actively confirm that they received the meaning within it that you meant to send. This is how a good communicator (or communication protocol) adapts to noisy and lossy mediums. And remember, chat and email even if done perfectly are missing nearly 100% of your sublingual and nonverbal signal.


The receiver can be of great help here, so don’t be a passive recipient of communications. If you have any uncertainty about what someone has communicated to you, as the recipient of a message, you have to clarify. This applies to factual information for sure, but don’t forget that many messages convey tone, and tone is easily mis-interpreted. Do you think the sender is angry at you for some reason? Are they being sarcastic? Don’t assume they are a jerk - ask them to clarify! Remember, as the message recipient you are the only one who knows the message landed wrong. The sender likely has no idea - it's on you to set things back on the right path.

Even more reading


There’s likely more communication tips that are relevant in your own organization, whether it’s a tiny nonprofit or a huge global organization. If you’re looking for more good sources on reading and advice for good communicating, there are a few books which I and some of my colleagues highly recommend:


Comments

Popular posts from this blog

Parsing the $MFT NTFS metadata file

Incident Response in the Cloud

Container Forensics with Docker Explorer