Part of the Secure Continuous Delivery series.

Security Education and Awareness

Sunday, 27 November 2016

In the previous article we introduced a basic delivery pipeline as a point of reference for this series. One of the risks I presented initially was the tendency to reach for tools and automation instead of starting with education and training. To then dive into particular tools and techniques would be contradictory, so we’re going to start with education and awareness.

Bearing in mind the focus of this series is on Secure Continuous Delivery, we’re specifically looking at the education and awareness aspects of security as it relates to software delivery. That means the standard infosec training you provide to all staff is a different issue (although many of the points below are equally applicable to that).

Who should I train?

Everyone! Seriously. All too often I hear security training being discussed as something to send developers on. “Send them on a secure coding course”, is a common response when confronted with the challenge of producing secure software. This is far too limited a view, in my opinion. Every role has a part to play in secure software delivery and we must help develop their skills in this area, whether we’re talking to business analysts, developers, user researchers, testers, scrum masters, architects or delivery managers. This is not to say that everyone must be a security expert; but everyone should have a foundational level of knowledge and awareness of their responsibilities and how to fulfill them.

Ditch your Flash CBT!

For many of us, the thought of going on security training fills us with dread. I suspect most of us have been subjected to the dry, Flash-based CBT that all new team members are forced to endure. This is perhaps the worst way to encourage good security practices in any organisation. They’re boring, entirely lack context, and fail to make any lasting impression on an individual. If you’re primarily concerned with being able to say that you’ve done security training for your staff, then by all means continue; but if you genuinely want your staff to be more security conscious, you’ll need to take a different approach.

There is plenty of research showing how we’ve trained users to: choose bad passwords through regular password expiry (more here and here), ignore security warnings through poor user experience or task interruption (more here), and work around security policy to get the job done (more here and here). Security training as it is currently implemented in many organisations falls foul of the same mistake by failing to engage staff adequately and make the topic relevant to them.

To draw on an example from another industry, when did you last watch the pre-take-off safety video / demonstration on a flight?

What does good look like?

Assuming you agree that we can and must do better than Flash CBT… how should we raise awareness of security? Here are a few points that you should take into account when developing a security training program.

Good security training is brief

This is about the only thing that Flash CBT got right. People are busy. They’re invariably juggling many different tasks at the same time; and they’re probably distracted by emails, text messages, other meetings, deadlines looming, budgets, and much more.

Training comes at a cost, so it needs to deliver greater value than it takes away. One way this can be achieved is by getting to the point quickly and effectively and not taking up more time than is necessary.

Good security training is contextual

Topics like data protection might be interesting to security practitioners, but to most people it’s dull. This is often because we’ve made little effort to speak to people using language and examples that are relevant and contextual to their jobs. Back in my school days, the most frequently asked question was “When are we going to use this in real life?” (second only to “Will this be in the exam?”). People need to know why the information you’re sharing with them matters to them, otherwise they will either ignore it or remember it just long enough to pass the test.

We also need to be sympathetic to the role they play in the organisation and tailor the content accordingly. I would expect the training given to software engineers to be radically different from that given to the marketing department or contact centre agents. Most importantly, make sure you train the decision-makers as well as the doers. Quite often people are promoted within companies and take on significantly greater responsibilities. At these transition points, we need to help them step into their new role with full awareness and understanding of what that means for them, their team and your customers.

Good security training is memorable

I’ve personally gained far more from training when the sessions are interactive and fun. Many of us share the challenges of information overload in both our work and personal lives, so any training or awareness plans should carefully consider how to make a lasting impression. Gamification techniques are often used to help increase engagement in training. Sites like StackOverflow allow people to earn status amongst their peers through recognition of their expertise and helpfulness. They rarely receive any other reward in return for many hours of free support (although I’m sure many are effectively being paid by their employers to help others as they spend much of their working day on the site).

If you make security training fun, people will remember what they’re taught and be happy to come back again.

Good security training is ongoing

The industry we work in is constantly changing. We need to account for that in the work we do to train others. This doesn’t necessarily mean dragging everyone back to the biggest meeting room you have for another hour-long ‘refresher’. It simply means that we can’t expect a one-off event to be sufficient.

On the more progressive end of the scale are fun events that keep security front and centre, for example running hack days or CTF (capture the flag) competitions. You could also take a feather from the hats of charities who are often masters of raising awareness through various events. If your company sponsors or partners with a charity, maybe ask for their advice on how to get people thinking about a topic that’s otherwise not on their mind.


With all this in mind, you may be wondering what topics you should consider covering in your training schedule. Here is a short list of ideas to get you started, along with a particular role that would benefit from each topic.

  • Prioritising security (Product Owner, Architect, Business Analyst)
  • Balancing security and usability (all roles)
  • Writing security into user stories (all roles)
  • Legal & regulatory obligations (all roles)
  • Threat modelling (Architect, Developer)
  • Secure design principles (Architect, Developer)
  • Secure programming principles (Architect, Developer)
  • Testing for security (Architect, Developer, Tester)
  • Measuring security (all roles)
  • Monitoring for security (all roles)