Should corporate security training be tailored based on a users' job role?

Question

I work in the Information Security team at my workplace. We work in the insurance and healthcare industry and work frequently with customer credit card, financial, and private health data.

Today I was meeting with security management to plan for this year's annual security training curriculum. We are thinking about customizing the training modules for end users depending on their job role. As examples:

• Additional, customized training modules for privileged users such as domain admins
• A training module customized for non-IT employees working in customer-facing roles
• A separate training module for developers, perhaps with a heavier focus on defensive coding and software development vulnerabilities - e.g: SQL injection

As the security risk associated with an IT domain admin level user is obviously very different from a non-IT customer-facing employee, it seems customizing the security training to the specific needs of the type of employee is reasonable. What may be important and relevant to an IT employee may not be so to a customer service representative working in a call center, so it seems a one size fits all approach is just ineffective.

However, I can also see the downsides of a customized approach. An end user could possibly reason that because they were not provided a specific module, that training module is not meaningful or important. In other words, it is possible to encourage end user employees to be more lax in their security habits as they associate only what they see in training as important. We want to avoid this perception.

Is customizing corporate IT security training based on job roles and the differing inherent risks associated with those roles a good practice?

What are some possible downsides to such a customized approach, other than described above?

Answer 1

The idea of customising the training to meet user requirements is in fact a very good approach. However, there will have to be certain additions to this approach which will then suit everyone in your organisation.

With that being said, it is very correct when you say that the training required for an application developer will not be the same as an HR person.

However, when you look at structure of ISO 27001, you will see that it has many aspects which will be applicable to all departments, such as access control, asset management and disposal, Intellectual property rights management, Business continuity procedures, Employment procedures, Incident handling, Acceptable use guidelines, Clear desk and Clear screen and much more. You will see that each of these items which I have listed above will be applicable to everyone.

Your training approach should take all these into account while also making the training role-specific. I have been taking an approach that is department-specific. Some modules have been exclusively reserved for certain departments, while most modules are applicable to all departments. Your training schedule should list out all these.

Finally the topics that you impart to your employees should actually be within the limits of your organisation's Information security management system (ISMS). So, if you have a well defined ISMS, look through all the policies and procedures that have been defined for your organisation. This will give you a good starting point to define all your topics.

Answer 2

Security Awareness expert here (awards, best-selling book).

Absolutely, you should/need to customise training to the role/risks.

Many international bodies actually call this out as important:

• NIST CSF (PR.AT)
• NIST SP 800-16
• SANS
• FBI/DHS
• Jonathan Steenland, COO of the National Cyber Center

Those were just what I could recall off the top of my head.

But your questions at the end seem to show a misunderstanding about how the materials would be created.

Set a baseline standard

Your organisation needs to set a minimum standard for awareness that meets the risk profile of your organisation. That means that everyone gets the same basic foundations. On top of that is the role-specific material.

Same material, role-specific examples

But it can go deeper than that to be more effective. I advocate creating material that is role-specific using the same base material, but having the examples be role-specific. Don't show an HR example to the Shipping department. Keep the examples specific to the role, where practical, but cover the same material so that the foundations are the same. This helps to show why the material is important to the employee.

Train to meet the risks

In addition, different roles in your organisation are going to experience different risks, and those unique risks should be addressed in training. Finance and HR experience different risks and need different tools/procedures to meet those risks. The Shipping department is going to have a completely different set of risks. Training should most definitely be customised to the risks.

Yes, that is going to look daunting to anyone who is not a dedicated security awareness curriculum designer. That is a lot of work. And that's why most organisations do not do it. But they should.

Easy mode: Champions

One way to make it easier is to employ a "Champions" programme where selected individuals in each department/risk area are trained and supported to help design, deliver and be a point of contact for the department/risk-specific material. This has been shown to be extremely effective in many organisations. You should then take the custom material that has been shown to work and roll that into your learning program to make it more consistent and repeatable.

Next step: not just role-specific but audience-specific

In addition, I also advocate having different material for the different technological and demographic groups in your organisation. "How to spot a phish" training needs to look different for people who have never heard of the concept before than for IT experts. And the language and concepts used need to be understood by the various demographic groups in your organisation. For example, ask different people whether they know what a "browser" is. You might be shocked to see who has not heard of the term. That means your "How to spot a phish" material needs to either not use the term or train people on it.

Graduated materials

In my materials, I graduate them so that there is a rising skill and knowledge level. People unlock the higher levels when they have shown to be proficient in the lower levels. This means that the IT experts only have to deal with the basic material once, but are challenged by the brand-new techniques in the high levels. New people can grow with the material.

Answer 3

This is more of a communication question than a security one, but I must acknowledge that the result has a strong impact on the global security practices. What matters here is that all employees can think that their activity is considered as important and that their poor practices would have serious effects.

If you present it that way:

• IT admins will follow a module dedicated to their job
• IT developpers will follow a module dedicated to their job
• non IT fellows will follow a generalist module

The risk is high that non IT staff members think that security is not their concern.

As one of my previous jobs was not IT focused, I think that non IT staff members could feel more concerned with the following presentation:

• one generalist module for everybody so that the base is shared among all employees, whatever their specific activity
• one additional module for every group

The content of the additional module is trivial for the IT groups, admins and developpers.

For non IT members, you will have to find examples related to their actual activity. Social attacks are a primary concern for the financial team, confidentiality is a primary concern for the customer service representative teams, etc. That way, you show every group that you have considered their activity and that lack of good security practices in their activity will have serious consequences.

The actual content will not be much different than the first approach, but it could be seen differently.