An employee signs in to Microsoft 365, a laptop connects to an external server and an administrator account makes a change. These are normal events in themselves. But what if the sign-in comes from an unusual location, the laptop starts behaving suspiciously shortly afterwards and the administrator account then grants new permissions?
The individual systems may each generate an alert. The question is whether anyone recognises the connection and assesses what is happening in time.
Security monitoring is therefore about more than collecting security alerts. It is about recognising potential threats, investigating suspicious activities and ensuring that relevant signals are actually acted upon.
Security products do not automatically provide an overview
Many organisations have several security measures in place. Firewalls monitor network traffic, endpoint protection checks workstations and servers, and identity platforms record sign-ins and changes to access rights.
Each system has its own perspective. A firewall may see a connection to an external address, for example, but does not always know which user initiated it. An identity platform records a suspicious sign-in, but may have no visibility of what happens on the workstation afterwards.
When security information is only examined within individual systems, important connections may go unnoticed. Security monitoring brings relevant signals together so that events can be assessed in context.
The aim is not to collect as much data as possible. The aim is to identify the signals within that data that actually deserve attention.
Which signals matter?
The information needed depends on how the IT environment is configured and the risks facing the organisation. Even so, several sources play an important role in many businesses.
Identities and access
— Unusual sign-ins, failed login attempts, changes to permissions and activities involving administrator accounts.Workstations and servers
— Suspicious processes, possible malware, anomalous behaviour and alerts from endpoint protection.Network and connections
— Unusual network traffic, suspicious external connections and security alerts from firewalls and other network systems.Cloud and business applications
— Changes to security settings, unusual data activity and events within critical applications.
Not every source needs to be monitored in the same way. A production environment with business-critical systems calls for different priorities from an organisation that works almost entirely in Microsoft 365. What matters is that the chosen monitoring reflects the actual IT environment and the impact an incident could have on business operations.
From isolated events to a recognisable pattern
An individual security alert does not always tell the whole story. Some events are entirely legitimate, while others only become suspicious when considered alongside earlier activities.
A sign-in from abroad may be explained by an employee travelling, for example. But if that same sign-in is followed by changes to security settings and the downloading of large amounts of data, a different picture emerges.
Connecting events from different sources can reveal patterns that would not be recognised within a single system. Both automated detection rules and expert assessment play a part in this.
In practice: three signals that deserve attention together
An account is being used while the employee is simply doing their work
An employee is working in the office and using the usual business applications. Meanwhile, an attempt is made from an unknown location to access the same Microsoft 365 account. Shortly afterwards, the identity platform records a successful sign-in and a new sign-in method is added.
Individually, these events could have various explanations. Taken together, however, they indicate that an unauthorised person may have gained access.
An investigation establishes that the employee did not carry out the sign-in or the change. Active sessions are terminated, the unauthorised sign-in method is removed and the account's security is checked again. An investigation then examines whether data has been accessed and how access may have been gained.
Without coordinated monitoring, the employee would probably not have noticed anything. After all, the business applications continued to function normally.
This is an illustrative example, not a description of a specific customer incident.
What do SIEM, SOC and MDR mean?
Several terms are used in security monitoring that are often confused with one another. They do not, however, describe the same thing.
SIEM: technology for collection and analysis
A Security Information and Event Management (SIEM) solution collects and analyses security data from different sources. The system helps to correlate events, flag anomalies and enable investigation.
A SIEM is a tool. Having one does not automatically mean that alerts are assessed or incidents are followed up.
SOC and MDR: people, processes and services
A Security Operations Centre (SOC) is the function or team that assesses security signals, carries out investigations and coordinates follow-up. This can be organised internally or outsourced.
Managed Detection and Response (MDR) is a service in which a specialist provider handles detection, analysis and often response activities as well. The precise scope varies between providers.
These concepts complement one another. A SOC may use a SIEM and other detection platforms, for example. An MDR service may take over parts of monitoring and response. The appropriate arrangement depends on the size of the organisation, the risks, the expertise available and the required availability of those responsible.
Not every alert is an incident
Security systems can produce many alerts. These include activities that subsequently turn out to be harmless, such as legitimate administrative tasks, software updates or unusual but permitted work.
An alert must therefore be assessed before conclusions are drawn. This includes considering the reliability of the signal, the user or systems involved, the potential consequences and the presence of additional indicators.
An effective monitoring approach prevents employees from being overwhelmed by warnings without clear priorities. Critical signals need prompt attention, while less urgent events should be handled appropriately.
Automation can help to enrich alerts and perform recurring tasks. Even then, however, the rules and authority to act must be clear. Automatically blocking an account or isolating a system can, after all, affect business operations.
Detection requires organised follow-up
An alert only has value when it is clear what happens next. This requires agreements on assessment, escalation and authority to act.
Detect
— Security systems record events and recognise activities that may indicate a threat.Assess
— The alert is investigated, supplemented with information from other sources where needed and classified by urgency.Escalate and intervene
— If an incident is suspected, those responsible are involved and appropriate measures are taken to limit the risks.Evaluate and improve
— The findings are used to improve detection rules, security measures and working arrangements.
Availability also matters here. A serious incident can occur outside office hours. Organisations therefore need to know when monitoring takes place, which alerts are addressed immediately and who is authorised to take action.
Monitoring during office hours differs from a service that assesses signals around the clock. Both may be appropriate, but the difference must be clear and reflect the risks the organisation is willing to accept.
Who makes the decision during a security incident?
An external security specialist may recognise an attack and recommend blocking an account or isolating a system. But such a measure can also interrupt business processes.
It is therefore necessary to agree in advance which actions may be carried out independently and when permission or consultation is required. Some threats justify immediate intervention. In other situations, the consequences of a measure must be established first.
The technical analysis may be handled by an IT administrator or security partner, but the organisation remains involved in decisions that affect its business operations. Good security monitoring therefore requires clear responsibilities as well as technical knowledge.
Security monitoring is no substitute for sound security
Monitoring helps to recognise suspicious activities, but does not automatically prevent vulnerabilities from being exploited. It therefore remains necessary to update systems promptly, restrict access rights, protect endpoints and configure the network infrastructure carefully.
It must also be clear which systems are actually included in monitoring. If important servers, cloud applications or identity systems remain out of view, relevant events may be missing. A central dashboard only provides a reliable picture when the underlying sources offer sufficient coverage.
Security monitoring therefore complements preventive security measures rather than replacing them.
From security alerts to real insight
An organisation does not need to be able to assess every technical detail of its IT environment itself. It does, however, need to be able to rely on an approach in which relevant security signals are recognised, assessed by experts and acted upon where necessary.
This requires appropriate technology, sufficient visibility of the IT environment and clear agreements on responsibilities and follow-up.
Ultimately, the value of security monitoring is not determined by the number of alerts collected or the number of dashboards available. Its value lies in the ability to recognise in time when something is going wrong and then take targeted action.
