How to assist non - technical end users communicate effectively and concisely during incident response?

Question

As a member of the Information Security team at my workplace, triaging, researching, and escalating if necessary of SIEM / IDS alerts is one of my job duties. I work at central company headquarters but there are also employees at remote offices.

Today while researching a IDS alert, I had to reach out to a non - technical remote user at another office for additional information. The end user had trouble providing a lot of the information I was asking for - e.g: how they are connected to network and accessing resources (e.g onsite, remote from home, through company VPN, direct or through proxy etc?) a clear description of what they see on their screen, their computer behavior at time of alert such as what they were doing (e.g: browsing, coding etc). I explained why I was asking for this information and restated the request in alternative ways, but it not help. The end user was just as confused. It was a frustrating experience, and in the end, I had to request assistance from another colleague.

Given the time sensitive nature of the task, and that a potential security incident was occurring, there was not enough time to teach the end - user , or guide them in detailed procedures. Visbility as to what was happening locally at that site in the SOC was limited. Technological support at the remote site was very limited. It was painful watching in the SOC of continued SIEM alerts for which response was hampered.

As I cannot physically interact with my colleague, what else could I have done to improve communication?

Alternatively, what can InfoSec, and more generally, IT employees do, to assist non - technical colleagues to communicate effectively in times of stress / emergency?

Answer 1

I explained why I was asking for this information and restated the request in alternative ways, but it not help.

Most of the time, non-technical users don't just struggle with your phrasing, but rather with understanding the underlying core concept of what you're asking. Rephrasing your request isn't going to help here, it's just going to create more confusion as they are now unsure whether you're asking for a second thing or not.

---

It was a frustrating experience,

It was frustrating for the user too.

---

and in the end, I had to request assistance from another colleague.

So why didn't you do so in the beginning? How did the colleague solve the issue? Why is the answer to your question not simply "do what your colleague did"?

---

Having worked as the trainer of a call centre, I can tell you that there's a particular skill in providing technical service to non-technical people: knowing how to extract information. As the expert between the two of you, the onus is on you to bridge the gap between you and the non-technical user.

To be fair, the difficult communication you experience is not always your fault. I've dealt with users who described that "their laptop won't start" when in fact they couldn't log in. But even in those cases, it's your task to work through the problem until you stumble on the actual issue.
You can't expect a layman to talk to an expert on the expert's level. No matter how frustrating you find it to have to talk to someone with less technical skill than you; keep in mind that if they had the same technical skill than you, maybe you wouldn't have a job there. Don't resent company employees for not knowing to do the job you're employed to do for them.

As a simple example, I needed to know which version of Windows was installed on their machine (7, 8 or 8.1). This user was clearly not able to find out by themselves; so how would you approach it?

There are some ways to walk them through to getting the right information (the shortest I know of now is to press the Win key + the Pause/Break key), but there was a much simpler way: I asked them to describe the start menu button.

For reference: the start menu button on W7 has a wavy flag in a circular button, on W8 there is no Windows flag, and on W8.1 there is a straight-line flag with no circular border around it.

This was an simple visual distinctionthat a layman could easily differentiate between, and thus there was no issue in communicating with the user. I got my information, the user didn't have to struggle to understand my questions or how to figure out how to answer them, and we didn't waste each other's time.

---

Given the time sensitive nature of the task, and that a potential security incident was occurring, there was not enough time to teach the end - user , or guide them in detailed procedures. It was painful watching in the SOC of continued SIEM alerts for which response was hampered.

This is a failing on your department's behalf. Your department is apparently depending on uninformed laymen for critical time-sensitive information. The difficulty in communicating is an obvious consequence when you've decided to rely on untrained laymen. This is why experts are hired for important jobs.

Your department needs to address this issue. There are many solutions here:

• Find a way to remote into the machine yourself
• Give the on-site users a training on what they need to do when you need them to give you the information
• Ensure that a trained employee can visit the site in a reasonable time frame
• Stop worrying about the time it takes to have untrained and unskilled people perform a task they were never prepared for.

Answer 2

In every programming job I have had in the last decade or two the IT department routinely takes over my PC to solve problems, install new software, etc.

Why can't you?

You may not currently have the ability to do so, but why not ask your boss, who ought to understand the technical benefits and also be able to communicate the need to install such a system effectively to higher management?

Answer 3

Unlikely options (probably not feasible):

• Train employees to have basic computer literacy.
• Do incident response training with your users. A couple hours per user should suffice to make them more proficient at describing what they see on-screen. You could train them to screenshot unfamilliar error messages.
• A structure where select (the most technically inclined) users in every office are trained to assist you with incident response.

Feasible options:

• Incident response training with end users of wildly varying ability, so that your team's interrogative skills improve. Medical professionals require years of training and experience to become good at Anamnesis. That is a people skill that is wholly separate from their medical knowledge and debugging ability.
• Remote desktop/remote admin tools
• Remote viewing and guidance tools - like TeamViewer's Whiteboard, where you can draw on the end users' screen.

A word such as 'icon' seems fairly ubiquitous. The notion of windows, scrollbars, buttons and keys too. A window may 'have focus' or 'be in the foreground'. An experienced, fully functional professional may be able to navigate to and press a button within a pogram that they are familliar with.... but not know that that is what you mean when you request them to. "Open 'Edge'. / Click the icon with the blue 'E'. / Open a browser window." may be absolute gibberish to them, while "Open the insert name of homepage." seems perfectly logical. My experience is limited to a stint in corporate tech support and I tend to underestimate how big the knowledge gap can be.

One thing I had to learn is that our ability to bridge this gap is situational. As patient as I can be on Christmas day when auntie wants to learn how to 'open the facebook' on her new phone, I am much less amenable to (and creative in) exploring what communication works and what doesn't if I am under pressure to resolve an issue. If I overestimate someone's ability and pressure them too much (or underestimate and they get annoyed with me), we're not getting anywhere. Simply put: If you speak different languages and voice is your only means of communication, you are going to have a bad time. You may not be able to level that playing field, and may need to lower your expectations.

One final example: Context is required for retention. A user that cannot fully understand an error message lacks the context that is required to remember it and describe it at a later time. Even if you can reproduce the error message, they may not be able to confirm that this is the error they got before.

Answer 4

in the end, I had to request assistance from another colleague.

What did the colleague do differently? Why was she/he successful and you weren't?

Or do you mean a colleague of the end user here?

People vary in their ability to convey things. All you can do is to 1) have some remote control tool 2) work on your communication abilities.

Point 2) is super important and many IT professionals could do better in this respect. You could try developing your overall abilities in this respect by e.g.

• talking to general (non-IT) audiences about IT topics,
• reading articles on IT in newspapers that target non-specialists,
• observing how your colleagues who communicate effectively, communicate and emulating them,
• preparing cheat sheets: terms to avoid and to use when interacting with non-IT people.