There are two ways to tell that an organization just got breached.
The first is a press release that begins, “The safety and security of our customers’ personal and financial information is our highest priority.”
The second is the declaration, “We met all regulatory and legal requirements for data protection.”
This statement might be true. But it also highlights the reality that good intentions and compliance are not enough.
Compliance is useful. Setting a standard has value. But as numerous experts have said, the standard is a minimum—a floor, not a ceiling. Troy Leach, senior vice president of the PCI SSC, which oversees one of the largest private-sector compliance regimes—the PCI DSS (Payment Card Industry Data Security Standard)—has said as much.
Leach said that since its start in 2004, his organization has agreed with the mantra that “compliance is not security.” He said it’s actually the other way around—security produces compliance.
“Compliance or attestation of compliance is a result of good security,” he has said. With that in mind, we’ve put together a few tips that will help your organization achieve better security by moving beyond basic security compliance training.
Your users put a lot of trust in your organization, with whom they share their sensitive information. But billions of people have had their personal and financial data stolen even while the companies storing that data were technically in compliance with security standards.
Indeed, endless examples show that compliance is not enough. While there is ongoing debate over whether any organization that got breached was fully compliant at the time of the breach, mega breaches are a fact of life.
Still one of the most infamous breaches is that of the mega-retailer Target, which was reportedly in technical compliance with the PCI DSS when about 110 million customer financial and contact records were stolen at the end of 2013.
One organization estimated that nearly 8 billion records had been compromised through 2019, including credit card numbers, home addresses, phone numbers, and other highly sensitive information.
But while the debate rages on over how many of those records were compromised because organizations were out of compliance, the point is that security compliance training is not enough for software developers.
What to do: Remember that the security compliance training required by your industry’s standards is a minimum threshold. The experts who spend countless hours developing security standards recognize that organizations don’t have infinite resources, so these standards represent only a starting point. Meeting the minimum requirements for security compliance allows you to enter the race, but if you want to reach the finish line, you’ll have to go further.
One of the most glaring flaws in compliance-based training is that role-specific training is rare. Standard compliance programs (such as HIPAA or PCI DSS) mandate annual security awareness training. Many organizations roll out these programs to all job roles throughout the organization. They remain relatively unchanged from month to month, or even from year to year.
Providing the same security awareness training to all employees saves money—at first. But in the end, these programs are a waste of time and can actually cause harm as software developers don’t reap any real benefit from the training.
The benefits of customized security training and updated programs are clear. Over the past decade, the BSIMM has shown that organizations with relevant, role-based security training have the most effective software security initiatives (SSI). When you give sufficiently qualified software developers the appropriate security compliance information, they’ll use it to do the right thing.
What to do: Customize your training program to address the different roles in the development practice. Specifically, provide your developers with compliance training that goes further than your organization-wide security awareness training. Update your training program regularly so that it remains relevant and able to support the goals of your organization.
Too often, security compliance training means checking off a required activity with minimal efficacy reviews.
It should mean much more than that. Training is a security control, and like any other control, it should be tested for effectiveness. At the very least, there should be a post-course evaluation. The most mature organizations use metrics to determine whether an individual has absorbed the prescribed information.
Feedback to the training team is also highly valuable. Feedback helps your team determine what works and what doesn’t. A static fire-and-forget program that doesn’t change from year to year is not going to cut it.
What to do: Define the metrics you’ll use to evaluate the effectiveness of your security compliance training program. Create a process whereby developers can provide feedback to the training team on the information they found most and least helpful and what information they’d like to see in future course versions.
When you’re creating or updating your security training program, do everyone a favor and customize compliance training by role. In the case of software development, make it specific to that practice. Once you’re providing employees with valuable information, implement a strategy to understand the training’s effectiveness. Request follow-up surveys or monitor team metrics to gather this understanding. Feedback and measurement allow trainers and managers to improve and evolve.