Agile 2013 is considered the premier Agile event of the year, and provides a week-long opportunity to engage in a wide-open interaction, collaboration and sharing of ideas with peers and colleagues within the global Agile community.
Last week, Dana Pylayeva, Rakuten Marketing Manager of Shared Services, attended the Agile 2013 conference as a volunteer. Over the next several weeks she will be sharing some of her takeaways from this conference in a series of blog posts.
Part 1 of the Agile series can be read here.
Security is often an afterthought for many software projects. As project teams work on delivering business features into production faster, they tend to de-prioritize security concerns in favor of new revenue-generating functionality. At the same time, hackers around the world are getting smarter in exploiting security vulnerabilities, gaining access to enterprise data, and violating privacy (as in the case of a hacker posting a Facebook bug report on Zuckerberg’s wall, reported on 8/18/2013).
Even when companies invest in penetration testing, they often find that closing a security loop hole is a very expensive undertaking. Security experts estimate the cost of fixing single vulnerability in a Web application to be anywhere from $400 to $4000.
How do we start thinking about security earlier in the development process? In her very engaging, hands-on security workshop at Agile 2013, Judy Neher shared a framework, which can be easily applied to real-word applications. This framework suggests that for every “user story” in a product backlog, there has to be an “abuser story” defined and added to the same backlog. While the user story describes a specific function of an application that an end-user needs to perform his job, the abuser story describes how that same function can be misused or exploited by a hacker.
A good abuser story also has refutation criteria (vs. acceptance criteria of a user story) – criteria that allows one to determine that the attack depicted by the abuser story is not possible.
Finally, every abuser story carries a cost, equal to the negative business value (in the case when business value delivered by a user story is negated by a risk of an attack introduced by it). Using this cost in conjunction with a rank of perceived threat will help prioritize abuser stories in the product backlog.
This practice aligns well with the Rakuten LinkShare approach to application security. We understand that security is critical to our clients and we have a dedicated security team that is focused on integrating security into the agile development lifecycle.
Stay tuned for upcoming Agile 2013 blog posts on DevOps and the importance of a learning culture.
To find out more about the innovative technology platform that empowers global expansion visit the Rakuten LinkShare Technology Pages.
Manager of Shared Services