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

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.

Most environments aren’t completely unsecured. Firewalls are enabled. Logging exists. Alerts are configured. From the outside it looks fine, maybe even responsible.

Controls aren’t usually missing. They’re inactive.

In recent work I’ve seen environments where security features were technically enabled but effectively useless. Logs existed but nobody read them. Alerts fired and nobody came. Things broke and the outcome was the same either way.

An organisation’s security is only as strong as the people interacting with it. The tooling matters less than whether someone looks at it. The architecture diagram matters less than whether someone notices when something breaks.

Controls that exist, but don’t actually do anything.

What “On Paper” Actually Means

A control that exists on paper isn’t badly designed or poorly intentioned. It meets one or more of these conditions:

• Enabled, but not enforced
• Deployed, but not monitored
• Producing logs that nobody checks

Being enabled doesn’t make something active. Being deployed doesn’t mean anyone owns it.

This usually comes down to a preference for “set it and forget it” over “observe and react.” Once the checkbox is ticked, the control fades into the background, assumed to be working indefinitely. That assumption is where things go wrong.

Where Controls Drift

Detection Without Response

Detection systems promise visibility. Alerts come in, someone investigates, action is taken.

In practice it works for a while. Dashboards get checked. Alerts are acknowledged. Then the noise builds. False positives pile up. A day goes by without anyone looking, then two. Eventually nobody is sure who owns the dashboard anymore.

Alerts become background noise. Data is still being generated, but nobody acts on it. An alert that nobody investigates isn’t protection, it’s a log entry.

Authentication With Escape Hatches

Strong authentication controls get undermined by exceptions. Legacy devices that “don’t support it.” Applications that need compatibility modes. Temporary workarounds that quietly become permanent.

Then there’s the choice problem. Multiple authentication options enabled for convenience, some far weaker than others. The intention is resilience but the effect is dilution.

Attackers don’t try to break the strongest path. They use the weakest one you left open “just in case.”

Segmentation Without Isolation

Segmentation looks good in diagrams. Separate zones, clean boundaries, tidy rulesets.

In practice those boundaries collapse at shared services. DNS, authentication, file shares, and management interfaces punch holes through supposedly isolated segments. Rules get added to “make things work” and the isolation erodes quietly.

The network looks compartmentalised. When it matters, it behaves like a flat one.

Why This Keeps Happening

Operational load is real. Security gets treated as a deployment task rather than a continuous process. Once a control is installed and doesn’t cause immediate issues, it slides down the priority list. There’s always something more urgent.

Environments accumulate controls without accumulating engagement.

The Cost of Paper Security

The biggest risk isn’t failure. It’s false confidence.

Teams believe they’re protected because the tooling is there. Incidents take longer to detect. Root cause analysis gets harder. Attackers exploit the gaps between controls, not by breaking defences, but by walking through the parts nobody is watching.

Security Is Behaviour

A control only exists if it changes outcomes.

If nothing reacts when it fails, nothing is protected. If no one owns it, it doesn’t exist. If no human ever sees its output, it’s noise.

Fewer controls that are actively observed beat a long list that only looks good in a report.