From both application usability and security standpoints, some users are intentionally attempting to subvert your work and find the holes in your planning. In many situations, this was not covered in your use cases. It’s time for something else: Abuse Cases.
“You are just not using it correctly.†This quote was mentioned in a recent client conversation while remembering a lost business opportunity. The company eventually parted ways with the software developer who expressed this out loud to a paying customer, but this is a pervasive sentiment that often repeats in the minds of architects, analysts and engineers.
After all, we have tried to anticipate every use case. We have thought through the workflow, determined the most efficient way for an actor to interact with a system, and laid it out in the most user-friendly way. Right?
I hate to break it to you, but users don’t care about your hard work and diligence. They will find their own way through your application regardless of the obstacles you put in their path and how well-planned your use cases are.
From Use Cases to Abuse Cases
In use cases, you create scenarios to describe specific interactions between a system and its actors usually represented in UML diagrams as ovals that are connected to stick figures. The system may be an application, a network or, well, even a grocery store. The actors are external entities to the system. They may be human or non-human.
I remember shopping in the grocery store during Covid with mask mandates and social distancing restrictions. Groceries are an essential need, so government agencies and corporations developed use cases for people to continue buying food and other vital items.
“Mask required†signs were placed on the entrances to buildings. “Stand here†floor stickers were placed six feet apart at checkout lines. Clear plastic shields were placed between cashiers and patrons. All of these are examples of use cases that were put into action.
But the one grocery shopping use case that most reminds me of software architecture was the placing of arrows at the ends of aisles. Stores turned their customer’s shopping patterns into a physical flowchart. “Enter here†and opposing “Stop, do not enter†directed shoppers to a safe, deterministic and efficient customer experience. What could go wrong?
Abuse Cases happen
Even though the ideal shopping pattern was literally printed out and stuck to the floor for shoppers that didn’t mean all problems were solved. In fact, sometimes when you develop and attempt to enforce a plan, that in itself can have a negative impact. Let’s look at a few of the potential and realized complications:
A Shopper:
- forgets their mask
- refuses to wear mask
- forgets (doesn’t make) shopping list and must double back on aisles
- ignores traffic flow arrows
- takes advantage of self-checkout because identity is obscured by mask
- buys all the toilet paper
And it’s not always a shopper’s fault. What about if an employee is blocking traffic flow entrance/exit while sticking shelves? Ther eare so many ways to abuse your wonderful plan.
An abuse or misuse case is a variation of a use case. However, where use cases describe scenarios that lead to a successful conclusion, abuse cases describe scenarios where the outcome negatively impacts the system.
Let’s leave the grocery store behind and move on to system and security architecture: the negative impact of abuse can be considered an interaction that impacts the system capability, performance, stability or security.
OWASP Defines an Abuse Case as:
“A way to use a feature that was not expected by the implementer, allowing an attacker to influence the feature or outcome of use of the feature based on the attacker action (or input).â€
https://cheatsheetseries.owasp.org/cheatsheets/Abuse_Case_Cheat_Sheet.html#notion-of-abuse-case
Developing Abuse Cases
Typically, abuse cases describe users not as actors but as “bad actors†or attackers and their actions differ significantly from use cases:
- Abuse cases describe scenarios in a less precise manner as we don’t always know the way in which a bad actor may attempt to undermine the system.
- Attackers are described with more detail than use case actors to include their motives, skills, and objectives.
- Negative actions are detailed in terms of long-term consequence to the system. In other words, how a negative action may provide access or opportunity to further negative actions. For example, successfully elevating privilege in a system may lead to new objectives such as data theft or the installation of ransomware.
Use case working sessions are generally performed at the beginning of the project during initial requirements gathering and will repeat as the project requirements or scope changes. Abuse cases are best developed after the use cases are developed or modified. Your organization’s Software Development Lifecycle (SDLC) methodology will determine the best cadence and order that matches your workflow.
Because developing abuse cases requires thinking outside of the box, it is best done as an exercise involving people of different skill sets, experience, and understanding of the system including architects, developers, testers, system and network administrators, etc. Choose you teams wisely.
What about Threat Modeling?
Threat modeling is an alternative to abuse case development where a potential threat is equal to an opportunity for abuse. Your SDLC methodology (and likely your project management experience) will dictate which is best for your organization, but the two approaches offer the same advantages to help secure your system from internal and external threats.
Threat modeling is supported by tools that help identify threats. As these tools have matured, the popularity of threat modeling has increased. However, you do not have to choose one over the other as they can be quite complimentary.
Conclusion
A detailed examination of developing abuse cases or threat models is outside of the scope of this article, but you can find great information in the OWASP approach to building, implementing and tracking abuse cases. It is largely SDLC agnostic though it may favor Agile in its language and examples. You can review the Abuse Case Cheat Sheet here:
Likewise, OWASP also provides an informative and actionable guide on threat modeling:
Each of these approaches present define and illustrate system, application and security risks in a manner that is informative, assignable and actionable. If your organization is not currently modeling abuses or threats, you are probably struggling with defect and security management that is painful and unsustainable. It’s time to identify your treats before they identify you.
We hope you found this post informational. If there are specific challenges you and your team face, the architects and engineers here at Clear Measure would be happy to work with you. Reach out to us now to find out all the ways we can help you!
