Disclaimer: The examples below are anonymised and aggregated across multiple engagements. The goal is to highlight recurring patterns, not embarrass any specific organisation.

Security Theatre: Field Notes from the Inside

The Scene

Most environments I assess are not wide open. They have firewalls, policies, and controls that look sensible on a slide deck.

The same weaknesses keep showing up anyway. Security gets implemented as a compliance checklist rather than an adversarial system.

That is security theatre: controls that exist, but fail under pressure.

It shows up in small things (a forgotten hyperlink), legacy things (Telnet still running), and complex things (multi-tenant routing edge cases that quietly break the idea of “internal”).

Most incidents do not start with a zero-day. They start with an assumption.

The Meaning

Security theatre is security that only works from one angle.

• It satisfies an audit requirement
• It meets a policy statement
• It was set up once and never re-validated
• It relies on “internal trust” as a boundary

It fails the moment an attacker does basic due diligence.

Real Security vs Theatre

A Simple Test

Rate each control against three questions:

1. Is it verified? Not configured, but tested.
2. Is it monitored? Will you know when it fails?
3. Is it owned? Is someone accountable for its health?

Two “no” answers means you do not have a control.

Field Notes

1. “Internal” RFC1918 Space Leaking Other People’s Infrastructure

On one client network, we found a large number of devices in the 172.30.x.x and 172.31.x.x ranges. Normal enough.

The exposed services were not normal:

• Cisco IOS devices presenting known vulnerabilities
• OpenSSH issues flagged, including severe exposure classes
• SNMP responding with default community strings (public)
• Telnet open in cleartext

When we pulled device information over SNMP, the fingerprints did not match the client’s environment. The devices looked like other organisations’ routers, visible from within this client’s own network.

Whether it was a provider-side forwarding mistake, a multi-tenant routing bleed, or a design choice nobody fully understood, the problem is the same:

“Internal” is a routing decision, not a security boundary.

A network can be “private” on paper while being multi-tenant in practice. Technically not the client’s fault. Still their problem.

The pessimistic outlook: unintended trust paths, lateral movement opportunities, messy incident response (“is that ours?” becomes a real question), and reputational fallout if the client network becomes a stepping stone into someone else’s infrastructure.

2. Monitoring Interfaces That Become Management Interfaces

SNMP is often justified as “monitoring only.”

In practice it provides device names, interfaces, routing hints, OS and platform fingerprinting, uptime, load, and depending on configuration, more. When SNMPv2c is exposed with default communities, “monitoring” becomes enumeration on demand.

The control exists (“we have monitoring”), but the threat model is absent (“monitoring endpoints are high-value targets”).

What to do instead:

• SNMPv3 with auth and privacy where possible
• Strict ACLs so only the monitoring system can reach SNMP
• Remove default communities, remove write communities unless there is a hard requirement
• Continuous checks for public/private drift

3. Telnet in 2026

Telnet still appears internally more often than people admit. Rarely a deliberate decision. More often a leftover: legacy device, a “temporary” troubleshooting session, vendor defaults, a project that ended but the port stayed open.

What to do:

• Disable Telnet everywhere, policy plus validation
• If legacy hardware makes that impossible, isolate it and treat it as hostile
• Enforce SSH and modern cipher suites for all management
• Log and alert on any Telnet session as a high-signal event

4. The Easiest Brand Hijack Is a Broken Hyperlink

One of the more sobering findings I have seen had no CVE attached.

A client website linked to their social media profiles. The X and Instagram links pointed to accounts that did not exist. We registered the usernames the website was implicitly endorsing.

Any visitor clicking those links landed on an attacker-controlled profile that looked official by association. I was, briefly, the client’s new social media manager.

The organisation likely had solid perimeter controls. Their public brand identity had an unguarded back door.

What to do:

• Treat web presence as an asset inventory: domains, handles, app store listings
• Reserve key usernames even on platforms you do not actively use
• Run a quarterly external exposure review with marketing and security together
• Add a brand protection checklist to release processes

5. Hidden SSIDs and Other Comforting Myths

I have assessed environments where the guest Wi-Fi was modern and well-configured (WPA3), additional SSIDs existed as “hidden,” and those SSIDs still covered public areas: roads, car parks, the perimeter.

Hidden SSIDs do not stop discovery. The tooling is trivial and takes minutes. They stop casual users from seeing the network in a dropdown list.

What to do:

• Remove unused SSIDs entirely
• Prefer WPA3-Enterprise (EAP) where feasible
• Segment wireless properly: guest is not corporate, corporate is not infrastructure
• Validate coverage from outside the perimeter

6. “Medium” Findings That Do Not Feel Medium

Scanner outputs create a predictable behaviour pattern. Critical gets attention, high gets scheduled, medium gets ignored, info gets laughed off.

Some medium findings describe classes of weakness that become severe with real-world conditions: SSH weaknesses that matter under MITM conditions, management interfaces with brute-force exposure, patch states that are “mostly fine” but leave a few critical paths open.

Severity is a starting hypothesis, not a verdict. Two mediums can combine into a critical.

Prioritise weaknesses that enable credential capture, management access, or trust boundary crossing regardless of how the scanner scored them.

7. Logs Exist, but Meaning Does Not

On the blue side, I often see logging enabled but not operationally useful.

Suricata is a good example. It can generate excellent visibility, but without a workflow it becomes noise. The questions that matter are: what are our top external destinations, which internal hosts talk to unusual places, and what changed since last week.

“We have monitoring” becomes a checkbox, and the logs do not get reviewed.

What to do:

• Build simple, repeatable queries that surface top talkers, new domains, and rare destinations
• Baseline normal behaviour and alert on deviations
• Assign ownership: someone reviews signals and acts on them

The Patterns Underneath

The field notes above are specific. Step back and the same three shapes keep appearing across otherwise unrelated environments. A control is present, it satisfies a diagram or an audit line, and it quietly does nothing under pressure. These are the patterns worth recognising before you find them.

Detection without response

Detection promises visibility. Alerts come in, someone investigates, action is taken. It works for a while. Dashboards get checked, alerts get acknowledged, then the noise builds. False positives pile up. A day goes by without anyone looking, then two, and eventually nobody is sure who owns the dashboard.

At that point the alert that fires and the alert that does not fire produce the same outcome: nothing. An alert nobody investigates is a log entry, not a control. I have watched a Cowrie session persist for minutes on a box that was generating events the whole time, with the events landing in an index nobody queried. The data was perfect. The response was absent.

If you want to test this in your own environment, trigger something that should alert and time how long until a human acts. If the answer is “never,” the detection is theatre.

Authentication with escape hatches

Strong authentication gets undermined at the exceptions, not the front door. Legacy devices that “don’t support it.” Applications that need a compatibility mode. A temporary workaround that quietly becomes permanent. Then the choice problem: several authentication methods enabled at once for convenience, some far weaker than others, with the intention of resilience and the effect of dilution.

Attackers do not attack the strong path. They enumerate the methods on offer and use the weakest one you left enabled “just in case.” A tenant with phishing-resistant MFA on the primary flow and a legacy protocol still accepting a username and password is a tenant with no MFA, for anyone who bothers to ask the right endpoint which methods it supports.

The test: list every way to authenticate to a system, then rate the weakest one. That is your real authentication strength. The strongest path is irrelevant if a weaker one is still reachable.

Segmentation without isolation

Segmentation looks clean in a diagram. Separate zones, tidy rulesets, clear boundaries. In practice the boundaries collapse at shared services. DNS, authentication, file shares, jump hosts, and management interfaces punch holes through supposedly isolated segments because something on one side needs something on the other. Rules get added to make a thing work, the isolation erodes a rule at a time, and nobody re-tests the boundary as a whole.

The network looks compartmentalised. When it matters, it routes like a flat one. This is the same failure as the multi-tenant routing in field note one, seen from the inside: “internal” and “isolated” are both routing decisions wearing a security costume.

The test: from a low-trust segment, see what you can actually reach. Not what the diagram says you should reach. What answers.

Why This Happens

Most security theatre comes from normal organisational pressure:

• Compliance is measurable; security is contextual
• Change control is painful, so legacy stays
• Ownership is fragmented, so controls drift
• Teams are stretched, so verification falls away
• Perimeters look strong, so internal trust grows by default

More tools will not fix this. Verification, ownership, and feedback loops will.

Breaking the Cycle

This week:

• Kill Telnet wherever it exists
• Remove default SNMP communities, lock SNMP behind ACLs
• Inventory and reserve public brand assets
• Delete unused SSIDs, validate coverage beyond the perimeter
• Review private ranges for routing weirdness and unintended reachability

The structural fix: a control is not done when it is configured. It is done when it is verified with adversarial thinking, monitored for failure, and owned with accountability.

If you cannot answer “who owns this control,” it is theatre waiting to fail.

The End

Security is not the number of controls you can list. It is the number that survive contact with an adversary.

If your “internal” network is only secure because everyone agrees to behave, that is not a network. It is a trust exercise.

Appendix: How Screwed Am I?

If any of these are true, you are looking at theatre:

• “It’s fine because it’s internal”
• “We enabled logging” (but nobody reviews it)
• “We use SNMP for monitoring” (but it’s v2c and broadly reachable)
• “It’s hidden” (SSIDs, panels, directories)
• “We patched most of it”
• “That’s only a medium”
• “We don’t know who owns it”

Hunt the assumptions, not just the CVEs.