Discover PerformanceHP Software's community for IT leaders // November 2012
5 steps to faster security
When the business wants faster software releases, security can’t always keep up. A panel of security experts says it doesn’t have to be that way.
Speed and agility are highly valued in IT today, when “faster and better” is the only way to stay ahead of the competition. Yet many organizations still struggle to integrate security into their accelerated development processes.
The problems that arise from increasing deployment speed without integrating security checks include:
- Little or no time set aside for security testing
- An adversarial relationship between the development and security teams
- Difficulty in remediating security issues due to long lags between development and security testing
- A no-win work environment for security professionals, who are in the role of bringing only bad news
HP Software Security Strategist Rafal Los recently tackled the conflict between speed and security in his Wh1t3Rabbit podcast series. With Nick Galbreath, director of engineering at Etsy, Mentor Graphics Senior DevOps Engineer James Wickett, and Olivier Saudan, senior software security analyst at an EU-based security solutions organization, Los discussed security’s role in a continuous integration cycle.
Wickett agreed with Los’ assertion that traditional waterfall development is nearly always the ruin of security, squeezing an already narrow window for security checks right down to zero.
“I have definitely been in the state before, where there’s months of work being done and then it flows to operations and then maybe to security, if you’re lucky, to do testing,” Wickett said. “You need to have security being embedded into the whole cycle.”
A new security workflow
To better bring software security into the development process early and often, the quartet suggested five ways to get faster, better security:
Increase the transparency of development processes.
The first thing that needs to happen, said Galbreath, is to identify the human interaction points involved in a software release. “It’s very important to make the deployment process visible, transparent, and easy to use,” he said. Ultimately, the goal is to identify mid-process points where security alerts, checks, and tests can be inserted.
Code and test in small chunks.
Organizations need to encourage a culture of software testing and monitoring in small chunks, Galbreath said. That means moving away from monolithic releases. By pushing out small changes in a rapid pace, with architectural review by the security person built in, if there’s a problem, the developer is immediately responsible and engaged.
Create new efficiencies, automation.
Look for efficiencies such as delivering the results of penetrations tests through a script or unit tests rather than a long, tedious document, Wickett said. This way, failed tests give developers immediate feedback on where to concentrate code changes, saving the organization hours in deciphering reports and writing unit tests.
Automate, but don’t eliminate human review.
In security, there are potentially an infinite number of negative test cases that you have to do. When you automate, you run the risk of forgetting what you have not yet automated, Saudan said. “You have to keep some human [involvement] in the process that regularly checks your application to discover things you may have forgotten.”
Treat high-risk and low-risk code differently.
For high-risk issues, you need a different review process and change-control rules than for low-risk changes, such as text changes to a web site or assigning a new IP address to a server. This is why many organizations bring operations into their continuous deployment methodology, Saudan said. “The people who are good at operations have a lot of knowledge, a lot of processes that prioritize changes based on the risks.” (See our recent DevOps issue for more about this emerging best practice.)
At Etsy, Galbreath said, code-branching strategies are essential to ensure that areas of high sensitivity and concern get greater change-control oversight. Highly sensitive changes such as configuration file changes or changes to site log-in/off all trigger an alert that tells the security team to look in on the new code changes before they are ready to go live.
When faster needs to slow down
While discussing how to accommodate faster software release, participants were careful to point out that speed isn’t always the highest priority. Security executives need to understand the specific technical and business challenges around each release to make judicious decisions about when to add security testing.
For example, some industries, such as banking, may not be able to accommodate a rapid deployment model with multiple releases per day. Other times, the nature of the code itself may make early testing unfeasible.
“Some things you can do in parallel, but there are just some things that you can’t test until the finished product is put together,” Los said. “We can prioritize and risk-rank our releases or our code chunks, but … not everything we do falls under one model.”