¶ SAP Threat Modelling and Attack Paths
SAP threat modelling in the RedRays Security Platform draws a landscape as one picture: the SAP systems a scan has found, and the Remote Function Call (RFC) connections between them that would let somebody already inside one system reach another without presenting a second credential.
- Reads only, never writes
- No logon is ever attempted
- Every path points one way
Every other check in the platform asks a question about a machine. This one asks the only question in the set that is about the landscape: an attacker already has one SAP system, so what does that system reach? The answer is not on the network and it is not in a patch list. It is in the outbound connection configuration each SAP system keeps about itself, and only the union of every system's configuration is an answer.
¶ What question does an SAP threat model answer?
It answers what an attacker reaches from a system they have already taken, rather than what is wrong with that system. Two phrases carry the weight. Reaches means a logon that succeeds, not a route a packet could take: two systems on the same network segment are not connected in this sense, and two systems in different data centres are connected if one of them holds the other's credential. Already inside means the first system is lost and the question starts after that. Nothing here is about how the first system fell.
¶ What is the unit on the map?
One RFC destination that would let a person on the source system reach the target system without being asked for another password. That is a narrower claim than "a connection exists". Two SAP systems that talk constantly over a destination demanding an interactive logon each time produce no line on the map, and are right to produce none. The map is a shortlist of exploitable hops, not an interface inventory.
One picture of a landscape in which every arrow is a destination that would carry somebody from the system at its tail to the system at its head without a second password.
The read is performed by the platform installed on your own infrastructure, so nothing is installed on the SAP systems themselves.
¶ Where to start
¶ How is a path different from a finding?
A finding is a property of one host and a path is a property of a pair, so no quantity of findings adds up to a map. "This host is missing a patch" reads the same from either end. "This host holds a saved logon into production" does not: reverse it and it is a different fact about a different machine, with a different owner and a different fix. Nothing in a vulnerability report carries that arrow.
The two compose rather than compete. A path into production is worth exactly what the account at the far end of it can do, which is the question SAP segregation of duties analysis answers, and the source system's own exposure is what vulnerability assessment and SAP profile parameters answer.
¶ What it does not cover
- Paths that are not RFC destinations. Database accounts, operating system trust, shared file systems, jump hosts, the transport directory and an administrator who uses one password twice are all outside the model, because the only evidence read is each system's own RFC destination configuration.
- Whether the path is used. The configuration records intent, not traffic. A destination created for a migration years ago and never deleted looks exactly like the one last night's interface ran over.
- Whether the stored credential still works. The analysis sees that a credential is configured, not that the account is unlocked and still authorised.
- What the far-end account can do. No user, role or authorisation object is read here. The user named in a destination is a string in a configuration field.
- Systems nobody read. A landscape drawn from three of five systems is not a smaller map, it is a map with silent holes in it, drawn at the same confidence as a complete one. This is the limit worth reading twice, and what the map does not claim is where it is set out.
A system that could not be read and a system with nothing to report are drawn identically, so check which systems were successfully read before treating an empty map as a clean landscape.
¶ Frequently asked questions
¶ Is this the same as network segmentation review?
No. Segmentation asks which packets can travel. Threat modelling here asks which logons already succeed. A destination with a saved password crosses a firewall that permits the traffic, and no firewall rule review will surface it, because the evidence is a configuration row inside SAP rather than anything on the wire.
¶ Do we need to install an agent on each SAP system?
No. The analysis is an authenticated read of RFC destination configuration from each system, performed by the platform installed on your own infrastructure. See what threat modelling reads from SAP and deployment and where data goes.
¶ Is it spelled threat modelling or threat modeling?
Both spellings refer to the same capability. The product interface and this documentation use both forms in places, which is a spelling difference and not two features.
¶ Can it show a path out of SAP into a cloud tenant?
Yes, where the path is an RFC or HTTP destination carrying a stored credential to an external host, including an SAP Business Technology Platform tenant. What is behind that host is a separate question and is the subject of SAP BTP security assessment.
¶ Does an empty map mean the landscape is clean?
Only if you also know which systems were successfully read. An empty map with a complete read is the result you are paying to be able to demonstrate. An empty map because no system could be read is not a result at all, and the two look alike unless you check. That distinction is the platform's founding rule, described in what a finding does and does not claim.