IT security as a network: how do I read attack paths?

Why is an IT system a network of entities and relations?

Security is hard to think about as long as you see your system as a list of devices — a server here, a laptop there, a cloud service somewhere. A different view helps: every account, every machine, every service, every file and every permission is an entity, a node. And everything that connects them — „this account may log in to that server“, „this service trusts that certificate“ — is a relation, an edge.

The field's own vocabulary slots in cleanly. The protection goals of confidentiality, integrity and availability (the CIA triad) describe which relations are allowed and which are not: who may read, who may change, who must stay reachable. A vulnerability is nothing more than a relation that can become active even though it shouldn't — a door you never planned for.

With this lens you stop looking at single boxes and start looking at the web between them. And that is exactly where attacks happen — never at one isolated point, but along connections that together form a way through.

What is an attack path — and why is it a chain?

An attack path is the concrete sequence of relations along which someone moves from a first foothold to their actual target. A single step is rarely enough. Usually an attacker first lands on an unimportant machine, finds a password there that also works elsewhere, logs in to the next node, picks up higher rights — and works onward like that. The field calls this sideways movement through the network „lateral movement“.

What matters: each of these steps is a relation that becomes active in that moment. Before, it was passive (learned but quiet) or empty (never used). The path arises not because one single wall falls, but because a series of relations becomes active one after another and closes into a chain. An attack tree is precisely the tool for drawing such chains as a diagram: the target on top, the ways to it below.

That is why the most important shift in perspective is this: don't ask „Is this machine secure?“ but „Which chain of active relations leads from somewhere out there all the way to my crown jewel?“ Security is a property of the path, not of any single node.

Entry nodes and choke points: where does a chain break?

Not all nodes are equally important. An entry node is the point where a path can begin at all — the externally reachable web form, the VPN access, the inbox a phishing mail drops into. That is the outer edge of your network, your attack surface. Here a first „empty“ turns „active“.

Far more interesting, though, are the nodes in the middle. Some entities sit on very many paths at once: an admin account, a central directory service, a server that all the others trust. Such a node is a choke point in the literal sense — a disproportionate number of chains run through it. That is exactly what makes it valuable to the attacker and exactly what makes it a lever for you.

Because when many paths run through the same node or the same relation, you don't have to close each path one by one. You cut the single load-bearing relation — and all the chains that ran through it break at once. Finding such bottlenecks is the real craft of reading attack paths.

Cut a relation instead of building „more walls“

The usual reflex with a security problem is to pile on more: another firewall, another scanner, another rule. That is more force on the same spot — and often it only ties up effort without closing the path. You are stuck not on too few walls but on an active relation that shouldn't exist at all.

The more effective move is to redirect the same energy: don't wall higher on the outside, sever a connection on the inside. Does this account really need access to that server? Must this service trust that certificate? May the same password be valid in ten places? Each of these questions aims at a relation you can reset from active to empty — and with it a piece of the path disappears.

In practice these are sober measures: limit permissions to the minimum (least privilege), segment networks, separate accounts, dismantle trust relationships. Each one deliberately cuts an edge. That often does more than an extra tool on the outer wall, because it doesn't raise the wall — it breaks the way behind it.

Provenance: how did this relation become active?

When something goes wrong, it isn't enough to know that an attacker was inside — you want to know which way they took. For exactly this, the field has the concept of provenance: the traceable chain of how a piece of data, an access or a state came to be. Which entity triggered which action that led to the next?

In the model's terms this is nothing other than reading the path backwards. A relation has become active — but why? Which prior relation activated it? Stepping back one link at a time, you walk the chain in reverse all the way to the entry node. A relation that was once active stays visible — it doesn't turn empty again, at most passive. That is why the path can be reconstructed after the fact.

In practice this is logs, data lineage and audit trails: the record of who did what, when, with which right. They turn a plain list of events into a readable graph of cause and effect — and turn „we were attacked“ into „this is how the path ran, and here is where we cut it earlier next time.“

Where does the model stop — and where do you need real tools?

Be honest with yourself: this view is a thinking aid, not proof of security. It orders what you look at and makes clear why a single patch sometimes breaks a whole chain while another does nothing. But it won't tell you on its own which vulnerability sits in your software or whether your configuration really holds.

Actually uncovering paths is craft with tools: a penetration test that plays through real attacks; an audit that checks configuration and processes; vulnerability scanners, attack-graph software and monitoring that continuously map relations. The model replaces none of these — it helps you read their results and set priorities.

And security is never finished. Every new service, every new account, every new integration pulls in new relations and can open new paths. So the most honest stance isn't „we are secure“ but „we know our most important paths, check them regularly with real tools — and cut the load-bearing relations before someone else tries.“

Seen through the model

Picture a small company. An employee opens a phishing mail and enters her password on a fake page. It looks like a one-off — one account lost. But see it as a network: the mail was the entry node, and with the password the first relation becomes active — „attacker can log in as this employee“.

Now the chain begins. The same password also works on the internal file server — a second relation becomes active. On the file server lies a list of admin credentials — a third. With the admin account the attacker reaches the central directory service that all machines trust — and thereby practically every node in the building. No single wall has fallen; a series of relations became active one after another and closed into a path.

The reflex would be to harden the entrance: better spam filter, more training. Sensible, but it doesn't close the path. The lever is the choke point in the middle: had the password not worked everywhere (cuts relation two), had the admin list not lain exposed (cuts relation three), had the directory service been segmented — each single cut edge would have broken the chain long before it reached the target. That is the sketch; whether it holds in reality only a real test will tell.

Step by step

Sketch the network roughly: what are your crown jewels (target entities) and which accounts, services and machines stand in relation to them? You don't need completeness, only the most important nodes and edges.
Mark the entry nodes: where can a path begin from outside at all — web access, VPN, inbox, exposed service? That is your attack surface.
Trace a chain: from one entry node, step forward in your mind link by link. Which relation would become active next — a reused password, a trust relationship, a too-broad permission?
Find the choke points: which entity or relation sits on conspicuously many chains at once? That is your lever — cut once there and break many paths.
Cut instead of walling: sever the load-bearing relation rather than raising a wall outside. Least privilege, segmentation, separate accounts — each measure resets an edge from active to empty.
Secure provenance and verify with real tools: keep logs and audit trails so you can read paths backwards — and have your assumptions confirmed by pentest, scanner or audit. The sketch does not replace that.

Frequently asked

What is an attack path in IT security?

An attack path is the concrete sequence of steps by which someone moves from an initial foothold to their actual target inside a system. In the model this is a chain of relations that become active one after another: gain entry, collect privileges, jump to the next node (lateral movement), and so on all the way to the crown jewel. The key insight is that security is a property of the entire path, not of any single device — an attack unfolds along connections, never at one isolated point.

How does an attack path differ from an attack tree?

An attack path is a single chain: one concrete route from an entry node to the target. An attack tree is the higher-level representation that shows many such routes at once — the target at the top, the various chains that lead there below it. In the model's terms: a path is a sequence of active relations, a tree bundles all possible sequences into one diagram. Both tools answer the same underlying question — which relations do I need to cut so that as many routes as possible break at once?

Why does „more firewalls“ often not help against attack paths?

Because a firewall sits at the perimeter, but a path typically continues on the inside. Once an attacker has cleared the entry node, they move further through internal relations — reused passwords, trust relationships, overly broad permissions. More walls on the outside is more force applied to the same spot. What works better is cutting a load-bearing relation on the inside: revoking a central privilege, segmenting networks, separating accounts. A single severed edge can break an entire chain, while one more outer wall leaves the path behind it untouched.

What does provenance mean in IT security?

Provenance is the traceable chain of how a state, a piece of data, or an access event came to be — which entity triggered which action that led to the next. In practice this means logs, data lineage, and audit trails. In the model, provenance is reading a path backwards: you step from a relation that became active back through each prior link all the way to the entry node. This helps you understand an incident and cut the chain earlier next time — provided you recorded the traces in the first place.

Does this model replace a penetration test or an audit?

No, and that matters. The network view is a thinking aid: it organizes what you look at and explains why some measures close many paths at once. But it won't surface a concrete vulnerability in your software or verify that your configuration actually holds. For that you need real tools: a penetration test that plays through actual attacks, an audit, vulnerability scanners, and monitoring. The model helps you read their results and set priorities — it is the lens, not the proof.

What is lateral movement and where does it fit the model?

Lateral movement is an attacker's sideways progression through a network: instead of staying on the first machine, they hop from node to node using stolen credentials, picking up higher privileges along the way and closing in on the target. In the model each of these hops is a relation becoming active — exactly the steps that make up an attack path. Making lateral movement harder therefore means thinning out the internal relations: fewer trust relationships, no passwords that work everywhere, segmented networks.

Keep thinking

Last updated: 2026-07-01