Preparing PASTA Today 🍝 Threat Modelling for Real Banking Systems
- VENUGOPAL PARAMESWARA
- 1 day ago
- 9 min read
In this post, we’ll prepare some PASTA—not the edible kind, but the Process for Attack Simulation and Threat Analysis—using a very real, very common banking scenario.
Threat modeling often gets a bad reputation. Too theoretical. Too many diagrams. Too much “security says NOs"
Industry surveys paint an interesting picture. While a strong majority of software organizations say threat modeling is important, far fewer actually do it consistently as part of every project.
While public data rarely breaks this down by industry, banking teams typically sit at the higher end of these averages due to regulatory pressure and fraud risk. However, even in banks, threat modeling is often applied selectively—during major initiatives or audits—rather than as a lightweight, repeatable practice for every feature.
This gap is exactly why lightweight, scenario-driven models like PASTA work so well—especially in fast-moving banking program.
Threat modeling is actually a storytelling exercise—one where we follow a perfectly normal banking feature and ask a simple question:
“What could realistically go wrong here?”
.
The scenario we’ll use throughout
Mobile banking app
A customer:
Logs in
Adds a new beneficiary
Transfers money
This single flow is responsible for:
Massive customer convenience
Massive fraud losses (when things go wrong)
Let’s walk it through all 7 stages of PASTA.
Step 1: Define the business objectives
Before we worry about boiling water or chopping garlic for my PASTA, we need to answer a simpler question:
Whome are we cooking this dish for?
Do I need to make some adjustments to the key ingredients based someone's allergic reaction or health condition?
How many are there to be fed etc..
If you notice this stage of PASTA is deliberately not talking about threats or security .
From the bank’s point of view, this feature exists to:
Increase digital transactions
Reduce branch and call-center load
Provide a smooth, low-friction customer experience
Stay competitive with other banks and fintechs
This framing is crucial and matters.
Because every security control we add later will either support these goals—or quietly fight them!.
Threat modeling works best when we admit that upfront.
Step 2: Define the technical scope
At this stage, we’re not worrying about threats yet — we’re just agreeing on which systems are in our kitchen and which ones aren’t.
Threat modeling fails most often when teams forget this simple rule: we’re not cooking everything in the fridge.
This stage is all about zooming in and getting concrete.
For our simple “add beneficiary + transfer” flow, the scope typically includes:
Mobile app (Android / iOS)
Backend API layer
Authentication service
OTP delivery service (SMS / email / push)
Core banking system
Fraud monitoring engine
Logs, alerts, and support tools
Already, this looks less “simple” than the UI suggests.
That’s the first PASTA lesson:
User simplicity is often built on system complexity.
Step 3: Application decomposition
Stage 3 is where we do 'mise en place'. We stop saying “the app adds a beneficiary” and break it into the exact steps and handoffs. Think of it like in cooking — chopping ingredients, moving between stations (chopping board → stove → plating), and noting what ingredients (data) are handled at each point. In banking flows, the most important part isn’t the steps — it’s the handoffs between systems where assumptions and trust creep in.
In technology terms, that is steps, data, components, and trust boundaries.
Lets break down the 'steps' part:
Login / session established
Initiate Add Beneficiary
Enter beneficiary details
OTP / step-up verification
Beneficiary stored + status set (pending/active)
Initiate transfer
Validate limits + risk checks
Execute transfer (core banking)
Notify customer + log event
Lets also list the 'data/ingredients':
Customer ID
Session token
Beneficiary account number / IFSC
OTP / verification result
Transfer amount
Device fingerprint / IP
Risk score / fraud flags
Please note you don't need the whole ingredients for each step.
Pick the only relevant ones from above. You know (or will know) how it affects the taste if you over utilize or under utilise an ingredient in a dish!.
Now lets determine the 'Trust boundaries/handoffs or kichen stations'. The classic trust boundaries are:
Device ↔ API gateway/backend
Backend ↔ OTP provider
Backend ↔ Fraud/risk engine
Backend ↔ Core banking
Backend ↔ Notification channels
Backend ↔ Logs/SIEM/support tools
In cooking there are few high conequence actions like flame on high heat or adding salt or sugar etc
Similarly in applications decomposition there are similar high consequence steps which are high risk / audit critical step
like:
Beneficiary creation
Step-up auth / OTP
Transfer execution
Limit checks / risk decision
Customer notification
Logging / audit trail
So just like our recipe card, you will have to prepare application decomposition card for each high consequence steps:
Step: Add beneficiary
Station: Mobile app → Backend API
Ingredients: session token, beneficiary acct/IFSC
Output: “beneficiary add request created”
Key questions we ask:
Where does sensitive data first appear?
Which system trusts which other system?
Where do we assume the user is legitimate?
They say fraudsters or hackers doesn’t break security like encryption or access controls. They simply abuses assumptions between systems.
Step 4: Threat analysis — thinking like an attacker
Stage 4 is where we stop following the recipe and start imagining everything that could go wrong if someone wanted to sabotage the dish.
Kitchen | Banking |
Distracted Junior staff | Compromised user session |
Saboteur adding salt | Fraudster adding beneficiary |
Spoiled ingredient | Malware on device |
Recipe thief | API abuser |
Sneaky sous-chef | Insider misuse |
We walk the recipe and ask: if someone wanted to ruin this dish, where would they intervene?
Threat analysis works best when you do it step-by-step.
Cooking step → Threat question:
Chopping → What if the knife slips?
Boiling → What if the heat is too high?
Plating → What if someone swaps plates?
Banking equivalent:
Add beneficiary → What if this happens from a hijacked session?
OTP → What if it’s intercepted or reused?
Transfer → What if limits are slowly tested and bypassed?
Focus on outcomes attackers want, not technique . No one cares how the sauce is spoiled — only that the dish is inedible.
Let’s meet some realistic attackers:
Someone who bought leaked credentials
Malware already running on a phone
A bot network abusing APIs
A low-privilege insider misusing access
Their goals are refreshingly simple:
Add their own account as a beneficiary
Move money out
Avoid detection long enough to repeat it
Walking the flow, we ask uncomfortable questions:
Can beneficiary addition happen without re-authentication?
Is OTP tied to login only, not to what is being done?
Are device, IP, or behavior changes noticed?
Can actions be chained quietly over time?
Recipe Step (Flow) | Kitchen Analogy | Threat Scenario | Attacker Intent |
User logged in | Chef allowed in kitchen | Compromised session | Act as legitimate user |
Add beneficiary | Adding a new ingredient | Fraudulent beneficiary added | Redirect funds |
OTP verification | Taste check | OTP intercepted or reused | Bypass validation |
Cooling-off period | Letting dish rest | Time-based attack | Avoid detection |
Transfer initiation | Serving the dish | Funds transferred in small amounts | Stay below alerts |
Risk checks | Head chef approval | Risk engine bypass | Avoid blocks |
Notifications | Plating & serving | Alerts delayed or ignored | Buy time |
Logs & monitoring | Kitchen CCTV | Logs incomplete | Evade investigation |
At this stage, we are not judging design choices.We are just identifying what attackers would love.
Step 5: Vulnerability analysis — where things get easy
In Stage 4, we thought like saboteurs and asked what could go wrong if someone wanted to ruin this dish. But not every kitchen nightmare is possible in every kitchen.
Stage 5 is where we stop imagining and start inspecting. We walk back through our own kitchen and ask a more uncomfortable question: which of these problems does our setup actually make easy?
Threat analysis shows us the dangers. Vulnerability analysis shows us our weaknesses.
In our cooking context:
Threat (Stage 4) | Vulnerability (Stage 5) |
Someone adds too much salt | Salt jar is open and unlabelled |
Sauce burns | No timer, heat too high |
Wrong ingredient added | Ingredients look similar |
Dish swapped | No labeling before plating |
In our banking context:
Threat | Vulnerability |
Beneficiary added fraudulently | No step-up auth for beneficiary creation |
OTP abuse | OTP reused across actions |
Silent fraud | No velocity checks |
Delayed detection | Logs exist |
Important observation after your analysis:
These are rarely “bugs”.
They’re trade-offs made for speed, UX, or legacy reasons.
PASTA doesn’t shame these decisions—it surfaces them.
Step 6: Attack modelling — tell the fraud story
If Stage 4 was imagination and Stage 5 was inspection..then Stage 6 is rehearsal.
Attack modelling is not about inventing new problems. It is about chaining the weakneses we already found in exact order someone would exploit them.
In cooking terms:
It is not “the sauce could burn”. But “first the heat is too high, then the timer is missing, then no one notices until it’s too late”
In banking terms, taking fraud without alarm scenerio:
Attacker logs in using compromised credentials
Adds a beneficiary during a low-activity period
OTP is reused / intercepted
Cooling-off period passes without scrutiny
Transfers begin just below alert thresholds
Alerts arrive after funds are gone
No exploits.No zero-days.Just patience and system knowledge.
This is why attack modeling is so powerful. It shows how small, reasonable gaps become big losses when combined.
Step | Action | System Weakness Used | Result |
1 | Login using stolen creds | Session trust | Attacker is “legitimate” |
2 | Add beneficiary | No step-up auth | Attacker-controlled account added |
3 | Complete OTP | OTP reuse window | Verification bypassed |
4 | Wait | Passive monitoring | No intervention |
5 | Transfer funds | Threshold-based alerts | Fraud stays invisible |
6 | Detection | Delayed alerts | Funds already moved |
Step 7: Risk and impact analysis
In a real kitchen, this is the moment before the plate leaves the pass.
The chef asks:
If this dish goes out as-is, could someone get sick?
Would customers complain—or worse, post about it?
Would this survive a health inspection?
Is this a minor tweak, or should the dish be pulled entirely?
Finally, we step back and speak the language decision-makers understand.
Impact isn’t just:
Money lost
It’s also:
Regulatory scrutiny
Customer trust erosion
Incident response costs
Brand damage
The payoff of PASTA shows up here:
A single control (like step-up auth for new beneficiaries)
Can disrupt multiple attack paths
With minimal UX impact if designed well
That’s not “security theater”.That’s risk-aware design.
Providing a sample Annualized Loss Exposure using FAIR as a reference
Automating PASTA: from scratch cooking to a pre-heated kitchen
Up to this point, we’ve prepared PASTA the traditional way.
We clarified business objectives.
We decomposed applications carefully.
We walked attack paths step by step.
We quantified impact and debated trade-offs.
That process works — but it’s also time-consuming, skill-intensive, and hard to repeat consistently across every feature, sprint, or team.
In cooking terms, this is the difference between:
Making pasta entirely from scratch every single time
Versus walking into a pre-heated kitchen with ingredients measured, stations labeled, and timers already set
This is where automating PASTA starts to make sense.
What automation actually means (and what it doesn’t)
Automating PASTA does not mean:
Replacing human judgment
Auto-generating generic threat lists
Turning threat modeling into a checkbox exercise
Instead, it means removing the mechanical effort so teams can focus on decisions that matter.
Think of it like this:
The chef still decides the recipe — the kitchen just makes it easier to cook well every time.
How CreativeCyber automates the hardest parts of PASTA
Without changing the methodology, automation helps where teams usually struggle the most:
1. Business objectives — structured, not vague
Instead of starting from a blank page, teams are guided to:
Define business context clearly (customer type, transaction value, regulatory exposure)
Attach quantitative impact early (₹ exposure, compliance obligations)
Make trade-offs explicit before security controls are discussed
This directly supports Stage 1, where most threat models quietly fail.
2. Application decomposition — without missing critical handoffs
Manually decomposing applications is error-prone:
Trust boundaries get skipped
“Side systems” like logs and alerts are forgotten
High-consequence steps are under-emphasized
Automation helps:
Map systems, data flows, and trust boundaries consistently
Highlight high-risk and audit-critical steps by default
Ensure nothing important falls through the cracks
This reinforces Stage 2 and Stage 3, without turning them into architecture documents.
3. Attack modeling — visual, repeatable, explainable
Instead of free-form narratives, attack paths can be:
Modeled explicitly
Visualized clearly
Replayed and explained to non-security stakeholders
This is especially powerful in Stage 6, where seeing how an attack unfolds changes conversations completely.
4. Countermeasure impact — before you deploy
Perhaps the biggest advantage of automation shows up after analysis.
Rather than asking:
“Will this control help?”
Teams can see:
Which attack paths a control breaks
How much risk reduction it delivers
What residual risk remains after mitigation
This transforms PASTA from analysis into decision support.
The outcome: PASTA becomes repeatable, not rare
When PASTA is automated thoughtfully:
It stops being something you do once a year
It becomes something you can apply feature by feature
It fits naturally into design, build, and review cycles
In cooking terms:
Good kitchens don’t rely on heroic chefs. They rely on good preparation, good tools, and good processes.
After walking through one very ordinary banking feature, a few patterns become clear.
Threat modeling works best when it’s treated as a conversation, not a document that gets written once, reviewed once, and archived forever. The value isn’t in the diagrams themselves — it’s in the questions teams are forced to ask while creating them.
You also don’t need an endless list of scenarios. One well-chosen, realistic flow is often enough to surface the most meaningful risks. When the scenario is grounded in everyday usage, the insights tend to be deeper and far more actionable.
Perhaps most importantly, security is most effective when it is explicitly aligned with business objectives. Controls that support customer experience, operational efficiency, and regulatory goals tend to survive. Controls that fight them quietly get bypassed or eroded over time.
And finally — the most liberating lesson:
You don’t need to model everything. You just need to model something real.
A single feature.
A single flow.
A single honest conversation about how it could fail.
So the next time a feature is being designed, shipped, or reworked, pause for a moment and ask:
“What kind of PASTA are we preparing today?” 🍝