Security debt often begins when a local solution ignores the shape of the larger system.
I spent part of this weekend removing a driveway. Not all of a driveway. Just the part that should never have been there.
Our house sits back from a rural road outside Hamilton. There is a concrete pad in front of the garage, a trailer nearby, a grove along one side, and enough trees, grass, gravel, and accumulated decisions to keep a person occupied indefinitely.
At some point in the property's history, somebody needed another way to get from the private road on the property to the house.They did the obvious thing.
They took the shortest path.
They spread gravel from the road toward the concrete pad and called it a driveway. There was only one problem.
The driveway approached the pad from the wrong direction.
The garage, pad and natural vehicle flow are aligned one way. The added driveway comes into them at exactly ninety degrees.
It worked.
That is important. Cars could drive across it. Gravel supported tires. Nobody needed to file an architectural exception with the driveway governance board. For years, apparently, this was good enough.
But the entire system had to adapt around the mistake.
A driver coming in that way had to turn awkwardly to orient toward the garage. The gravel occupied space that would otherwise be useful landscape. Another route was still required to make the property work properly. And, as I discovered while rearranging all of this, rain and snowmelt already had their own ideas about how they wanted to cross the same piece of ground.
The driveway was not merely inefficient.
It was diametrically opposed to the actual relationship between the structures it was supposed to connect.
Cybersecurity contains a great deal of this.
Working is not the same as aligned
One of the dangerous things about infrastructure is that a poor architecture can function for a very long time.
- The system boots.
- Packets travel.
- Employees log in.
- Transactions complete.
- Audits pass.
Therefore we conclude that the architecture works.
Often what is really happening is that humans and machines have accumulated adaptations around an arrangement that does not correspond to the underlying relationships.
- A user needs access, so somebody adds a firewall rule.
- An application needs another application, so somebody creates a service account.
- A contractor cannot reach a system, so somebody adds a VPN path.
- An acquisition brings another identity system, so somebody builds synchronization between them.
- A legacy application cannot support modern authentication, so another appliance is placed in front of it.
- A security control breaks a business process, so somebody creates an exception.
- Then an exception is created for the exception.
Eventually no individual decision looks unreasonable. Taken together, however, they form the technological equivalent of a driveway meeting the garage sideways.
The organization is moving.
It simply requires enormous amounts of steering.
Compensating controls become compensating architecture
Security people are comfortable with the idea of compensating controls. Sometimes the ideal control cannot be deployed, so another mechanism reduces the risk.
That is entirely legitimate.
The problem begins when compensation becomes permanent architecture. A system designed around network location rather than identity accumulates increasingly sophisticated perimeter controls. A system designed around standing privilege accumulates monitoring to watch the privilege. A system without useful provenance accumulates forensic tools to reconstruct what happened afterward. A system whose applications possess enormous credentials accumulates approval processes intended to compensate for what those credentials could do.
A system that cannot express authority cleanly eventually depends on institutional folklore:
- “Don't touch that account.”
- “This service needs domain admin for some reason.”
- “That firewall rule predates me.”
- “If you remove that route, accounting stops working.”
- “We tried changing it once.”
Every one of those sentences may describe a perfectly rational adaptation. But adaptations have a cost. Humans must remember them. Systems must preserve them. New engineers must learn them. Auditors must document them. Attackers get to discover them.
And every future change must negotiate with them. We usually call some of this technical debt. In security architecture, I think there is a more specific form:
adaptation debt.
It is the accumulated cost of making real flows conform to an architecture that does not match them.
Follow the flows
The driveway problem became easier once I stopped thinking about driveways. There were really three flows intersecting in one patch of land.
- Vehicles needed to move between the road and the garage.
- People needed usable and visually understandable space.
- Water needed to move downhill.
Water is particularly unsympathetic to architectural diagrams.
Rain and snowmelt cross the property according to gravity, not according to where somebody once spread gravel. The correct solution therefore was not simply to move the driveway.
It was to understand the flows together.
The trunk sections from a large dead tree we had cut down a few weeks earlier could define the new vehicle boundary. Flower pots on some of those sections could make the boundary visually obvious to drivers while turning it into landscape rather than barricade. The old gravel could be loosened with a wrecking bar, shoveled into a bucket, and moved to the route where vehicles actually need it. And the lowest point could be excavated first so a French drain could carry water beneath the vehicle path rather than leaving a permanent soggy intersection.
Nothing particularly sophisticated is involved.
- Steel.
- Stone.
- Wood.
- Gravity.
- Attention.
But once the relationships are understood, the materials begin doing several jobs at once.
That is architecture.
Cybersecurity should model relationships before controls
We often begin security design by asking which controls a system needs.
That may already be one question too late.
First ask: What is actually flowing here?
- Data?
- Authority?
- Identity?
- Money?
- Software?
- Human attention?
- Commands?
- Evidence?
What dictates these flows?
- Who originates the flow?
- Who is supposed to receive it?
- Who is allowed to alter it?
- Where should it cross trust boundaries?
- Where should it never cross?
- What happens when two flows intersect?
Only then does it make sense to decide where the gates go.
This becomes increasingly important as we add AI and autonomous software to existing systems. An AI agent connected to a poorly aligned architecture does not repair the architecture.
It moves through it faster.
Give an agent a broad service credential because the existing application architecture cannot express narrower authority, and we have automated the adaptation. Give it access to six repositories because nobody knows which contains the authoritative state, and we have automated the ambiguity. Give it permission to act because the system cannot distinguish recommendation from approval, and we have automated the missing governance boundary.
The answer is not merely a better model.
Sometimes the gravel is simply in the wrong place.
Security architecture is the shaping of flows
There is an instinct in cybersecurity to think of architecture as boxes.
- Applications.
- Networks.
- Clouds.
- Firewalls.
- Endpoints.
- Identity providers.
- Databases.
Those matter.
But the useful architecture is often in the relationships between the boxes.
- Who trusts whom?
- What flows where?
- Under whose authority?
- With what evidence?
- Which relationship is primary, and which exists only because something else was poorly aligned twenty years ago?
That last question can be surprisingly productive.
Some of the strangest structures inside mature enterprises are not requirements at all. They are fossils. They record an old constraint, an acquisition, a hurried migration, a vendor limitation, an emergency fix, or somebody's perfectly reasonable effort to take the shortest path available at the time.
The person who laid my sideways driveway was probably not an idiot.
It was shorter. It was cheaper. It solved the immediate problem.
The mistake would be assuming that because the gravel is there, the gravel defines the future.
Remove adaptations when you can remove their cause
The satisfying thing about moving the driveway gravel is that each bucket accomplishes several things. Material disappears from a place where it creates a bad flow. The same material appears where it supports the correct flow.
- Landscape becomes available.
- The drainage problem becomes visible.
- The eventual geometry becomes easier to understand.
The system becomes simpler by subtraction.
Cybersecurity architecture rarely gets enough opportunities like that. We add controls much more easily than we remove them. But when we can eliminate the structural condition that required a compensating control, we should.
Replace broad standing authority with task-scoped credentials and some monitoring may become unnecessary. Make provenance native and some forensic reconstruction becomes easier. Align identity with actual human and service relationships and layers of network-based assumptions can disappear. Separate machine recommendation from human authorization and elaborate procedural workarounds become simpler.
The objective is not fewer controls for its own sake.
It is fewer unnecessary adaptations.
A resilient system can still be complex. But its complexity should arise from the complexity of the world it serves, not from generations of compensating for a gate that faces the wrong direction.
This morning, there is still plenty of gravel left to move. There is a wrecking bar lying beside the hole, a small yellow bucket, several large pieces of a dead tree marking where vehicles should go, and a trench beginning to reveal where the water wants to go. Eventually it will simply look like a driveway. Nobody driving on it will need to know why the old one was wrong.
That may be one of the best measures of good architecture.
The people and systems using it no longer have to compensate for the design.
