News Stay informed about the latest enterprise technology news and product updates.

DevOps explained: Why experts call DevOps and security a perfect match

At RSA Conference 2015, a pair of DevOps proponents explained why the nascent movement to integrate development and IT operations staff pays security dividends.

SAN FRANCISCO -- So what exactly is DevOps? A next-generation development framework? An emerging software security...

paradigm? An existential state of being?

None of those descriptions are quite accurate, according to a pair of DevOps proponents who spoke at RSA Conference 2015 last week. While some see DevOps as a traumatic, frightening shift for IT professionals, the two speakers at RSA said it is proving to be a transformative movement for anyone involved with software security and that it will eventually become the default methodology for developing and updating software.

Speaker David Mortman, chief security architect and distinguished engineer for Dell, headquartered in Round Rock, Texas, described DevOps as a philosophy and a culture that fosters rapid, continuous iteration in software development, emphasizes data analysis and information sharing to identify software architecture problems, streamlines process bottlenecks and quickly implements software changes.

Mortman said that DevOps is meant to be an alternative to traditional waterfall-style development, a thorough process heavy on quality control, but that moves at a measured pace that typically limits major software releases to once every 18 to 24 months.

Joshua Corman, chief technology officer of application security vendor Sonatype Inc., based in Fulton, Md., said DevOps builds on the recent agile development paradigm by not only focusing on rapid software development and deployment, but also fostering collaboration between developers and IT operations teams.

"DevOps allows you to go fast, try new things, fail and iterate quickly -- be more efficient, profitable and competitive," Corman said. "There's more velocity, which is why developers love it, and operations teams get to be more efficient, release more break-fixes, offer faster mean-time to repair and roll out more new features."

Busting DevOps security myths

Mortman said many seem to believe that DevOps hinders security by breaking down separation of duties, limiting code checks and pushing software iterations into production without proper quality control.

These, though, all are myths, Morman said: With DevOps, software security improves if it's done right, most notably because code "almost never" goes out into a live environment without testing, but developers aren't forced to log in manually to test it; the testing happens automatically.

"Instead, they're using tools to automate testing, so fewer people are involved and tweaking individual configurations," Mortman said. Because less manual code auditing and documentation is needed, he added, "when there is an issue, you can have a higher confidence factor you know what's going on in that [server]."

Another common myth, Mortman explained, is that some organizations believe they don't need to implement DevOps because they already use the ITIL framework to ensure software development processes are aligned with business needs.

However, Mortman said, the process methodology of DevOps is largely borrowed from ITIL; in fact, the term DevOps was even coined at an ITIL conference.

"DevOps is ITIL without the paperwork," Mortman said. "It's a process that works every single time, and that's the holy grail of ITIL."

Mortman also addressed how some security pros familiar with DevOps believe that there is a lack of maturity with the most popular DevOps software configuration and deployment tools, such as Chef, Puppet, Rudder and Docker.

He admitted there is some truth to reports of issues like tricky integration with corporate directory services, a lack of role-based access control and, especially, weak configuration checks that result in faulty builds being propagated without proper validation. Mortman said, though, that new tools are emerging to solve some of those problems, such as a Chef tool that validates test cookbooks (configuration and policy distribution elements) for builds before distributing them.

"We don't mean to stand up here and say [DevOps] is perfect," Corman said, "but in a way you don't have a choice because the status quo isn't working."

More specifically, Corman referenced the estimated $40 billion enterprises spend annually on information security; he noted that -- even though research shows attackers target software more than networks, hosts, data and people -- software security receives a relatively miniscule $500 million of that spending.

Adding to the software security dilemma is that, instead of writing their own code, Corman said, enterprises increasingly assemble code from existing building blocks, much of it from unvalidated open source elements.

"That's why Shellshock and Heartbleed and issues with software supply chain have been killing us: because our software's been assembled from code of unknown origin with unknown risk," Corman said. "This is one of the reasons why it's open season on open source."

Security and DevOps: An opportunity

Mortman said, at its core, DevOps is intended to make software development processes far less complex, and complexity is the enemy of security.

"The more complex your code is," Mortman said, "the more security vulnerabilities you're going to have, the more unstable your code is going to be, and harder it will be to make changes without breaking things."

In addition to being able to identify software security flaws and roll out fixes more quickly, both speakers emphasized that DevOps offers security teams plenty of benefits in the way of change management, simplified inventorying of both applications and software components, and ultimately a larger window into the software development process and more opportunities to influence it.

"We as security teams don't typically have any way to affect the choices of IT or operations or developers," Corman said, "so you may not have control of SaaS provider or a data center, but DevOps gives you that entry point, and when you're spinning within their culture, you have a much more extended sphere of influence."

Corman noted that, apart from security, DevOps is gaining traction in the enterprise for a variety of reasons, so it's to infosec pros' advantage to join the "DevOps tribe" while it's still in its early days.

Added Corman, "You can take the initiative and lead the first pilot implementation, wait for it to happen in your organization and engage early, or you can pretend it won't happen and be replaced."

Next Steps

Is DevOps going mainstream? Learn why it's no longer a niche approach to software development.

Gartner: DevOps is good; DevSecOps is better

PRO+

Content

Find more PRO+ content and other member only offers, here.

Conference Coverage

RSA Conference 2015 special coverage: News, analysis and video

Join the conversation

4 comments

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

> "DevOps is ITIL without the paperwork," Mortman said. "It's a process that works every single time, and that's the holy grail of ITIL."

I find it hard to believe that anyone in IT can claim that anything - Agile, Continuous Delivery, DevOps, cloud, Docker, microservices, whatever - is "a process that works every single time" and still be taken seriously.

Can anyone in this conversation kindly provide any shred of evidence for such an extraordinary assertion?
Cancel
Regarding the quote, I think you're arguing semantics to an extent. Mortman's point is that, unlike ITIL, which can fail as a process because of its complexity, DevOps is faster and simpler as a process and that even if the result is a flawed iteration, the process enables rapid fault assesment and repair.

Here's a link to the presentation, which may not necessarily provide what you're looking for, but I'm sure Corman and Mortman would be happy to engage separately.
https://www.rsaconference.com/writable/presentations/file_upload/asd-t07r-continuous-security-5-ways-devops-improves-security.pdf
Cancel
Hi g2580228, DevOps is far from perfect and processes fail all the time. The point I was trying to make was more that DevOps strives for repeatable processes and to do so heavily leverages automation as much as possible. People are terrible at doing repeated tasks consistently and so we should leverage computers as much as possible since they are far better at that.
Cancel
Hi Eric, David

Thanks for responding. Some comments:

> Mortman's point is that, unlike ITIL, which can fail as a process because of its complexity, DevOps is faster and simpler as a process

@Eric: How would you define DevOps as a process? Could you point me at a reasonably unambiguous definition of what that process might be?

> DevOps is far from perfect and processes fail all the time. The point I was trying to make was more that DevOps strives for repeatable processes and to do so heavily leverages automation as much as possible.

@David: Could you provide some supporting references for that assertion? My experience so far is that the discussion around DevOps encompasses everything from processes to cultures to mindsets to tools.

Candidly speaking, I also fail to see how you derive that point you were trying to make from the statement that "it's a process that works every single time." Could you explain that?

Andrew Phillips

PS: Apologies for the unintentional anonymous post previously.
Cancel

-ADS BY GOOGLE

SearchCloudSecurity

SearchNetworking

SearchCIO

SearchEnterpriseDesktop

SearchCloudComputing

ComputerWeekly.com

Close