The difference between applied and reactive training is huge in the field of software development, especially when AppSec is involved. I'm a big fan of the "applied learning" side of the equation, at least as it relates to security. In his article, "The 7 Deadly Sins of Application Security," 20-year industry vet and Aspect Security CTO and co-founder Jeff Williams nails why:
One thing I've noticed is that two organizations with the exact same application security activities can have wildly different results over time. One organization will improve, steadily stamping out entire classes of vulnerabilities. The other will continue to find the same problems year after year. The difference is culture.
That last word, culture, is key. A strong focus on continued learning is huge in any enterprise learning environment, let alone one that trains people how to keep the apps they develop and sell safe from inconvenience-causing, reputation-wrecking security flaws. In a dev world where a product being compromised can represent a Hindenburg-level client-relations disaster, that makes the difference between concept- and event-based training huge — and one every decision maker needs to know about.
Training teams about specific events certainly has its place. New bad stuff comes to light with increasing frequency these days, and giving your developers the specific training they need to conquer newfound exploits and looming AppSec flaws can be critical to your company's continued, healthy operation. Beyond that, building a culture of preventative learning is all about giving developers universal tools — ideas that can be applied in multiple areas and, perhaps more importantly, expanded upon as needed.
Let's go back to high school for a moment to help describe the difference. First, think of a history class: While the stuff you picked up there is certainly useful and valuable in its own right, it probably doesn't have the same day-to-day utility as the lessons you picked up in a basic math class. Why? One talks about specific events, while the other addresses concepts that can be reused in countless places. We calculate tips and subtract discounts from retail prices on a near-daily basis, after all — specific knowledge is useful, but skills (when applied properly) carry on forever.
Okay, that analogy isn't perfect. But it does go a long way toward explaining why coaching is better when it gives healthy doses of conceptual learning and concrete, specific examples, and why giving developers general tools is a better approach than dealing with AppSec issues as they become known across the industry.
Developers aren't security experts. While responsibilities vary from company to company, a developer's primary responsibility is to produce code.
That responsibility means developers have a lot on their proverbial plates in terms of work duties and info they must retain about their current projects. When it's time for their brains to make room for new knowledge, what do you think will be the first to go? That's right: the least important (work-related) data. For many developers, this "least important data" is likely info from the annual secure-development training class they took a few months back — unless there is some sort of remediation coaching function that reinforces the course's teachings.
The ideal situation? For developers to use the vulnerabilities found in code they're currently working on as a coaching tool on how to avoid making those same mistakes in the future. Being coached on the fixes while developing the code lets them see security concepts applied in a real-world, specific-to-them situation. It's the mix of taught concepts plus this reinforcement that makes the difference when it comes to long-term memory.
In the end, committing to a security-minded culture means committing to education — and that means committing to teaching skills as well as specifics. Like a lot of things in the development world, they feed into one another. Give a team the tools to combat security issues in general (often through classes), and they can apply those skills during testing and remediation coaching, not to mention while they're fixing real-life security issues. Because they approached those situations with skills they picked up, they're a lot more likely to remember them the next time a problem arises. The two ideas drive the sort of change any enterprise should be looking for.
At the very least, give your enterprise's educational plans a thorough review, keeping in mind the difference between concepts and events. If you can't overhaul your entire coaching concept, you can at least start the shift toward enhanced security practices, and thus toward becoming one of those steadily improving organizations Jeff Williams addressed earlier. That's the kind of change any company would like to make.
Photo Source: Wikimedia Commons