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
BlueBorne Attack Highlights Flaws in Linux, IoT Security
Kelly Sheridan, Associate Editor, Dark Reading,  12/14/2017
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
The Year in Security: 2017
A look at the biggest news stories (so far) of 2017 that shaped the cybersecurity landscape -- from Russian hacking, ransomware's coming-out party, and voting machine vulnerabilities to the massive data breach of credit-monitoring firm Equifax.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2017-0290
Published: 2017-05-09
NScript in mpengine in Microsoft Malware Protection Engine with Engine Version before 1.1.13704.0, as used in Windows Defender and other products, allows remote attackers to execute arbitrary code or cause a denial of service (type confusion and application crash) via crafted JavaScript code within ...

CVE-2016-10369
Published: 2017-05-08
unixsocket.c in lxterminal through 0.3.0 insecurely uses /tmp for a socket file, allowing a local user to cause a denial of service (preventing terminal launch), or possibly have other impact (bypassing terminal access control).

CVE-2016-8202
Published: 2017-05-08
A privilege escalation vulnerability in Brocade Fibre Channel SAN products running Brocade Fabric OS (FOS) releases earlier than v7.4.1d and v8.0.1b could allow an authenticated attacker to elevate the privileges of user accounts accessing the system via command line interface. With affected version...

CVE-2016-8209
Published: 2017-05-08
Improper checks for unusual or exceptional conditions in Brocade NetIron 05.8.00 and later releases up to and including 06.1.00, when the Management Module is continuously scanned on port 22, may allow attackers to cause a denial of service (crash and reload) of the management module.

CVE-2017-0890
Published: 2017-05-08
Nextcloud Server before 11.0.3 is vulnerable to an inadequate escaping leading to a XSS vulnerability in the search module. To be exploitable a user has to write or paste malicious content into the search dialogue.