Research Is a Cybersecurity Skill. Are We Training for It?

I was working in a government cybersecurity role when my CIO reached out with a request for help. Someone in his local government technology circle had contacted him because their organization believed it was under attack, and their security team needed assistance figuring out what was happening. He passed along some information from a log, and I replied that I would look into it. A few minutes later, another email arrived with an update: the attacker had apparently been targeting them for at least the past few days.

I started researching the information they had provided. After about seven minutes, including checking and rechecking what I had found, I was able to identify the activity as routine scanning by BinaryEdge. That was the explanation for the activity I had been asked to review, and I passed my findings back to my CIO.

What stayed with me was how much that small piece of work depended on knowing how to research something. I had a starting point and a question that needed an answer. Getting from one to the other required knowing where to look, which tools could help, and how to check whether the explanation I had found actually fit the information in front of me. Those are skills I think we should spend more time deliberately developing in cybersecurity.

We expect security professionals to investigate unfamiliar things fairly regularly. An IP address appears in a log. A domain shows up in an email. A process is running on a machine, and nobody seems to know what it does or why it's there. Sometimes the answer is straightforward. Other times, the first thing you find gives you another lead, and you have to pivot from there to keep the investigation moving. How much opportunity do we give people to practice that process before someone needs an answer from them?

Knowing How to Research

Research sounds like a fairly basic skill. We all know how to open a browser and search for something. But there's quite a bit that happens between entering a search term and arriving at an answer you can explain and support. You have to decide what you're trying to establish, choose sources that might help establish it, and understand what the information you find actually tells you.

Consider an unfamiliar IP address. Registration information might tell you which organization holds the address range. Other sources might help you understand how the address has been used or whether it has been associated with scanning. You still have to connect that information to the activity you're reviewing. Finding a name attached to an address is useful, but you need to understand whether that finding answers your question or simply gives you somewhere else to look.

Knowing your tools matters here. What information does a particular tool provide? Where does that information come from? What does it leave out? If two tools give you the same answer, are they drawing from separate sources, or are they repeating the same underlying information? It's easy to collect several results that appear to confirm one another without actually learning anything new.

There's also a practical familiarity that develops through use. You remember which source helped with a similar question, which search terms produced useful results, and which approach led you nowhere. When one source doesn't have what you need, you have another place to try. You don't need to have every answer memorized, but it helps to have some experience working your way toward one.

Making Time to Practice

I think organizations should have a training budget, and part of that budget should support opportunities to practice researching and investigating. Courses and certifications can help develop that knowledge. Hands-on exercises give people somewhere to use it, encounter gaps in their understanding, and work through those gaps before they're dealing with an actual operational concern.

National Cyber League includes open-source intelligence among its challenge categories, and TryHackMe offers OSINT exercises as well. They're examples of the kinds of practical learning opportunities worth considering when building a training program. The exercises should give people experience starting with limited information, choosing an approach, following what they find, and checking their answers. The particular platform matters less to me than whether the work develops skills people can use.

That also requires time. Paying for access to a training platform is a reasonable start, but people need an opportunity to use it during the workweek. If training always has to wait until everything else is finished, it may be waiting for a while. Giving someone time to work through a challenge should be treated as part of developing their ability to do the job.

There could be value in having people occasionally explain their process to the rest of the team, too. What did they start with? What did they try? How did they verify the answer? An approach that worked for one person might give someone else a useful place to start the next time they encounter something unfamiliar. Even the dead ends can be worth discussing.

The BinaryEdge situation was a small example of the kind of question security staff are expected to answer. Someone had information they couldn't explain, and they needed help understanding it. Research is part of that work, and I think it deserves a place in how we train for it. When we're deciding what our teams need to learn, knowing how to work from an unfamiliar clue to a supported answer should be on the list.