Compliance is about measurement. You measure your effectiveness against a standard so you can later present those measurements to a third party as proof of your compliance. One common measurement for companies requiring PCI compliance is security training. PCI Requirement 6.5 (PDF link) states that companies holding cardholder data must train their developers at least once a year on application security topics.
However, compliance-focused measures and practical training often have different aims. It’s not difficult to send your developers to a security training once a year. On the other hand, savvy managers and executives understand that training is only effective when developers understand the concepts, remember them, and use them to actually create secure software.
In this post, we’ll tackle three questions that arise from the struggle to remain compliant. Why do so many companies do the bare minimum when it comes to security training? Does training developers effectively require developers to be in training all the time, hurting productivity? And is there another method of training that allows developers to learn what they need to while remaining productive?
You Get What You Measure
You may have heard the saying “what you measure is what you get.” It refers to the tendency of people to focus on what is measured. If you tell a team of developers that they’ll be evaluated based on how many lines of code they write, they’ll make sure to write huge amounts of code, even if the code is terrible. So choosing what to measure and how to measure it impacts the behavior of those being measured. If you choose to measure the wrong thing, it can lead to major dysfunction.
Most regulations, such as PCI and SOC2, require developers to be trained on secure coding practices “at least annually.” Based on the “what you measure is what you get” philosophy, many companies send developers to security training once a year to get the “check mark”. These companies only focus on what is measured and how to tell their auditors, “Yes, we send our developers to training once per year.”
But how much do developers remember? After a week, 90 percent of what the developers were taught will be forgotten. You can be compliant all you want. Your software could still be the joyous playground of hackers who are stealing your customers’ lunch money. Don’t kid yourself. Being compliant doesn’t necessarily mean you’re secure.
If you’re thinking that maybe security training should be more frequent than once a year so developers actually use it and retain it, you’re on the right track. However, traditional classroom training has major downsides as well. And best of luck when you try to convince an executive to toss loads of money at sending developers to classroom training once a month. The loss of productivity alone would make that arrangement a non-starter. Is it possible to strike a balance?
Remain Compliant While Staying Productive
Every time a security bug is found, you can’t send the development team to a week-long training session to teach them how to fix it. That’s horribly inefficient. But sending them to training once per year won’t help them fix or prevent security bugs.
A balance is needed. You need your developers to be prepared for what they’ll see in their day-to-day work, to recognize security issues as they come up, and know how to fix them. The ability to securely design a system is also needed. Training of some sort is required apart from simply remaining compliant.
We at Hunter2 believe in always available, hands-on security training. We provide a framework for training developers when required in a tight, efficient format that helps them retain what they learn. Individual security vulnerabilities are taught using labs which require the developer to exploit the vulnerability and then fix it.
Here are some characteristics of our style of training:
- The training is focused on the specific needs of the developer and/or company as a whole
- Training is available on demand when the developer needs it
- The training is given in an interactive format to engage the developer’s mind and increase retention of the concepts
- The training uses the same technologies the developers use every day
This style of training can be likened to software as a service offerings. It’s always on, always available, and developers are free to reach out and use it when they need it.
Benefits of Effective Security Training
Now we’ve reached the balance required. With a continuous training model, the “at least once a year” requirement is met. A clear record will exist of your developers launching the training when they need it and completing interactive tasks that demonstrate competence. All of your developers will have training within the year. You can assign certain labs to new hires based on what security topics are most important for your company and software.
Another benefit is the ability for the labs to be customized based on the needs of the company. If analysis indicates that SQL injection is not really a problem for you, then you don’t need to force everyone to learn the ins and outs of SQL injection. If you have a rash of XSS vulnerabilities, however, you can assign XSS training to all of your developers. They’ll enter the lab, take a few minutes to really understand what XSS is all about, then fix it in the lab environment. Your developers will be ready to face XSS in their actual code.
Take the time to measure and identify the vulnerabilities in your code base. When you understand what your weaknesses are, you can tailor your training to match what your needs are. You can also adapt over time as your needs naturally change.
On-demand, hands-on security training helps compliant companies solve two problems:
- You have to train your developers at least once a year
- You want the training to be effective, and not a massive waste of time and money
Hands-on security training in interactive lab environments give your company the tools you need to be compliant without sacrificing productivity. And you’ll have the satisfaction of knowing that you aren’t simply checking a box, but providing a secure foundation for your software.