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.
About the Author
You May Also Like