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.
Government Shutdown Brings Certificate Lapse Woes
Curtis Franklin Jr., Senior Editor at Dark Reading,  1/11/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
The Year in Security 2018
This Dark Reading Tech Digest explores the biggest news stories of 2018 that shaped the cybersecurity landscape.
Flash Poll
How Enterprises Are Attacking the Cybersecurity Problem
How Enterprises Are Attacking the Cybersecurity Problem
Data breach fears and the need to comply with regulations such as GDPR are two major drivers increased spending on security products and technologies. But other factors are contributing to the trend as well. Find out more about how enterprises are attacking the cybersecurity problem by reading our report today.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-6455
PUBLISHED: 2019-01-16
An issue was discovered in GNU Recutils 1.8. There is a double-free problem in the function rec_mset_elem_destroy() in the file rec-mset.c.
CVE-2019-6456
PUBLISHED: 2019-01-16
An issue was discovered in GNU Recutils 1.8. There is a NULL pointer dereference in the function rec_fex_size() in the file rec-fex.c of librec.a.
CVE-2019-6457
PUBLISHED: 2019-01-16
An issue was discovered in GNU Recutils 1.8. There is a memory leak in rec_aggregate_reg_new in rec-aggregate.c in librec.a.
CVE-2019-6458
PUBLISHED: 2019-01-16
An issue was discovered in GNU Recutils 1.8. There is a memory leak in rec_buf_new in rec-buf.c when called from rec_parse_rset in rec-parser.c in librec.a.
CVE-2019-6459
PUBLISHED: 2019-01-16
An issue was discovered in GNU Recutils 1.8. There is a memory leak in rec_extract_type in rec-utils.c in librec.a.