Master Threat Analysis: Guide to Frameworks & Workflows
Your queue probably looks familiar. The SIEM is full, the EDR is noisy, cloud logs are late, and the ticket backlog keeps growing because every tool reports a different slice of the same event. Analysts spend more time reconciling context than deciding what to do.
That's where threat analysis stops being an abstract security term and starts becoming operational discipline. Done well, it turns disconnected signals into a defensible narrative: what happened, how confident you are, what matters now, and what action reduces risk.
For smaller SOCs, startup security teams, and mixed IT/SecOps groups, the integration problem is often a significant blocker. Recent 2025 data indicates that 68% of SMBs report silos between CTEM and SIEM/EDR as a top barrier to effective security, which makes it harder to run real-time analysis and use standards like MITRE ATT&CK and Sigma in unified workflows, according to SentinelOne's overview of threat analysis.
Table of Contents
- Beyond the Alert Tsunami
- Defining the Analyst's Craft
- The End-to-End Threat Analysis Workflow
- Mapping Analysis to Security Frameworks
- Essential Telemetry and Data Sources
- From Analysis to Action Practical Examples
- Integrating and Automating Threat Analysis
Beyond the Alert Tsunami
Organizations often don't have a visibility problem. They have a decision problem.
A mature SOC can collect endpoint logs, DNS telemetry, authentication events, firewall records, SaaS audit trails, vulnerability findings, and code scanning results. Yet analysts still get stuck because the evidence arrives in separate consoles, on different timelines, and with different schemas. One alert says suspicious process. Another says unusual login. A third says outbound DNS anomaly. Nobody has stitched them together into one attack path.
Threat analysis fixes that by adding structure. It asks four practical questions:
- What are we seeing
- How do these events connect
- What is the likely attacker objective
- What should the team do next
That sounds basic, but many SOCs still operate in a tool-first way instead of an analysis-first way. They buy better feeds, more dashboards, and more automation, then wonder why fatigue doesn't improve. The reason is simple. More signals without a method create more ambiguity.
Where teams usually break down
The failure points are usually operational, not intellectual.
- Too much isolated telemetry: Endpoint, network, cloud, and application evidence sit in separate systems, so analysts chase fragments.
- Weak triage discipline: Teams treat all suspicious events as roughly equal, which slows down response to the incidents that combine reach and impact.
- No shared language: One analyst writes "credential abuse," another writes "suspicious login," and a third maps nothing to ATT&CK at all.
- Poor handoff quality: Detection engineering, incident response, and exposure management each keep their own notes and rarely feed improvements back into one loop.
Practical rule: If an analyst can't explain an alert in terms of behavior, scope, and probable objective, the team hasn't completed threat analysis. It has only reviewed evidence.
Modern threat analysis has to live inside workflows that connect exposure management, detection, investigation, and response. That matters even more for lean teams. They don't have separate specialists for every control domain, so the workflow has to do more of the integration work for them.
What good looks like
A workable model is less glamorous than vendor diagrams. It looks like normalized telemetry, one investigation surface, portable detections, and a habit of mapping findings to open standards your team already uses. It also means accepting trade-offs. Some detections should stay broad to preserve coverage. Others should get tighter because the cost of analyst interruption is too high.
Threat analysis isn't another layer on top of the SOC. It's the discipline that lets the SOC operate with context instead of noise.
Defining the Analyst's Craft
A good threat analyst doesn't just list events. They reconstruct intent.
Think of the role less like a reporter reading back log entries and more like a detective rebuilding a sequence from partial evidence. A process started. A token was reused. DNS requests changed shape. A privileged account touched systems it usually doesn't. Each artifact matters, but the value comes from the explanation that connects them.
Threat analysis is not just alert review
Threat analysis is the process of turning technical evidence into a reasoned assessment of adversary behavior, likely impact, and next actions. That includes evaluating competing explanations, identifying confidence levels, and recommending response steps that fit the actual risk.
That's different from several adjacent disciplines that security teams often blur together.
- Threat intelligence gives you outside-in context such as adversary behaviors, infrastructure patterns, and relevant indicators.
- Threat modeling asks what could happen to a system before or during design.
- Threat hunting actively searches for hidden malicious activity that controls may have missed.
Threat analysis intersects with all three, but it isn't the same job. In practice, it often sits at the center. It uses intelligence as context, borrows modeling logic for impact thinking, and can trigger hunts when the evidence suggests broader compromise.
Threat disciplines compared
| Discipline | Primary Goal | Key Question | Timing |
|---|---|---|---|
| Threat Analysis | Explain observed activity and guide response | What happened, how serious is it, and what should we do now? | During and after observed events |
| Threat Intelligence | Provide adversary and environment context | Who is likely to act, how do they operate, and what indicators matter? | Before, during, and after incidents |
| Threat Modeling | Anticipate risks in systems and workflows | How could this system be attacked and where are the weak paths? | Mostly before deployment, then revisited |
| Threat Hunting | Search for missed or stealthy malicious activity | What hostile behavior are our controls not surfacing yet? | Proactive and iterative |
The practical test is simple. If the output is a list of indicators, that's not threat analysis. If the output is a plausible narrative with confidence, impact, and action, it is.
What analysts actually produce
Strong analysis usually produces some mix of the following:
- An attack narrative: The chain of events, not just the alert list.
- A confidence statement: How sure the team is, and what evidence could change that.
- A severity rationale: Why the incident matters based on business impact and scope.
- Response guidance: Containment, eradication, recovery, and follow-on detection improvements.
- Framework mapping: ATT&CK techniques, defensive gaps, and candidate detection content.
The analyst's job isn't to sound certain. It's to make uncertainty manageable.
That last point matters. Security teams often reward speed and confidence signals, but rushed certainty creates brittle decisions. A strong analyst is comfortable saying, "This looks like credential abuse with moderate confidence. We need endpoint process lineage and identity logs to confirm lateral movement." That's more useful than a dramatic but unsupported call.
The craft also includes restraint. Not every oddity needs a theory-heavy write-up. Real-world SOCs need analysts who know when to escalate, when to suppress, and when to watch. Good threat analysis creates focus. It doesn't create theater.
The End-to-End Threat Analysis Workflow
A repeatable workflow matters more than a brilliant analyst having a good day. When teams rely on instinct alone, quality swings by shift, by experience level, and by how tired the queue is.
The workflow below is the one that tends to hold up in real SOCs. It's not fancy. It's durable.
Scoping and collection
Phase 1 is scoping. Start by defining the incident boundary before you start pulling every available log.
Ask:
- What triggered this investigation
- Which identities, hosts, workloads, or applications are in scope
- What decision do we need to make first
Scoping keeps analysts from drowning in adjacent noise. If the trigger is suspicious authentication against an admin account, the first boundary may be identity provider logs, endpoint activity on systems that account touched, and network records tied to those sessions. It probably isn't every cloud trail event for the week.
Phase 2 is data collection. Pull the minimum evidence that can confirm or reject the first working theory.
Useful sources often include:
- Identity records: Authentication events, MFA outcomes, token use, privilege changes
- Endpoint evidence: Process trees, command execution, file writes, persistence changes
- Network telemetry: DNS, proxy, VPN, east-west flow logs, firewall decisions
- Application logs: Web access, API calls, database errors, session anomalies
The key is correlation-ready collection. Gather timestamps, asset identifiers, user context, and process lineage in ways that let you line records up later.
Analysis and enrichment
Phase 3 is hypothesis and analysis. At this stage, many teams either perform the substantive analysis or skip it entirely.
Start with a simple statement: "I believe this is X because of Y and Z." Then try to break your own theory. If you can't, your confidence increases. If new evidence points elsewhere, change the theory quickly.
For prioritization, many teams still get good results from qualitative scoring when they use it consistently. OWASP's threat modeling approach evaluates threats by damage potential and scope of impact, and organizations using likelihood-impact style matrices report a 40-60% improvement in mean-time-to-detect when analysts focus on compound threats rather than isolated indicators, according to OWASP's threat modeling process.
That matters in practice. A suspicious login by itself may not be urgent. A suspicious login plus privilege change plus unusual data access across multiple systems is a different story.
Phase 4 is enrichment and correlation. Add the external and internal context that changes decisions.
That can include:
- Asset criticality: Is the target a developer laptop or a production admin workstation?
- Identity sensitivity: Is this a break-glass account, a service account, or a low-privilege user?
- Known behaviors: Does the sequence line up with expected ATT&CK techniques?
- Historical baseline: Is this normal for this user, host, or service?
Treat enrichment as decision support, not decoration. If a data source doesn't change triage or response, it probably doesn't belong in the hot path.
Reporting and remediation
Phase 5 is containment and reporting. Good analysts don't stop at "malicious" or "suspicious."
They produce outputs that another team can act on:
- What happened: A concise attack narrative
- What was affected: Systems, accounts, data, and business function
- How confident we are: Evidence, gaps, and unresolved questions
- What to do now: Containment and remediation actions
- What to improve later: Detection logic, visibility gaps, and control changes
A useful incident report should support three audiences at once. The responder needs immediate steps. The detection engineer needs evidence to tune content. The security lead needs a defensible severity rationale.
If your workflow consistently produces those outputs, the SOC becomes calmer. Not quieter. Just clearer.
Mapping Analysis to Security Frameworks
Raw findings are hard to reuse. Framework mapping turns them into a common language that detection engineers, responders, leaders, and auditors can all work with.
That's why mature teams don't stop at "PowerShell launched a child process" or "suspicious DNS activity observed." They translate those observations into standardized behavior descriptions and then map defensive options against them.
Using ATT&CK as a common language
MITRE ATT&CK gives teams a consistent way to describe tactics, techniques, and procedures. That matters because analysts, MSSPs, and internal engineering teams often use different shorthand for the same behavior.
In day-to-day analysis, the workflow is straightforward:
- Observe behavior: Credential dumping attempt, suspicious script execution, abnormal remote service use
- Map the technique: Place the activity in ATT&CK terms
- Group by tactic: Initial access, execution, persistence, credential access, lateral movement, exfiltration
- Use the mapping: Improve reporting, pivot to related detections, and compare coverage gaps
This creates portability. A write-up that says "we observed a likely lateral movement path using remote services" is useful. A write-up that also maps the behavior into ATT&CK is easier to hand to another team using Splunk, Sentinel, Elastic, Defender, or a different MDR platform.
Using D3FEND to drive action
ATT&CK describes attacker behavior. D3FEND helps teams think about defensive measures that counter or reduce that behavior.
That pivot is where analysis becomes operational. Once you've mapped observed behavior, you can ask:
- Which telemetry should detect this earlier
- Which hardening measures reduce the path
- Which response controls can interrupt the technique
- Which deception or isolation options make sense
A practical example helps. If analysis shows repeated use of valid accounts followed by unusual remote execution, the ATT&CK side gives you a standardized description of the behavior. The D3FEND side pushes the team toward better identity controls, session monitoring, endpoint restrictions, and containment patterns that match the technique instead of just the symptom.
Good framework use doesn't make reports prettier. It makes detections reusable and response choices less arbitrary.
A mapping habit worth keeping
The teams that get value from frameworks use them lightly but consistently. They don't try to tag every line in every log. They map the behavior that explains the intrusion path and the controls that can realistically change outcomes.
A few habits help:
| Practice | Why it works |
|---|---|
| Map only meaningful behaviors | Reduces noisy tagging and keeps ATT&CK useful |
| Tie each mapped behavior to evidence | Prevents framework theater |
| Add defensive mappings during remediation | Turns analysis into control improvement |
| Reuse mappings in detection content | Helps build portable rules and dashboards |
Frameworks don't replace analyst judgment. They sharpen it. When the same intrusion pattern appears again under different tooling or in a different environment, your team can still recognize it and respond in a consistent way.
Essential Telemetry and Data Sources
Threat analysis is only as good as the evidence it can compare. Teams often talk about visibility as if more is always better. It isn't. The goal is relevant telemetry with enough context to correlate behavior across control planes.
That means choosing data sources that answer different questions. What ran. Who authenticated. What moved over the network. What changed in the cloud. What the application did. What the endpoint wrote to disk. Which DNS requests looked like command and control rather than routine resolution.
Endpoint and identity telemetry
Start with endpoint and identity data because they usually tell you the most about execution and access.
Endpoint telemetry should capture process creation, parent-child relationships, file activity, registry or persistence changes where relevant, and script execution. osquery can help with structured endpoint state and activity collection, especially when teams want portable queries across mixed fleets.
Identity telemetry is just as critical. Authentication events, failed versus successful MFA, token use, role changes, session anomalies, and administrative actions often reveal the shape of an intrusion earlier than malware evidence does. In many incidents, valid account abuse is the pivot point that connects initial access to lateral movement or data access.
For analysis, these sources answer questions like:
- Did the user really do this
- Was a privileged path involved
- Did a suspicious process follow the login
- Did the same identity touch assets outside its normal pattern
Network, cloud, and application telemetry
Endpoint data tells you what ran. Network and application data often tell you what that activity meant.
Network telemetry should include DNS logs, proxy records, firewall decisions, VPN data, and east-west flow visibility where possible. DNS is especially useful for spotting patterns consistent with tunneling or command-and-control style behavior. Proxy and firewall records help validate external reachability and sequence timing.
Cloud telemetry should include API activity, control plane changes, workload events, storage access, and configuration changes. For cloud-heavy environments, this is often where analysts find the first defensible answer to "what changed."
Application telemetry includes web server logs, authentication events, API traces, database errors, and session-level anomalies. These records are essential when investigating SQL injection attempts, privilege misuse inside apps, or suspicious access to sensitive workflows.
Technical threat intelligence becomes useful when it is correlated with those internal records, not when it is pasted into a dashboard. Organizations that combine technical threat intelligence with structured frameworks like MITRE ATT&CK achieve 35% faster incident response cycles, according to BlueVoyant's guide to threat intelligence process and technology.
What to collect first if coverage is uneven
Few teams acquire every source cleanly on day one. Prioritize based on investigation value.
- First priority: Identity events and endpoint process telemetry
- Second priority: DNS, proxy, and core firewall records
- Third priority: Cloud control plane and application authentication logs
- Fourth priority: Deeper packet or niche telemetry for targeted use cases
If you're forced to choose, choose the data that helps you connect user action, system execution, and network consequence. That triad solves more real investigations than a giant pile of low-context logs ever will.
From Analysis to Action Practical Examples
Threat analysis becomes real when you can take mixed evidence and produce a useful decision before the attacker finishes the next step.
The two examples below show how that works. They aren't vendor demos. They reflect the kind of stitched-together reasoning analysts use every day when the telemetry is imperfect and time matters.
Example one ransomware as a connected story
The first alert is easy to dismiss. A user clicks a link from email, lands on a new domain, and spawns a script interpreter from a document process. On its own, that could still be clumsy admin activity or a test file. The mistake many teams make is stopping there and waiting for a second high-confidence alert.
A better approach is to assemble the attack path immediately.
The analyst pulls:
- Email and web telemetry to verify the delivery and click chain
- Endpoint process lineage to see parent-child execution
- Identity logs to check for token reuse or privilege shifts
- Network telemetry to look for outbound callbacks and lateral movement signs
- File activity to spot staging, tooling, or encryption behavior
Within one timeline, the events now read differently. The same host launches a suspicious child process, reaches out over the network, then attempts remote execution patterns against adjacent systems. A service account is touched unexpectedly. Shortly after, file activity changes on multiple endpoints.
That is no longer "an alert." It is a likely intrusion sequence with execution, credential abuse, lateral movement, and payload preparation.
A compact analyst note might look like this:
| Evidence | Interpretation | Action |
|---|---|---|
| Document process spawns script interpreter | Likely malicious execution path | Isolate the host |
| New outbound network behavior follows execution | Possible staging or command channel | Block related communication path |
| Privileged identity touches unusual systems | Possible credential abuse | Disable or rotate impacted credentials |
| File activity spreads across hosts | Potential ransomware preparation or detonation | Segment affected systems and begin containment |
The ATT&CK mapping gives the team a stable language for reporting. The operational response comes from the analysis narrative, not from any single alert severity.
When multiple weak signals align on one host, one identity, and one time window, treat the chain as the unit of analysis.
Example two insider preparation before impact
Insider cases are harder because the behavior often looks legitimate in isolation. A user reads logs. A user checks permissions. A user browses internal docs. None of that is automatically malicious.
The signal appears in the sequence.
Suppose an analyst sees a privileged user researching security tooling, accessing log locations they don't normally touch, and then performing unusual web or file activity near a permission change. No one event justifies a major response. Together, they suggest covert preparation.
Statistical analysis helps reduce noise. Statistical analysis in cybersecurity can deliver up to 40% fewer false positives compared to traditional qualitative methods, and it can assign more precise probabilities to events such as potential compromise of an administrator account, according to SentinelOne's cybersecurity statistics overview.
That doesn't mean a model replaces the analyst. It means the SOC can score combinations of behaviors more reliably than intuition alone. For insider-style investigations, that matters because false positives are expensive. You don't want to escalate every curious admin. You do want to escalate a pattern that clusters around privilege, concealment, and timing anomalies.
Useful data in this scenario includes:
- Identity and access changes
- Endpoint command and process activity
- Log file access patterns
- Web activity anomalies
- Cross-source checks using osquery or YARA where relevant
A practical triage pattern is:
- Establish baseline variance for the account or role
- Identify sequence anomalies rather than single events
- Weight privileged context heavily
- Require corroboration across at least two telemetry types
- Use human review before disruptive action
Here's a short walkthrough that reinforces the mindset:
The response is also different from the ransomware case. You may not isolate a system immediately. You may increase monitoring, preserve evidence, restrict access carefully, and involve HR, legal, or internal investigations depending on policy and jurisdiction.
That is still threat analysis. The output isn't just a detection verdict. It's a proportionate response plan built from evidence, confidence, and organizational context.
Integrating and Automating Threat Analysis
Manual analysis is indispensable for weird cases, first-seen behaviors, and high-impact investigations. It still doesn't scale as the primary operating model.
The way forward is to automate the repeatable parts and preserve human judgment for the ambiguous parts. Most SOCs already know this in theory. The failure usually comes from automating the wrong things. They automate alert closure logic before they automate evidence enrichment. They automate ticket creation before they normalize telemetry. They automate playbooks that assume the incident is already understood.
What to automate and what to keep human
Automate the mechanics first.
- Automate enrichment: Asset criticality, user role, related alerts, recent vulnerability context, and known ATT&CK mappings should appear automatically with the event.
- Automate translation into portable content: Convert validated findings into Sigma, YARA, query packs, and correlation logic that can move across tools.
- Automate routine response actions: Disable a token, isolate a host, block an indicator, or open the right incident path when confidence is high enough.
- Automate exposure feedback: When analysis reveals a recurring weak path, feed it into CTEM workflows so the issue becomes a tracked exposure reduction task.
Keep humans on the parts that involve competing explanations, business risk trade-offs, and unusual context. A SOAR playbook can enrich an alert and quarantine a host. It shouldn't be the only decision-maker for an ambiguous insider case or a novel cloud control-plane pattern.
Automation should compress analyst toil, not compress analyst judgment.
Building a unified operating model
A unified operating model ties together CTEM, SIEM, EDR, detection engineering, and response so the output of one stage improves the next one.
In practice, that means:
| Capability | What it should do |
|---|---|
| Data normalization | Bring endpoint, network, cloud, and app records into one schema or at least one investigation surface |
| Detection portability | Let teams write or translate detections once and reuse them across platforms |
| Case correlation | Group related signals into incidents by identity, host, workload, or campaign behavior |
| Response orchestration | Trigger approved actions with clear thresholds and auditability |
| Exposure feedback loop | Turn incident lessons into hardening, validation, and control improvements |
For modern teams, open standards matter because environments are mixed and they stay mixed. Sigma, YARA, osquery, ATT&CK, D3FEND, OCSF, ECS, and NIST-aligned practices reduce the cost of moving between tools and providers. They also make your threat analysis more durable than any one product interface.
The best threat analysis capability isn't a separate tower. It's a workflow embedded into how the SOC collects evidence, scores risk, enriches context, maps behavior, and executes response. Once that loop is in place, every investigation can improve your detections, every exposure finding can sharpen your triage, and every response can leave the environment harder to attack than it was before.
ThreatCrush brings that unified model into one platform by combining CTEM, SIEM, EDR, and SOC workflows with a single agent, open standards, normalized detections, and active defense options. If you want to reduce tool silos and operationalize threat analysis across detection, exposure management, and response, take a look at ThreatCrush.
Try ThreatCrush
Real-time threat intelligence, CTEM, and exposure management — built for security teams that move fast.
Get started →