Discover PerformanceHP Software's community for IT leaders // July 2012
Speed and security? Just add automation
Securing software doesn't have to cost you the gains driven by agile and DevOps methods. Collaborating on truly secure automated processes lets you make security the default, not an add-on.
Every IT leader—CIOs, CISOs, VPs of you-name-it—is being challenged to deliver real value to the business, at top speed. Replacing “silos” with more fluid processes is a big topic, as agile software development principles are increasingly common in the enterprise. At the leading edge of this movement is DevOps, a philosophy that will eventually affect how your enterprise delivers secure IT services and applications.
The short definition for a movement that has yet to truly crystallize is that DevOps extends the concept of agile development to agile delivery. As the name implies, it’s about tearing down the wall between developers and operations teams. But if Security remains marginalized in its own silo, that agility won’t materialize—and neither will reliably secure applications.
Whether your IT organization formally embraces DevOps or just seeks incrementally increased collaboration and agility, you’ll feel the pressure to remove bottlenecks and deliver the goods better and faster. In that regard, security can be one of the greatest offenders. Not only do late-stage security gatekeepers slow down the process, they do so to create “bolted on” security solutions in a world where, increasingly, only truly “baked in” security will do.
The DevOps philosophy in no way diminishes the value of security. It merely shifts when, and how deeply, security enters the software development process. The result is a world in which security’s presence seems transparent, because secure development and deployment have been made the default, not the thing added last. The way this happens is through automation.
With automation, the security professional shifts from gatekeeper to consultant, and migrates from a “control” mindset to a governance mindset. Instead of toiling on the software assembly line, your security team provides its formidable expertise at key stages of software development. This level of integration builds in expertise that is repeatable and scalable.
Making automation happen
Automation is a key to how Apps and Ops teams make DevOps work. But to get security built in properly, software security professionals need to be intimately involved. Here are four primary goals for security professions in DevOps-style automation:
- Collaborate. Embrace change, and the pursuit of delivering better value to the business, faster. Seek out stakeholders in both Operations and Applications who can participate in vetting new process ideas.
- Implement. The security team must drive the enablement by infusing tools and processes with checks and triggers to alert to insecure code conditions. This effort will primarily involve creating test environments and augmenting software testing tools with authoritative guidelines to address identified risks based on severity.
- Prepare for change. To continue to meet business demand, create a change management process to handle ongoing improvement of automated processes as risks change and evolve.
- Train. Educate the development team on how to use the automated processes and make sure they understand security principles involved and where personal discretion is and is not permitted.
Once a new automated process is up and running, the influence and expertise of the security team can't be avoided; security happens by default. And the organization will have the proactive participation of security leaders to thank.
Providing true value
As security automation takes hold in the organization, where code checks happen by default and developers are more rapidly outputting software that meets your risk management requirements, the role of the security team can move upstream.
Security experts can focus on innovation in the areas of governance and enforcement. Security expertise can be spent not policing lines of code, but on the bigger picture: determining the risk tolerance of the organization, setting policy and refining the automation work streams.