A Method for Developing Abuse Cases and Its Evaluation

Abstract

Abstract:To develop secure software, software engineers need to have the mindset of attackers. Developing abuse cases can help software engineers to think more like attackers. This paper describes a method for developing abuse cases based on threat modeling, attack patterns, and Common Weakness Enumeration. The method also includes ranking the abuse cases according to their risks. This method intends to help non-experts create abuse cases following a specific process, and leveraging the knowledge bases of threat modeling, attack patterns, and Common Weakness Enumeration. The proposed method was evaluated through two evaluation studies conducted in two secure software engineering courses at two different universities. Evaluation studies show that the proposed method was easier to follow by non-experts in generating abuse cases than brainstorming, and could reduce the time needed for creating abuse cases. Other findings from the evaluation studies are also discussed in the paper.

An Exploratory Study Gathering Security Requirements for the Software Development Process

“…Additionally, the use of threat modeling techniques, such as attack trees or misuse cases, can also help to identify potential vulnerabilities and abuse scenarios. In this context, Williams et al [32] propose the development of abuse stories based on a list of keywords from threat modeling, attack patterns, and Common Weakness Enumeration. The study shows better results when creating abuse stories than using brainstorming.…”

“…Abuse stories should identify patterns, antipatterns, or bad practices utilized by software developers, which could be applied in a heuristic manner in the process of software development. (d) Monitoring (Integration with Software Development Lifecycle): Integrating abuse stories into the software development lifecycle can aid in identifying and mitigating potential risks during the early stages of development [32]. Regular security assessments within each sprint can facilitate prompt rectifications in the code development or refactoring process.…”

“…Yoo et al [30] incorporates the goals of attackers, offering more realistic meanings to security threats, and mentions that any change in or addition of functional requirements requires the risk of being re-evaluated. Conducting abuse stories for threat modeling could help to define various abuse scenarios used for bad users or attackers [31,32]. For instance, in the development of E-Commerce Platforms, abuse stories could define ways in which the systems working to prevent fraudulent activities, such as phishing scams, fake product listings and conduct payment fraud.…”