What People Actually Mean When They Say Protect And Defend
Most people treat Protect And Defend as two separate phases of a project. They spend weeks hardening a system, then switch hats and spend another few weeks trying to breach it. That separation is the main reason it fails in practice. The method works when you run both sides simultaneously, using the same tooling, the same timelines, and the same failure modes. I ran into a specific problem last year that made this obvious. We were securing a containerized deployment for a mid-size logistics company. The defend team configured network policies using Calico, and the protect team was using a different CNI plugin in their test environment. Both teams thought they were testing the same setup. The protect team kept finding open egress paths that the defend team had explicitly closed. It took three days to realize the CNI mismatch was causing the defend team's network policies to silently fail. The workaround was straightforward once we found it: lock the CNI version in a Dockerfile pin, add a CI check that dumps the actual iptables rules after deployment, and compare them against the expected baseline before any penetration test starts. This alone cut our false-positive rate from about 40% down to roughly 5%.
How To Run A Real Protect And Defend Exercise
Start by defining the attack surface before you write any defensive rules. I mean the literal list: every ingress port, every outbound connection, every shared volume, every service account token. Write it down. If something isn't in the document, it doesn't get tested and it doesn't get defended. Next, build your red team scenario from that list. Not from some generic vulnerability database. From the list. Pick three entry points and plan how an attacker would move from each one. Most people skip this step and just run automated scanners. Scanners are useful for inventory, not for strategy. They'll tell you there's an open port. They won't tell you whether that port matters to anyone who actually wants to steal data from your system. For the defense side, configure everything in code. I use Terraform for infrastructure and GitOps for policy changes. Every rule change goes through a pull request. The defend team reviews the PR. The protect team can see it and plan around it. This kills the "I didn't know that rule was deployed" conversation that usually happens right before an exercise starts.
Run the exercise in a staging environment that mirrors production as closely as possible. I know people say this and then use a sandbox that has half the logging agents and a different kernel version. That makes the results useless. If your staging environment can't handle the same traffic pattern as production, the exercise is just a warm-up drill. Run realistic load during the exercise. Attack patterns change under load. A slow scan that looks ineffective at 100 requests per minute will find gaps at 10,000 requests per minute because the defense system drops packets or queues connections differently. Here's something most guides don't mention. The defend team should not have live access to the exercise environment during the attack window. I know that sounds extreme. But when defenders can see the attacker's movements in real time, they stop thinking about what could go wrong and start thinking about how to fix it immediately. That's not an exercise. That's just regular work with an audience. Let the defenders review logs after the exercise is over. Force them to process the same fragmented evidence an incident responder would actually see.
Get the Full Details
Common Mistakes That Waste Three Weeks
Using too many tools is the biggest one. I've seen teams bring in four different vulnerability scanners, two endpoint detection platforms, and a SIEM that ingests everything. The protect team spends two weeks tuning alert thresholds so they can actually see the attacks. The defend team spends two weeks figuring out which alerts are real. Nobody does any actual defense or offense. Keep it to one detection platform and one scanner. Tune it properly. The noise from a second tool usually drowns out the signal from the first one anyway. Another mistake is treating every finding as equally important. When your exercise ends with a list of 200 vulnerabilities, half of them are theoretical. The other half might be exploitable under very specific conditions. Spend the post-mortem time on the three findings that actually demonstrated a realistic path to data exfiltration. The rest can go on a backlog. I learned this the hard way after an exercise where our team spent four hours debating a SQL injection that required a specific browser extension and a deprecated library version that no one in production was running. We should have spent those four hours documenting why the real attack path worked and how to close it. Protect And Defend exercises also break when the timeline is too compressed. Two days sounds efficient until you realize the defend team needs time to triage alerts, the protect team needs time to re-connoiter after each blocked attempt, and everyone needs time to debrief while the details are fresh. A well-run exercise usually takes five to seven days minimum for a medium-complexity system. If you're planning something shorter, you're not doing an exercise. You're doing a walkthrough, and you should call it that.
When This Approach Won't Work
There are scenarios where Protect And Defend as a structured exercise simply doesn't fit. If you're running a legacy mainframe system with no API layer, you can't reasonably simulate modern attack techniques. The exercise becomes theater. If your team has fewer than four people who understand the system at a deep level, the exercise will either expose too much or learn too little. You need people who can design realistic attacks and people who can spot when the attack isn't hitting what it should. Those are different skill sets. Sometimes a continuous approach beats a periodic exercise. Red teaming-as-a-service with ongoing monitoring gives you different coverage than a week-long exercise every six months. The tradeoff is cost and the fact that continuous testing never lets the defend team catch their breath. There's value in the break. There's value in the focused intensity of a short exercise where everyone knows something important is happening and treats it accordingly. If you decide to run this, start small. Pick one subsystem. Define the attack surface for that one piece. Run a two-day exercise. Document what happened. Then scale up. The teams that try to exercise their entire infrastructure on day one usually end up with a thick report nobody reads and a lot of burned-out engineers.
