SOC analysts rarely see a cyberattack from start to finish at first glance. More often, they receive a single signal: an unusual login, a script being executed, a connection to a rarely seen IP address, or a sudden spike in data transfer. Any of these events may indicate a threat, but it may also have a completely harmless explanation. Only by putting them together can analysts determine whether they form a coherent story and what that story actually means.

From an analyst’s perspective, telemetry — the data provided by different cybersecurity systems - resembles a collection of clues. The more reliable traces are available from different parts of the environment, the greater the chance that individual observations can be combined into a coherent picture of an event. For telemetry to be useful, however, organisations need to ensure sufficient coverage of the most important areas of their environment, proper source configuration, and adequate data quality and retention. This does not mean collecting everything that can technically be collected: too much data creates noise and increases costs, while telemetry that is too limited may leave gaps that cannot be filled later during an investigation. These decisions determine whether, after suspicious activity is detected, an analyst has enough material to reconstruct what happened or is left with only a handful of disconnected fragments.

An alert - what happens next?

An alert is the starting point of an investigation. It may be generated based on a predefined rule or a known attack technique, but behavioural mechanisms also play an important role in modern EDR systems. Rather than assessing only individual events, they analyse entire chains of related activity and look for unusual behavioural patterns. The mere appearance or execution of a file does not necessarily indicate a threat. What matters is what happens next: which processes the file launches, which commands it executes, what it communicates with, and what changes it makes to the system. An alert therefore points to activity that requires attention, but it does not yet prove that a security breach has occurred.

When we analyse an alert, we first try to establish what kind of activity we are dealing with. Does the event concern a user, device, process, or service? What happened beforehand? Has similar activity appeared elsewhere? And finally, is there a legitimate business reason that could explain it?

An unusual login may indicate an account takeover, but it may just as easily result from the use of a VPN or an employee travelling. A script executed with elevated privileges may be part of an attack, but it may also be part of planned administrative work. The analyst’s task is to formulate several possible hypotheses and determine which one best fits the available data.

At SOC360, a common starting point for analysis is an alert based on metadata that is not recognised by the available Cyber Threat Intelligence sources. The absence of such recognition does not, however, mean that a file is either safe or malicious - especially since changing the metadata of modern malware is relatively easy. Each such event therefore requires individual analysis. In a process tree, for example, we may see an archive being downloaded, its contents extracted, a file executed, and an installation process started. This sequence may relate to legitimate software just as easily as to a file downloaded from an unverified source, so only further analysis of the telemetry allows us to classify the event correctly.

To determine which scenario we are dealing with, we begin by expanding the context. We check where the file was downloaded from, what user activity preceded the download, and which processes, scripts, and commands were executed during installation. The telemetry may then reveal further relevant clues, such as unusual network connections, additional scripts being launched, or further components being downloaded.

Each piece of information helps us test our earlier assumptions. Some hypotheses can be ruled out, while others require further investigation, sometimes including analysis of the file itself. Only after bringing these observations together can we determine with greater confidence whether we are dealing with legitimate software, unusual but acceptable user activity, or a genuine threat.

A good investigation starts with the right visibility

To verify hypotheses in this way, however, an analyst needs access to the right data. How much we can establish after an alert appears depends not only on our expertise, but also on which parts of the environment are being monitored and what telemetry the systems in use actually provide.

There is no single tool that can show the entire course of an attack. EDR provides visibility into endpoint activity, while NDR monitors network communications. Identity security systems provide information about accounts and authentication, while application logs show what is happening inside a particular service. Each of these system categories observes different types of activity and uses different detection mechanisms. From a SOC perspective, they are therefore complementary points of observation rather than interchangeable solutions.

This is particularly important because modern attacks are difficult to fit into a single predefined scenario. Attackers often use legitimate system components, such as LOLBins (Living-off-the-Land Binaries), RMM (Remote Monitoring and Management) tools, or other administrative software. Their use does not necessarily indicate a threat. It is often the unusual context or a sequence of related events that reveals activity requiring further investigation. This is why systems that use behavioural detection mechanisms are so important: they can identify anomalies in the way users, processes, and devices behave.

In practice, one of the biggest limitations during an investigation is the lack of a complete view of what happened. If an organisation protects its devices only with antivirus or even a next-generation antivirus solution, it may successfully block some known malicious files, but it will not have access to the detailed telemetry required to trace a more complex chain of events. Part of the story simply remains invisible.

Without EDR, it is difficult to reconstruct which processes were launched, which commands they executed, and how they related to earlier events. Similarly, NDR may identify suspicious communication, but without telemetry from the workstation or server, it may not always reveal what initiated that communication on the device.

This becomes even clearer in the case of a compromised web application, for example as a result of a WordPress vulnerability. Application logs show events taking place at the application layer, while EDR provides visibility into activity at the operating system level. Combining both perspectives gives a much more complete picture of the incident. If one of these sources is missing, a gap remains in the investigation; if both are absent, the analysis may be limited almost entirely to artefacts left behind on the machine.

At SOC360, we therefore understand visibility not as the number of deployed security products, but as the ability to examine an event from several complementary perspectives. Every unmonitored area creates a potential blind spot. In practice, a single investigation often requires moving between several such perspectives. An EDR alert may draw attention to an unusual process, NDR data may show which address the device communicated with, and an identity security system may help establish which account was used for earlier activity. Each source answers a different question, and bringing them together makes it possible to build a more reliable picture of what happened.

Simply having the right systems in place does not guarantee that this visibility actually exists. A tool may be deployed but still fail to collect part of the available telemetry, operate only on selected devices, or provide data only to a limited extent. The question is therefore no longer just “Do we have the right source?” but also “Is this source actually showing us everything it should?”

A deployed system does not always mean full visibility

Simply installing a tool does not guarantee visibility. The system must be properly configured and integrated with the rest of the environment, and then maintained in a way that ensures it actually receives the data required for analysis.

The problem does not always lie in the configuration of the security system itself. An agent may be installed on only some devices, an integration account may not have sufficient permissions, a connector may retrieve only selected categories of events, or the infrastructure may be configured in such a way that some data never reaches the tool at all. In other cases, the data is available but retained for too short a period or stored in a form that makes it difficult to correlate events from different sources. This is where organisations need to consider the balance between longer data retention and its cost.

NDR is a good example. The system itself may be deployed and correctly configured, but if network devices do not send it a copy of the relevant traffic, part of the communication remains outside its field of view. The problem may only become apparent during an incident investigation: an EDR alert points to suspicious activity on a device, so we want to examine the network context, but the relevant data is missing from the NDR system. Not because the solution is malfunctioning, but because the traffic we need to investigate never reached it in the first place.

As a result, an organisation may believe that a particular area is being monitored, while only a real investigation reveals a gap in visibility. It is like installing a security camera that works perfectly but does not cover the location that later turns out to be crucial to the investigation.

Telemetry configuration should therefore not be treated as a one-off implementation task. Environments evolve through updates, migrations, new services, and infrastructure changes. What provided sufficient visibility a few months ago may gradually begin to provide only a fraction of the information analysts need.

The most dangerous blind spot is the one no one notices

Some problems with telemetry sources are relatively easy to detect. When an API key expires, an agent stops working, or a connector loses its connection, the system may generate a technical alert. The team then receives a clear indication that visibility has been reduced.

More dangerous are failures that generate no notification at all. A source may stop sending data completely or begin sending significantly less of it, even though the integration still appears to be active. This may result from a configuration change, an update, a new event format, incorrect filtering, or a partial connection failure. In extreme cases, an attacker may also deliberately interfere with telemetry.

For an analyst, silence in the data is ambiguous. It may mean that nothing happened, but it may also indicate a loss of visibility. If an organisation does not monitor the continuity of its telemetry flows, it is easy to confuse these two situations.

At SOC360, we use our own statistical analysis engine to help detect anomalies in the way data is received. It can identify, among other things, a sudden halt in an event stream, an unusual drop in event volume, or a change in frequency compared with the source’s previous profile. This allows us to detect a problem even when the monitored system itself has not generated a technical alert.

A system will not respond on behalf of the organisation

Even a correctly deployed solution will not provide effective protection if the signals it generates are not continuously analysed and the organisation is unable to respond quickly enough.

We have encountered an organisation that came to us only after its environment had already been encrypted. It had a high-end security solution in place, but no one was monitoring it continuously, and the configured policies did not include active automated response when suspicious files were detected. As a result, simply having an advanced security tool was not enough to stop the developing attack.

Telemetry and alerts only begin to have operational value when someone can assess them correctly and translate them into action quickly enough.

From telemetry to decisions - the role of the SOC analyst

Even high-quality telemetry does not answer the question of what actually happened in the environment on its own. It provides individual traces that an analyst must connect in order to establish where the suspicious activity began, what happened next, how far the attacker progressed, and whether they managed to maintain access to the environment.

The goal of an investigation is not merely to determine whether an attack took place. We also need to answer the questions required for response: where the incident began, what its scope is, whether the attacker still has access, and what actions should be taken to stop the activity effectively and limit its impact.

This is where the value of a SOC analyst becomes clear. Security systems provide telemetry, detect anomalies, and generate alerts, but it is the analyst who connects distributed pieces of information into a coherent story and uses that story to determine what should happen next.

Will your telemetry provide the data you need when an incident occurs?

Telemetry readiness does not depend solely on the number of systems deployed. What matters most is whether the organisation has sufficient visibility, whether the sources are functioning correctly, and whether the collected data can actually be used during a real investigation.

• Does monitoring cover the most important layers of the environment: endpoints, network, identities, applications, and cloud?
• Are the sources configured to record the data required for detailed analysis?
• Do the sources complement one another so that key areas of the environment do not remain outside visibility?
• Is the data retained long enough to allow analysts to go back to the beginning of an incident that was detected with a delay?
• Does the organisation monitor the continuity of telemetry flows and know when a source has stopped sending data?
• Are alerts continuously analysed by a team that understands the environment and can reconstruct the course of an incident?
• Once a threat has been confirmed, is it clear what actions need to be taken, who is responsible for them, and how quickly they should be carried out?

The answers to these questions show whether an organisation merely owns a set of security tools or actually has the capability to observe its environment, investigate incidents, and respond to threats.

Fewer blind spots, faster decisions

Effective incident analysis starts long before an alert is generated. It requires deliberate data collection, proper source configuration, and continuous verification that telemetry is still flowing as expected. Only then can an analyst connect traces from devices, networks, accounts, and services into a reliable picture of an incident.

SOC360 combines telemetry from complementary systems with 24/7 analyst coverage and mechanisms that can also detect silent data loss. As a result, the absence of information is not automatically treated as the absence of a threat.

See how SOC360 can help your organisation reduce monitoring gaps and turn data from security systems into effective analysis and response.