Agile Coding Production Requires Agile Security

Organizations devote vast resources to developing new code. Sometimes that code is intended to fix bugs, sometimes to improve the user experience and sometimes to deliver entirely new capabilities. Whatever the purpose, the expectation is that all that effort is going to return value to the organization. But whenever deployment of the latest code is held up by inefficient or outdated security controls, the organization’s return on investment (ROI) shrinks. Organizations should never bypass security controls in the name of ROI, but to make sure you’re never put in a position where you may be tempted to decide between the two, the way we implement those security controls should add as little friction to the deployment process as possible.

How can organizations implement security in a way that gets their code into production faster so they can get the full value out of their latest and greatest code? This is a question explored in “The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win” from 2013, and the author spends a lot of time discussing the concept of “Work in Progress” or WIP. The concept of WIP is not new, but “The Phoenix Project” pushes the idea that reducing WIP is key to successful DevOps. One key factor in reducing WIP is to implement appropriate security controls in ways that minimize deployment delays.

Common Challenges with Testing Environments for DevOps 

DevOps teams fix problems and work to bring new capabilities to our users, and every delay in getting that latest and greatest code into production affects the business. A common scenario and pain point for developers is when they push code into their testing environment and discover that some pre-existing security control is incompatible with their new code. This sends the development and security teams scrambling to make necessary changes to get the code to work. Those changes could be in the application or the security control, and just determining whether the application or the security control should change can be time-consuming. The later in the process these conflicts reveal themselves, the more expensive the resolution tends to be, and that expense should be measured both in terms of person-hours and in terms of delayed ROI.

Advanced Cloud Security Can Help

To avoid code implementation issues, security should be tightly integrated with every organization’s DevOps practices, or what is also known as DevSecOps. Here are three tips that can help:

1. Choose security tools that are easy to deploy and easy to manage. The security skills shortage we face isn’t going away anytime soon, and you can’t count on your existing dev teams to already have a broad security skill set. Look for the tools that deliver effective security, but don’t generate the false positives that drive administrative overhead. You only have so much staff; deploy the right tools so that they minimize the time spent on labor-intensive policy tuning and false-positive resolution. With the right tools, your team will have more bandwidth to focus on higher-value tasks. Look for solutions that include tools that ease deployments (e.g. cloud formation templates for FortiGate) or that can be consumed as a service (e.g. FortiWeb Cloud WAF as a Service).
2. Choose tools that enable you to maintain a consistent security posture wherever you deploy your applications. Modern enterprise networks are diverse and often span multiple environments. A typical enterprise today often has applications deployed across a range of private data centers and public clouds. You need security solutions that follow your applications and data to deliver consistent, seamless security and streamlined operations across all clouds.
3. Create processes that enable developers to develop within the same security configuration that will be used in production. Leverage APIs and automation tools to make spinning up “production class” operating environments quick and easy. Leaving “add security controls” to the end of the process increases the chances for unpleasant late-breaking surprises. Don’t let setting up security be the task that keeps your awesome new code stuck in WIP status.

Conclusion

“The Phoenix Project” has been out for a few years, but it remains a great primer for getting up to speed on the basics of DevOps – and surprisingly, presenting it as a “DevOps novel” works pretty well. If our security controls and processes keep code stuck as WIP too long, we become an impediment to the business. Security is more than just a cost of doing business; if we do this right and enable rapid code deployment without compromising security, security becomes a business enabler and a competitive advantage.