News and views from the leader in Online Performance Marketing

TwitterFacebookGoogle

Reflections from Agile 2013 – Part 2:
Integrating Security with “Abuser Stories”

agile

danaAgile 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.

Dana Pylayeva
Manager of Shared Services
Rakuten Marketing

2 thoughts on “Reflections from Agile 2013 – Part 2:
Integrating Security with “Abuser Stories”

  1. This is a great example just from this hour, Dana:

    http://www.theglobeandmail.com/report-on-business/international-business/us-business/nasdaq-halts-all-trading-after-technical-problem/article13912917/

    Was it a bug that made it through R&D? An incident with root cause of an underinvestment in the assets on which the software runs? An incident caused by an underinvestment in cost-of-ops?

    Either way, odds are very very good that the cost-of-incident dwarfs any proportionate savings in development costs, cost-of-asset, or cost-of-operations. Thus, a mistake was likely committed in minimizing TCO.

  2. I think the concept of negative business value is a very interesting one, Dana.

    As I come from an operations background as opposed to a development background, I immediately think of negative business value from an ops standpoint. Historically, in ops, we have thought of TCO as having two major variables, cost of asset and cost of operations.

    In reality, there is a third, deeply intertwined variable, which is cost of incident (whether that incident is a security incident, an availability incident, or what have you).

    Savings in one area imply costs in others, and this analysis helps us to figure out how to minimize total overall costs. For example, buying double the disk and adopting RAID increases cost of asset but reduces cost of incident (because a single disk failure doesn’t bring the system down). By the same token, increasing cost of operations by selecting more capable performance DBAs might reduce cost of asset by eliminating the need to purchase more expensive hardware (we saw this occur in a project for Rakuten in Japan, not sure if you were in the loop on that one).

    In any event, I think of cost of incident when I think of “negative business value”.

    I can see the same model of cost allocation and the resulting thought process can be mapped to development along the lines of what you wrote. I suspect you might think deeper thoughts on this subject (r&d specifically) than I would get to, and I wonder what they are. Will you be at OOW this year Dana?

Comments are closed.

CyberChimps