0x01 Preface
I had a few draft posts sitting around that I never got around to finishing — months passed and I just didn’t pick them up again, so I’m leaving them as-is. Looking at all the hype coming from both vendors and buyers in the industry, security architecture somehow never gets its moment. Ideas documented in security architecture books from 2002 and 2003 still haven’t really landed properly two decades later. Figured I’d throw my own thoughts into the mix — a casual take on how to actually build security architecture. Take it with a grain of salt.
0x02 Main Content
Two parts: collaboration and governance. Quick summary of each.
1. Collaboration
The basics: define clear ownership for each team, establish collaboration workflows, and use some kind of sync mechanism to reduce information gaps across departments. Form virtual teams for special projects. The security architecture group handles design requirements from both internal and external stakeholders — including security governance and risk management teams (some organizations fold part of governance responsibilities into architecture; in theory, a dedicated team would work better). Implementation goes to the platform team, and delivery to end users runs through the operations team. Security architecture sits right in the middle — bridging upward and downward. The job is to complete solution design that aligns with Policy Design, identify gaps, apply the right pattern or model, and ultimately produce the System Approach for the platform.
A platform is one of the prerequisites for continuous delivery. Beyond that, when interfacing with business units, you can’t just rely on the context from a single meeting — you need to build a long-term mechanism for deep understanding of the business.
Platform
Continuous external delivery gradually drives internal platform-building within the team. This creates a delivery platform for security capabilities. A small security platform can take on R&D and ops; a slightly larger team can incorporate day-to-day security operations needs. But just hiring a few security ops engineers and developers doesn’t make it a “platform.” A real platform needs platform-grade, systematic products. Internalize policy, process, and risk management into the platform, integrate systems via APIs, and output self-service capabilities.
Business
Deep security involvement in business scenarios will naturally create dedicated roles for this. Before crafting any comprehensive solution, you need plenty of business context — and that context needs to be systematic and interconnected. For example: what’s shared between contracts, wallets, and spot trading? How does a change in one area affect another? Do security controls trigger chain reactions? Whether it’s an InfoSec BP or a BISO, both roles can serve as a bridge for deep business collaboration. Practically speaking, this means joining architecture committees or becoming the dedicated security contact for a specific business line — giving you access to more effective information, especially when the business is iterating fast.
2. Governance
Security governance principles have evolved from “secure by default” to “shift left” — which is really just a question of time and space. The end result is default-secure, shift-left defense-in-depth: get security design in as early as possible and actually make it stick. But with infrastructure moving toward IaC, both infra and applications now get dynamic resource changes, which means release frequency keeps climbing. That in turn pushes security operations to automate responses faster, shrinking the window between detection and remediation, and cutting out unnecessary steps. In recent years we’ve seen X-DR and X-SPM emerge in the detection and response space, and X-SOAR and attack simulation appear in security operations. Internally: manage and protect assets (PDRR-P). Externally: form the risk management surface (PDRR-D). Automate it all through security operations, and use attack simulation to validate the strength of the system architecture — both the defense and the design process. That’s probably the most common defensive pattern you’ll see.
In this process, I also pay attention to framework integration (embedding security attributes into enterprise architecture in some coherent way), infrastructure changes and business-specific characteristics (Web3 businesses and hybrid multi-cloud setups are both headaches), and information protection and data security. Quick notes on each below.
Framework Integration
Both security architecture and enterprise architecture have developed their own methodologies — TOGAF for the well-known enterprise architecture side, Octave for risk management, SABSA and O-ESA for security, among others. Figuring out how to blend domain-specific frameworks with enterprise architecture frameworks becomes really important during security design, because all subsequent solutions should be implemented against that foundation.
Cloud and Web3
Cloud and cloud-native are still where things are heading — or more precisely, resource virtualization and dynamic scheduling. Even if you’re not using public cloud, you’ll need elastic capabilities. I’ve had a few distinct shifts in how I felt about this: first when I was using cloud personally while the company was still on IDC; then when the company started moving to cloud; then when it got to hybrid cloud, and eventually hybrid multi-cloud. Each step felt completely different. Cloud security is obviously something companies actively care about, but the security products cloud vendors offer are often fairly basic, and tenants don’t have much autonomy — while defaulting to implicitly trusting the cloud vendor. From a security practitioner’s standpoint, it feels like cloud vendors want to do security but can’t quite pull it off. For tenants, they’re just consuming resources. For the cloud vendor, everything is their production network. Add Web3 into the mix: decentralized business running on centralized cloud — potentially facing account shutdown due to compliance issues or supply chain crises. Cloud gives you elasticity, but the assets aren’t fully yours. For Web3 specifically, if it’s a decentralized chain or deployed smart contracts, any security incident basically means you can’t get the quick fix and damage control you’d have in traditional security — forget about asset recovery. Look back at the past year and count how many projects got wiped out. And yet Web3 project infrastructure design isn’t all that different from traditional security. That’s partly why I named this section “Cloud and Web3.” You absolutely have to dig deep into both the business and the infrastructure.
Information Protection and Data Security
Data security can be a technical capability or a goal you’re working toward. I’ve been seeing a lot of data security articles lately, but most of them start from DSMM or the data lifecycle. Let me look at information protection and data security on the corp side through an architecture lens instead. Unlike site/production environments, corp data is far more scattered and the scenarios are more complex. Production data can be quickly classified and categorized — key-value formats are fairly fixed, and detection mechanisms are relatively easy to build. The office environment is a different story. Matching a national ID number in a production environment versus detecting one in a corporate office environment are very different problems. There’s no fixed pattern — it might be in email, it might be in a wiki, it might be in a document. Distribution is too complex. That means you need different systems and tools just for discovery. You can address this through mandatory active document labeling combined with DLP at fixed checkpoints — see the diagram below (adapted from Microsoft’s data protection framework).
There’s a previous post on endpoint security that covers the details — won’t repeat them here. Privacy protection is people-focused: it zeroes in on the sensitive parts of data that people generate. Data protection is data-focused: it covers PII, financial data, and other sensitive data (I’m lumping privacy protection and data protection together under “information protection” here for simplicity — not necessarily the most precise framing). All of this needs data security to provide the technical backbone — isolation, encryption, watermarking, desensitization, tokenization and other techniques to achieve data “security.” That said, I no longer expect to achieve data security purely through data governance the way I did at the start. Now I take a broader view and combine foundational security and application security solutions to get there. One more thing worth saying: a comprehensive solution absolutely does not mean bundling different products or solutions from a single vendor.
0x03 Wrap-Up
If a security architecture team has low visibility within the organization, it’s usually because no effective collaboration workflows were established — which creates friction on both internal output and external delivery, plus information gaps all around. That said, this isn’t entirely something the security architecture team lead can control. Even the head of security can’t always decide it.
When visibility is low, the team’s reason for existing gets questioned, and self-doubt sets in.
As a security architect, I’ve seen some truly terrible designs and hit wall after wall. I feel more and more strongly about the importance of top-level design. It’s like when I first recognized the value of data — I tried to use automated operations to surface problems and push fixes reactively. What you actually need is architectural design that prevents the problem at the source. Same pattern everywhere: the firewall change request comes in, and that’s when people finally think to look at the system design. Reactive firefighting might look impressive in the moment, but it just grinds you down.
I don’t like people who lie, and I don’t like people who don’t keep their word. People say work and life are separate, that skill and character are unrelated. I’ve come to feel that character matters more than skill — what you really need in the workplace are people where the two are matched. You shouldn’t overlook someone’s character just because they can do a certain job. I’ve always had one hope: to use my own work to push security forward as a field. After seeing so many lies in the security industry (probably true in other industries too), I’ve stopped expecting some ideal environment. I focus more on doing real work — if I can contribute my own small part, that’s enough.
My first real awareness of data’s value came from various data breaches. Later, working on anti-intrusion, I ran into the importance of data protection again. Some of my governance thinking came from DSMM training — starting from data classification to understand the full data lifecycle. But then when I got involved in cryptography infrastructure, I developed a new perspective on data security backed by cryptographic techniques: true random number generation, establishing roots of trust, PKI, key management, and so on. That gave me a clearer sense of the gap between “talking about data security” at the operations level versus data security supported by actual algorithms. From there I started paying closer attention to the distinctions between Information Protection, Data Privacy, and data security (what is Privacy? Is Privacy data the most valuable? Started looking into data security legislation). My research shifted from Data at Rest / Transit toward Data in Use. Started getting into privacy computing topics — MPC applied to KMS, TEEs on AWS and Azure, and so on. And currently: data governance for the corp/office environment, combining information isolation, endpoint security, DLP, and information protection to achieve a reasonable level of data security.
In mid-December 2022, I got to experience a Fangcang field hospital firsthand.