Preface
Back in May I’d already decided to write a few new posts on security architecture, but ended up only getting a small part done. Progress was limited, ideas hadn’t fully settled, and my thinking kept hitting walls. Recently though, I feel like I’ve absorbed quite a bit, and when I flipped back through Enterprise Security Architecture I realized I’d been reading it for several months already — so I figured it was time to turn my notes into something coherent.
The previous three-part series “What is Security Architecture” was mostly experience-driven, bottom-up, summing up practical methods learned from hands-on work. This time I’m using Enterprise Security Architecture as a reference to take a top-down look at the journey from methodology to actual implementation. The more I read, the more I find the two perspectives reinforce each other.
Enterprise Security Architecture Methodology
Concepts
Any universal method still needs to be adapted to its context. After finishing the book, it really helped me pull together everything I’d been accumulating…
Since each phase has a lot of things to consider independently, I put together a table based on the book’s content, and also posted a text version summary here on gist:
Note: All screenshots below are from the original book
At a high level, there are three Phases and six Layers.
The three phases are: Strategy/Planning → Design → Operations. The six layers are:
- Contextual Security Architecture
- Conceptual Security Architecture
- Logical Security Architecture
- Physical Security Architecture
- Component Security Architecture
- Operational Security Architecture
In terms of processing order, by the time you’re defining the Operational Security Architecture, you should already have thought through the Logical and Physical Security Architectures, along with potential issues at the Component level.
In other words, whenever anything needs to be delivered as output, Manage & Measure is happening in the background — whether driven by yourself or by others/the team.
The diagram below uses Directory Services as an example to show how the 6 Layers are formed.
0-1
There are two diagrams here, each showing how this framework operates. The first covers the entire three phases (at an abstracted level) — how business strategy, influenced by various inputs (Goals, market, financials, raw product signals), feeds back into security strategy, and the cases and factors considered as you move from Logical → Physical, all the way to establishing trusted operations.
Whether some parts of this are outdated doesn’t really matter for now. In methodology migration, the details rarely have a big impact. You can even map Yin-Yang theory onto security (the following is just riffing):
Opposition and Constraint
The adversarial relationship between attackers and defenders. Inside an enterprise, critical permissions get split across different departments — that’s constraint too. Externally, companies and regulators constrain each other. Not necessarily opposition, but mutual check. Take internal red-vs-blue: is it opposition? Sort of, but not really — they end up doing a joint debrief afterward. Why bring in a Blue Team? To surface risks early, use offense to drive defense.
Mutual Containment
Offense contains defense; defense contains offense. You put up a block, and the attacker’s infrastructure is already automated around it. They get in, so you set up a honeypot. Inside the company, red and blue teams form an inside-outside dynamic. New technology brings new risk, which drives new security.
Interdependence
No attack, no defense. But no theft prevention doesn’t mean no theft. Vendors sell to enterprises, provide tech support, and then some of those enterprise folks spin out their own companies. Everyone’s circling the same ecosystem. The polite framing is “mutual growth.” Inside the enterprise, it’s the same logic — platforms, middle-layers, collections of components that product lines pull from as needed.
Dynamic Balance
It’s all about momentum. Attack and defense rise and fall against each other. Same with team dynamics: if your project is strong, stakeholders push back; if you’re weak, your manager might come advocate for you. If attackers hit hard and you can’t hold, law enforcement steps in. If your defenses are solid and the business is humming, more people will come at you.
Mutual Transformation
People move from the vendor side to the enterprise side and back. There’s also the saying: “How can you defend what you don’t know how to attack?” Without that perspective, defense is always reactive.
These things are great for talking through problems and expanding your thinking. But they’re not a good method for grounding actual design decisions. Real implementation means working through complexity, evaluating management cost, budgets, and all the rest — approached with rigor, not handwaving.
Summary
It’s not hard to see that the practical experience from before and the methodology in this book share a common core. Even though the book came out in 2005, it still holds up as a desk reference today — especially for folks who just moved into enterprise-side security (fellow new-generation migrant workers in the information technology services sector, who should embrace optimism, acceptance, and freedom from worry). It doesn’t need to be read cover to cover; for experienced practitioners, skimming the table of contents is probably enough to get the gist. Its biggest value is helping you build the big picture — knowing what belongs where, and when to do what.