“You’re Both Right…Now Go To Your Rooms!”

Those of us on the security side of the DevOps vs. company security argument tend to only see one side of the story as the truth – the security side. But that’s not always true.

Traditionally, DevOps and security have butted heads. One side sees security and policy as a roadblock to successful development. The other side feels that developers ignore or downplay the importance of what they’re trying to do and what they’re trying to protect. Similar to two siblings arguing, organization leaders (parents) simply tell them to deal with each other and send them “off to their rooms,” instead of trying to address the underlying problem.

This causes a stalemate, where some security is applied and some is worked around or ignored. In these situations, no one is happy, as development speed and efficiency is less than ideal – and the ideal security policy isn’t being implemented either.

The argument in favor of security is easy to understand – but there are often solid arguments on the development side, too – and it would benefit security professionals to understand these arguments and learn how to ensure both sides get what they want. Understanding and addressing development’s needs can help improve your company’s processes – to the benefit of all.

A Common Misconception

A myth among security professionals is that developers want no security in place at all. That is simply not the case. Developers want to ensure the security of the apps they’re building; however, they want to do so in a way that aligns with their need for speed and agility.

Security is a goal for both teams. It’s the level and amount of security – and how much control each team must surrender in order to achieve security – where differences arise.

In fact, in order to secure their applications, developers want to identify and remove vulnerabilities. What they don’t want, however, is for security policies to become a hindrance and prevent them from collaborating and developing software in an efficient and cost-effective way.

Being secure is not a tough sell – but asking someone to change the way they work for the sake of security is.

Put Yourself In Their Shoes

As a developer, you need security to be something that operates behind-the-scenes. Developers are not hired to be security experts – and they don’t want to have to learn to become one. That’s the job of security teams. Developers will be more willing to accept security policies and tools if they don’t have to think about them, change how they do things, or spend any effort to make them work.

As you think about it from their point of view, it’s easy to see that the traditional way of implementing security has no place in today’s development world. Organizations need to be agile and flexible to be effective; this is true of developers – and is also true of security professionals.

Modern security solutions need to be enablers of DevOps teams – making it easier for them to build, deploy and operate secure applications in an efficient manner. Security solutions also need to be ready to grow with your company’s success. No company wants to have to adjust their methods and processes to account for success.

An Automated Solution

Security professionals need to embrace automated security solutions to answer this common developer complaint. The automation of security protocols can be a way to resolve the security vs. development conflict.

With the speed that potential attacks change on a regular basis – and the way that DevOps embraces continuous integration and delivery tools, services can be created and modified so often that it becomes impossible to manually review and ensure each one is configured, deployed and communicating as intended – or are being operated in compliance with the latest corporate security policies.

Automated tools can find security issues or configuration errors in the background – not affecting the way developers work – and then act to eliminate or correct them. It quickly becomes easy to identify and protect vulnerable containers that could be externally accessible. By doing this, potential attacks and breaches are prevented.

Automated security can also keep your systems up-to-date on the latest attacks and potential issues. It does this behind-the-scenes, so your development environments are constantly protected, regardless of whether they’re on-premise, or in a private or public cloud. Just as importantly, automation ensures development is not interrupted each time there is an update.

Conclusion

Security automation ensures that developers’ arguments are listened to and met – and that teams do not have their efforts limited because of the need to remain compliant. A wise person once said there are three sides to every story: yours, mine – and the truth. Those of us who live and breathe security would do well to remember that, especially when it comes to DevOps.

About the author: Reuven Harrison is CTO and Co-Founder of Tufin. He led all development efforts during the company’s initial fast-paced growth period, and is focused on Tufin’s product leadership. Reuven is responsible for the company’s future vision, product innovation and market strategy. Under Reuven’s leadership, Tufin’s products have received numerous technology awards and wide industry recognition.

Copyright 2010 Respective Author at Infosec Island via Infosec Island Latest Articles "https://ift.tt/2OrCays"