The pattern nobody wants to talk about
Locked Shields 2026 concluded in Tallinn on April 24, with over 4,000 participants from 41 nations forming 16 multinational teams against roughly 8,000 real-time cyberattacks across critical infrastructure: air defense, e-voting, 5G, satellite management, and a fully built power generation system. The official communiqués, as always, praised the participants' ability to "detect and respond to malicious cyber activities."
That framing is true. It is also, year after year, the part everyone wants to talk about, and it quietly buries a less flattering pattern: the blue teams that struggle don't struggle because their SOC playbooks were weak. They struggle because something broke beneath them and they never saw it coming. They were looking up at Layer 7 while the red team was already at Layer 2.
If you've sat on a blue team, you know the conversation. A service goes dark. The first ten minutes are spent shouting at the firewall. The next ten are spent on the EDR console. By the time someone runs arp -a or looks at a BGP table, the round is half over.
This post is a walk through the OSI model, not because the seven-layer model is sacred, but because it's the cleanest checklist for engineers who've drifted into reflexive IR thinking. If your gut response to "service is down" is "check the WAF," you are skipping five layers of attack surface the red team has already moved into.
Table of contents
Why the OSI model still earns its place
Every few years someone publishes a "the OSI model is dead, use TCP/IP" take. They're right that the model is an abstraction: Layers 5 and 6 in particular are mostly bookkeeping in modern stacks. They're wrong that this makes it useless. OSI is a triage frame. When something is broken or under attack, walking the layers bottom-up is the fastest way to find out where the failure lives, instead of where your tooling happens to have visibility.
Red teams know this. They pick the layer where your detection is thinnest. In a Locked Shields environment, that is almost never Layer 7.
Layer 1: Physical
In the exercise the physical layer is abstracted, but the lesson translates: out-of-band management, console servers, KVMs, lights-out management interfaces (iDRAC, iLO, IPMI). These are routinely left on default credentials or shared management VLANs, and they offer a path that bypasses every detection control above them.
The honest blue team failure: treating the OOB network as "infrastructure, not in scope." It's in scope. If red can reach your iDRAC, the firewall above it is decorative.
Layer 2: Data Link
This is where a disproportionate amount of damage happens, and it's the layer most senior defenders have stopped thinking about because "the switch handles it." The switch does not handle it. The switch enforces whatever you configured, which is often nothing.
The Layer 2 attack catalogue is not new. That's the point. None of this is novel research:
- ARP spoofing/cache poisoning still works on any segment without Dynamic ARP Inspection. Gives the attacker a man-in-the-middle position invisible to your L3+ tools
- CAM table flooding turns a switch into a hub, broadcasting frames the attacker can sniff
- VLAN hopping via double-tagging or DTP abuse: your "segmented" network is one misconfigured trunk port away from flat
- DHCP starvation and rogue DHCP hand out your own gateway, route everyone through it
- STP attacks claim to be the root bridge, reshape the L2 topology, force traffic through your tap
- LLDP/CDP injection useful for reconnaissance and, on some platforms, for tricking neighboring devices
The defenses are old, well-documented, and chronically half-deployed: port security, DHCP snooping, Dynamic ARP Inspection, BPDU Guard, Root Guard, disabling DTP, separating management VLANs. None of them sit on the cover of a vendor whitepaper. All of them decide rounds.
The honest blue team failure: trusting that the network team did this in 2019 and never verifying it again. Run the checks. They take an hour.
Layer 3: Network (and yes, BGP)
The IP layer is where defenders feel comfortable, and that comfort is misplaced once you cross into routing protocols.
For internal routing (OSPF, EIGRP, IS-IS), the same pattern as L2 repeats. Authentication is optional in the protocol, mandatory in reality, and routinely disabled "for now" in lab and exercise environments that then end up in production muscle memory. An attacker on a peering segment without OSPF MD5/SHA authentication can inject routes, blackhole traffic, or quietly redirect it.
Then there is BGP. BGP runs the internet on a trust model whose roots go back to RFC 1105 in 1989, and Locked Shields scenarios increasingly include it because real-world adversaries do too. The relevant attack surface:
- Route hijacks: announcing a more specific prefix you don't own to pull traffic toward you
- Route leaks: announcing routes learned from one peer to another in violation of policy, often accidentally, with the same operational impact as a hijack
- Session resets: using crafted TCP traffic to tear down BGP sessions. This is why TCP-AO (RFC 5925), or historically TCP MD5, exists
- Path manipulation: AS-path prepending and community abuse to shift traffic in ways your monitoring doesn't catch, because the routes are still "valid"
The mitigations are operational, not product-shaped: RPKI origin validation, max-prefix limits, prefix filters on every eBGP session, peer authentication, BGPsec where you can get it. If your answer to "are we vulnerable to a route leak from our upstream" is "the firewall will catch it," it won't. The firewall sees the packets that arrive. It cannot see that they arrived via a path that shouldn't exist.
The honest blue team failure: treating routing as a "network team problem" siloed away from security. In an exercise, and in reality, routing is security.
Layer 4: Transport
Less drama here, but the basics still matter: SYN flood protection, sensible TCP timeouts, awareness that an idle TCP session can be hijacked if sequence numbers leak, UDP amplification vectors on any service you're exposing (DNS, NTP, memcached, CLDAP). Most defenders cover this competently. The mistake at L4 is usually not detection. It is exposure. Services reachable from segments they shouldn't be reachable from.
Layers 5 and 6: Session and presentation
In practice, this is "TLS and everything around it." Weak ciphers, expired or improperly validated certificates, session resumption misconfigurations, mutual TLS that isn't actually mutual because the server doesn't verify the client cert chain. Locked Shields scenarios routinely embed misconfigured TLS as a deliberate trap. Defenders who only check that "HTTPS is on" miss it.
The other underrated L5/6 issue is application session management: predictable session IDs, tokens that don't rotate, JWTs signed with none. These are L7 vulnerabilities in the OWASP sense, but they live at the session/presentation seam, and they are how an attacker with a foothold pivots into a long-lived identity.
Layer 7: Application
This is where most defensive tooling actually lives, which is why most defenders default to thinking here. Web vulnerabilities, malware behavior, authentication abuse, API logic flaws. None of it is unimportant, it's just well-trodden, and your stack already pays attention to it. The bias to correct is the reverse one: if you find yourself thirty minutes into an incident still chasing an L7 explanation when the symptoms don't fit, walk back down the stack.
The firewall is not the story
A working hypothesis from years of Locked Shields after-action reports, and from the day jobs that feed them: the median experienced blue team engineer overweighs detection and underweighs configuration. Detection is what their tools sell. Configuration is what actually loses or wins the round.
A useful pre-engagement 5 step checklist for an experienced defender, in the order an attacker thinks about them:
- Is Layer 2 hardened on every access switch: port security, DHCP snooping, DAI, BPDU Guard, no DTP, management VLAN separated?
- Are routing protocol sessions authenticated, with max-prefix and prefix filters on every eBGP peer? Is RPKI validation actually enforced, not just enabled?
- Are management planes (OOB, iDRAC/iLO/IPMI, switch management, hypervisor consoles) on a segment your attacker cannot reach from a compromised user endpoint?
- Is TLS configuration verified, not assumed: including client cert validation where mTLS is claimed?
- Then the L7 stack: WAF rules, EDR coverage, SIEM detections, IR playbooks.
The order matters. The first four items are where rounds are quietly lost before the IR phase even begins. They are also the items least likely to be on a quarterly review slide, because they don't generate alerts when they're working.
Where Tanium fits (once the basics are right)
I want to be honest about scope. Tanium does not authenticate your BGP peers. It does not configure Dynamic ARP Inspection on your access switches. The first four items on the checklist above are network engineering, and no endpoint platform replaces that work.
But the moment you walk back up the stack, the picture changes. Because once the network plane is configured correctly, the next question is: do you actually know what is running on every endpoint? Patched, hardened, configured the way you think it is? Running the services it should, and nothing more?
That's the layer where we deployed Tanium at Locked Shields 2026. During the live window, the platform delivered:
- Real-time inventory of every host on the estate for Windows and Linux, including segments we onboarded mid-exercise
- Software bill of materials and library-level visibility covers every endpoint, down to component and version
- Vulnerability data linked directly to the remediation: find the vulnerable library, deploy the fix from the same console
- Automatic deployment of the Tanium agent to newly discovered hosts, with no manual onboarding queue
- Distribution and update of partner AV and EDR agents pushed alongside Tanium across the full fleet from a single console
- OS and third-party patching at scale like Windows cumulative updates, .NET, SharePoint, Linux kernel and library patches
- Hardening scripts deployed and re-applied across the estate, so no host stayed unconfigured
- Local-credential rotation deployed on a short cadence to cap the useful lifetime of any stolen password
- Custom incident response packages authored under pressure and pushed to the fleet, covering firewall rule deployment, persistence cleanup, implant removal
- Threat hunting across the full endpoint estate from a single console
- Agent-based command delivery as a fallback when standard network paths were degraded
None of that replaces getting Layer 2 right. All of it stops working if you don't know what endpoints you have. The two disciplines are complementary. The teams that do well at Locked Shields run both in parallel: a hardened network plane underneath and a fully managed, fully visible endpoint estate on top.
The takeaway
Locked Shields is impressive, and the IR work it showcases is real. But the exercise also keeps showing, year after year, that experienced defenders win in the foundational layers. The team that locked down ARP and DHCP on the access segment, authenticated their routing sessions, and segmented their management plane will, on average, beat the team with the slicker SOAR playbook.
If you take one thing from this post: the next time something breaks and your reflex is to open the firewall console, open show mac address-table or show ip bgp summary first. The answer is more often there than you'd like to admit. Then, once the network plane is sound, make sure you have a real endpoint platform sitting above it. The basics first. The platform second. In that order.
Locked Shields 2026 figures and quotes via CCDCOE, SHAPE NATO, and exercise scenario detail confirmed via SANS Institute.
Featured image by: Blue Team 10 @ Locked Shields