From Products to Systems: The Future of Integrated Security

Security is bought as products and fails as a system. That sentence is the whole argument, and the rest of this piece is an attempt to say why it happens so consistently and what changes when integration is treated as a discipline rather than an outcome.

Procurement shapes the program

The reason security is bought as products is that procurement is organized around products. A budget line exists for access control. A different line exists for network security. A third exists for monitoring. Each line has an owner, a cycle, and a set of vendors who compete within it.

This structure has real advantages. It makes cost comparable, it makes accountability legible, and it lets specialists evaluate specialists. It is not a stupid way to organize.

What it cannot do is produce coherence, because nothing in it is responsible for coherence. Each purchase is evaluated against alternatives within its category. No purchase is evaluated against the question of whether the categories together describe the environment being protected.

The result is familiar to anyone who has inherited a mature program: individually defensible components, collectively incoherent. Every element can be justified. The whole cannot be described.

The seam is the system

In a program assembled from products, the interesting failures occur at the seams — the places where one system's assumptions meet another's.

An identity system deprovisions an account. Does the physical access control system learn about it, and how quickly? A monitoring provider receives an alarm. Do they know whether the property is occupied, and who to call if it is? A vendor is granted access for a project. What ends that access when the project ends — a date, an event, or an assumption?

Each of these is a question about a boundary rather than about a system. Systems have owners. Boundaries usually do not, and a boundary without an owner is a place where two competent parties each reasonably believe the other is handling it.

The failure mode is not that a component was weak. It is that two adequate components were connected by an assumption, and the assumption was never written down or tested.

Integration is designed before it is built

The common approach to integration is to attempt it after procurement: buy the components, then connect them. This is backwards, and the reason is not technical.

Connecting systems after the fact means accepting the interfaces each vendor chose to expose, which were designed for their convenience rather than for the program's model. It means discovering incompatibilities at the point where the budget is spent and the alternatives are gone. And it means the shared model — what exists, what it is called, who owns it — gets reverse-engineered from whatever the systems happen to record, rather than being decided deliberately.

Designing integration first inverts each of those. The shared model is decided before anything is bought. Interfaces are specified rather than discovered. Vendors are selected on their ability to meet the specification rather than on their feature list. And the boundaries are named and assigned while there is still room to insist on it.

This is a sequencing argument, and its cost is that it produces a document before it produces an installation. Documents are politically weaker than installations. That is the honest reason this stage is usually skipped.

What a shared model contains

A shared model is less exotic than it sounds. It answers four questions consistently across every system in the program.

What exists. One list of the people, properties, entities, devices, and systems in scope, with one name for each. Two systems calling the same property by two different names is a small problem that becomes a large one at the moment someone is trying to reconcile them under pressure.

What is protected, and why. Not everything in the inventory carries the same weight, and a program that treats it as though it does will spread effort evenly across items of wildly different consequence.

Which systems touch what. For each item, the set of systems that hold, monitor, or control it. This is where the seams become visible, because an item touched by three systems has at least three boundaries.

Who is accountable. For every item and every boundary, a named party. "The vendor" is not a named party. Neither is "IT."

That is the model. It is maintained rather than produced once, and its value is almost entirely in being current.

Testing the failure path

The other discipline that separates a system from a collection is testing the wrong outcome rather than the right one.

Most acceptance testing confirms that a system does what it is supposed to do when everything is working. That is necessary and insufficient. The questions that matter in an integrated program are about degradation: what happens when the network link between two systems drops, when a monitoring provider does not answer, when an integration silently stops passing events, when a credential is revoked in one place and not another.

Systems rarely announce these conditions. An integration that has stopped working usually looks identical to an integration with nothing to report. The difference is only discoverable by deliberately checking, which means someone has to have decided in advance what to check and how often.

This is unglamorous work and it is the difference between a program that is believed to be working and one that is known to be.

What changes when integration is treated as the discipline

A program designed as a system rather than assembled as a collection differs in three observable ways.

Its current state can be described. Somebody can say what exists, what protects it, and who is responsible, without assembling that from several people's memories.

Its boundaries have owners. When something falls between two systems, there is a prior answer about whose problem it is, decided when nobody was under pressure.

Its failures are visible before they matter. Not all of them — but the class of failure where an integration quietly stopped working, which is the most common and the most expensive to discover late.

None of this requires better components. Most programs already have adequate components. What they lack is a layer above the components that holds the model and owns the seams, and that layer is not a product anyone sells. It is a decision about how the work is organized.