Cloud

10/3/2017
10:30 AM
Jeff Schilling
Jeff Schilling
Commentary
Connect Directly
Facebook
Twitter
LinkedIn
RSS
E-Mail vvv
100%
0%

DevOpsSec: A Big Step in Cloud Application Security

Why it's time for DevOps and security teams to bury the hatchet -- and not in each other's back.

In 2010, when I said, "I think the cloud is our opportunity to get ahead of cyberthreats" at a Washington, DC, speaking event, I literally heard a gasp in the audience. And for the next five years, I was "that guy" on security panel discussions who defended the position — and one of the lone people in the industry who held this view.

In subsequent years, an increasing number of security professionals began joining the ranks of cloud security "believers," and today I no longer feel isolated at security conferences. My belief that the cloud is a better security option for applications is based on two factors: software orchestration of segmentation, and building a true, verifiable defense-in-depth architecture.

Today, I see a third opportunity that will make the cloud even more secure. It is an emerging term currently gaining momentum, Dev-Ops-Sec aka DevOpsSec.

A New Approach
The root of the word, DevOps, refers to the process used by many cloud application developers to automate their workload deployments. As part of the "agile development process," cloud developers constantly make incremental changes to applications in the cloud, normally in two-week sprints. For security professionals, merely talking about this process makes them cringe at the thought that every new sprint inevitably will create another application vulnerability that they must identify and protect against. 

Quite simply, this is "old think." According to Gartner, 75% of data center security incidents are caused by lagging application patching, and current dwell time averages for most companies exceed 120 days. Improved collaboration between DevOps and security teams can remedy these two major security challenges.

Software developers have been at odds with security professionals for years. Security teams place stringent compliance and security standards on them, and software developers leverage software libraries to write applications that for the most part have security vulnerabilities already baked into the code. Typically, if you ask developers who the enemy of productivity is, they will say the security team. If you ask members of the security team who the biggest threat is, they will say software developers.

Meeting of the Minds
With the concept of DevOpsSec, a good security and development team can now join hands and sing "Kumbaya" while addressing mutual challenges. In the cloud, cutting-edge DevOps teams no longer update software in production environments. Using continuous delivery and DevOps automation tools, they can build a whole new "production prototype" in their test environment, normally leveraging containerization. 

They are able to apply their updated application code to these servers, conduct load testing, and make sure none of the application functionality is broken. Application patches can be inserted to ensure they're added to the test environment simultaneously. After all, an Apache, WordPress, or other patch is just another application software change. 

If the test environment checks out, the next step of the DevOps process enables the software development team to change scripts in the automation framework used to replicate new production environments in the virtual data center where the current production environment resides. When ready for "go-live," the DevOps team takes a 15-minute outage for production and deletes or tears down the current production environment, in literally seconds. 

The automation framework then deploys the new production environment, with application code changes and patches applied in 5 to 10 minutes, depending on the complexity of the application and scaling. The result: a threat actor who compromised the environment just lost her access, and gone is the era of 100-plus days of dwell time! In this paradigm, threat actors have to start the kill-chain process all over. And, if you're  successful (and lucky!), the changes you made with patching or application updates may send attackers back to the drawing board to start all over — forcing them, in some cases, to move on to easier targets. 

Bottom line: Security teams need to stop looking at their shoes and join in the agile development process to ensure they apply application patches during the software development process.  Software developers need to drink a few more Red Bulls and do their part by conducting static and dynamic application code update tests that ensure changes won't open up the environment to SQL injections or other OWASP top 10 vulnerabilities. 

If we accomplish this, then world hunger and peace are next on the checklist.

Related Content:

Join Dark Reading LIVE for two days of practical cyber defense discussions. Learn from the industry’s most knowledgeable IT security experts. Check out the INsecurity agenda here.

Jeff Schilling, a retired U.S. Army colonel, is Armor's chief security officer. He is responsible for the cyber and physical security programs for the corporate environment and customer-focused capabilities. His areas of responsibilities include security operation, governance ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Election Websites, Back-End Systems Most at Risk of Cyberattack in Midterms
Kelly Jackson Higgins, Executive Editor at Dark Reading,  8/14/2018
Intel Reveals New Spectre-Like Vulnerability
Curtis Franklin Jr., Senior Editor at Dark Reading,  8/15/2018
Australian Teen Hacked Apple Network
Dark Reading Staff 8/17/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2011-2765
PUBLISHED: 2018-08-20
pyro before 3.15 unsafely handles pid files in temporary directory locations and opening the pid file as root. An attacker can use this flaw to overwrite arbitrary files via symlinks.
CVE-2018-15594
PUBLISHED: 2018-08-20
arch/x86/kernel/paravirt.c in the Linux kernel before 4.18.1 mishandles certain indirect calls, which makes it easier for attackers to conduct Spectre-v2 attacks against paravirtual guests.
CVE-2018-15572
PUBLISHED: 2018-08-20
The spectre_v2_select_mitigation function in arch/x86/kernel/cpu/bugs.c in the Linux kernel before 4.18.1 does not always fill RSB upon a context switch, which makes it easier for attackers to conduct userspace-userspace spectreRSB attacks.
CVE-2018-15573
PUBLISHED: 2018-08-20
** DISPUTED ** An issue was discovered in Reprise License Manager (RLM) through 12.2BL2. Attackers can use the web interface to read and write data to any file on disk (as long as rlm.exe has access to it) via /goform/edit_lf_process with file content in the lfdata parameter and a pathname in the lf...
CVE-2018-15574
PUBLISHED: 2018-08-20
** DISPUTED ** An issue was discovered in the license editor in Reprise License Manager (RLM) through 12.2BL2. It is a cross-site scripting vulnerability in the /goform/edit_lf_get_data lf parameter via GET or POST. NOTE: the vendor has stated "We do not consider this a vulnerability."