The Problem With Waiting for a Signature
Signature-based detection works on a simple premise: an attack leaves a known fingerprint. Your EDR, SIEM, or IDS compares observed behaviour against a catalogue of known-bad patterns. When the catalogue matches, you get an alert.
AI-generated attacks break this model at the source. A generative AI tool can produce thousands of phishing variants, none of which share a single string with a known template. AI-driven malware can modify its own bytecode mid-execution, shifting its signature in real time. A supply chain payload crafted by an LLM looks like legitimate build tooling until it doesn't.
IBM's 2026 report found that phishing is now India's leading initial attack vector at 19%, followed by drive-by compromise at 16% and supply chain compromise at 15%. All three are AI-accelerated. None of the three leave a reliable signature until after the initial access is already established.
This is not an argument against detection tools. It is an argument for a layer that operates before detection — one that maps the attack surface structurally, before any attacker arrives.
That layer is STRIDE.
What STRIDE Actually Is — And Isn't
STRIDE is a threat modelling methodology developed at Microsoft in the late 1990s. The acronym stands for six threat categories:
- Spoofing — impersonating something or someone trusted
- Tampering — modifying data or code in transit or at rest
- Repudiation — performing an action and denying it
- Information Disclosure — exposing data to unauthorised parties
- Denial of Service — degrading or disrupting a system's availability
- Elevation of Privilege — gaining capabilities beyond what was granted
What STRIDE is not: it is not a detection framework, a log analysis tool, or a vulnerability scanner. You do not run STRIDE against live traffic. You run STRIDE against a diagram of your system — a Data Flow Diagram (DFD) — and ask, for every element, every data flow, and every trust boundary: which of these six threats applies here?
The output is a structured catalogue of threats specific to your architecture, each mapped to a mitigation control. That catalogue exists before any attacker arrives. It is completely indifferent to whether the attacker is using a script, a commercial exploit kit, or a GPT-4o jailbreak.
An AI-generated phishing email is a Spoofing threat in STRIDE. An LLM-mutated payload that rewrites itself to evade EDR is a Tampering + Elevation of Privilege threat. A supply chain compromise that installs a backdoor in your build pipeline is a Tampering + Repudiation threat. STRIDE names all of these before they happen — because it works from structure, not signatures.
Where Signatures Fail: A STRIDE-Mapped Comparison
The following table maps the five most common AI-accelerated attack patterns in Indian BFSI (based on CERT-In advisories and IBM 2026 data) against signature-based detection and STRIDE threat modelling. The gap is not subtle.
| AI-Accelerated Attack Pattern | STRIDE Category | Signature Tool Coverage | STRIDE Coverage |
|---|---|---|---|
| LLM-generated spear phishing Personalised lures using scraped LinkedIn, regulatory language, executive names |
Spoofing | Low — no signature matches novel content | Yes — trust boundary between email gateway and user identified; controls mapped |
| Self-mutating malware Payload rewrites its bytecode mid-execution to evade EDR signatures |
Tampering + Elevation of Privilege | Low — signature is stale by the time file executes | Yes — process trust boundary and code integrity requirements identified in DFD |
| AI-crafted supply chain payload Malicious dependency introduced into build pipeline, mimics legitimate package syntax |
Tampering + Repudiation | Partial — hash mismatch may catch, but only after pull | Yes — build pipeline modelled as untrusted external entity; integrity controls required |
| Deepfake voice / vishing for payment authorisation Voice cloned from earnings call audio; calls treasury team to authorise transfer |
Spoofing + Repudiation | None — phone channel outside tool perimeter entirely | Yes — out-of-band authorisation channel identified as unprotected trust boundary |
| AI-optimised credential stuffing ML model learns failed login patterns and adapts timing/volume to evade rate limits |
Elevation of Privilege | Partial — adaptive attacks tune to stay below alert thresholds | Yes — authentication boundary identified; step-up and anomaly controls required |
The pattern is consistent: signature tools have partial or no coverage precisely where AI-generated attacks are strongest — novelty, adaptability, and operating outside the tool's perimeter. STRIDE has full coverage of all five because it works from a model of the system, not a library of known-bad content.
A STRIDE Walkthrough: UPI Payment Initiation Flow
To make this concrete, here is a condensed STRIDE exercise on the UPI payment initiation flow common to every Indian private-sector bank. This is the exact flow an AI-generated attack would target — high value, well-understood externally from NPCI public documentation, and operating under the CERT-In 6-hour reporting obligation.
Step 1 — Define the Scope
Components in scope: Mobile banking app, API gateway, UPI switch connector, core banking system, NPCI interface. Trust boundaries: app-to-gateway (internet), gateway-to-switch (internal DMZ), switch-to-NPCI (regulated network).
Step 2 — Draw the Data Flow
Data flows: (1) User → App: VPA + amount + MPIN, (2) App → Gateway: signed JWT + device fingerprint, (3) Gateway → UPI Switch: ISO 20022 message, (4) Switch → NPCI: NFS protocol, (5) NPCI → Switch: response, (6) Switch → Core Banking: debit instruction.
Step 3 — Apply STRIDE to Each Element
| Element | Threat | STRIDE Category | AI Exploitation Vector | Required Control |
|---|---|---|---|---|
| Mobile App | Attacker clones app UI to harvest MPIN | Spoofing | LLM generates play-store description that passes review; UI cloned from APK | App attestation, certificate pinning, Play Protect enforcement |
| JWT in transit | Token intercepted and replayed | Tampering + Repudiation | AI-optimised MITM proxy adapts to SSL pinning variants | Short expiry, jti claim, server-side token binding |
| API Gateway | Rate limit bypass via AI-tuned request cadence | Elevation of Privilege | ML model learns per-IP throttle behaviour and distributes requests | Behavioural rate limiting (per-session, not per-IP), step-up auth on anomaly |
| Core Banking debit | Transaction log manipulated post-debit | Repudiation | Insider uses LLM to craft plausible log entries that mask the debit | Immutable audit log, hash-chained entries, RBI DPSC audit trail requirement |
| NPCI interface | ISO 20022 message fields tampered in transit | Tampering | Payload manipulation at DMZ boundary; AI-generated field values evade business rules | Message-level signing (JWS), field validation at gateway before switch handoff |
This exercise takes 3–4 hours for a team familiar with the flow. The output — a structured control list tied to specific architectural elements — directly maps to your CERT-In incident reporting obligations, your RBI IT governance requirements, and your SEBI CSCRF control library if you are a market intermediary.
CERT-In's 2022 Directions require organisations to maintain documented threat assessments for critical systems. RBI's 2026 Cybersecurity Directions (released July 31, 2026) require banks to conduct periodic threat modelling as part of technology risk assurance. A STRIDE artefact is direct evidence for both.
What to Do on Monday
STRIDE does not require a specialist tool to start. You need three things: a whiteboard (or Miro), a DFD of your highest-risk flow, and two hours with your application owner and security architect. The methodology is free. The discipline is the investment.
Practically:
- Pick one high-value flow. Payment initiation, customer onboarding, or admin access provisioning. Not the entire platform.
- Draw the DFD to L2. Processes, external entities, data stores, data flows, trust boundaries. Nothing more complex than a decent architecture review diagram.
- Run the six letters across each element. For every process, every flow, every data store — ask which of S, T, R, I, D, E applies. Expect 15–25 threats for a single flow.
- Map each threat to a control. Existing controls get a tick. Missing controls become the gap list.
- Prioritise by AI exploitability. Threats that AI-generated attacks can execute at scale — spoofing, tampering in transit, AI-tuned rate limit evasion — get Priority 1 treatment.
The gap list from step 4 is your CERT-In-evidenceable threat assessment. The Priority 1 items from step 5 are your board-level risk narrative for the next quarter.
Run STRIDE Inside RiskSage
RiskSage's STRIDE Threat Modelling module lets you build your DFD, run the six-letter analysis per element, and auto-generate a control gap report mapped to RBI, CERT-In, and SEBI CSCRF obligations. AI control suggestions flag which gaps are highest-risk for AI-accelerated attack vectors.
The Honest Caveat
STRIDE is not a silver bullet. It is a structured way to find threats before they are exploited. It does not guarantee you will find every threat — DFDs have scope boundaries, and a threat you did not model is a threat you did not find. It also does not replace your detection stack. Once a threat materialises as an active incident, you need SIEM, EDR, and response playbooks to contain it.
The argument is not STRIDE instead of detection. The argument is STRIDE before detection. For AI-generated attacks that arrive with no signature, the only layer that reliably works before the attack is one that operates from your architecture, not your alert log.
Twenty-six per cent of Indian breaches are already AI-generated. That number will not go down. The question is whether your threat model was built before they arrived.