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
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.
A Realistic Threat Model for the Masses
Lysa Myers, Security Researcher, ESET,  10/9/2019
USB Drive Security Still Lags
Dark Reading Staff 10/9/2019
Virginia a Hot Spot For Cybersecurity Jobs
Jai Vijayan, Contributing Writer,  10/9/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
7 Threats & Disruptive Forces Changing the Face of Cybersecurity
This Dark Reading Tech Digest gives an in-depth look at the biggest emerging threats and disruptive forces that are changing the face of cybersecurity today.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-17612
PUBLISHED: 2019-10-15
An issue was discovered in 74CMS v5.2.8. There is a SQL Injection generated by the _list method in the Common/Controller/BackendController.class.php file via the index.php?m=Admin&c=Ad&a=category sort parameter.
CVE-2019-17613
PUBLISHED: 2019-10-15
qibosoft 7 allows remote code execution because do/jf.php makes eval calls. The attacker can use the Point Introduction Management feature to supply PHP code to be evaluated. Alternatively, the attacker can access admin/index.php?lfj=jfadmin&action=addjf via CSRF, as demonstrated by a payload in...
CVE-2019-17395
PUBLISHED: 2019-10-15
In the Rapid Gator application 0.7.1 for Android, the username and password are stored in the log during authentication, and may be available to attackers via logcat.
CVE-2019-17602
PUBLISHED: 2019-10-15
An issue was discovered in Zoho ManageEngine OpManager before 12.4 build 124089. The OPMDeviceDetailsServlet servlet is prone to SQL injection. Depending on the configuration, this vulnerability could be exploited unauthenticated or authenticated.
CVE-2019-17394
PUBLISHED: 2019-10-15
In the Seesaw Parent and Family application 6.2.5 for Android, the username and password are stored in the log during authentication, and may be available to attackers via logcat.