Concept card

Threat-First SAP Analytics Architecture (the T in GSTACK)

As of 2026-07-23

Edited by Cédric-Olivier Mâry, sole editor and publication director — 27 years in the SAP ecosystem. How these pages are produced, and where automation is used.

What is Threat-First SAP Analytics Architecture (the T in GSTACK)?

The threat tree walks every SAP analytics flow through four steps — asset classification, trust boundaries from ECC to external share, STRIDE-light per boundary, and blast-radius scoring — producing a one-page document per flow.

The 4-step threat tree on SAP analytics flows

Apply to every critical data flow on the engagement. Output is a 1-page-per-flow document.

Step 1 — Asset inventory

What data does this flow carry? Classification levels:

Public — counts, KPIs at country level, anonymized buyer-persona
Internal — country-grouped revenue, partner relationships, named-customer logos
Confidential — per-customer transactional, individual employee, payroll, MNPI
Restricted — PII identifying natural persons, health data, payment card data

The higher the classification, the smaller the acceptable blast radius.

Step 2 — Trust boundaries

Walk the flow from origin to consumption. At each transition, draw a boundary:

ECC source → Datasphere replication (boundary: SAP RFC trust)
Datasphere → BDC Iceberg lakehouse (boundary: lakehouse object-store ACLs)
BDC → SAC live model (boundary: SAC role + space)
SAC story → embedded export to Office (boundary: SAC export policy)
SAC story → shared to external auditor (boundary: SAC public link)

At each boundary, name what the attacker would have to compromise to cross it.

Step 3 — Attack tree (STRIDE-light per boundary)

Why it matters

Data classification (public, internal, confidential, restricted) sets the acceptable blast radius before any control is designed — the higher the classification, the smaller that radius must be.
Each trust-boundary transition (ECC to Datasphere, Datasphere to BDC Iceberg, BDC to SAC live model, SAC to external auditor) names exactly what an attacker would need to compromise to cross it.
STRIDE-light applied per boundary surfaces SAP-specific attack vectors — S-User reuse, RLS bypass via SAC drill-through, a Joule agent inheriting service-account scope.

Key points

Apply per data flow, not per project — each flow gets a 1-page threat tree.
4 steps: asset inventory · trust boundaries · STRIDE-light per boundary · blast-radius scoring.
SAP analytics-specific boundary list: ECC→Datasphere, Datasphere→BDC, BDC→SAC, SAC→export, SAC→public link.
Output: a [GSTACK · threat-model · Pn] line per finding, fed into engagement risk register.
Pairs with ownership-map (C306) — every finding gets a named owner.
Threat-First SAP Analytics Architecture (the T in GSTACK) is mastered only when it changes a named buyer decision.
Start with the semantic contract and control model before demonstrating the tool.
Use current SAP, analyst, study, KG, and news signals as evidence, not decoration.
Separate verified facts from directional trends and modeled assumptions.
Define owner, metric, threshold, support path, and rollback before scaling.

Terms used on this page

Trust boundary: A point in the architecture where attacker-controlled input meets privileged code or data.
STRIDE: Microsoft threat-classification framework: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege.
Data classification: Tagging of data with a sensitivity level (public/internal/confidential/restricted) used to scope acceptable blast radius.
Asset inventory: The first step of any threat model — what are we protecting? Skip this and the rest is theatre.
Decision owner: The accountable person who accepts the trade-off and funds the next action.
Semantic contract: The shared definition of business terms, metrics, entities, and access rules used by tools and teams.
Control plane: The layer that applies policy, access, lineage, monitoring, and escalation across the operating model.
Evidence grade: A label that separates verified fact, directional signal, modeled assumption, and field observation.

Sources

Full card available to members. What the full card adds: the full decision framework · the SAP vs Snowflake / Databricks / Fabric comparison · the common pitfalls and their fix · the cheat sheet · the architecture schemas · the code blocks.

Open in the app →