
Cybersecurity teams are under increasing pressure to detect and respond to threats faster. As attacks become more sophisticated and security teams face a shortage of skilled cybersecurity professionals, many organisations turn to a Security Operations Centre (SOC) or Managed Detection and Response (MDR) provider.
On paper, the concept is straightforward:
The SOC monitors your environment, detects threats, investigates suspicious activity and helps your organisation respond.
But there is an important question that every organisation should ask before subscribing to a SOC service:
Are you actually buying security operations, or are you simply buying security notifications?
This distinction can have a significant impact on the effectiveness of your security programme.
Imagine receiving a call from your SOC:
“We have detected a security alert on your network. Please investigate this immediately.”
The SOC has done its job — it detected something.
But what happens next?
Your internal IT or cybersecurity team may now have to determine:
Suddenly, the organisation that subscribed to a SOC service is doing much of the investigation and response work itself.
This creates a fundamental question:
If you are paying for a SOC but your internal team is still required to perform the heavy lifting, what exactly are you paying for?
A monitoring and notification service has value. But it is not necessarily the same as a true MXDR service.
A security alert is not the end of the security operation. It is the beginning of an investigation.
A mature security operation should move beyond:
Detect → Notify
and provide a more complete process:
Detect → Investigate → Validate → Contain → Respond → Remediate → Learn
This is one of the key differences between simply outsourcing monitoring and engaging an organisation that provides a genuine managed detection and response capability.
For example, if suspicious PowerShell activity is detected on an endpoint, simply sending an alert to the customer creates another task for the customer’s IT team.
A stronger MXDR approach would investigate the activity, correlate relevant telemetry, determine whether the behaviour is malicious, identify the affected assets and users, assess the scope of the incident and provide appropriate response actions.
The objective should not simply be to tell the customer:
“Something happened.”
The objective should be to help the customer understand:
“What happened, how serious is it, what is affected, what have we done about it, and what needs to happen next?”
There is another challenge that organisations need to consider: alert volume.
Modern organisations can generate thousands or even millions of security events. If a SOC relies heavily on forwarding alerts without effective prioritisation, correlation and investigation, analysts and customers can quickly become overwhelmed.
And when everything becomes an alert, nothing feels truly important.
This creates another potential risk:
Alert fatigue.
In discussions with customers, we have heard a recurring concern: they do not simply want more alerts. They want the right alerts, properly investigated and prioritised.
There is little value in receiving a large number of notifications if the important incident is buried among lower-priority events.
A SOC should therefore be measured not simply by:
“How many alerts did you generate?”
but by questions such as:
In the business world, there is often a trade-off between cost, capability and service scope.
A lower-cost SOC can certainly be attractive.
For organisations with budget constraints, a remote SOC with a highly competitive price may initially appear to provide an excellent bargain.
But cybersecurity leaders should ask a more important question:
Does the service actually support the security objective that management expects the SOC to achieve?
This is where cybersecurity managers can sometimes find themselves caught in the middle.
The cybersecurity manager requests funding from management because the organisation needs better threat detection and response.
Management approves the investment.
The SOC is implemented.
Then, if a significant security incident occurs, management may reasonably ask:
“We approved the SOC because you told us it would improve our security. Why did we still suffer a breach?”
That is a difficult question.
The answer should not simply be:
“The SOC sent us an alert.”
The organisation needs to understand whether the SOC was actually designed and contracted to perform detection only, or whether it was expected to provide investigation and response capabilities as part of an MDR/MXDR service.
The difference between these two models matters.
At UnThreats, we believe a SOC should reduce the security burden on the customer — not simply transfer the burden from one team to another.
UnThreats is an MSSP serving organisations in Singapore and Malaysia, providing MXDR services based on CrowdStrike technology.
Our philosophy is simple:
We don’t just flag the alert and leave the customer to figure out the rest.
Our role is to provide the operational expertise required to help customers understand and respond to security threats.
That means going beyond basic alert notification and focusing on the security context behind the alert.
When an incident is detected, the objective is to answer the important questions:
What happened?
Why did it happen?
How serious is it?
What systems or users are affected?
Is the threat still active?
What should be done next?
This is what we believe customers should expect when they invest in an MXDR service.
Another important difference in the UnThreats approach is our focus on CrowdStrike NG-SIEM as the core platform of our SOC operations.
Rather than operating a SOC around multiple SIEM platforms and fragmented technologies, UnThreats focuses on a unified operational model built around CrowdStrike technology and NG-SIEM.
Why does this matter?
Because operational complexity has a direct impact on SOC effectiveness.
When analysts need to work across multiple platforms, different interfaces, different detection engines and different operational processes, it can create unnecessary complexity.
A focused platform approach allows our team to standardise:
More importantly, lessons learned from one customer environment can help improve detection and investigation methodologies across the service.
A detection use case developed, tested and refined through operational experience can potentially be adapted and redeployed where appropriate for other customer environments.
This creates a continuous improvement cycle rather than treating every customer environment as an isolated SOC deployment.
An effective MXDR provider should become an extension of the customer’s security team.
Your internal IT or cybersecurity team should not have to become SOC analysts overnight simply because an alert has been escalated to them.
Instead, the SOC should provide the expertise, investigation and security context that helps the customer’s team make better decisions.
For example:
SOC:
“We detected suspicious activity on workstation ABC.”
Customer:
“What happened?”
SOC:
“Please investigate.”
SOC:
“We detected suspicious PowerShell activity on workstation ABC. Our investigation identified the affected user, process execution chain and related telemetry. The activity has been assessed as potentially malicious. We have investigated related activity and identified the affected scope. The recommended containment and remediation actions are provided below.”
The difference is significant.
In the first scenario, the SOC creates another task.
In the second, the SOC helps the customer deal with the security problem.
Cost will always be an important consideration.
Organisations have budgets. Cybersecurity teams need to demonstrate value. Management needs to understand the return on security investments.
But security should ultimately be measured against the organisation’s security objectives, not simply the lowest subscription price.
A low-cost service may provide excellent value if its scope matches your requirements.
Likewise, an expensive service may provide poor value if it generates large volumes of alerts without meaningful investigation or response.
The key question is therefore not:
“How much does the SOC cost?”
It is:
“What security outcome am I getting for the money I am spending?”
Before selecting an MSSP or MXDR provider, organisations should clearly understand:
These questions can reveal a significant difference between providers that may appear similar on a quotation.
A SOC is not simply a dashboard.
It is not simply a team that watches alerts.
And it should not simply become another mailbox that forwards security notifications to your IT department.
The real value of an MSSP or MXDR provider lies in the combination of:
Technology + People + Processes + Threat Intelligence + Investigation + Response
At UnThreats, our objective is to bring these elements together through a focused operational model built around CrowdStrike technology.
We believe customers should not have to ask:
“We received the alert. Now what do we do?”
Instead, the SOC should already be working through that question with them.
Because when an organisation invests in a SOC or MXDR service, the objective should not be to receive more alerts.
The objective is to improve security outcomes, reduce response time and reduce the burden on the customer’s internal security team.
Before signing your next SOC or MXDR contract, ask yourself one simple question:
Are we paying for monitoring, notification, or an actual security operations capability?
If your SOC identifies the problem but leaves your team to investigate, triage, isolate, eradicate and remediate everything themselves, you may be buying a notification service rather than a true MXDR service.
At UnThreats, we believe there is a better way.
Detect the threat. Understand the threat. Respond to the threat.
That is the difference between simply being alerted to a security problem and having a security operations partner that helps you deal with it.
UnThreats — MXDR powered by CrowdStrike technology.
For organisations in Singapore and Malaysia looking for an MSSP that goes beyond alert notification, the conversation should start with one question:
“What happens after the alert?”