Threat modelling in a SOC context: how to anticipate attacks

Modern security operations generate huge volumes of alerts, logs and telemetry. But volume alone doesn’t guarantee visibility. Many organisations assume their monitoring will detect malicious activity, yet when incidents occur, it often becomes clear that the right evidence was never captured in the first place.

Effective security monitoring requires a clear understanding of how an environment could realistically be attacked and whether the systems in place would detect those behaviours. Without that perspective, monitoring risks becomes reactive and unfocused, generating noise rather than meaningful security insight.

In this blog, we explore how threat modelling helps address that challenge. We explain how it is applied within a Security Operations Centre (SOC), how frameworks such as STRIDE help structure threat analysis, and how credible attack scenarios are translated into practical SIEM detections. We also look at how this process is used during customer onboarding to validate log coverage and ensure monitoring is aligned to real attack paths rather than assumptions.

What Is Threat Modelling?

Most security teams focus on responding to alerts after something suspicious has already happened. Threat modelling takes a more proactive approach. It’s the process of anticipating how an attacker could compromise an organisation before they try. In a SOC, it means looking through an attacker’s lens and asking questions: 

• If credentials were stolen, what would happen next? 

• If privilege was abused, would we detect it? 

• If someone moved laterally, what evidence would exist? 

It shifts security operations from passively monitoring logs to deliberately validating that the attack paths that matter are visible and defensible.  The real risk isn’t that the logs don’t exist, it’s that the logs don’t actually prove anything. 

Threat modelling in a SOC context

In a SOC, threat modelling is a practical way to anticipate how attackers might target a customer’s environment. It involves analysing systems and attack paths to identify where an adversary could gain access, move laterally, or achieve their objectives, and then building detections around those scenarios in advance. Threat modelling is typically performed through three different methods: 

Architectural: This refers to threat modelling the network architecture, identifying how systems integrate with each other and understanding network and trust boundaries. 

Configuration: Ensuring systems are configured correctly with sufficient access controls so people can access the resources that they need. 

Log Source: This is the threat modelling that Evalian performs, analysing each log source to determine high impact actions and identify likely attack paths that an attacker will take. 

This type of threat modelling enables our SOC to align detection engineering to realistic threats and the nuances between the same log source of different customers, rather than a “one-size-fits-all” approach. During this process, high-impact assets and processes alongside critical systems are prioritised to ensure full coverage. 

Why STRIDE for SOC threat modelling

To structure our analysis, we use the STRIDE methodology. STRIDE provides a systematic way to evaluate different types of threats across systems and data flows, ensuring we don’t overlook common attack patterns. The STRIDE model covers six core threat categories: 

• Spoofing – Identity abuse 

• Tampering – Data integrity 

• Repudiation – Accountability gaps 

• Information Disclosure – Confidentiality exposure 

• DoS – Service disruption 

• Elevation of Privilege – Privilege escalation 

By following this model, it encourages the SOC to perform structured thinking across identities, data flows, applications and infrastructure; mapping cleanly to detection use cases and SIEM rule development. The resulting threat scenarios inform the creation of high-fidelity SIEM detections, where alert logic is aligned to behaviours that strongly indicate malicious or suspicious activity. 

Using threat modelling during customer onboarding

Threat modelling begins at onboarding. As soon as a new customer or log source enters the pipeline, we assess the environment through an attacker’s lens. While logs are being ingested and normalised, we analyse the architecture, trust boundaries, privileged roles, critical assets, and data flows to understand how the environment could realistically be abused. 

This allows us to identify credible attack paths before they are exploited. Log ingestion becomes intentional rather than volume-driven; we validate that the telemetry required to detect high-risk behaviours exists, and where gaps are identified, they are addressed early through additional logging, new data sources or compensating controls. 

The result is detection engineering aligned to realistic threat scenarios from day one — not generic, broad rules, but context-aware detections tailored to the customer’s environment and designed to produce high-fidelity alerts tied to meaningful risk. 

Mapping threat models to log coverage

A threat model is only valuable if it translates into measurable visibility. Each identified attack scenario is mapped to the telemetry required to detect it – brute-force activity to authentication logs, malware execution to endpoint telemetry, privilege escalation to identity and audit logs. By explicitly linking attacker techniques to specific log sources, we create traceability between credible threats and the monitoring controls designed to detect them. 

This process frequently exposes logging gaps during onboarding. Administrative actions may not be captured, endpoint telemetry may lack critical detail such as command-line arguments, or SaaS platforms may provide insufficient audit depth to deliver meaningful security value. Identifying these deficiencies early prevents investigative blind spots later, where malicious activity may have occurred but cannot be reconstructed due to missing evidence. 

Ensuring monitoring is risk-driven rather than volume-driven. Collecting more logs does not automatically improve detection; telemetry must demonstrate security value. Detection engineering is therefore focused on behaviours that materially increase organisational risk, reducing unnecessary noise and improving signal quality. The outcome is a structured, defensible monitoring strategy aligned to credible attack paths – not reactive alert generation. 

From threat models to KQL threat detections

Once credible attack scenarios are identified and the required telemetry validated, the next step is to convert them into actionable detection logic. This is where threat modelling moves from theory to measurable protection. Adversary behaviours are decomposed into specific, observable events within available data sources and aligned to recognised tactics and techniques using frameworks such as MITRE ATT&CK, ensuring detections are structured and mapped to the broader threat landscape.  

Rather than attempting to detect abstract concepts such as lateral movement or privilege escalation, we break these techniques down into observable system-level behaviours. For example, lateral movement may translate into remote authentication events between hosts, unusual service creation, or suspicious use of administrative tools. Privilege escalation may surface as role assignment changes, token manipulation activity, or abnormal parent-child process relationships. By grounding each technique in queryable telemetry, detection logic becomes precise and testable.  

Tuning is built into development from the outset. Baseline behaviour is assessed to separate legitimate administrative activity from genuinely suspicious patterns, and environmental context – such as known service accounts or approved automation workflows – is incorporated to reduce false positives without weakening coverage. The objective is not to generate more alerts, but to produce high-fidelity detections that meaningfully indicate malicious behaviour while remaining sustainable for the SOC. 

Real-world examples of threat modelling in action

Threat modelling delivers the greatest value when applied to real customer environments rather than theoretical architectures. In practice, it has repeatedly exposed detection gaps that were not covered by default or in-built SIEM rules. While many platforms provide generic detections for common threats, they rarely account for customer-specific systems such as bespoke SaaS applications or internally developed tools. 

The following example shows a detection created through threat modelling of Google Workspace. The following spoofing scenario, where an attacker has successfully logged into a victim’s account from a different IP to usual, followed by a password change, is a strong indicator of compromise which would not be detected without a customer query. 

This query detects Google Workspace logins from IP addresses a user hasn’t used in the past 14 days and then checks whether that login is followed by a password change within one hour. It’s designed to identify potential account takeover activity, where an attacker logs in from a new location and quickly changes the password to establish control. 

Why threat modelling matters for our clients

Threat modelling shifts security operations from reactive monitoring to deliberate defence. Instead of relying on default alerts or assumed coverage, it provides clear visibility into what is being monitored, why it is being monitored, and how that monitoring aligns to genuine business risk. 

By mapping credible attack paths to real telemetry and detection logic, we ensure monitoring is intentional and defensible. Detection coverage is tied directly to high-impact behaviours – not log volume, not generic rule sets, and not theoretical threats. Customers gain clarity that identity compromise, privilege escalation, abuse of critical applications and other material risks are not just logged, but actively detectable in practice. 

Most importantly, threat modelling replaces assumptions with validation. Rather than believing protection exists, we test whether it does. The result is a proactive, risk-driven security posture that delivers measurable protection, higher signal quality and greater confidence at the leadership level. 

Threat modelling with Evalian

Security monitoring is only effective if it can detect the attack paths that matter. Threat modelling allows organisations to validate that their logging, telemetry and detections actually provide visibility into real threats.

If you want to understand whether your current monitoring would detect a genuine compromise, Evalian’s security specialists can help. We assess attack paths, validate telemetry coverage and design high-fidelity detections aligned to your environment.

Speak to our team to review your detection capability and strengthen your security monitoring strategy.