Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Application Security

12/20/2018
07:20 PM
Connect Directly
Twitter
Twitter
RSS
E-Mail
100%
0%

3 Reasons to Train Security Pros to Code

United Health chief security strategist explains the benefits the organization reaped when it made basic coding training a requirement for security staff.

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." 

Ericka Chickowski specializes in coverage of information technology and business innovation. She has focused on information security for the better part of a decade and regularly writes about the security industry as a contributor to Dark Reading.  View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Joe Stanganelli
50%
50%
Joe Stanganelli,
User Rank: Ninja
12/31/2018 | 10:53:10 PM
Re: Coders?
@Dr. T: Sure. The more you know, the more flexibly and powerfully you are able to innovate a solution. This is true of pretty much everything.

I recently read a story of an ad man who was able to come up with effective copy for a watch by understanding the process of the development of the watch technology. The same applies to security -- particularly because so much of blue-team work relies on anticipating red-team actions and innovations that may seem non-intuitive.
Joe Stanganelli
50%
50%
Joe Stanganelli,
User Rank: Ninja
12/31/2018 | 10:49:34 PM
"Code shaming"
I saw a reference to this debate recently on Twitter. One security pundit was commenting that we shouldn't "code-shame" security people for not knowing to code because of the shortage of talent and to encourage their contributions. Perhaps a fair point to some extent, but for crying out loud, we are talking about some fairly critical skills here. Can you be an effective and high-quality security professional without knowing to code? Sure, probably. Can you be even BETTER at your job by knowing how to code? Almost certainly. (Plus, you'll be able to communicate better with the devs, who typically don't give a crap what the security people think or have to say.)
t6c4u2c
50%
50%
t6c4u2c,
User Rank: Apprentice
12/28/2018 | 10:26:29 AM
Basics of coding.
Any particular language that'd be useful for SecOps to learn/understand?  Python, Javascript or others perhaps?  
Dr.T
50%
50%
Dr.T,
User Rank: Ninja
12/27/2018 | 9:20:58 AM
Automation
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. Yes. Automation will help and when aligned with the security policies then we have an effective countermeasure.
Dr.T
50%
50%
Dr.T,
User Rank: Ninja
12/27/2018 | 9:18:51 AM
Scripting
in one case an experienced network security pro took what they learned and built out a firewall automation API for the firm. Yes. Knowledge of scripting will help security personnels to find creative solution and automation. AI is another aspect of it.
Dr.T
50%
50%
Dr.T,
User Rank: Ninja
12/27/2018 | 9:16:50 AM
Coders?
"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." I would not think we expect security guys become coders, however this would help to understand and find out creative solutions.
Dr.T
50%
50%
Dr.T,
User Rank: Ninja
12/27/2018 | 9:14:49 AM
DevSecOps
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. This is important for an organization to be successful in their security program. Working together.
Dr.T
50%
50%
Dr.T,
User Rank: Ninja
12/27/2018 | 9:13:16 AM
Coding to CICO
I always thought CICOs know how to code at least they know how to script, if not I am not sours how they can manage their role.
97% of Americans Can't Ace a Basic Security Test
Steve Zurier, Contributing Writer,  5/20/2019
TeamViewer Admits Breach from 2016
Dark Reading Staff 5/20/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: I told you we should worry abit more about vendor lock-in.
Current Issue
Building and Managing an IT Security Operations Program
As cyber threats grow, many organizations are building security operations centers (SOCs) to improve their defenses. In this Tech Digest you will learn tips on how to get the most out of a SOC in your organization - and what to do if you can't afford to build one.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-7068
PUBLISHED: 2019-05-24
Adobe Acrobat and Reader versions 2019.010.20069 and earlier, 2019.010.20069 and earlier, 2017.011.30113 and earlier version, and 2015.006.30464 and earlier have an use after free vulnerability. Successful exploitation could lead to arbitrary code execution .
CVE-2019-7069
PUBLISHED: 2019-05-24
Adobe Acrobat and Reader versions 2019.010.20069 and earlier, 2019.010.20069 and earlier, 2017.011.30113 and earlier version, and 2015.006.30464 and earlier have a type confusion vulnerability. Successful exploitation could lead to arbitrary code execution .
CVE-2019-7070
PUBLISHED: 2019-05-24
Adobe Acrobat and Reader versions 2019.010.20069 and earlier, 2019.010.20069 and earlier, 2017.011.30113 and earlier version, and 2015.006.30464 and earlier have an use after free vulnerability. Successful exploitation could lead to arbitrary code execution .
CVE-2019-7071
PUBLISHED: 2019-05-24
Adobe Acrobat and Reader versions 2019.010.20069 and earlier, 2019.010.20069 and earlier, 2017.011.30113 and earlier version, and 2015.006.30464 and earlier have an out-of-bounds read vulnerability. Successful exploitation could lead to information disclosure.
CVE-2019-7072
PUBLISHED: 2019-05-24
Adobe Acrobat and Reader versions 2019.010.20069 and earlier, 2019.010.20069 and earlier, 2017.011.30113 and earlier version, and 2015.006.30464 and earlier have an use after free vulnerability. Successful exploitation could lead to arbitrary code execution .