1. Home >
2. Developer Blogs >
3. How We Built a Successful Security Training Program for Developers

---

In this blog, we want to speak directly to our Security Team colleagues at other companies. We have similar challenges, and we’re not out to make Security to be some kind of “special sauce,” proprietary to OneLogin. We benefit from the knowledge-sharing you all do, and we share back, too.

Let’s talk about Secure Engineering training for developers. The easy answer is, “yes, let’s have some.” The harder questions come next: Make or buy? OWASP Top 10? What else? In this article, we’d like to talk about how we approached Secure Engineering training, what we prioritized, etc. We’d like to see if any of this resonates with you at your organization.

Our list of training requirements included:

• Cover whatever your compliance obligations say to cover.
• Also cover anything else you’ve found to be important, even if not in the “Top 10.”
• Be time-efficient both for your engineers and your security team.
• Reflect that people often need to hear something more than once before they retain it.
• Withstand “press play and go to lunch” by the occasional folk.
• Be maintainable and amenable to iteration. As you identify new topics, it should be easy to add them.
• Be measurable.

What We Did

OneLogin is using a combination of “make” AND “buy” to get the best of both worlds. Including some content we make ourselves ensures we can speak to the specifics of our technical architecture, how our organization operates, and so on. Including best-of-breed, off-the-shelf content specific to the languages and technologies we use at OneLogin likewise adds to that support.

The Bits We Made

We researched requirements for topics to cover by first understanding our compliance obligations (e.g. cover the OWASP Top 10). We then looked backward by going back through historical bug data to look for our own trends, even if those patterns aren’t common elsewhere. We also looked forward to new technology we knew was coming to our stack and bundled in advice for how to securely use that technology without waiting for JIRA to tell us it was necessary.

Once we had that list, we identified that we needed to cover more than just individual bug patterns and their mitigation. To be truly effective, training needs to be memorable and persuasive, not just a dry recitation of expectations. We dug up compelling examples from our own experience and the experiences of others.

We included material on adversary capabilities, tactics and techniques. We’ve all probably met a developer who will acknowledge the theoretical potential of a vulnerability but who will protest “but an attacker would have to be able to discover X or know Y.” Teaching engineers about open source intelligence, Amass, Certificate Transparency, Directory Busters, Google Dorking, etc. can be very useful. It’s not that you need to turn your whole company into practicing pen-testers. Rather, it helps engineers make more informed risk-assessments by overcoming some of the cognitive resistance like “I don’t see how I personally could ever figure this out, so I suspect nobody else could figure it out either.”

With this kind of approach, Security at OneLogin offers a mature training program on par with, and in many cases exceeding, what companies many times our size have.

The Bits We Bought

Tailoring the descriptions of vulnerabilities, their impact to us, the specific mitigation strategies we use at OneLogin, all was a great fit for us. Even so, there were some areas where off-the-shelf easily eclipsed anything we could do internally within our means. The biggest example of this are the “lab exercises” that we put engineers through as a companion to the presentation materials.

Sure, there are DIY solutions here. You can have everyone download and instantiate the open source Juice Shop (an intentionally vulnerable app, for practice) on their own machine. Or, try to maintain a running instance of something like it “internally” for practice use. These all have costs: the time-cost of having students all set this up. There is risk associated with having people install intentionally-vulnerable stuff, or the risk of running an intentionally vulnerable instance without leaving something on your intranet for real attackers to pivot into and persist within. If you run a single instance, you have to keep cleaning it up after students “drop tables” on it. Etc. We didn’t go this route.

For us, we selected the Veracode Security Labs, previously known as “Hunter2.” It works well for us! We get individual lab exercises focused on individual vulnerabilities (and their mitigation), and a backend that keeps track of whether a participant successfully demonstrates mastery. It’s browser based, nothing for the developers to install. It covers not just demonstrating an exploit, but has participants actually fix their own cloud instance and can detect when they’ve done so. Every student gets an individual instance spun up (and automatically spun down) in Veracode’s cloud. This is a big win for our security team who can focus their time on other things and let Veracode maintain this infrastructure, develop new labs, etc.

How It Comes Together

We’ve woven our own presentation materials together with these off-the-shelf labs. Our engineers get our customized training on IDOR, then practice what they’ve learned in the IDOR lab. Then they switch back to another topic, listen, learn, and practice that one, too.

When we started offering this, we initially did this all live. The instruction was live, and the class would then transition to working quietly on the lab exercise with people able to ask questions if they got stuck. Then repeat for the next topic, and so on. After several iterations of this, we were confident enough that we’d built in pre-emptive answers to most common questions, and turned the entire thing into learn-at-your-own-pace, by converting the presentation segments into videos.

Moving to the video format wasn’t a choice for “worse, but, justified in the name of saving the instructor time.” The video format is actually better! We all know what it’s like to try to multitask during a meeting. We do it because we can’t afford to be unreachable for 2 solid hours, etc. An uninterrupted block of 2 hours is worth its weight in gold to an Engineer - that’s an expensive thing to ask of them. By comparison, Engineers have a variety of times during the day where they can spare 10 minutes. They’re waiting for a meeting to start, and don’t want to get engrossed in their next big bug. They’re waiting for a recompile or waiting for the automated test suite to run.

Many of us have seen this phenomenon at many companies where, in a symbolic act of making everyone acknowledge the importance of security, you get everyone to stop and give you a day. Or 2 days. Security IS that important, but that doesn’t mean we should pass up opportunities to put time-scraps to good use. Figuring out how to make effective use of time-remnants means we can, ultimately, take up MORE of our engineers’ time on security training than we might otherwise get support for. And, if you have “security day,” how often can you really hold it? How long do new hires go before they get that training? Our self-paced approach means there’s no reason for new hires to commit any code before availing themselves of the training.

Modularizing things also makes the training itself more viable for people to return to as reference material later. It’s hard to imagine an engineer digging back into some monolithic training package and trying to find their way back to 1 slide out of 100+, which they dimly remember being relevant to their current problem. But when there’s an 11-minute video dealing with precisely the topic that an engineer is supposed to bug-fix today, taking another look at the video is a natural thing to do.

Veracode provides us with measurements of who successfully completes the labs. If we wanted, we could have settled at that for measurement, and initially did so, with the videos themselves simply being on our internal wiki. As we start measuring even more, it’s easy to start loading those videos into a Learning Management System already in use at OneLogin, to give us tracking of that content as well.

We’ve already identified new topics we want to include, and it’s been easy to add that content. Since the whole thing isn’t delivered as a single monolithic video, there’s been no need to try to splice new content in. People who have seen the rest can easily consume just the updates.

“Security First” is today how we operate at OneLogin.
We continue to provide our Customers, Partners, Suppliers and Prospects with Trust and Security Assurance via the program we operate. For further information, please visit OneLogin Trust. Alternatively, you can reach out to us via your Customer Account Management or directly at Security@OneLogin.com

For now, we hope you’ve enjoyed this look into how we approach Secure Engineering training. Thanks for reading!

---

---