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.