Traditionally, DevOps practitioners think of business value as simply measuring the difference between money earned and money spent. In that line of thinking, security is often relegated to a secondary goal because it fails to directly drive revenue. The misguided goal is to deliver functionality at all costs, even if it compromises the integrity of the system or data. As Rob Joyce, head of the National Security Agency's Tailored Access Operations group, mentions in his talk at Usenix Enigma conference: "Don't assume a crack is too small to be noticed, or too small to be exploited... We need that first crack, that first seam. And we're going to look and look and look for that esoteric kind of edge case to break open and crack in." In this blog post, I present two concepts: malicious user stories and rejection criteria that can be used in DevOps to secure systems.

At the 2015 Secure DevOps Symposium hosted by the SEI's CERT Division in Washington, D.C., Mark Schwartz, chief information officer of United States Citizenship and Immigration Services (USCIS), brought up a simple method his agency used to conceptualize and implement security features in their software development projects. This method was to define security-specific features called malicious user stories and attach to them rejection criteria to code against.

A malicious user story defines the action a malicious user would take to compromise a system or perform some other nefarious act. Rejection criteria are simple, testable, pass/fail statements that indicate whether a system is vulnerable to this action. We label them rejection criteria to drive home the point that we do not want malicious users to be able to execute the related malicious user story. The term malicious user story can also be used in a broader sense across multiple applications and systems, not only for a particular module or single application. Additionally, if the rejection criteria are testable, a team can automate and execute these tests during our continuous integration process for our development and prevent deployments if the tests fail.

The names malicious user stories and rejection criteria are a play on words for the more commonly known user stories and acceptance criteria. User Stories are a technique for succinctly defining requirements from an end-user perspective and may include tasks from handling user interaction to technical implementation. Acceptance criteria are clear, pass/fail statements by which the user story is accepted (or rejected) and considered complete.

Malicious user stories are not new to DevOps. People refer to them as abuser stories or security stories or tack them onto existing user stories as acceptance criteria. From a semantic aspect, I prefer the term malicious user stories because it keeps the focus on the user aspect of the story. Malicious users are users on your systems too; unfortunately, their goal is to subvert the regular user or system behavior to compromise the system or its underlying data. Elevating security characteristics to become hard requirements by way of their own user stories, rather than tacking them on as acceptance criteria to existing feature user stories ,marks security as a core deliverable of business value.

A simplified example of a malicious user story is:

As a malicious user I want to leverage bots to purchase large numbers of event tickets to resell at a higher price in a secondary market.

The rejection criteria can be listed as:

A malicious user is able to purchase large numbers of tickets via bots.

User is validated as human to prevent bot purchases.

Wrapping Up and Looking Ahead

The opportunity cost--and lost business value--of not tracking and rejecting malicious user stories can be catastrophic. Despite the difficulty of measuring the return on investment of adding security features to a software system, it is critical that security is treated as a first-class quality attribute of a software system. From the various data breaches and their associated costs to victim organizations that have happened in the past three years, it is becoming glaringly obvious that the business value of properly protecting systems is priceless.

Additional Resources

View the webinar DevOps Panel Discussion featuring Kevin Fall, Hasan Yasar, and Joseph D. Yankel.

View the webinar Culture Shock: Unlocking DevOps with Collaboration and Communication with Aaron Volkmann and Todd Waits.

View the webinar What DevOps is Not! with Hasan Yasar and C. Aaron Cois.

Listen to the podcast DevOps: Transform Development and Operations for Fast, Secure Deployments featuring Gene Kim and Julia Allen.

Read all of the blog posts in our DevOps series.