Security runs on pub-sub: the mesh, the logs and the monitoring
In plain words: Lots of security works like a noticeboard: some things pin up what they saw, others read the board and act, and neither has to know the other. Architecture and strategy, explained simply
In short
- Publish and subscribe, pub-sub for short, means that things which know something announce it to a shared channel, and things which care about it listen. Neither side needs to know the other exists.
- Logging, monitoring, detection, the security mesh and even zero trust decisions are all this pattern wearing different names.
- Once you see it, the questions get sharper: who publishes, who subscribes, what is the channel, and who is allowed to listen?
The pattern in one paragraph
A publisher sends a message about a topic: a login failed, a file was shared, a workload started. It does not say who should receive it. A subscriber says which topics it wants, and the channel in the middle delivers. Because the two sides never talk directly, you can add a new subscriber without touching the publisher, and a slow subscriber does not slow the source down. Services such as Ably describe the pattern in these terms, and it is a long-standing idea in distributed systems.
Where it hides in security
- Logging. Every system publishes events. The log platform is the channel. The detection rules, the audit team and the compliance report are subscribers, each with a different interest in the same stream.
- Monitoring and detection. A rule is a subscription with a condition: tell me when this topic shows this pattern. Alerts are new messages published to a second channel for people and playbooks to subscribe to.
- The security mesh. The idea behind cybersecurity mesh architecture is that identity, analytics and policy are shared across tools. In pub-sub terms, tools publish what they see and subscribe to what others decide, instead of each keeping a private view.
- Zero trust. A policy decision is a message too. When a risk signal changes, anything enforcing access should hear about it quickly, not at the next nightly sync.
Why it matters
The pattern explains the usual failures. If a system does not publish, you are blind to it, however good the rules. If the channel drops or delays messages, detection is quietly late. If every tool publishes in its own format, subscribers spend their time translating. And if anyone can subscribe, the channel itself becomes a way to learn a great deal about your estate, so access to the stream needs the same care as access to the data.
It also explains the cost story. Publishing everything is cheap to say and expensive to store, which is why teams end up choosing topics and retention deliberately, rather than keeping every message for ever.
What to do on Monday
- List your main publishers and tick the ones you cannot see at all. Those are your blind spots.
- Name the channel for each kind of event, and who owns it. A stream without an owner is a stream nobody notices breaking.
- Measure delay, from event to alert, not only volume. A late signal is a missed one.
- Agree one common event format where you can, and a mapping where you cannot.
- Restrict who can subscribe to sensitive streams, and log the subscriptions.
Sources
- Eugster, Felber, Guerraoui and Kermarrec, The many faces of publish/subscribe, ACM Computing Surveys, 2003.
- Ably, What is pub/sub?, an introduction to the pattern.
- NIST, SP 800-92: Guide to Computer Security Log Management (2006).
- The Ascent of Security Architecture on the lgkm.org home page, for the mesh stage.
- Earlier on this topic: Where security architecture stands, and why most organisations run several at once
- Later on this topic: Post-quantum migration starts with a cryptography inventory
Personal work and my own view, not my employer's. Sources are public.