Requirements and Use Cases

Many times, requirements and use cases are not things that the average Joe (with apologies to my friend Joe) believes warrant security attention. But Architecture and Design is where it all begins, it is in that phase of development that requirements and use cases are being developed. If you miss the security boat there, then you've set the Rube Goldberg machine of hack, exploit, pay-the-lawyers, fix and patch, into motion.

The problem is that the Average Developer doesn't really care too much about Secure Design, Threat Modeling and Attacker Stories. That stuff just gets in the way of fun (writing code) and profits (selling code) - though we might like to assert that we don't see much of the profits being six or seven layers deep from the President & CEO. So lets explore the Attacker Story by first understanding exactly what a Use Case represents.

Requirements

The study of Software Requirements is a college-level course in-and-of itself. So I'm not going to spend too much time on the topic except to say this: building in security and constraints through your Software Requirements phase doesn't help a whole lot. If it did, we wouldn't have insecure software and buffer overruns. On top of Software Requirements we must add use cases and attacker stories (or abuse cases). Both of these things inform development and quality engineering. They help development consider the activities and actions of both the user and the attacker. On the QE side, the tools help the testers verify the implementation functions as designed and is resilient to attack.

Use Cases

A use case is a technique that helps us express functional requirements in a developer and tester friendly manner. But a use case is not a substitution for documenting specific requirements. Neither is it intended for all subject-object interactions. A use case should be specific enough to supplement design requirements so that correct design is implemented and sufficient tests are constructed to verify functionality. Use case modeling expresses the intended system behavior for specific actors.

Consider a simple banking application use case for making a transfer:
As a user of the Banking App, I want to transfer funds out of my account into another account in order to meet my personal financial goals.

This use case helps us think about what a specific actor wants to do with a given resource and for a specific purpose.

Abuse Cases (Attacker Stories)

An Attacker Story or Abuse Case exactly like a use case, except it is constructed from the perspective of an attacker. It may be based upon a specific use case, but it also can be based upon well known threat model attributes, such as those associated with STRIDE or DREAD. Using the example above, we can develop an abuse cases as follows:

As an attacker, I can access a user's account and transfer funds to other accounts for the purpose of stealing money.

As an attacker, I cannot steal money by accessing a user's account and transfer money to other accounts.

Just as in the use case, the abuse case causes an attentive developer and tester to ask questions:

• How does the user access the account?
• How do we prevent the attacker from gaining unauthorized access?
• How do we assert that user has permission to transfer funds?
• How do we prevent an attacker who has gained access to an account from stealing money?

Therefore, the Attacker Story helps us express the emergent security requirements from which we can design and implement controls and tests to prove the controls work. In the best situation, each use case should have one or more abuse cases.

We can (and many times should) create diagrams explaining both the use case and the abuse case.  While the example below is patently simple, it does express the idea that we don't want an un-authenticated user performing the same functions as an authenticated user.

Nevertheless, in both instances we consider different aspects of the same usage.  Perhaps one of the first questions we investigate is, "how does an attacker become an authenticated user without proper credentials?"  Perhaps session hijacking is exploited, or perhaps we use a form of multi-factor authentication and the attacker has performed this SIM attack or this one.

Use Case

Abuse Case

In summary,

Software Security is not an afterthought. If you're not considering how your information system can be attacked when you're in the architect and design phases, then you'll be playing catch-up for the entire lifecycle. Security is like a feature: it must be designed into the product and it must be testable. Security is an emergent property of software, just like any other feature or quality.