What happens in the SOC when the company is asleep?

Every day, thousands to millions of technical records are generated in a corporate environment. A firewall records a network connection. A server records a user login. A cloud service stores information about a document download. Endpoint protection monitors running processes, and the e-mail system records changes to mailbox rules. Most of these events are legitimate.

Some, however, may be the first sign of an attack. A single record is often not enough to determine whether it is normal activity, a user error, or a security incident. Meaning emerges only after multiple events are connected, placed in context, and professionally assessed. This is exactly what a SOC – Security Operations Center, or security operations center, is for.

What is a SOC

A SOC is a combination of people, processes, and technologies designed for continuous security monitoring, threat detection, investigation of suspicious events, and coordination of incident response. It is not merely a room with screens or a single software tool. The operation of a SOC includes in particular:

Area	SOC role
Monitoring	Monitoring security events
Detection	Identifying suspicious behaviour
Analysis	Verifying the scope and severity of the event
Response	Containing the attack and coordinating measures
Investigation	Determining the cause and course of the incident
Improvement	Adjusting rules based on new findings

 

A security operations center therefore does not merely monitor whether a tool has issued an alert. It assesses what the alert means in the context of a specific organization.

An attack can begin with an inconspicuous event

A serious incident does not have to begin with an immediate system outage or a ransom note on the screen. The first sign may be, for example:

• a login from an unusual location,
• the launch of a non-standard process,
• a device communicating with a risky domain,
• the creation of a new administrator account,
• a change to e-mail mailbox rules,
• unusual data downloading,
• or repeated unsuccessful access attempts.

Each event on its own may have a legitimate explanation. An employee may be travelling. An administrator may be changing the configuration. After an update, an application may communicate with a new service. The security significance therefore often becomes apparent only when several signals are combined.

For example:

Time	Event
01:14	Login from a new device
01:18	Creation of an e-mail forwarding rule
01:26	Access to financial documents
01:39	Download of an unusual volume of data
01:47	Attempt to access administration

 

An isolated login may not be an incident. Combined with other activities, however, it may indicate a compromised account. This is precisely why it is not enough merely to store security records. They need to be connected, evaluated, and compared with the normal behaviour of users and systems.

1. Security events are collected from various sources

A SOC needs visibility across the corporate environment. Security data may come, for example, from:

• firewalls,
• servers,
• workstations,
• cloud services,
• identity management systems,
• e-mail platforms,
• VPN or remote access,
• databases,
• applications,
• manufacturing and OT systems.

The centralization and correlation of these events is typically handled by SIEM – Security Information and Event Management. SIEM collects records from different sources, normalizes them, and uses rules or analytical mechanisms to look for suspicious combinations. For SIEM, ANASOFT highlights centralized monitoring, event correlation, historical analysis, and integration with existing security tools.

SIEM and SOC are not the same thing. SIEM provides data, correlations, and alerts. SOC provides the people and processes that evaluate them and respond to them.

2. A detection rule generates an alert

When a system identifies activity that matches a configured rule or an unusual pattern, it generates a security notification – an alert.

This may include, for example:

• logins from geographically distant locations within an impossible timeframe,
• a large number of unsuccessful login attempts,
• the launch of a risky tool,
• the disabling of security protection,
• an unusual change in permissions,
• communication with known malicious infrastructure,
• or behaviour typical of ransomware.

An alert, however, does not automatically mean a confirmed incident. Security tools may also detect legitimate administrative activity, testing, or non-standard but authorized activity. The analyst's first task is therefore not to raise the alarm. It is to determine whether the alert represents a genuine risk.

3. The analyst performs an initial assessment

The initial review is often referred to as triage. The analyst assesses in particular:

• what triggered the alert,
• which user or device it concerns,
• whether the activity matches normal behaviour,
• which systems may have been affected,
• whether there are other related events,
• and what the potential impact may be.

The result may be one of three basic decisions:

Result	Meaning
False positive	The activity is legitimate
Suspicious event	Further investigation is required
Incident	There is a confirmed security risk

 

The organization's context plays an important role.

The same event can have a different meaning in two companies. The use of a remote administration tool may be a routine part of support in one company, while in another it is a technology that should not be present on any device. A SOC therefore needs to know the protected environment, critical systems, user roles, and normal operating scenarios.

4. Events are connected into the story of an attack

Individual technical records usually do not describe the entire incident. The analyst therefore looks for answers to questions such as:

• Where did the attack begin?
• Which account or device was compromised?
• How did the attacker move further?
• What permissions did the attacker obtain?
• Which data did the attacker access?
• Is the activity still continuing?
• Which other systems may be at risk?

The result is a timeline of events. For example:

1. the user opened a phishing link,
2. the login credentials were submitted to a fraudulent website,
3. the attacker logged in to the e-mail account,
4. created a rule to hide or forward messages,
5. searched for communications with suppliers,
6. attempted to change payment details.

Such a scenario shows why phishing cannot be viewed merely as an e-mail filter problem. The article Phishing no longer looks like phishing: How AI is changing fraudulent e-mails explains how more convincing communication increases the likelihood of identity compromise.

5. The incident is prioritized according to risk

Not every incident requires the same response. Priority is influenced, for example, by:

• the criticality of the affected system,
• the permissions of the compromised account,
• the type of data being processed,
• the scope of the activity,
• the attack's ability to spread,
• the potential impact on operations,
• and the analyst's confidence that it is a genuine incident.

Compromise of a test account with no access to sensitive data has a different significance from compromise of an administrator identity that manages the cloud, user accounts, or backups. This is why a risk-based approach is important in a SOC. The goal is not to address all alerts in the same order. The goal is to identify as quickly as possible the events that may cause the greatest damage.

6. Incident containment begins

Once an incident is confirmed, the next objective is to prevent it from continuing or spreading. Depending on the type of situation, the response may include:

• blocking a user account,
• terminating active sessions,
• resetting authentication credentials,
• isolating a device from the network,
• blocking a malicious domain or IP address,
• stopping a suspicious process,
• revoking permissions,
• or temporarily restricting a specific service.

Some measures can be automated. Others require a decision by an analyst, administrator, or system owner. Speed, however, must not completely replace context. Incorrectly isolating a critical server can itself cause an operational problem. A SOC therefore needs clear rules, responsibilities, and escalation procedures.

7. The company receives information it can act on

A security alert without context may look like this:

Suspicious activity detected. Severity: High.

Such a message on its own does not provide enough information to make a decision. High-quality incident communication should explain:

• what happened,
• who or what the incident concerns,
• why the activity is suspicious,
• what the possible impact is,
• what has already been done,
• and what further steps are required.

For example: A login from a new device was recorded on a finance user's account, followed by the creation of an external e-mail forwarding rule. Active sessions were terminated and the account was temporarily blocked. Recent changes to payment details need to be verified and the user's authentication mechanisms need to be reset.

The difference between these two messages illustrates the difference between an alert and a processed security incident.

8. The response does not end when the attack is blocked

After the active threat has been contained, the investigation continues. It is necessary to determine:

• how the attacker gained access,
• how long the attacker was present in the environment,
• which systems and data may have been affected,
• whether the attacker created additional accounts or access paths,
• whether the attacker left a mechanism for returning,
• and whether there are other compromised devices.

If only the visible consequence is removed, but not the root cause, the incident may recur. In the case of a compromised account, changing the password may therefore not be enough. It may also be necessary to:

• terminate all active sessions,
• check registered MFA methods,
• review delegated permissions,
• check e-mail mailbox rules,
• analyze access to other services,
• or check the user's device.

The article MFA is not always enough: Which authentication methods are more resistant to phishing follows on from protecting accounts against phishing and compares SMS, OTP, push notifications, and phishing-resistant authentication.

9. New detection rules emerge from an incident

Every incident can improve future protection. After it is resolved, it is possible to adjust:

• detection rules,
• threshold values,
• lists of risk indicators,
• response scenarios,
• access policies,
• or the way security data is collected.

For example, if an attacker used a new method to create a hidden e-mail rule, the SOC can add detection for similar behaviour for other users as well. If an alert repeatedly occurs during legitimate activity, the rule can be refined and the number of false positives reduced.

A SOC is therefore not static oversight. Detection must be continuously adapted to:

• changes in infrastructure,
• new applications,
• new types of attacks,
• and lessons learned from the organization's own incidents.

Why sending alerts by e-mail is not enough

A company can have high-quality security technologies and still lack effective security monitoring. A problem arises when alerts:

• arrive in a general mailbox,
• are not monitored by anyone outside working hours,
• have no clear owner responsible for reviewing them,
• contain too little context,
• or are so numerous that a serious incident gets lost among them.

This phenomenon is known as alert fatigue – fatigue caused by an excessive number of alerts. If an analyst or administrator receives hundreds of low-information-value alerts every day, the likelihood of giving each of them appropriate attention gradually decreases. A SOC should therefore do more than merely receive alerts. It needs to:

1. filter out noise,
2. connect related events,
3. set priorities,
4. add context,
5. and ensure a response.

Why continuous monitoring is important

An attacker does not necessarily wait deliberately for night-time. An incident can arise at any time. Cloud services, e-shops, remote access, manufacturing, or logistics systems operate even when internal IT is not fully staffed. If suspicious activity appears on Friday evening and is not reviewed until Monday morning, an attacker may gain dozens of hours to:

• move between systems,
• gain higher privileges,
• search for sensitive data,
• disable protection,
• or prepare the destructive phase of the attack.

Continuous monitoring does not promise that every incident will be stopped immediately. It does, however, shorten the time between the first detectable signal and the start of the response. Missing or insufficient monitoring is among the weaknesses that can allow a problem to remain unnoticed. The broader context of layered protection is discussed in the article How to keep your corporate infrastructure from being hacked.

A SOC does not only monitor external attackers

Suspicious activity does not have to come exclusively from outside. A SOC can also help detect:

• misuse of legitimate permissions,
• unintentional handling of sensitive data,
• a compromised internal account,
• unauthorized tools,
• or non-standard behaviour of a device inside the network.

This does not mean, however, that every unusual employee activity represents an intentional insider threat. An account may have been taken over by an attacker. A user may have made a mistake. A change may have been legitimate but incorrectly documented. The analyst's task is to distinguish between these scenarios based on the available data and context.

This is also why security cannot be built solely on the assumption that the internal environment is automatically trustworthy. The article Zero Trust security: What it means and why companies need it discusses continuous verification of identity, devices, and permissions in more detail.

SOC, SIEM, and security tools are not synonyms

These terms are often used together, but they refer to different layers.

Term	Main role
SIEM	Collection and correlation of security events
EDR	Detection and response on workstations and servers
Firewall	Control and protection of network communication
SOC	People and processes that evaluate and address events
Incident response	Organized response to a confirmed incident

 

A SOC can use SIEM, EDR, firewalls, and other sources. However, simply owning these tools does not guarantee that a company has:

• relevant detection rules configured,
• continuous monitoring,
• trained analysts,
• clear escalation procedures,
• or prepared response scenarios.

Technology creates visibility and response capabilities. The operating model determines whether these capabilities are actually used.

Which companies need a SOC

The need for security monitoring is not determined solely by company size.

What matters in particular is:

• the value of the data being processed,
• the criticality of operations,
• the accessibility of systems from the internet,
• the number of devices and users,
• use of the cloud,
• the number of external access points,
• regulatory requirements,
• and the internal team's ability to respond outside working hours.

A smaller company may have a relatively simple environment but process sensitive financial or health data. A manufacturing company may have a limited number of users, but a system outage can stop operations. An e-commerce company may depend on the continuous availability of applications and payments.

What a company needs to have prepared for a SOC to work

Even a high-quality security operations center cannot effectively protect an environment about which it does not have enough information. Before or during the engagement of a SOC, it is necessary to define in particular:

Area	Required information
Critical systems	What must remain available
Important data	Which information has the highest value
Contact persons	Who makes decisions during an incident
Responsibilities	Which measures can be taken immediately
Operational exceptions	Which unusual activities are legitimate
Escalation	When and to whom an incident is reported

 

With no such information, an analyst may identify a technical anomaly but may be unable to assess its business impact or choose an appropriate response. A SOC is therefore not an external service separated from the company. It is part of a broader security management process in which responsibilities must be clearly divided among analysts, IT, management, and system owners.

The most common misconceptions about a SOC

“If we have a SOC, an attack cannot succeed”

A SOC reduces the time needed for detection and response. However, it cannot guarantee that every attack will be stopped before it has any impact.

“A SOC monitors people”

A SOC analyzes security events and the behaviour of accounts or devices. The goal is to identify risk, not to evaluate employees' work performance.

“It is enough to connect the logs”

Collecting data alone is not enough. Relevant rules, context, prioritization, and response procedures are required.

“Internal IT has to handle all alerts”

The role of a SOC is to filter out some of the noise, review events, and provide the company with actionable information.

“A SOC is only for large corporations”

What matters is risk, the criticality of operations, and internal capacity, not only the number of employees.

A SOC does not make security a flawless system

Cybersecurity cannot rely on a single technology or a single team. A firewall can block an attack. MFA can make account takeover more difficult. EDR can isolate a device. SIEM can connect events from multiple systems. A SOC ensures that these signals are assessed in context and that a confirmed incident leads to a specific response. The role of a SOC is therefore not to create the impression that an attack is no longer possible.

Its role is to reduce the likelihood that suspicious activity will remain unnoticed long enough to develop into a large-scale incident. Common shortcomings, such as missing processes, insufficient monitoring, or reliance on isolated measures, are also discussed in the article The 5 most common IT security mistakes companies make.

When the company sleeps, security events continue

A security operations center does not assess only individual alerts. It connects events in context, distinguishes legitimate activity from a genuine threat, sets priorities, and coordinates the response. The result should not simply be a greater volume of technical data. It should provide answers to practical questions:

• Is anything dangerous happening in the corporate environment?
• Which systems or accounts are at risk?
• Is the attack continuing?
• What impact could it have?
• What needs to be done now?

It is precisely the ability to answer these questions that distinguishes security monitoring from the mere collection of logs.

Continuous monitoring has value only when it leads to a response

Technical tools can alert you to suspicious activity. Real protection, however, emerges only when an event is assessed in time, placed in context, and turned into a specific course of action. Before implementing or expanding security monitoring, it is therefore necessary to evaluate:

• which systems and data are critical,
• which events are currently being collected,
• who reviews the alerts,
• what the procedure is outside working hours,
• and which responses can be carried out without unnecessary delay.

ANASOFT provides security monitoring through a Security Operations Center that combines continuous monitoring, security event analysis, and incident response.

Frequently Asked Questions