PASTA Threat Modelling for Real Banking Systems: The Add-Beneficiary & Fund-Transfer Walkthrough

Introduction

Threat modelling has a reputation problem. Too many diagrams, too theoretical. When AppSec teams spend three sprints producing a threat model that never makes it into a Jira epic, the exercise becomes ritual rather than engineering.

Yet every Indian retail bank runs the same flows that get compromised the same ways — not because encryption was weak, but because assumptions between systems were never written down. The handshake between the mobile app and the OTP service. The implicit trust placed on the risk engine’s decision. The mutable cooling-off flag in core banking that customer service agents can lift.

PASTA (Process for Attack Simulation and Threat Analysis) is the 7-stage, risk-centric methodology that fixes this. Unlike STRIDE alone, PASTA connects threat discovery to business impact and then to a prioritised control backlog. This walkthrough applies all seven stages to the most fraud-targeted flow in Indian retail banking: add beneficiary + transfer money.

Why Banking Teams Should Pick PASTA Over STRIDE Alone

STRIDE is a threat taxonomy — a checklist of six threat categories. It tells you what kind of threat could exist at each component. What it does not tell you is whether any of those threats actually matter to your business, your CFO’s risk register, or your SEBI CSCRF assessment.

PASTA wraps STRIDE inside a business-impact framework. The difference in outputs is significant.

The Scenario: Data Flow Diagram

Before the seven stages can begin, you need a DFD that captures all systems, trust boundaries, and data flows. For the add-beneficiary + fund-transfer flow, two trust boundaries matter: the Device Zone (the customer’s mobile handset and carrier network) and the Bank Perimeter (everything the bank controls directly).

Stage 1: Define the Business Objectives

Why does the add-beneficiary + transfer flow exist? Before cataloguing threats, PASTA demands you articulate the business rationale — because risk can only be assessed relative to the value being protected.

• Drive digital transaction volume and defend against fintech disintermediation
• Meet RBI digital adoption targets and UPI/NEFT SLA obligations
• Reduce branch and call-centre transaction load
• Operate under DPDP Act, RBI Cyber Security Framework, and SEBI CSCRF obligations

Loss-event quantification: A successful fraud event on this flow produces direct financial loss (debit from customer account), RBI Banking Ombudsman exposure, measurable customer churn in the cohort, and brand damage that suppresses digital acquisition. Annualised Loss Expectancy (ALE) can be computed per FAIR by multiplying frequency of breach events by probable magnitude of loss.

Stage 2: Define the Technical Scope

One of the most common PASTA failures in banking is a scope that stops at the primary flow and misses the supporting infrastructure. The full scope for this walkthrough includes:

• Mobile application (iOS + Android, WebView if applicable)
• API Gateway (WAF, TLS termination, rate limiting)
• Authentication service (session management, token issuance)
• OTP provider (SMS gateway, TOTP service, attempt counters)
• Fraud / risk engine (velocity rules, ML scoring, decision API)
• Core banking system (beneficiary table, cooling-off logic, ledger)
• Settlement rails (NEFT, IMPS, UPI adapter, NPCI interface)
• SIEM / audit logging (event enrichment, alerting pipelines)
• Customer support tooling — critically, this is often omitted despite having direct write access to beneficiary and cooling-off fields

Stage 3: Application Decomposition

Each step in the flow is decomposed to identify what data is written, what trust transitions occur, and which system is the authority for each state change. Nine steps cover the full beneficiary + transfer lifecycle.

Stage 4: Threat Analysis

With the flow decomposed, PASTA requires identification of realistic threat actors — not abstract adversaries, but actors who are actually observed in Indian BFSI incident data.

STRIDE Catalog for This Flow

Applying STRIDE to the decomposed flow yields the following threat catalog. These are the inputs that feed Stage 5 vulnerability analysis.

Stage 5: Vulnerability Analysis

PASTA distinguishes between threats (what an attacker wants to do) and vulnerabilities (the weaknesses that make it possible). The following six vulnerabilities map directly to the STRIDE threats above.

• Beneficiary creation does not require a dedicated step-up. State change (adding a payee) uses the same authentication as read operations. This is the primary attack surface.
• OTP scope is overly broad. The same OTP flow — or even a recycled OTP value — is accepted for both add-beneficiary and transfer actions. Reducing OTP scope per action closes several attack paths.
• Cooling-off can be lifted by CSA/maker with insufficient checker enforcement. The cooling-off period is implemented as a database flag, not an immutable timer. CSA tooling allows modification without a second approver or SIEM alert.
• Velocity rules count rupee amounts, not behavioral patterns. Ten transfers of ₹49,000 each do not trip a ₹50,000 threshold. Sub-threshold burst behavior combined with new-payee weight is not evaluated.
• Log alerts arrive after settlement clears. The SIEM rule fires on transaction volume anomalies, but NEFT settlement completes in 18–30 minutes. By the time the alert is actioned, funds have cleared.
• Device binding is advisory, not enforced. A new device can complete the full beneficiary-plus-transfer flow if credentials and OTP are available. Device registration is a UX hint, not a control gate.

Stage 6: Attack Modelling — The Fraud Narrative

PASTA Stage 6 builds attack trees and simulates realistic attack chains. The most common fraud narrative for this flow in Indian BFSI combines credential stuffing, SIM swap, and sub-threshold velocity — all exploiting the vulnerabilities identified in Stage 5.

Stage 7: Risk & Impact Analysis

The final PASTA stage produces a risk matrix that maps each finding to likelihood, impact, an overall risk rating, and the highest-value control intervention. Risk ratings here use a 2×2 qualitative scale anchored to the loss quantification from Stage 1.

Mapping PASTA to Indian Regulations

A PASTA output is not just an AppSec artefact — it is evidence. The findings and controls from Stages 5–7 map directly to clauses that SEBI, RBI, and CERT-In auditors examine. The table below shows the specific clauses and what inspectors look for.

Why Manual PASTA Stalls

PASTA is powerful in theory and frustrating in practice when run entirely manually. Five structural blockers cause most banking AppSec programmes to abandon the methodology after one cycle:

• Authored once, never refreshed. The threat model from the initial application launch is still being submitted two years later. Threat actors have evolved; the model has not.
• Findings in slides, controls in Jira — traceability dies on first hand-off. Without a structured linkage between threat-model finding and control implementation, the connection is lost within weeks.
• No quantification — every finding is “high.” Without FAIR or an equivalent quantification layer, prioritisation is political rather than risk-based. CISO and CFO cannot have the same conversation.
• Regulator mapping is manual. Every SEBI or RBI audit re-derives the same cross-walk from threat-model findings to regulatory clauses. This is hours of work that should be automated.
• Detection rules do not trace back to threat-model leaves. The SIEM team writes rules based on vendor recommendations, not the threat model. Gaps are invisible until an attacker finds them.

Practitioner Checklist

If you are running PASTA for the first time on a banking flow, these five steps will get you from blank page to actionable backlog in a single working session: