Posted by David Harvey on September 21, 2016
The official organizational response to a data breach almost always includes the statement: “We met all regulatory and legal requirements for data protection.” Training is required for many compliance regimes, and it might just be good enough as a compliance control. However, as a security control it’s inadequate. There are multiple major retailers that were fully compliant with regulations, and yet they suffered massive breaches. Major health insurance giants were also fully compliant with HIPAA at the time of a breach exposing the “protected” sensitive information of millions.
What’s my point, you ask? Compliance training is obviously failing software developers.
One of the key flaws in compliance-based training is that it’s rare to find role-specific training. Standard compliance programs (such as HIPAA or PCI-DSS) mandate annual security awareness training. Based on my experience, these security awareness training programs are rolled out to all job roles throughout the organization. Additionally, they remain relatively unchanged from month-to-month, or even from year-to-year. This is ostensibly to save money. However, it is truly a waste of time and can actually cause harm as software developers don’t reap any real benefit from the training.
Training should be customized by role in the development practice. Additionally, training programs should be continually updated to maintain relevance that will benefit the goals of an organization.
Over the years, BSIMM data has consistently shown that organizations with the most effective software security initiatives customize training by role. They also ensure that training programs are up to date and relevant. I’ve seen on many occasions that when sufficiently qualified software developers are given the appropriate information, they’ll use that to do the right thing.
More often than not, compliance training is simply checking off a required activity with minimal efficacy reviews. Training is a security control. Like any other control, it must also be tested for effectiveness. At the very least there should be a post-course evaluation. Highly mature organizations use metrics to determine whether an individual has absorbed the prescribed information.
Feedback to the training team is also highly valuable. This helps them determine what works and what doesn’t. A static fire-and-forget program that doesn’t change from year to year is obviously not going to cut it.
As users, we put a lot of trust in the companies with whom we share our sensitive information. In fact, I have had my employment, retirement, and banking data stolen as part of a data breach on multiple occasions through the same application. This was a Fortune 30 company (a former employer). The stolen records were from the defined retirement plan that the company directly managed.
At the time of the breaches, the development and operations teams that had created and deployed this application were fully compliant will all U.S. and foreign regulations regarding the use and handling of my data. Thus, I have personal experience to make the claim that ‘compliant’ doesn’t necessarily equate to ‘safe.’
It’s also ironic that the company that allowed my data to be exposed still claims security as a brand attribute…
When providing training to employees, do everyone a favor and customize compliance training by role. Make software developer training specific to the software development practice. Once you’re providing employees with valuable information, implement a strategy to understand the training’s level of effectiveness. Request follow up surveys or monitor team metrics to gather this understanding. Feedback and measurement allow trainers and managers to improve and evolve.
Get the latest Software Integrity news, thought leadership, and more.