Focusing on security while sticking to Agile development principles means it's time to think like a bad guy.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
And the place to focus your malice is on the humble user story, that simple building block of Agile security normally found -- in a variety of versions -- on colored sticky notes all over the whiteboard.
A user story offers a simple approach to viewing security vulnerabilities. "It's an easy way to help organizations see their products in the way that attackers do," said Judy Neher, president and CEO at San Jose, Calif.-based Celerity IT LLC, a company that engineers gas and liquid delivery systems used in manufacturing semiconductors.
Neher spoke about reducing software vulnerabilities at the Agile2015 conference in Washington, D.C.
Tackle Agile security during coding
If ever there was a good time to don a black hat, it's probably now, given the large number of very public data breaches -- Target and the federal government are two of many -- over the last few years. The earlier the security risks are found, the better. For example, the U.S. National Institute of Standards and Technology (NIST) said it is 30 times more expensive to fix vulnerabilities after a code is launched than to deal with it during coding. Some estimates are even higher, suggesting the cost might be 100 times more.
Judy Neherpresident and CEO at Celerity
Even knowing the costs, it can be easy to just push security concerns aside until the very last moment. One Agile2015 attendee from a large, popular entertainment company admitted no one at his enterprise thought about Agile security until "just before launch." Neher said even she was slow to get on the security bandwagon, because she focused on her concrete to-do list, rather than dealing with security when she was primarily a developer.
"But the time to think about security is when you start to think about requirements," she said. "You need to think about how a particular feature can be misused or abused right from the start."
Begin with a user story and see, as Neher suggested, if it's possible to turn it into an abuser story by brainstorming with team members about possible negative scenarios. "Who wants to get at my data?" Neher asked. "Why do they want my data? What can they do with it? What is the attacker going to get out of the attack?"
Attendees support early security efforts
Starting this early in the process would be a relief to some developers, who said they loved the idea. "We typically don't do any security until the end, so I like this idea of starting at the user story stage," said an Agile program manager at a large energy company. "It would really reduce the stress, if we could find the problems earlier."
The acceptance criteria should also come under scrutiny. Missing or weak acceptance criteria could make the software vulnerable, Neher warned, and should also go through a worst-case-scenario review. In fact, every time something is added or changed, team members must ask themselves how that new feature might be abused, intentionally or otherwise, Neher said.
Eventually, these abuser stories can rank with the rest of the stories on the product backlog, all based on the threat risk. To get a better feel for the risk, Neher recommended a process called "informed brainstorming," in which a team brings in a subject matter expert or a security officer to explore the potential for misuse and the assumptions that the development is based on.
"Attackers are not standard issue customers," she explained. "Who are our adversaries and what do they want from us? We have to assume they're going to exploit all our weaknesses."
Granted, there are business decisions to make, as well. The trick is to find the balance between function and security, and to prioritize the development effort appropriately. "We're never going to eliminate the threat completely, but we want to be able to reduce it," Neher said.
For companies that need help coming up with security requirements, Neher recommended checking out Appendix F of an NIST publication, Assessing Security and Privacy Controls in Federal Information Systems and Organizations -- Building Effective Assessment Plans.
Short iterations for Agile security
Modify Agile to make it work
Agile software quality insights