Abuse Cases

Abuse Case
• What an Abuse Case is?
• Why abuse cases are important when considering the security of an
application
• A proposal for a pragmatic approach to building a list of abuse cases
and tracking them for every feature planned for implementation as
part of an application. Regardless of the project methodology used
(waterfall or agile).
Abuse Case Objective
• The main objective is to provide a pragmatic approach in order to
allow a company or a project team to start building and handling the
list of abuse cases and then customize the elements proposed to its
context/culture in order to, finally, build its own method.
Why clearly identify the attacks
Clearly identifying the attacks against which the application must defend is
essential in order to enable the following steps in a project or sprint:
• Evaluate the business risk for each of the identified attacks in order
perform a selection according to the business risk and the project/sprint
budget.
• Derive security requirements and add them into the project specification or
sprint's user stories and acceptance criteria.
• Estimate the overhead of provision in the initial project/sprint charge that
will be necessary to implement the countermeasures.
• About countermeasures: Allow the project team to define them, and to
determine in which location they are appropriate (network, infrastructure,
code...) to be located.
Abuse Case: definition
• An Abuse Case can be defined 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).
Abuse Case
• Misuse and abuse cases describe how users misuse or exploit the
weaknesses of controls in software features to attack an application.
• This can lead to tangible business impact when a direct attack against
business functionalities, which may bring in revenue or provide
positive user experience, are attacked.
• Abuse cases can also be an effective way to drive security
requirements that lead to proper protection of these critical business
use cases.
Abuse Case
• Misuse and abuse cases describe unintended and malicious use scenarios of the
application, describing how an attacker could do this.
• Create misuse and abuse cases to misuse or exploit the weaknesses of controls in
software features to attack an application.
• Use abuse-case models for an application to serve as fuel for identification of concrete
security tests that directly or indirectly exploit the abuse scenarios.
• Abuse of functionality, sometimes referred to as a “business logic attack”, depends on the
design and implementation of application functions and features.
• An example is using a password reset flow to enumerate accounts. As part of business
logic testing, identify the business rules that are important for the application and turn
them into experiments to verify whether the application properly enforces the business
rule. For example, on a stock trading application, is the attacker allowed to start a trade at
the beginning of the day and lock in a price, hold the transaction open until the end of the
day, then complete the sale if the stock price has risen or cancel if the price dropped?
Make a workshop that includes people with
the following profiles:
• Business analyst: Will be the business key people that will describe each feature from a
business point of view.
• Risk analyst: Will be the company's risk personnel that will evaluate the business risk from
a proposed attack (sometimes it is the Business analyst depending on the company).
• Penetration tester: Will be the attacker that will propose attacks that they can perform on
the business feature(s) in question. If the company does not have a person with this
profile then it is possible to request the service of an external specialist. If possible,
include 2 penetration testers with different backgrounds in order to increase the number
of possible attacks that will be identified and considered.
• Technical leaders of the projects: Will be the project technical people and will allow
technical exchange about attacks and countermeasures identified during the workshop.
• Quality assurance analyst or functional tester: Personnel that may have a good sense of
how the application/functionality is intended to work (positive testing), not work
(negative testing), and what things cause it to fail (failure cases).
The figure provides an overview of the chaining of the different steps involved (from left to right):
Step 1: Preparation of the workshop
• First, the key business people must be sure to know, understand and be able to
explain the business features that will be processed during the workshop.
• Secondly, create a new Microsoft Excel file or any other similar software with the
following sheets:
• FEATURES
• Will contain a table with the list of business features planned for the workshop.
• ABUSE CASES
• Will contain a table with all abuse cases identified during the workshop.
• COUNTERMEASURES
• Will contain a table with the list of possible countermeasures (light description) imagined for the abuse
cases identified.
• This sheet is not mandatory, but it can be useful (for an abuse case to know), if a fix is easy to implement
and then can impact the risk rating.
• Countermeasures can be identified by the AppSec profile during the workshop, because an AppSec
person must be able to perform attacks but also to build or identify defenses (it is not always the case for
the Pentester profile because this person's focus is generally on the attack side only, so, the combination
Pentester + AppSec is very efficient to have a 360 degree view).
Step 2: During the workshop
• Use the spreadsheet to review all the features.
For each feature, follow this flow:
• Key business people explain the current feature from a business point of view.
• Penetration testers propose and explain a set of attacks that they can perform against the feature.
• For each attack proposed:
• Appsec proposes a countermeasure and a preferred set up location (infrastructure, network, code, design...).
• Technical people give feedback about the feasibility of the proposed countermeasure.
• Penetration testers use the CVSS v3 (or other standard) calculator to determine a risk rating. (ex: CVSS V3
calculator)
• Risk key people accept/increase/decrease the rating to have final one that match the real business impact for
the company.
• Business, Risk and Technical key peoples find a consensus and filter the list of abuses for the current
feature to keep the ones that must be addressed, and then flag them accordingly in the ABUSE
CASES sheet (if risk is accepted then add a comment to explain why).
• Pass to next feature...
Step 2 (cont..)
• If the presence of penetration testers is not possible then you can use the following
references to identify the applicable attacks on your features:
• OWASP Automated Threats to Web Applications
• OWASP Testing Guide
• OWASP Mobile Testing Guide
• Common Attack Pattern Enumeration and Classification (CAPEC)
Important note on attacks and countermeasure knowledge base(s):
• With the time and across projects, you will obtain your own dictionary of attacks and
countermeasures that are applicable to the kind of application in your business domain.
• This dictionary will speed up the future workshops in a significant way.
• To promote the creation of this dictionary, you can, at the end of the project/sprint, gather
the list of attacks and countermeasures identified in a central location (wiki, database,
file...) that will be used during the next workshop in combination with input from
penetration testers.
Step 3: After the workshop
• The spreadsheet contains (at this stage) the list of all abuse cases that
must be handled and, potentially (depending on the capacity)
corresponding countermeasures.
Now, there are two remaining task:
• Key business people must update the specification of each feature (waterfall)
or the User Story of each feature (agile) to include the associated abuse cases
as Security Requirements (waterfall) or Acceptance Criteria (agile).
• Key technical people must evaluate the overhead in terms of charge/effort to
take into account the countermeasure.
Step 4: During implementation - Abuse
cases handling tracking
In order to track the handling of all the abuse cases, the following approach can be used:
If one or several abuse cases are handled at:
•Design, Infrastructure or Network level
•Make a note in the documentation or schema to indicate that This
design/network/infrastructure takes into account the abuse cases ABUSE_CASE_001,
ABUSE_CASE_002, ABUSE_CASE_xxx.
•Code level
•Put a special comment in the classes/scripts/modules to indicate that This
class/module/script takes into account the abuse cases ABUSE_CASE_001,
ABUSE_CASE_002, ABUSE_CASE_xxx.
•Dedicated annotation
like @AbuseCase(ids={"ABUSE_CASE_001","ABUSE_CASE_002"}) can be used to
facilitate tracking and allow identification into integrated development environment.
Step 5: During implementation - Abuse
cases handling validation
• As abuse cases are defined, it is possible to put in place automated or manual
validations to ensure that:
• All the selected abuse cases are handled.
• An abuse case is correctly/completely handled.
• Validations can be of the following kinds:
• Automated (run regularly at commit, daily or weekly in the Continuous Integration Jobs of
the project):
• Custom audit rules in Static Application Security Testing (SAST) or Dynamic Application Security
Testing (DAST) tools.
• Dedicated unit, integration or functional security oriented tests.
• Manual:
• Security code review between project's peers during the design or implementation.
• Provide the list of all abuse cases addressed to pentesters so that they may validate the protection
efficiency for each abuse case during an intrusion test against the application (the pentester will
validate that the attacks identified are no longer effective and will also try to find other possible
attacks).
https://cheatsheetseries.owasp.org/cheatsheets/Abuse_Case_Cheat_Sheet.html