The Methodology
Most enterprise security programs are built around tools. This one is built around intelligence. The difference is not philosophical — it is operational. Intelligence tells you who is coming for you, how they will get in, what they are after, and what your defenses look like from their perspective. Everything else — every tool, every detection rule, every playbook — is built on top of that foundation. Without it, you are spending budget against a threat you have not defined.
And why the difference matters more now than it ever has
The adversary has a plan. They have studied your organization, mapped your attack surface, identified your weakest entry points, and selected the techniques most likely to succeed in your specific environment. They may have been planning this for months. They are using AI to accelerate every phase of that planning — reconnaissance that once took weeks now takes hours, spearphishing that once required manual crafting now scales to thousands of targets, evasion testing that once required significant expertise now runs automatically against your detection rules before the operation begins.
Most enterprise security programs are not built to match this. They are built to deploy tools, configure alerts, and respond to what fires. That is not a security posture — it is a cleanup operation. By the time the SOC sees the alert, the adversary has already succeeded in everything that matters: initial access, lateral movement, and in many cases, data staging. The detection happened at the endpoint, at the end of a kill chain the adversary completed without friction.
Intelligence-led security inverts this. You start with the adversary — who they are, what they want, how they operate, what your environment looks like from their perspective. Every subsequent decision flows from that understanding: which log sources matter, which detections to build, which gaps to close first, which hunts to run, which executives to protect. The intelligence is not a feature of the program — it is the foundation on which everything else is built.
These phases are not sequential steps in a project plan. They are continuous, interdependent disciplines that feed each other. Threat hunting findings become detection rules. Detection gaps become log requirements. IR data becomes hunting hypotheses. Recovery gaps become hardening priorities. The program is a cycle, not a checklist — and it is never finished, because the adversary is never finished.
The adversary automation problem: The adversary is using automation and AI at every phase of their operation. If your security program is still manual — if your analysts are doing by hand what can and should be automated — you are fighting an asymmetric battle you will eventually lose. Automation is not a nice-to-have. It is a requirement for staying operationally relevant against a modern adversary.
Threat landscape analysis · Attack surface mapping · IR data mining · Third-party & supply chain risk
The first question intelligence-led security asks is not "what tools do we have?" It is "who are our adversaries, what do they want, and what does our environment look like from their perspective?" These are not the same question, and conflating them is why most security programs spend budget in the wrong places.
Threat landscape analysis produces a prioritized adversary profile: the three to five threat actors most likely to target your organization based on your industry, your size, your geopolitical exposure, your technology stack, and your incident history. For each adversary, you need their objectives (espionage? disruption? financial gain?), their preferred initial access vectors, their documented TTPs mapped to MITRE ATT&CK, and their most likely course of action against an organization like yours. This is not a threat intelligence subscription — it is a structured analytical product that drives every subsequent decision in the program.
Attack surface mapping then answers the second question: what does your environment actually look like from the outside? This means internet-facing assets — including ones you may not know about, cloud resources spun up by development teams without security review, forgotten subdomains, third-party portals with access to your environment. It means your identity attack surface — privileged accounts, service accounts, federation trusts. It means your data — where your crown jewels live, who has access, and what path an adversary would need to traverse to reach them.
Your own IR data is one of the most underutilized intelligence sources in enterprise security. Every incident your organization has experienced contains validated intelligence about your actual vulnerabilities — not theoretical ones — and about which techniques adversaries have successfully used against you specifically. Pivot rates, dwell times, initial access vectors, lateral movement paths: these are ground truth about your environment that no external threat intelligence can replicate. Mining your IR data is not a retrospective exercise — it is an intelligence collection activity that directly informs your hunting hypotheses, your detection priorities, and your hardening roadmap.
Third-party and supply chain risk belongs in this phase because your adversary does not always come through your front door. They come through your vendors, your partners, your software supply chain — the trusted relationships your organization has that bypass your perimeter controls. Mapping your third and fourth-party exposure is part of understanding your attack surface. And when you build your recovery plan, supply chain compromise scenarios need to be explicitly included — because restoring from a backup that contains a supply-chain-delivered implant is not recovery, it is reinfection.
The intelligence feed that matters most: ISAC participation — sector-specific threat intelligence sharing with peer organizations — gives you visibility into threats your adversaries are actively deploying against organizations like yours right now. This is not generic threat intelligence. It is validated, sector-specific, current intelligence from organizations that share your adversary set. It belongs at the beginning of the program, and it belongs in the continuous feedback loop that keeps the program current.
Log source inventory · Field-level analysis · Adaptability framework · Pipeline integrity · Agent health
Most organizations approach log management as a cost problem: how do we reduce what we're ingesting to fit our SIEM budget? That framing misses what logs actually are — intelligence. Every log source is a collection asset. Every field within a log is a data point that either supports detection, supports investigation, or supports future analytical value. Managing logs as a cost without understanding their intelligence value is the equivalent of a military commander cutting reconnaissance assets to save budget before an operation.
Log analysis at the field level — not just the source level — is where most programs fail. The question is not only "do you have Windows Security Event Logs?" It is "do you have the right audit policy configured to capture process creation, command line arguments, and parent-child process relationships?" The log exists. The detection cannot be built. These are fundamentally different problems with fundamentally different solutions — and you cannot solve one by addressing the other.
Before recommending any log source be cut, a proper adaptability analysis must be conducted. This means evaluating three distinct dimensions: detection value today, investigation value today, and potential value in the future if the threat landscape shifts. A log source with low detection value may have high investigation value — it may be the pivoting point analysts use to reconstruct an attack chain after the fact. A log source with low current value may become critical if a new adversary technique emerges that relies on data only that source captures. These are not hypothetical considerations — they are real tradeoffs that require intelligence to evaluate, not cost-cutting to decide.
The third dimension of log intelligence that most programs miss entirely is pipeline integrity: are your systems actually sending the logs they are supposed to send? You configured the endpoint agent six months ago. The agent silently failed last Tuesday. Your SIEM shows green coverage because it does not know what it does not know. Three of your critical servers have gone dark, and your detection coverage is now full of gaps that look complete on paper. Agent health monitoring, expected versus actual log volume tracking, and automated alerting when a source goes unexpectedly silent are not operational niceties — they are core to knowing whether your security program is actually functioning. And critically: sophisticated adversaries deliberately kill logging before they move laterally. An unexpected drop in log volume from a specific host is itself a detection signal — but only if you are monitoring for it.
The question that changes the conversation: When someone proposes cutting a log source to reduce costs, the right response is not "we need those logs." The right response is: "Show me the adversary technique that log covers, show me its investigation value in our last three incidents, and show me what our detection blind spot will be if we remove it." That is an intelligence-led conversation. The cost conversation happens after the intelligence conversation — not instead of it.
MITRE ATT&CK mapping · Summiting the Pyramid · Gap analysis · Detection engineering · Automation · SIEM migration
Detection engineering in an intelligence-led program starts from the adversary, not from the tool. You know which adversaries are most likely to target you. You know their documented TTPs. The question detection engineering answers is: for each technique in your primary adversary's playbook, can you detect it — and how robustly? Not in theory. Not based on what your SIEM vendor claims. Actually, given the data you have, the rules you have built, and the testing you have done.
MITRE's Pyramid of Pain, extended by the Center for Threat-Informed Defense's Summiting the Pyramid methodology (December 2024), gives you the framework to answer that question with precision. Summiting the Pyramid scores each detection rule by the behavioral dependencies inside it — what specific artifacts or behaviors does this rule require to fire? A rule that fires only when a specific hash is present is trivially bypassed. A rule that fires based on behavioral patterns regardless of which tool the adversary uses scores high on the pyramid and survives adversary evasion. Building a detection program means systematically moving your analytics up the pyramid — and Summiting the Pyramid gives you the scoring methodology to do that at scale.
The gap analysis that follows maps your current detection coverage against your adversary's documented TTPs. The output is not a list of missing detections — it is a prioritized engineering roadmap that tells you exactly which gaps carry the most risk given your specific adversary set, which gaps can be closed with your existing data, and which gaps require additional log sources before detection is even possible. This is where Phase 2 and Phase 3 connect: detection gaps that cannot be closed without new data become log requirements that feed back into the log strategy.
Automation is not a feature of a mature detection program — it is a requirement. The adversary is using automation at every phase of their operation: automated reconnaissance, automated spearphishing, automated evasion testing against your detection rules before they execute. If your analysts are manually triaging every alert, manually enriching every IOC, manually building every playbook execution — they are already behind. Analyst fatigue is not a human resources problem. It is a security problem. When analysts are overwhelmed with volume, they miss the signal inside the noise. Automation closes that gap: automated enrichment, automated triage, automated playbook execution for known-pattern alerts, freeing analysts to focus on what requires judgment. SIEM migration — when the platform you are running can no longer support the program you need — must also be automated. A manual SIEM migration is a multi-year project that leaves your detection program in limbo. A well-engineered migration framework moves your detection logic, your data sources, and your playbooks systematically, preserving coverage throughout the transition.
When off-the-shelf tools cannot do what the program requires — when the gap between what a vendor's product does and what your specific environment needs is too wide — bespoke tooling fills that gap. Field-level log analysis at scale, coverage scoring against a specific adversary's TTP set, automated gap identification and prioritization — these are capabilities that require engineering when no commercial product addresses them precisely enough. The transparency and mathematical defensibility of that tooling matters: when a CISO asks why the coverage score is what it is, the answer has to be explainable, auditable, and reproducible. Vibe-coded automation that works but cannot be explained is not defensible. Rigorous, transparent tooling that can be validated is.
The automation imperative: The adversary does not sleep. They do not take weekends. They do not get alert fatigue. Your security program — if it depends on human analysts to do what automation can do — is structurally disadvantaged against an adversary who has already automated their reconnaissance, their social engineering, their evasion testing, and their lateral movement. Automation is not about replacing analysts. It is about ensuring analysts are not wasted on work that should never have reached them.
Intel-led hypothesis building · Adversary course of action models · Hunt findings feeding detection and logs
Most threat hunting programs are built around a schedule. A team of analysts hunts for two weeks every quarter, produces a report, and moves on. That is not threat hunting — that is a periodic assessment with a hunting label. The adversary does not operate on your quarterly calendar. They operate continuously, adapting to your defenses, testing your detection boundaries, and waiting for the gaps that appear when your attention is elsewhere.
Intelligence-led threat hunting starts from a question, not a calendar: given what we know about our primary adversary's techniques and their most likely course of action against our specific environment, what behavioral indicators should we be looking for that our current detections would not catch? The hypothesis is built from adversary intelligence — specific TTPs, specific infrastructure patterns, specific behavioral signatures documented in threat reporting and in your own IR data. The hunt tests whether those behaviors are present in your environment right now, whether your detections would have caught them, and whether the data you have is sufficient to answer the question. Every hunt produces one of three outputs: a confirmed threat, a detection gap, or a data gap — and each of those feeds directly back into the program.
Hunt findings that confirm a detection gap become engineering requirements. Hunt findings that reveal a data gap become log requirements. Hunt findings that confirm a threat become an incident — but also an intelligence product, because every adversary technique confirmed in your environment is ground truth about your adversary's course of action that must be immediately fed back into your detection engineering and your next round of hunting hypotheses.
The military parallel: Military intelligence does not wait for the enemy to attack before collecting intelligence. It monitors continuously for Indicators and Warnings — precursor activities that signal an adversary is preparing to act. Threat hunting is this discipline applied to enterprise security. You are looking for the behavioral signals that precede the incident — not responding to the incident after it has occurred.
Enterprise security awareness · Executive protection · Continuous monitoring · Physical security integration
It does not matter how well your systems are protected if the people who operate them are not. The adversary understood this long before enterprise security did. Social engineering — phishing, pretexting, business email compromise — remains the most reliable initial access vector not because technical defenses have failed, but because the human layer is almost never treated with the same rigor as the technical layer. Endpoint detection is tested and validated. Human detection — the ability of your employees to recognize and resist social engineering — is measured with a quarterly phishing simulation and a compliance checkbox.
Enterprise-wide security awareness is not a training program. It is a continuous capability. Employees need to understand the current threat landscape — specifically, the techniques adversaries are using right now, in your industry, against organizations like yours. They need to know what AI-generated spearphishing looks like, because it does not look like the training examples they saw three years ago. They need to understand OPSEC — what information they are making available about themselves and about your organization that an adversary can use to build a targeting profile. And they need a reporting culture: when something looks wrong, they report it immediately, without fear of embarrassment, because the cost of a missed report vastly exceeds the cost of a false alarm.
The executive layer requires a different level of rigor. Executives are not just high-value targets for phishing — they are targets for physical threat, for reputational attack, for coercive approaches. The digital footprint of a typical Fortune 500 executive is detailed enough to plan an operation against them from open sources alone: home address through property records, daily routine through fitness app data, family members through social media, travel patterns through LinkedIn. Continuous monitoring of that footprint — surface web, deep web, and dark web — is not optional for executives in high-visibility or controversial positions. A one-time assessment is a snapshot. The threat environment is continuous. The monitoring must be continuous.
The integration point: Human security and cyber security are not separate programs with separate budgets and separate teams. The adversary who cannot breach your network may breach your CFO's personal email. The adversary who cannot social engineer your SOC may social engineer your CEO's assistant. The program that protects systems but leaves people exposed has protected half of what needs protecting — and the adversary will find the unprotected half.
Purple team · Red team · Breach and Attack Simulation · Summiting the Pyramid applied to results
An annual penetration test tells you one thing: on the day the test was conducted, a team of external professionals could find and exploit these specific vulnerabilities using these specific techniques. It does not tell you whether your detections fired. It does not tell you whether your analysts executed their playbooks correctly under pressure. It does not tell you whether the adversary most likely to target you would have been caught or would have moved through your environment undetected. It is a point-in-time assessment of a dynamic environment, and the security posture it describes is outdated before the report is finalized.
Purple teaming is the discipline that answers the question the annual pentest cannot: given our specific adversary's documented techniques, do our detections fire, do our analysts respond correctly, and where exactly does our visibility fail? Red and blue work collaboratively — offense teaching defense in real time. Every technique the red team executes either fires a detection or reveals a gap. Both are valuable. Both feed directly back into the detection engineering roadmap. The output is a detection efficacy map scored against the Pyramid of Pain using the Summiting the Pyramid methodology — not a list of vulnerabilities, but a prioritized, defensible assessment of where your detection program stands against the specific adversary most likely to target you.
Breach and Attack Simulation extends this to continuous automated validation: not quarterly exercises but ongoing testing of whether your detection rules fire against specific techniques as your environment changes and as new adversary techniques are documented. When a new TTP is attributed to a threat actor targeting your industry, you should be able to test your coverage against it within days — not at next year's pentest. BAS is not a replacement for human-led purple teaming. It is the continuous layer that keeps your detection posture synchronized with the actual threat landscape between exercises.
Forensic readiness · Scope of compromise · Evidence preservation · DFIR feeding the program
Digital Forensics and Incident Response capability is built before you need it, not during the incident when it is too late. Forensic tooling pre-deployed, evidence preservation procedures documented, legal and communications protocols established, chain of custody procedures ready, and — critically — an out-of-band communication plan that does not rely on the infrastructure the adversary may be monitoring. Ransomware operators specifically target and monitor internal communications during the period between initial access and execution. If your incident response coordination happens over the email system the adversary has access to, you are coordinating your response in front of them.
The most common and most costly DFIR mistake is restoration before investigation. An organization gets hit, shuts down the affected systems, restores from backup, and declares the incident over — without understanding the scope of compromise. How long was the adversary present before execution? What other systems did they touch? Did they establish persistence mechanisms that survived the restoration? Did they exfiltrate data before executing? Were other parts of the environment compromised that have not yet been activated? Restoring without answering these questions means restoring into a compromised environment, and the adversary will be back.
DFIR findings are among the most valuable intelligence inputs the program receives. Every confirmed adversary technique becomes a detection rule. Every pivot point the adversary used that you could not see becomes a log requirement. Every gap in your visibility that allowed the adversary to operate undetected becomes a hunting hypothesis. The incident is not just a crisis to be resolved — it is an intelligence collection event about your specific adversary's behavior in your specific environment. Organizations that treat DFIR as pure crisis response and discard the intelligence leave the most valuable lessons on the table.
Forensic preservation before restoration — always: The evidence that tells you the scope of compromise exists only as long as the affected systems are preserved. Once you wipe and restore, that evidence is gone. Legal hold, regulatory reporting, insurance claims, and your own intelligence program all depend on what forensics can recover before restoration. The pressure to restore quickly is real and legitimate. The cost of restoring without understanding the scope is higher. Forensic investigation and restoration are not mutually exclusive — they are sequenced, not concurrent.
Crown jewel identification · Adversary-specific recovery · Backup isolation · Tested against real TTPs
Traditional disaster recovery planning is an IT function: define your Recovery Time Objective, define your Recovery Point Objective, test that you can restore from backup within those parameters, and document the runbook. That discipline is necessary. It is not sufficient. A DR plan that has never been tested against the actual threat — ransomware that targets backups first, wipers that propagate through your backup infrastructure, supply-chain-delivered implants that survive restoration — is a theory, not a plan.
Intelligence-led recovery starts with crown jewel identification: what are the assets — systems, data, capabilities — that if destroyed, encrypted, or exfiltrated would be existentially damaging to the organization? These are not necessarily the most expensive assets or the most regulated assets. They are the assets whose loss would most impair the organization's ability to operate, compete, and recover. Recovery prioritization is built around these assets, not around technical categories.
Backup architecture must be evaluated against your adversary's documented TTPs, not against generic DR scenarios. Ransomware operators go after backups first — specifically because they know DR depends on them. If your backup infrastructure is connected to the same network as your primary environment, an adversary who compromises your primary environment can compromise your backups. Air-gapped or immutable backups, tested specifically against ransomware and wiper scenarios, are a security requirement — not an IT preference. Supply chain compromise adds another dimension: if your backup contains a supply-chain-delivered implant, restoring from that backup reintroduces the implant. Supply chain verification before restoration is part of an intelligence-led recovery process.
Root cause before restoration is the non-negotiable sequencing principle. You do not restore until you understand how the adversary got in, what they did, and whether the initial access vector has been closed. Restoring before closing the door means the adversary can walk back in the moment your systems are back online. This is not hypothetical — it is documented in breach after breach. The pressure to restore is intense. The discipline to complete forensic investigation and root cause analysis before restoration is what separates organizations that recover once from organizations that get hit twice.
The Executive Officer equivalent · Synthesizing across disciplines · Translating between technical and leadership
A mature intelligence-led security program has nine interdependent disciplines that must be continuously synchronized. Threat intelligence feeds detection engineering. Detection gaps feed log strategy. Log strategy feeds hunting hypotheses. Hunting findings feed DFIR readiness. DFIR findings feed recovery planning. Recovery exercises feed hardening priorities. Hardening priorities feed the threat landscape assessment. The cycle is continuous and the disciplines are interdependent — a change in one propagates changes through all the others.
This program requires someone who understands all nine disciplines well enough to synthesize across them, identify when one discipline's output should change another discipline's priorities, translate between the technical teams executing each discipline and the leadership making investment decisions, and hold the program coherent as the threat landscape evolves. This is not the CISO — the CISO is accountable for the program but is too far from the operational detail to synthesize at this level. It is not a senior analyst — a senior analyst is too deep in a single discipline to see across all of them. It is a specific role that most organizations do not have a name for, and that gap is where programs break down.
In military terms, this is the Executive Officer — one level above the field operators, technically competent across all the disciplines the unit executes, responsible for ensuring the pieces fit together and the unit operates as a coherent whole rather than a collection of independent specialties. The XO does not replace the intelligence officer, the operations officer, or the logistics officer. They ensure that what each of those officers is doing is synchronized with what the others are doing, and that the commander's intent is being translated into coordinated action across all disciplines simultaneously.
Enterprise security without this role produces capable individual teams working in silos. The threat intelligence team produces excellent analysis that the detection engineering team never sees. The DFIR team finds gaps that the hunting team never hunts for. The recovery plan is built by IT without input from the security team that understands the adversary's most likely destructive technique. The validation program tests detections that have not been updated since the last threat intelligence cycle. Each team is doing good work. The program is not working — because no one is responsible for making it work as a whole.
The rarest capability in enterprise security: Technical depth across multiple disciplines, strategic thinking about how they interconnect, and the communication skills to translate between the language of security operations and the language of executive risk. This combination is rare because it requires a career path that most organizations do not deliberately build. It is also the combination that determines whether a security program performs at the sum of its parts or below it.
The adversary is not static. They adapt to your defenses, adopt new techniques, shift targets, and incorporate new tools — including AI — into their operations. A security program that was calibrated to the threat landscape six months ago is already partially obsolete. The only way to stay ahead is a program that continuously updates itself: new threat intelligence updates hunting hypotheses, hunt findings update detection rules, detection gaps update log requirements, IR data updates the threat landscape assessment, and the cycle continues.
ISAC participation and community intelligence are the external inputs that keep the feedback loop connected to the broader threat environment. Your organization's incident data is the most specific intelligence you have — but it is limited to what has happened to you. ISAC intelligence tells you what is happening to organizations like you right now, which adversary techniques are being actively deployed in your sector, and which defensive measures are proving most effective. That intelligence belongs at the beginning of the loop — and it belongs in the continuous update cycle that keeps the program synchronized with reality.