3 Reasons to Train Security Pros to Code

As security leaders strategize for a strong 2019, one of the initiatives that crops up on a lot of CISO to-do lists is getting cybersecurity better embedded into DevOps teams. When done right, DevSecOps can help security teams reduce risk faster while at the same time rejecting the role of "the office of 'no.'"

Many times when security people talk about appsec, they lament the fact that developers don't know enough about security. Part of the DevSecOps ethos is getting out of that finger-pointing, tribal mentality and instead coming together as a cohesive team no matter the role — whether developer, operations staff, QA, or security. 

"Empathy is a two-way road," says Aaron Rinehart, chief enterprise security architect for UnitedHealth Group. "Meaning, I always hear security people talking about how development people need to learn security. Well, you know what? How about we teach software engineering to security?" 

This thought was the seed of a program that Rinehart ushered forward at United Health almost two years ago that required all security people to take some basic programming classes. 

"We're not trying to create coders," he explains. "What we're trying to do is sort of build common understanding, common problem, common empathy." 

The program is low-budget, built on free online courses on the internet. For those who've never written code in their entire life, Rinehart's team pointed them to a beginner's level course to get an understanding of syntax and the like. From there, everyone was pointed to AutomateTheBoringStuff.com, for classes on Python. 

According to him, the program has reaped some major benefits. Here are the three biggest. 

1. Changing Mindsets 

"I never thought this one little thing would inspire so much change," Rinehart says. "I would say in the end we didn't get a whole bunch of new coders, but what we did was we changed people's thinking." 

So, even something as simple as developing patch management policies shifted as the people setting these policies recognized that patching complicated internally developed systems isn't the simple button-press process that updating a Microsoft application is. It takes development work, testing, and so on. 

"So that team went forth and wrote their own software security policy that was really in tune with the developers," he says.

2. Fostering Skills to Build Their Own Automation

While not everyone turned into coders, the courses did inspire at least some teams to code their own security tooling for different kinds of security automation. 

"Now you have people that can go from idea to product on their own, right? You have this new sort of innovation engine; it's now possible," Rinehart says. "Now not every person is going to do that, right? But you've created the ability." 

For example, in one case an experienced network security pro took what they learned and built out a firewall automation API for the firm. 

"We already had standards and rule sets, and being a CCIE the person had depth and context of what to write for this API," he says. "It was amazing."

In another case, incident response team members started building out their own apps.

"They were one of the first teams who started taking on development practices, and they reached this mandate where they were not going to use anything that a developer at UnitedHealth Group could not use," he says. "Because sometimes security people think they’re above the law, but they’re not."

3. Moving to Security as Code

In addition to helping security people build their own automation, the coding skills also allowed the team to start building out security policy as code. 

"So there are products now where we are taking our policies and standards and we’re actually creating code that reflects those requirements," Rinehart says, explaining this is much preferable to having people try to translate these technical or industry regulatory requirements into written documents that developers then have to read, parse and then figure out how to code accordingly. "We're contributing tangible pieces back into the product now, versus trying to explain policies that even we don't really understand to somebody who has to do something with it."