Would you say your security staff is your first or last line of defense? Your answer to that question should inform the way in which you develop and manage your security training. Regardless of whether you say “first,” “last,” or something in between, however, training is an indispensable part of any security program. Without it, your tools, no matter how good, are reduced to being little more than resounding gongs.
An organization’s most valuable assets are its people. And yet we tend to spend more time thinking about how technology can fix our problems than we do ensuring our people are properly trained to prevent those problems in the first place (or, at least, detect and contain them sooner). Fortunately, standing up an effective security training program is not hard; we just need to start with the basics.
Before we can talk about how to train our staff, we need to consider why we do so. What is it that we need them, individually and collectively, to do for our organizations? You probably have some overarching goals for your security team. You may also have metrics and key performance indicators (KPI) to track your progress. But have you deconstructed your goals into, or mapped your metrics/KPIs to, specific practices or tasks?
Suppose that you work in a Software-as-a-Service (SaaS) company, and one of your security program goals is to protect the confidentiality of your customers’ data. What does it take for your team to do that? You would need a multitude of administrative and logical controls including:
Even with such a short (and definitely incomplete) list of controls, you should already be asking yourself: does my security team have the needed skills to prevent and detect compromises to customer data? Using our short list as an example, you would need expertise in software development, background checks, encryption technologies, identity and access management, as well as data classification and controls. Having distilled the goal into its required practices, you could conduct a gap analysis that would allow you to determine what knowledge, skills, and levels of proficiency your staff requires.
Let’s camp out on the first item on our list of controls: secure software development processes. This is, admittedly, a pretty broad area but we can narrow it a bit for our running example by focusing on cloud services. It is helpful to classify skills by sophistication or maturity. You might, for instance, think of skills in three levels:
If you’re just getting started, you may decide that your team must be able to ensure your products contain no known vulnerabilities before they are released. This means that someone on your team must be able to run vulnerability scans, interpret the results, and create tickets to remediate any findings. But as you think of it some more, you realize that this should all be done in an automated manner. That requires skills in automation for running the scans and automatically creating tickets from them. Then, you imagine a future in which your team might be able to automatically find vulnerabilities as soon as a developer decides to commit code to a repository, ensuring these code flaws can’t even make it into the repository, much less the product.
After going through this drill a few times, you’ll know not only your required skills but also ways to mature them over time. Now, you can assign them to individual team members. The assignment decision should not be arbitrary. Instead, look at it as a way to improve retention and knowledge sharing. If you assign a skill to someone who is already interested in (or even passionate about) it, you’ll end up with a staff member who is more engaged and therefore more likely to stay onboard. The opposite, by the way, is also true: assign it to someone who has no interest or tolerance for it and they’ll be updating their resumes in a week. There is a third case: you transfer the skill assignment from someone who is indifferent about it (or maybe even hates it) to a more receptive person. You not only end up with two happier employees but you also encourage knowledge transfer within your team. In the end, you have an enthusiastic champion but also an experienced backup.
Staff enthusiasm, engagement, and happiness are things we neglect at our own peril. There aren’t enough cybersecurity professionals in the workforce to begin with, so we must nurture and develop the ones we have. This is not to say, of course, that we tolerate sub-par performers. On the contrary, we hold them accountable, but consider, too, whether their performance can be improved through training, perhaps in an area that is a better fit for the individual.
While individual training is crucial, it’s also important to look at the team collectively. In part two of this blog series, we’ll take a deeper dive into cybersecurity training from a team perspective.
Update: Read Part 2 of this series here.
To learn more about IronNet cybersecurity training, visit IronNet.com.