DEV Community

Cover image for The Epistemology of Offense and Defense: A Foundational Framework
Narnaiezzsshaa Truong
Narnaiezzsshaa Truong

Posted on

The Epistemology of Offense and Defense: A Foundational Framework

Why attackers and defenders live in incompatible knowledge systems—and what that means for security architecture


This post lays out the epistemological model I've been developing publicly since late 2025—a model that explains why attackers and defenders consistently talk past each other, and why traditional defensive tooling fails to detect the most damaging intrusions.

If you work in security engineering, red teaming, detection engineering, or architecture, this framework will help you understand:

  • why "intended system" and "latent system" diverge
  • why configuration drift is predictable, not accidental
  • why feature abuse outpaces exploit-based attacks
  • why intent detection is fundamentally different from anomaly detection
  • why SMBs need a different security model than enterprises

This is the theoretical foundation behind my care-based security approach and the consulting methodology I use at Soft Armor Labs.


The Divergence

Offense and defense begin with different questions.

Offense asks: "What is true enough for me to act?"

Defense asks: "What is true enough for me to trust?"

This single divergence creates two incompatible knowledge systems.

Offense is satisfied with partial truth, probabilistic truth, or even opportunistic truth. Defense requires stable truth, repeatable truth, and institutional truth.

Offense thrives on ambiguity. Defense collapses under it.


1. Exploration vs. Enumeration

Offense epistemology:

  • Knowledge is discovered through movement
  • Truth emerges from trying things
  • The world is a graph of possibilities
  • Unknowns are invitations
  • The environment is a puzzle to be solved, not a system to be maintained

Defense epistemology:

  • Knowledge is cataloged through inventory
  • Truth emerges from documentation
  • The world is a list of assets
  • Unknowns are liabilities
  • The environment is a system to be stabilized, not explored

Offense is inductive. Defense is deductive.


2. Fluid vs. Static

Offense assumes:

  • Configurations drift
  • People take shortcuts
  • Trust chains are leaky
  • Documentation is outdated
  • Reality diverges from architecture diagrams

Defense assumes:

  • Configurations reflect intent
  • People follow process
  • Trust chains are understood
  • Documentation is authoritative
  • Architecture diagrams represent reality

Offense epistemology is grounded in how systems behave. Defense epistemology is grounded in how systems are supposed to behave.

This is why offense feels like truth and defense feels like belief.


3. Consequence vs. Compliance

Offense validates through consequence:
"Did the action produce the effect I expected?"
Truth = outcome.

Defense validates through compliance:
"Does the system meet the defined standard?"
Truth = alignment with policy.

Offense epistemology is empirical. Defense epistemology is bureaucratic.

This is why offensive operators often feel like scientists and defenders often feel like administrators—even when both are brilliant.


4. Capability vs. Permission

Offense epistemology is built on:

  • What can this identity do?
  • What can this feature be repurposed for?
  • What can this trust relationship imply?

Defense epistemology is built on:

  • What should this identity do?
  • What should this feature be used for?
  • What should this trust relationship allow?

Offense maps the latent system. Defense maps the intended system.

The gap between those maps is the entire attack surface.


5. Breach vs. Order

Offense epistemology begins with:

  • Something is misconfigured
  • Someone is overprivileged
  • Some trust chain is too long
  • Some process is exploitable
  • Some human is tired

Defense epistemology begins with:

  • Controls exist
  • Policies are followed
  • Monitoring is accurate
  • Privileges are scoped
  • People behave predictably

Offense sees entropy. Defense sees structure.

Both are right—but only one is actionable.


6. Environment vs. Vendor

Offense epistemology is grounded in:

  • Observing real behavior
  • Reading documentation as capability statements
  • Testing assumptions
  • Following trust chains
  • Exploiting emergent properties

Defense epistemology is grounded in:

  • Vendor best practices
  • Compliance frameworks
  • Security tooling outputs
  • Architecture diagrams
  • Policy documents

Offense learns from what is. Defense learns from what should be.


7. Contextual vs. Universal

Offense epistemology is environment-specific. Defense epistemology is environment-agnostic.

Offense asks:
"What is true here, in this exact configuration, at this exact moment?"

Defense asks:
"What controls should exist everywhere, at all times?"

This is why offense scales poorly but succeeds deeply. Defense scales well but often fails locally.


8. Intent vs. Events

Offense epistemology is narrative. Defense epistemology is atomic.

Offense looks for:

  • Sequences
  • Motives
  • Patterns
  • Emergent behavior

Defense looks for:

  • Alerts
  • Logs
  • Anomalies
  • Violations

Offense sees the story. Defense sees the timestamps.


9. The Meta-Epistemology

Offense must understand:

  • How defenders think
  • What defenders assume
  • What defenders ignore
  • What defenders trust
  • What defenders automate

Defense rarely understands:

  • How attackers reason
  • How attackers explore
  • How attackers validate truth
  • How attackers chain capabilities
  • How attackers use legitimate features

This asymmetry is epistemic, not technical.


Implications for Detection Engineering

The gap between offense and defense isn't a skills gap or a tools gap. It's a knowledge gap—not in what each side knows, but in how they know it.

Security tools optimize for the defensive epistemology: inventory, compliance, alerts, documentation. They measure the intended system. Attackers operate in the latent system—the one that exists in the spaces between policy and practice, between architecture diagrams and actual configurations, between what people should do and what they actually do under pressure.

Effective defense requires learning to see like an attacker without abandoning the responsibilities of a defender. This means:

  • Treating documentation as hypothesis, not fact
  • Mapping capability, not just permission
  • Validating through consequence, not just compliance
  • Understanding that the attack surface lives in the gap between your two maps

This is why UEBA has been "the future of detection" for a decade but remains underdeployed. Intent detection requires understanding sequences and narratives. Most security tooling is optimized for atomic events. The mismatch is epistemological.


Why SMBs Need a Different Model

Traditional security is control-based: it assumes you can inventory everything, enforce everything, monitor everything. That's the defensive epistemology taken to its logical extreme. It works for well-resourced enterprises with dedicated security teams. It fails for everyone else.

SMBs operate under different constraints:

  • Limited personnel who wear multiple hats
  • Pressure to ship, not to secure
  • Configuration decisions driven by expediency
  • Documentation that exists in someone's head
  • Trust relationships that evolved organically

These aren't failures—they're predictable outcomes of operating under resource constraints. A security model that assumes they won't exist is a security model that will fail.

Care-based security starts from different assumptions:

  • Structurally honest: acknowledges that systems behave differently than intended
  • Emotionally literate: recognizes that humans under pressure take shortcuts
  • Operationally grounded: validates through consequence, not compliance theater
  • Sociotechnically aware: understands that security is about people, process, and technology together

The epistemological framework explains why this approach works: it bridges the gap between offensive and defensive ways of knowing, meeting organizations where they actually are rather than where frameworks assume they should be.


Final Thought

The hardest problems in security aren't technical. They're epistemological.

If you want to defend effectively, you must first understand that you and your adversary are operating in different knowledge systems—and that theirs is often more accurate about how your environment actually works.

Start there.


For the mythic-operational and sociotechnical context behind this framework, the Substack version is here.


Related Canon

This framework connects to my technical series on dev.to:

Myth-Tech AI/ML Security Framework—A 17-part series mapping mythological archetypes to AI/ML security patterns, including drift detection, memory architecture, and adversarial dynamics.


Provenance

I've been developing and publishing this epistemological framework in public since late 2025—across Substack, dev.to, Zenodo, and in my books. If you've encountered similar language or concepts elsewhere, this is the origin point.

Selected Zenodo publications (DOI-timestamped):

Full archive: ORCID 0009-0000-1964-6440

Books & Frameworks: Gumroad

This framework underlies the care-based security methodology, the Myth-Tech canon, and the sociotechnical approach I use in my consulting work. The lineage is here.


This framework is part of the Soft Armor Labs canon.

Top comments (0)