From genes to security architecture
Competition and falsifiability
I was out of town much of last week, so between that and some vacation time, I’m a week or more behind in posting. I actually wasn’t gone that long, but the cruel mistress of air travel knocked the stuffing out of me for a bit. I’ve flown home from Shanghai in less time that it took from St. Louis. I’ll be trying to catch up this week.
It’s useful to reflect for a second on our changing understanding of the human genome. Classically, the genome was thought of as a series of instructions - instructions for creating proteins. As the human genome project was spinning up, there was a palpable excitement that once fully “decoded”, the genome would open the door to understanding the genetic underpinnings of, well, pretty much everything. Got disease X? We’ll track down and modify the specific gene or genes that controlled that. This also fed some of the most recent eugenics trends. All we need to do is figure out which genes made people taller, stronger, and smarter.
Now, of course, while our ability to do genetic analysis is now off-the-shelf, we’ve come to learn that the truth is vastly more complicated. While it’s true that genes do behave largely as understood, it’s not a simple matter of modifying a single gene or set of genes, but it is the regulation of genes that may matter equally. Our body enables and disables genes pretty much continuously, and the nuanced interplay of genes and their regulation is the new frontier. This is to say, our genes are components, but it is the system within which they operate that is where the action is. As the linked article points out, the genome is not the architecture nor a framework, but rather components within the broader, and more complicated, system.
It is this view of architecture as a system, and not a conglomeration of components, that allows this analogy to dovetail with cybersecurity. Or at least, that’s what I’m going to propose. In my last post I noted that unlike math, where a problem is decomposed into simpler elements then is recomposed into stable truths, we in cybersecurity seem to lack an analogous process for our challenges. Particularly those where we want to create a stable architecture for a solution - one that is reusable, and in which failures serve to improve future iterations of the architecture.
I think the shift we should probably make is from thinking of an architecture as a bunch of nouns, to a bunch of verbs. Most reference architectures are essentially inventory lists or compliance checklists. They say, “a mature organization has an MDR service, a PAM tool, an asset correlator, and an incident response playbook.” They define the boundaries of the swimlanes and the existence of the equipment. Rather, I’m going to argue that an inventory list is not an architecture. A real architecture must define system behavior under stress. It isn’t enough to say you have a firewall; you must explicitly claim what the specific, measurable outcome is when a specific failure mode occurs. For our purposes I want to define ‘architecture’ as declared behavior under defined failure conditions.
My suspicion is that my friends and colleagues who are more facile in all matters architectural are going to email me saying, “you dope, of course real architecture does just that. Read a book once in a while.” Perhaps. But I’m appealing here to how the term is actually used in practice. If you go to your networking team and say, “can I see our network architecture” you’ll get a lovely diagram showing network connections and equipment. If you go to your identity team and ask “what’s our identity architecture” you’ll get told about databases holding identity attributes, permissions, and a list of supporting services like SSO or MFA. Inventory lists - valuable no doubt, but nouns one and all1.
Part of what I’m responding to here isn’t the lack of sophistication in IT architecture. A glance at the work of ITANA or even the Educause Enterprise, Business, and Technical Architects community group shows plenty of it. But rather, where it seems to be lacking is within the cybersecurity space. I don’t know if this is because we’ve outsourced creating security solutions to vendors, or we’re all just too busy - my appeal to the defense of The Beleaguered CISO - but what it truly means to have a security architecture must, it seems to me, be more than lists of policies and controls.
What I’m describing is called a behavioral reference architecture. A behavioral reference architecture does not describe where controls sit, but how decisions are made and enforced across a distributed system2. It defines the signals that matter, the logic that interprets them, and the enforcement points that act on them - creating a coherent, testable model of defense rather than a static diagram of components. I’m going to keep pointing to a fully baked zero-trust architecture as the most commonly understood model. Ironically, the majority of ZT deployments I’ve seen in higher education leave out the most important component - the policy engine - falling back on modest micro-segmentation and gentle NAC in its place.
Most reference architectures describe what should be present, not what should happen. Without explicit claims about outcomes, constraints, and failure modes, they cannot be tested, compared, or improved, and thus never converge into shared engineering practice. As you may have noted in my previous post, it is the lack of codified and shared engineering practice among higher ed organizations that I find disappointing. But perhaps this lacuna is a symptom of this more general failure to develop truly “architectural” security architectures. Ones that meet the definition of what I’ve labeled a behavioral reference model.
Creating these explicit claims (and subsequent tests) of an architecture is, of course, challenging for us in cybersecurity; it’s relatively straightforward to test for the known, but brutally difficult to do the reverse - which is where most of our challenges arise. I’m not even sure what the conceptual language of such claims should be. My intuition is telling me that we might want to borrow from the SRE (Site Reliability Engineering) work done by Google that defines SLOs (Service Level Objectives) and SLIs (Service Level Indicators) for a service. SRE is entirely about how systems behave under stress. Thus SRE defines systems by measurable outcomes and behavior under failure is a first-class concern. But this in a nutshell is our core problem: security lacks agreed-upon SLIs (“blocked attack rate” is not as clean as is latency for a networked service) and of course, security vendors sell capabilities, not guaranteed outcomes3.
I feel obligated to propose some SLOs and SLIs as examples. To push this analogy let’s reframe SLIs as a “SBI” or a Security Behavior Indicator (SBI). If we want SBIs that are observable, time-bound and tied to behavior, not merely the presence of tooling, then examples might be:
% of privileged logins using phishing-resistant MFA
mean time to revoke access after termination
% of endpoints reporting EDR telemetry within last 24h
time from exploit publication to detection rule deployment
% of lateral movement attempts detected in simulation
Similarly we can reframe SLOs as a Security Outcome Objective or “SOO”. A few examples of SOOs include:
≥ 99% of administrative authentications use phishing-resistant MFA
compromised credentials are disabled within 15 minutes
≥ 95% of endpoints maintain active EDR telemetry at any time
known exploited vulnerabilities are mitigated within 72 hours
Notice the shift that we have made from “we have MFA” to “MFA behaves this way under pressure.” This is the core of the move from checklists to a behavioral reference model. We are moving from what exists to what must happen. Before the shift, architecture is treated as components (for example, firewall, MFA, PAM), topology (where things sit) and capabilities (what tools can do). After the shift to producing SOOs, architecture becomes explicit commitments about outcomes under defined conditions.
Remember, we are not merely translating metrics but creating operational narratives. For example, if a compromised credential remains active for 47 minutes against a 15-minute SOO, the architecture has failed - not the user. The question becomes: which dependency (IAM, HR feed, ticketing latency) broke the guarantee?
We’ve spent forty years defining what controls we have, and almost no time defining what they must actually do.
I suspect part of our challenge (as security professionals) in viewing our environment as a system is that we’ve fallen back on “defense in depth” for so long. Your nextgen firewall doesn’t recognize an attack and permits it through. No worries, hopefully your endpoint solution recognizes it or its activity on the host. Does that fail as well? Hopefully network segmentation or credential hardening can constrain the infection. And so on, one failure triggering yet another control plane after the other. Essentially, while defense in depth will always remain a wise course, I wonder if we’ve allowed it to become a proxy for robust systems engineering.
As I’ve argued elsewhere, and as a recent article perfectly summarizes, “the root cause of most successful cyberattacks is not a failure of security controls, but a failure of system design.” This shouldn't be news to anyone. If you look at the footnotes of that very modern commentary on AI-driven threats, the source material is a remarkably prescient blog post dating back to 2016.4
Of course that blog and the comment about a '“failure of system design” are referring largely to applications (which are themselves systems). Whereas I’m speaking about the system of security architecture writ large. I would be remiss not to mention, as was pointed out to me by a colleague while discussing this, that computer science has long wrestled with the issues I’m raising, but with much deeper thought and academic rigor5. For the moment though, I think it’s enough to try to formulate SOOs and SBIs if for no other reason than to challenge our usual thinking.
I’d like to pivot the discussion at this point back to the issue of a lack of convergence of architectures within our community, as well as re-introduce the notion of epistemic humility as influenced by what we’ve learned from the drama surrounding Anthropic’s Mythos. Recall that by epistemic humility I’m referring to the fact that our environments are rife with things we don’t and maybe can’t know about them. Everything from zero-day vulnerabilities to unimagined user-behavior. While it’s unidimensional, the takeaway lesson from Mythos seems to be that the quantity of unrecognized vulnerabilities in software is far greater than even the most cynical of us imagined.
For me, some of the significance to this is that because malicious adversaries have the same or similar capabilities as Mythos provides, the attack surface of any security architecture is much larger than we’re prepared for. If an adversary can auto-generate zero-days at scale, your component inventories (nouns) are completely useless, leaving your system's dynamic degradation behavior (verbs) as your only line of defense.
Returning to the challenge of testing an architecture: how are we to test its ability to detect and mitigate an attack when the diversity and breadth of those attacks just expanded by an order of magnitude? There is no simple answer to this, except I see this as an even more compelling reason for our community to converge on the most robust solutions for security architecture and to stop assuming that “which ever vendor we can afford and is popular” is a strategy for success.
As I’ve noted, we have shared references for guidance, e.g., NIST publications and control sets, but we lack a mechanism for shared synthesis of architectural models. That is, architectures that produce consistent and predictable outcomes: SOOs are not defined. I suspect that one reason for this is that our models, our architectures aren’t falsifiable - they don’t converge because they don’t compete.
A falsifiable reference architecture enables comparison across institutions, iteration, and then convergence. That is, “did it work?”, “what failed and why?”, and “this pattern consistently produces the desired outcomes.” Without falsifiability, you get what I described as the diffusion of practice instead of engineered convergence. I’m going to argue that SBIs and SOOs are the foundational metrics that make a security architecture falsifiable. If you don't define an SOO, you haven't declared a baseline that can be proven wrong.
I should probably define falsifiability for those not raised on Karl Popper. Popper proposed that a claim is falsifiable if there exists a conceivable observation that would prove it wrong. Falsifiability has become a cornerstone of the scientific method. Operationally, falsifiability requires someone to define the disconfirming condition, someone to test for it, and importantly, someone to care if it fails.
The reason I think competition is so essential for us when thinking about falsifiability is that without competition, three things happen. First, there is no incentive to test disconfirmation. It’s natural to simply test what confirms our beliefs or, alternatively, to quietly reinterpret failures. Second, ambiguity goes unchallenged - without competition, who is going to challenge you on statements like “the firewall improves our security posture”? This is not crisp nor will it support exploration of questions like “under what conditions does it fail?” Finally, and I’ve seen this far too often both inside and outside of security, failure is socially suppressed. Failures are often reframed as exceptions. Competition, on the other hand, needs not just independent judgment or reputational stakes, but an incentive to find flaws.
Fundamentally, falsifiability is not merely a property of a model, but a property of the environment in which it is evaluated. Without independent actors incentivized to challenge it, even a formally falsifiable claim becomes operationally unfalsifiable.
More simply, without the discipline that competition between security architectures would engender - the discipline to define security behavior indicators and security outcome objectives so that competition is possible - it’s difficult to see how we will ever move beyond the informal diffusion of practice to engineered rigor.
So what should be our next steps? By writing this I’m hoping to seed some thinking about SBIs and SOOs within the security community. I’m also hoping that the technical architecture community turns its eye toward cybersecurity. (And remember, a mature cybersecurity architecture will need to account for non-technical, human behavior as well as the usual adversary/defender binary). What would be a good next step is for us to put some thought into establishing the test harness for falsifiability. No one can write a deterministic, purely technical script to test for the vast, unknown attack surface exposed by AI engines like Mythos but we need to bridge the gap between human systems engineering and narrative simulation.
The closest proxy for a system stress test is the human and administrative execution layer. One option would be to use collaborative, improvisational role-playing exercises as the dynamic test harness6. By forcing mixed-role groups (CISOs, researchers, IT engineers, and administrators) to actively improvise how stress, professional ambition, and trust break down a system, you create a generative model that surfaces unexpected behavioral indicators and system failure points that no checklist could predict.
We also need an open-source repository of behavioral blueprints that declare explicit SOOs. If such an animal already exists it needs to become part of the lingua franca of security professionals. This must include the outcomes from when a model is tested under stress (i.e., when it fails). When an institution experiences a breach, the post-mortem should not simply state “the user clicked a link,” but rather: “Our architecture claimed a 15-minute credential revocation window (SOO), but failed under the stress of an asymmetric identity attack because of a cross-functional dependency gap.”
Cybersecurity seems to be entering a new phase, one in which its function more visibly underpins our entire civic and economic life. In this new phase, the nature of collaboration is also under pressure to evolve. Our collaborations must move from asking “what do we have?” and start asking “what must happen, how fast, and how often?”
To be fair, the wisely designed network architecture does include behavior under failure. Internet Protocol (IP) networking is designed to be highly decentralized and route around damaged links though it still relies on a physical layer of infrastructure to function (which is why it failed so quickly during the 2003 invasion of Iraq. The US heavily targeted those physical links with kinetic weapons.)
You can see how this elides with my preoccupation with governance throughout this blog. See: https://michaelcorn.substack.com/t/policy.
A SRE style formulation would look something like this: “When X → system does Y → within T → observable via Z”. So translating this from SRE to security we would take something like “99.9% of requests succeed under load” and turn it into “100% of malicious traffic is dropped within X ms,” sticking with a firewall example.
No, this wasn’t my idea, but that of the PI of a grant I’m participating on. We’re currently using Fiasco as the RPG. Working with people smarter than you is always a wise move.