Abuse Case Model - Revision history

Tom: /* Example */

2026-03-04T05:17:59Z

‎Example

Tom: /* Example */

2026-03-04T01:54:44Z

‎Example

Tom: /* Definition */

2026-03-04T00:11:01Z

‎Definition

Tom: Created page with "==Definition== Identifying abuse before designing architecture: Embedding Game-Based Threat Modelling into Agile Delivery at a Major Latin American Bank CyberSec Games 510 fo..."

2026-03-04T00:04:38Z

Created page with "==Definition== Identifying abuse before designing architecture: Embedding Game-Based Threat Modelling into Agile Delivery at a Major Latin American Bank CyberSec Games 510 fo..."

New page

==Definition==
Identifying abuse before designing architecture: Embedding Game-Based Threat Modelling into Agile Delivery at a Major Latin American Bank

CyberSec Games
510 followers

March 3, 2026
This case study is based on the account of Max Alejandro Gómez-Sánchez Vergaray, AppSec & DevSecOps Consultant, who designed and led an application security programme during the digital transformation of one of the largest banks in Peru. Over the course of the programme, more than 3,000 people were trained in secure software development using OWASP Cornucopia.

Why Security Became Urgent
When I began leading the application security programme, teams were delivering software at scale and the bank was undergoing digital transformation. Agile methods were well established but while security existed on paper it was not yet embedded into everyday engineering practice and lacked sponsorship.

Then the bank experienced a cyber attack.

Delivery teams paused feature work to resolve security problems and executive attention followed. External consultants were engaged at significant cost, and a threat modelling approach was introduced based on Trike - a semi-automated formal model focused on Denial of Service and Elevation of Privilege threats.

While the methodology was sound, the problem was sustainability. Consultancy-led threat modelling can assess systems, but it does not automatically create internal engineering capability. My goal was to ensure that security thinking became part of how teams built software, not something triggered only by incident or audit.

The Structural Problem in Agile
In a traditional SDLC, security activities are distributed across phases. Requirements analysis, design, development, and testing are each linked to security activities and checkpoints.

Agile changes that dynamic. Work begins with high-level user story exploration. Stories are refined and prioritised in sprint planning. Architecture often evolves in parallel. By the time a traditional threat model is created around an architectural diagram, many functional decisions have already been made.

In practice, identifying security requirements during architectural threat modelling is often too late. The backlog is already shaped. Trade-offs have been made. Time pressure is real.

I realised that if we wanted security to influence design meaningfully, it had to be integrated before architecture crystallised.

The Two Concepts That Changed the Model
To make this work, I relied on two foundational concepts: abuse case modelling and Secure Scrum.

Abuse case modelling takes each legitimate use case and models a corresponding negative scenario, behaviour undesired by the system owner. The goal is not simply to enumerate threats, but to identify the security requirements that prevent those undesirable outcomes.

For example, if a use case involves user authentication, an abuse case might explore credential stuffing or brute force attempts. The discussion then naturally leads to security requirements such as rate limiting, password strength policies, or multi-factor enforcement.

Secure Scrum builds on this by integrating security requirements directly into user stories. Instead of treating security as an external checklist, security requirements become part of system requirements from the moment user stories are identified.

Why I Chose OWASP Cornucopia
I had experience with OWASP’s research and its card-based framework, OWASP Cornucopia. Traditionally, Cornucopia is played against an architectural diagram to identify threats.

I decided to reposition it.

The bank operated using a SAFe-aligned model with quarterly planning events so that an overall vision, work items, and dependencies are all identified before sprints begin for the quarter. These sessions brought cross-functional teams together to define plans and break them down into epics and stories

This was the ideal point to insert OWASP Cornucopia.

We shuffled the cards and to participants, ensuring a mix of suits. A facilitator guided the session, clarifying complex cards and moderating discussions. Epics were placed visibly on the wall. Each participant examined their cards and argued how specific threats or misuse scenarios related to particular epics or user stories.

The real power was not found in the mechanics of the game, but in the conversations it triggered. Engineers and Product Owners collectively explored what could go wrong and reasoned about attacker behaviour in the context of real features.

From those discussions, we derived security requirements and attached them directly to backlog items.

Moving the “Magic” Earlier
In many Agile environments, threat modelling occurs after architecture diagrams are drafted. By then, the cost of change is higher.

By integrating Cornucopia into quarterly planning, we moved the magic earlier. We “spread left” as far as we could, to the very first artifacts in our agile workflow.

As a result, security requirements were identified well before sprint work began. When architecture was later discussed, it already reflected security-conscious decisions. Subsequent structured threat modelling sessions were more focused and more effective because they operated on stronger inputs.

We also aligned our requirements with recognised standards such as the OWASP Application Security Verification Standard. This ensured that our approach was not informal or purely cultural. It was grounded in established verification practices.

To support governance, we introduced a lightweight traceability matrix linking each user story to its associated security requirements and related weaknesses. This allowed us to manage defects systematically if requirements were not properly implemented, while keeping overhead manageable.

Scaling Capability
What began with a single team expanded steadily. Engineers appreciated that the method fit their workflow rather than disrupting it. Over time, I trained more than 3,000 people across the organisation in secure software development practices using Cornucopia as an entry point.

Eventually, I implemented a train-the-trainer model. Security could not depend on one facilitator. Engineering leads were trained to run their own sessions. This distributed ownership was critical to sustainability.

Annual retraining ensured that security culture did not fade. Teams developed shared vocabulary around misuse, abuse cases, and preventive controls. Security thinking became habitual rather than exceptional.

The Real Value
The greatest value was not the number of threats identified. It was the change in behaviour.

Security requirements became visible within user stories. Product Owners understood the impact of prioritisation decisions. Architecture discussions included security trade-offs as standard practice. Late-stage rework decreased because risks surfaced earlier.

In recent years, automated and AI-driven threat modelling tools have become more common. Automation is valuable, but tools do not replace shared reasoning. When engineers collectively analyse how their systems could be abused, they develop judgement. That judgement influences countless micro-decisions that no tool can fully predict.

I often share a piece of advice I once received: it is much better to have a good threat model that’s finished than a perfect threat model that isn’t finished.

In Agile environments, pragmatism matters. By e

@@ Line 77: / Line 77: @@
 I often share a piece of advice I once received: it is much better to have a good threat model that’s finished than a perfect threat model that isn’t finished.
-In Agile environments, pragmatism matters. By e
+In Agile environments, pragmatism matters.
 ==References==

@@ Line 6: / Line 6: @@
 CyberSec Games March 3, 2026
-This case study is based on the account of Max Alejandro Gómez-Sánchez Vergaray, AppSec & DevSecOps Consultant, who designed and led an application security programme during the digital transformation of one of the largest banks in Peru. Over the course of the programme, more than 3,000 people were trained in secure software development using OWASP Cornucopia.
+This case study is based on the account of Max Alejandro Gómez-Sánchez Vergaray, AppSec & DevSecOps Consultant, who designed and led an application security programme during the digital transformation of one of the largest banks in Peru. Over the course of the programme, more than 3,000 people were trained in secure software development using [https://cornucopia.owasp.org/about OWASP Cornucopia].
 Why Security Became Urgent
-When I began leading the application security programme, teams were delivering software at scale and the bank was undergoing digital transformation. Agile methods were well established but while  security existed on paper it was not yet embedded into everyday engineering practice and lacked sponsorship.
+When I began leading the application security program, teams were delivering software at scale and the bank was undergoing digital transformation. Agile methods were well established but while  security existed on paper it was not yet embedded into everyday engineering practice and lacked sponsorship.
 Then the bank experienced a cyber attack.
@@ Line 24: / Line 24: @@
 In practice, identifying security requirements during architectural threat modelling is often too late. The backlog is already shaped. Trade-offs have been made. Time pressure is real.
-I realised that if we wanted security to influence design meaningfully, it had to be integrated before architecture crystallised.
+I realized that if we wanted security to influence design meaningfully, it had to be integrated before architecture crystallized.
 The Two Concepts That Changed the Model
 To make this work, I relied on two foundational concepts: abuse case modelling and Secure Scrum.
-Abuse case modelling takes each legitimate use case and models a corresponding negative scenario, behaviour undesired by the system owner. The goal is not simply to enumerate threats, but to identify the security requirements that prevent those undesirable outcomes.
+Abuse case modelling takes each legitimate use case and models a corresponding negative scenario, behavior undesired by the system owner. The goal is not simply to enumerate threats, but to identify the security requirements that prevent those undesirable outcomes.
 For example, if a use case involves user authentication, an abuse case might explore credential stuffing or brute force attempts. The discussion then naturally leads to security requirements such as rate limiting, password strength policies, or multi-factor enforcement.
@@ Line 46: / Line 46: @@
 We shuffled the cards and to participants, ensuring a mix of suits. A facilitator guided the session, clarifying complex cards and moderating discussions. Epics were placed visibly on the wall. Each participant examined their cards and argued how specific threats or misuse scenarios related to particular epics or user stories.
-The real power was not found in the mechanics of the game, but in the conversations it triggered. Engineers and Product Owners collectively explored what could go wrong and reasoned about attacker behaviour in the context of real features.
+The real power was not found in the mechanics of the game, but in the conversations it triggered. Engineers and Product Owners collectively explored what could go wrong and reasoned about attacker behavior in the context of real features.
 From those discussions, we derived security requirements and attached them directly to backlog items.
@@ Line 57: / Line 57: @@
 As a result, security requirements were identified well before sprint work began. When architecture was later discussed, it already reflected security-conscious decisions. Subsequent structured threat modelling sessions were more focused and more effective because they operated on stronger inputs.
-We also aligned our requirements with recognised standards such as the OWASP Application Security Verification Standard. This ensured that our approach was not informal or purely cultural. It was grounded in established verification practices.
+We also aligned our requirements with recognized standards such as the OWASP Application Security Verification Standard. This ensured that our approach was not informal or purely cultural. It was grounded in established verification practices.
 To support governance, we introduced a lightweight traceability matrix linking each user story to its associated security requirements and related weaknesses. This allowed us to manage defects systematically if requirements were not properly implemented, while keeping overhead manageable.
 Scaling Capability
-What began with a single team expanded steadily. Engineers appreciated that the method fit their workflow rather than disrupting it. Over time, I trained more than 3,000 people across the organisation in secure software development practices using Cornucopia as an entry point.
+What began with a single team expanded steadily. Engineers appreciated that the method fit their workflow rather than disrupting it. Over time, I trained more than 3,000 people across the organization in secure software development practices using Cornucopia as an entry point.
 Eventually, I implemented a train-the-trainer model. Security could not depend on one facilitator. Engineering leads were trained to run their own sessions. This distributed ownership was critical to sustainability.
@@ Line 69: / Line 69: @@
 The Real Value
-The greatest value was not the number of threats identified. It was the change in behaviour.
+The greatest value was not the number of threats identified. It was the change in behavior.
-Security requirements became visible within user stories. Product Owners understood the impact of prioritisation decisions. Architecture discussions included security trade-offs as standard practice. Late-stage rework decreased because risks surfaced earlier.
+Security requirements became visible within user stories. Product Owners understood the impact of prioritization decisions. Architecture discussions included security trade-offs as standard practice. Late-stage rework decreased because risks surfaced earlier.
-In recent years, automated and AI-driven threat modelling tools have become more common. Automation is valuable, but tools do not replace shared reasoning. When engineers collectively analyse how their systems could be abused, they develop judgement. That judgement influences countless micro-decisions that no tool can fully predict.
+In recent years, automated and AI-driven threat modelling tools have become more common. Automation is valuable, but tools do not replace shared reasoning. When engineers collectively analyze how their systems could be abused, they develop judgement. That judgement influences countless micro-decisions that no tool can fully predict.
 I often share a piece of advice I once received: it is much better to have a good threat model that’s finished than a perfect threat model that isn’t finished.
 In Agile environments, pragmatism matters. By e