How SOC engineers reduce the time it takes to detect cyber attacks using automation
As an organisation, how can you be sure that you are detecting cyber attacks quickly? In many real-world cases, cyber attacker have infiltrated systems months before their security team identify that they have been compromised. IBM have reported that in 2025 on average it took organisations 241 days to detect that they have been compromised. It is important for SOCs to detect attacks quickly, so they need to aim for a low Mean time to Detect (MTTD).
What is Mean time to Detect (MTTD)?
Mean time to Detect refers to the average time it takes for a SOC to detect a security incident after it happens.
A lower MTTD metric is a measure of how well a SOC can respond effectively to cyber threats since a slow response to an incident can often mean the attacker has already carried out their objective. See the following Evalian Blog going in depth about how much time matters to SOCs – SOC Incident Response: The Critical First Hour.
MTTD should not be confused with Mean time to Respond (MTTR) which is the average time it takes for the SOC to respond to a security incident.
For the MTTR to be low, the SOC needs to be able to spot the incident in the first place.
To do this, SOC Engineers need to setup the SOC environment in a way which ensures the team have a sufficient view into organisation infrastructure so the correct data can be pulled out; a broad coverage of detection rules so when an attacker makes a move anywhere in the organisation estate, it is automatically picked up and the SOC can spring into action.
Visibility into Environments
SOCs have multiple tools up their sleeve to detect active cyber-attacks against organisations and all these tools require visibility into an organisations IT environment before any alerting can start taking place.
The first step SOC engineers will take upon onboarding the SOC onto an organisation will be to conduct threat modelling against the IT architecture to understand how it works, what systems connect to where, where critical assets within that infrastructure sit. After the architecture has been the audit logs produced by important assets found will be ingested into the SIEM.
It is critical that the SOC gains the maximum amount of visibility into the organisation, if key data sources are missed then the SOC will not be able to detect attacks affecting that area of the environment. For instance, an attacker might compromise an organisations VPN and then, when inside the network, attempt to laterally move to the domain controller.
If during onboarding, the SOC missed out the logs produced by the VPN the SOC may only be detect the threat once the attacker is attempting to compromise the domain controller and by then it might be too late.
In this example the MTTD might be quite high since the security incident began once the VPN was compromised but the actual detection may have only fired much later.
Detection rule coverage
The SOC may have onboarded all the necessary log sources within an organisation’s IT environment; without having sufficient coverage of detection rules, the attackers’ actions will still go unnoticed.
As mentioned previously, conducting threat modelling on organisations is paramount in reducing MTTD. This fact remains for the creation of detection rules. When a data source is onboarded, SOC engineers will threat model that source to understand what detection rules can be created for it, using frameworks such as MITRE and STRIDE to assist in ensuring a maximum amount of coverage is achieved.
To understand more about threat modelling and how Evalian uses it to anticipate attacks, read another one of our blogs –
How automation can be used to reduce MTTD
Having a sufficient visibility into an organisation’s IT environment through an expansive level of logging as well as a good coverage of analytic rules across those log sources is a great baseline. SOC Engineers, however, can implement tooling which can assist in bringing down the MTTD even further.
Enabling incident correlation
When designing analytical rules, the analyst or engineer writing the rule must consider what entities might be able to be pulled out of the data found in the alert.
An entity in the context of detection rules is a specific asset observed in the event data which caused a detection rule to fire. This could be, for example, an IP address which was observed during a suspicious login incident or the name of the device found in a potential malware incident.
Identifying these incidents and baking them into analytical rules is incredibly important to assist in alert correlation and enrichment. See below an example from the Microsoft Sentinel UI on how you can use Sentinel to map observables (on the left) to actual variables (on the right) in your detection query.
Figure 1 – Entity list for MS Sentinel detection
When entities are added to your detection query, Sentinel as well as most other SIEM’s will group incidents together based on common entities between them. This means if your SIEM raises an alert for suspicious login to a device and soon after an alert for the same device is fired due to potential malware being found on it. The SIEM will group those two incidents together based on the device and assist the analyst in detecting the incident therefore reducing the MTTD.
Threat incident enrichment
Threat intelligence is an incredibly important tool useful to SOCs and should form the backbone of many investigations which are carried out. With entities attached to incidents it is easy for SOC engineers to build the capability to automatically enrich the incidents with details of that entity which could prove useful in shortening the time to detect a security breach. See the diagram below illustrating how this automation could flow.
Figure 2 – Workflow for Entity Enrichment for a security alert
The above workflow is achievable using Microsoft Sentinel via Logic Apps. Logic Apps can be developed further as a full SOAR capability, for example, if the above flow detects that a security alert contains a malicious IP address, it could run automated actions such as adding that IP to a block list.
All in all, this flow would reduce both the MTTD and the Mean Time to Respond, since automated actions can be completed before a Security Analyst has even picked up the incident.
Utilising UEBA
Regular detection rules will often look for static patterns of user behaviour to raise a security incident. User Entity Behaviour Analytics (UEBA) is a form of tooling used by SOCs which creates baselines of user activity, for instance, how often a user completes a certain action so that security alerts can be raised when a user’s actions deviate from their baseline.
UEBA shortens the MTTD by increasing the number of methods the SOC can use to detect malicious activity.
Automated handling of incidents to reduce load
A challenge faced by all SOCs is incident load. Security Analysts are constantly triaging security alerts and, in doing so, can fall into a pattern of assuming incidents are false positives simply because the vast majority of them are.
This is known as alert fatigue. It is the job of the engineer to try to reduce security alert load, and one method for doing this is the automatic triage and closure of non-critical security incidents.
Similar to how Logic Apps in Azure can be used to enrich security alerts, they can also make intelligent decisions based on the entities which have been observed. The flow referenced earlier, which shows how a threat intelligence process can be expanded to include automatic actions, is a good example of this.
While the example shows a basic block action, this action can be anything which reduces the required effort and therefore the time spent on security alerts by Security Analysts.
Above is a basic example of how a flow could be built to take a security alert which has been enriched with threat intelligence and then decide based on what was found within it. In the example there is a block action however this action can be anything which reduces the required actions and therefore time spent on security alerts for security analysts.
Conclusion
By building strong foundations through thorough threat modelling, comprehensive log ingestion, and broad detection rule coverage, SOC engineers give themselves the best possible chance of catching threats early.
Automation takes this further still. Through incident correlation, threat intelligence enrichment, UEBA, and automated triage workflows, SOC engineers can dramatically reduce the manual effort required to detect and respond to incidents — while also combating alert fatigue that can cause analysts to miss genuine threats. The result is a SOC that is faster, smarter, and more resilient.
At Evalian, reducing MTTD is our key focus. By continuously refining our detection coverage and investing in automation, we ensure that when a security incident occurs, we know about it as quickly as possible, giving our clients the best chance of limiting its impact.
Evalian can support your SOC
Discover how SOC teams reduce Mean Time to Detect (MTTD) through better visibility, detection coverage, automation, and threat intelligence to identify cyber threats faster.
Evalian’s SOC as a Service
