Security Awareness: A 5-step Process to Making Your Training Program Role Based and Relevant

Security awareness training is one of many strategies used by companies to reduce their security risks. It seems like an obvious thing to do, considering the fact that almost every attack contains some form of social engineering as the initial perimeter breach. In most cases, it is a phishing e-mail.

Security awareness training is often cast as a mandatory training for all employees, with little customization or role based adaptation. As discussed previously, this can have detrimental effects on the effectiveness of training, on your employee’s motivation, and on the security culture as a whole. Only when we manage to deliver a message adapted to both skill level and motivation levels we can hope to be successful in our awareness training programs: When does cybersecurity awareness training actually work?

So, while many employees will need training about the identification of malicious links in e-mails, or understanding that they should not use the same password for every user account, other employees may have a higher level of security understanding; typically an understanding that is linked to the role they have and the responsibilities they take. So, while the awareness training for your Salesforce may look quite similar to the awareness training you give to your managers and to your customer service specialists, the security awareness discussions you need to have with your more technical teams may look completely different. They already know about password strength. They already understand how to spot shaky URLs and strange domains. But what they may not understand (without having thought about it and trained for it) is how their work practices can make products and services less secure – forcing us to rely even more on awareness training for the less technically inclined coworkers, customers, and suppliers. One example of a topic for a security conversation with developers is the use of authentication information during development and how this information is treated throughout the code evolution. Basically, how to avoid keeping your secrets where bad guys can find them because you never considered the fact that they are still there – more or less hidden in plain site. Like this example, with hardcoded passwords in old versions of a git repository: Avoid keeping sensitive info in a code repo – how to remove files from git version history

So, how can you plan your security conversations to target the audience in a good way? For this, you do need to do some up-front work, like any good teacher would tell you that you need to do for all students; people are different in terms of skills, knowledge, motivation for compliance, and motivation to learn. This means that tailoring your message to be as effective as possible is going to be very hard, and still very necessary to do.

The following 5-step process can be helpful in planning your content, delivery method, and follow-up for a more effective awareness training session.

A 5-step process for preparing your awareness training sessions.

First, you need to specify the roles in the organization that you want to convey your message to. What would be the expectations of the role holders of a good security awareness training? What are the responsibilities of these roles? Are the responsibilities well understood in the organization, both by the people holding these roles, and the organization as a whole? Clarity here will help, but if the organization is less mature, understanding this fact will help you target your training. A key objective of awareness training should here be to facilitate role clarification and identify expectations that always exist, but sometimes implicitly rather than explicitly.

When the role has been clarified, as well as the expectations they will have, you need to consider the skill sets they have. Are they experts in log analysis from your sys.admin department? Don’t insult them by stressing that it is important to log authentication attempts – this sort of thing kills motivation and makes key team members hostile to your security culture project. For technical specialists, use their own insights about deficiencies to target the training. Look also to external clues about technical skill levels and policy compliance – security audit reports and audit logs are great starting points in addition to talking to some of the key employees. But remember, always start with the people before you dive into technical artifacts. And don’t over-do it – you are trying to get a grasp of the general level of understanding in your audience, not evaluate them for a new job.

The next point should be to consider the atmosphere in the group you are talking to. Are they motivated to work with policies and stick with the program? Do they oppose the security rules of the company? If so, do you understand why? Make sure role models understand they are role models. Make sure policies do make sense, also for your more technical people. If an underlying reason for low motivation to get on board the security train is a lack of leadership, work with the senior leadership to address this. Get the leadership in place, and focus on motivation before extra skills – nobody will operationalize new skills if they do not agree with the need to do so, or at least understand why it makes sense for the company as a whole. You need both to get the whole leadership team on board, and you probably need to show some leadership yourself too to pull off a successful training event in a low motivation type of environment.

Your organization hopefully has articulated security objectives. For a more in-depth discussion on objectives, see this post on ISO 27001. Planning in-depth security awareness training without having a clear picture of the objectives the organization is hoping to achieve is like starting an expedition without knowing where you are trying to end up. It is going to be painful, time-consuming, costly, and probably not very useful. When you do have the objectives in place – assess how the roles in question are going to support the objectives. What are the activities and outcomes expected? What are the skill sets required? Why are these skill sets required, and are they achievable based on the starting point? When you are able to ask these questions you are starting to get a grip not only on the right curriculum but also on the depth level you should aim for.

When you have gone through this whole planning exercise to boil down the necessary curriculum and at what level of detail you should be talking about it, you are ready to state the learning goals for your training sessions. Learning goals are written expressions of what your students should gain from the training, in terms of abilities they acquire. These goals make it easier for you to develop the material using the thinking of "backward course design," and it makes it easier to evaluate the effectiveness of your training approach.

Finally, remember that the training outcomes do not come from coursework, e-learning, or reading scientific papers. It comes from practice, operationalization of the ideas discussed in training, and it comes from culture, when practice is so second nature that it becomes "the way we do things around here."

To achieve that you need training, you need leadership, and you need people with the right skills and attitudes for their jobs. That means that in order to succeed with security, the whole organization must pull the load together – which makes security not only IT’s responsibility but everybody’s responsibility. And perhaps most of all, it is the responsibility of the CEO and the board of directors. In many cases, lack of awareness in the trenches in the form of no secure dev practices, bad authentication routines, or insufficient testing stems from a lack of security prioritization by the board.