SIEM: monitoring, detecting and investigating cyber threats
The job of a SIEM is not to collect logs but to turn events from across your systems into a managed detection and response process. What determines quality is neither the volume of telemetry nor the number of built-in rules.
Use cases first, logs second
We design the system from priority threats towards the data, not the other way round.
Detections that are proven
Every critical detection is tested against reproduced attacker behaviour.
A path through to response
An alert should lead to an investigation and an action, not to one more line in a log.
SIEM solutions
Hafaza Tech designs and implements SIEM built on CrowdStrike Falcon Next-Gen SIEM, Elastic Security, Positive Technologies MaxPatrol SIEM, Guardsix and Fortinet FortiSIEM.
A cloud-native platform that combines Falcon's own telemetry with data from third-party sources: ingestion and normalisation of external logs, detection, search, investigation and response automation.
Falcon Onum adds security data pipelines and federated search, which makes it possible to separate collection from analysis. We consider it first of all where a tight link between endpoint protection and SIEM matters.
For organisations with strict on-premise or data residency requirements the architecture needs to be worked through separately.
Combines SIEM capabilities with the Elasticsearch search and analytics platform. A good fit where you need diverse telemetry, flexible search, your own detection engineering, scale and control over the deployment architecture.
Runs in the cloud, self-managed and in isolated environments. Includes native workflows for triage, enrichment, case management and response.
The flip side of that flexibility: the quality of the resulting system depends heavily on architecture, data pipelines and process maturity.
An enterprise SIEM with ready-made expert content and correlation rules. The vendor supplies detection content and the related configuration, which is then adapted to the customer's infrastructure.
Worth considering for on-premise and regulated environments where a local deployment model and predictable content support matter.
The new name for Logpoint — the rebrand took place in 2026 and the products and their purpose stayed the same. The SecOps platform covers SIEM, SOAR, NDR and related capabilities.
A particular emphasis on data sovereignty. May be of interest where control over security data and over the deployment architecture is critical.
An enterprise SIEM for centralised collection, normalisation, event correlation, incident monitoring and response.
Fits naturally into a Fortinet-based infrastructure while still supporting heterogeneous sources. A full on-premise deployment with guidance on sizing, high availability and disaster recovery, as well as on running without internet access.
One organisation needs the most flexible data platform it can get, another wants detection content out of the box, a third requires a strictly on-premise architecture, a fourth a single SOC platform with XDR and automation. That is why a SIEM is chosen against the SOC operating model and the security data architecture, not against a feature matrix.
Where a modern SIEM starts
Start with detection use cases, not with connecting every log
The classic approach — connect as many sources as possible, keep everything and work out later what to look for — produces an expensive system that collects a lot of telemetry and detects almost nothing. We design a SIEM from priority use cases towards the data, not the other way round.
What actually determines quality
Whether the data specific detections need is being collected
Whether it is parsed and normalised correctly
Whether there is enough context to investigate
Whether the rules match the real infrastructure
Whether they have been tested in practice
Whether an analyst can move quickly from alert to investigation
Whether response is built into a clear SOC workflow
For priority use cases we build the chain: threat → required data → detection → investigation → response.
Telemetry and data quality
A source appearing in the list of connected systems does not yet mean it is actually working for detection. Several steps sit between «the event arrived» and «the rule fired», and any one of them can break.
Source
→
Events
→
Required fields
→
Normalisation
→
Detection
Where telemetry comes from
Identity systems, Windows and Linux, EDR / XDR, firewalls, VPN, WAF, PAM, DLP, email security, network infrastructure, cloud, SaaS, applications, databases, vulnerability management and threat intelligence.
Problems appear quietly
A source has stopped sending events
The log format has changed
The parser no longer extracts a required field
Events arrive with a delay
Part of the infrastructure is no longer covered
Timestamps or time zones are handled incorrectly
Monitoring source health
Data source health needs to be watched as closely as the availability of the SIEM itself. Otherwise the system keeps running while part of the detection logic quietly stops firing.
Parsing, normalisation and context
Different products describe the same events in different ways
That is why raw telemetry is brought into a single model: raw event → parsed fields → normalised event → event with security context. This lets detections work across different sources regardless of a particular vendor's format.
What events are enriched with
Asset criticality and its owner
Privileged user status
Network zone
CMDB data
Vulnerability information
Threat intelligence and identity context
A successful sign-in becomes considerably more significant if the account is privileged, the target is critical and the connection source is unusual. Context turns an event into a signal.
Detection engineering is where a SIEM earns its value
The process that turns a threat scenario into a testable detection.
Threat
→
Required data
→
Detection logic
→
Validation
→
Investigation guidance
→
Tuning
What a modern SIEM can draw on
Correlation, event sequences, thresholds, indicator matching, behavioural analytics, anomaly detection, machine learning, vendor detection content and your own rules.
Rule count is a weak metric
The telemetry the rules need is missing
Rules are not adapted to the infrastructure
Detections generate constant false positive noise
Nobody has ever tested them
Alerts do not give the analyst enough context
Mature detection engineering focuses on accuracy, regular validation, maintainability and the managed evolution of detection content — not on the size of the rule library.
Log coverage is not the same as detection coverage
Collecting Windows Security logs from every domain controller is telemetry coverage, but not yet the ability to detect attacks.
What has to be verified is the whole chain, not whether a source appears in the connected list. A source can be connected and events can be arriving while the field you need is never extracted by the parser. The detection will not fire, and nobody will know until an incident happens.
Detection validation
Critical detections have to be tested
The full path is checked: action → event generated → collected → parsed → detection triggered → investigation possible. The goal is to validate the whole detection chain, not the syntax of a rule.
How they are tested
Controlled simulations
Adversary emulation
Purple team exercises
Replay of historical data
BAS and test events
Penetration test findings
Action
→
Event generated
→
Collected
→
Parsed
→
Detection triggered
→
Investigation possible
Modern security data architecture
Not all data has to be physically stored inside the SIEM itself in the same way.
Modern SecOps platforms increasingly bring SIEM, XDR telemetry, investigation, SOAR and case management together. The choice therefore comes down less and less to «SIEM or XDR» and more and more to data coverage, detection coverage, investigation and response.
Investigation and threat hunting
A good detection should let an analyst move straight into investigation
Beyond automatic alerts, a SIEM has to support threat hunting across historical data. Search speed and the ease of pivoting between entities are therefore part of the security capability, not just an interface feature.
Where an analyst should land from an alert
Raw telemetry
Identity and endpoint
Target asset
Authentication history
Related alerts
Network activity and threat intelligence
Who
→
What
→
Where
→
When
→
Why suspicious
→
Related activity
From detection to action: SOAR and automation
SOAR turns the results of detection and investigation into managed response. Routine steps run automatically, while high-risk decisions stay with a human.
SOAR is increasingly not a separate system but a built-in capability of a SecOps platform. When choosing a SIEM it is therefore worth assessing not only the detection engine but also how the platform turns an alert into an action.
AI in security operations helps build search queries, summarise incidents, explain detections, assemble investigation context and speed up triage. Some platforms combine deterministic playbooks with AI reasoning inside the same response workflow. The principle stays the same: AI will not make up for missing telemetry, will not fix a broken parser and will not replace weak detection logic — it strengthens a mature process rather than creating one.
Sizing, economics and data residency requirements
Device count alone is not enough for sizing. Technically similar deployments can have completely different economics.
What goes into sizing
EPS, GB or TB per day, peak load, source types, retention, search concurrency, indexing, replication, high availability and expected growth.
Licensing model
Platforms are licensed in different ways: by ingest, by stored volume, by EPS, by compute, by node count or by other load metrics. This is worth assessing separately from the technical characteristics.
Before onboarding large sources it helps to decide: is the telemetry used for detection, is it needed for investigation, is it required for audit, is full detail necessary and how long must the data stay searchable.
On-premise and sovereign environments
Whether logs may leave the infrastructure
Where data has to be stored
Whether cloud processing is acceptable
Whether a self-hosted or air-gapped option is needed
How parsers and detection content are updated
How remote sites are connected
Platforms are therefore compared not only on detection capability but also on data sovereignty, deployment model and operational requirements.
How Hafaza Tech implements SIEM
We do not treat SIEM as a «connect every log» project. The nine stages below follow the order in which a system actually starts detecting rather than merely collecting events.
01
Assessment
02
Use cases
03
Data architecture
04
Sizing
05
Integration
06
Detection engineering
07
Validation
08
SOC workflow
09
Continuous tuning
We identify critical assets, threat scenarios, existing security controls, SOC maturity, compliance requirements and current logging. For priority scenarios we build the chain «threat → required data → detection → investigation → response».
We design sources, collectors, pipelines, storage, retention, EPS and daily volume, the deployment model, high availability and the licensing model. Not all telemetry has to be stored in the same way or directly inside the SIEM.
Sources are onboarded in stages. For each one we check completeness, parsing, required fields, normalisation, timestamps, latency and source health. Events showing up in the SIEM does not yet mean the integration is finished.
Vendor detections are adapted to the customer's infrastructure and we build our own where scenarios are missing. For every important use case we define the owner, the required telemetry, investigation guidance, the validation method and the review cadence.
Critical detections are checked on the principle: can we reproduce the behaviour → see it → detect it → investigate it. The whole chain is validated, not the syntax of a rule.
For alerts we define severity, owner, triage, investigation, escalation, response and automation. After go-live we analyse false positives, gaps in detection and data, noisy sources and analyst feedback.
CrowdStrike, Elastic, MaxPatrol, Guardsix or FortiSIEM?
A good PoC is not a dashboard demo. We pick several real scenarios and walk the full path: collect → parse → detect → investigate → respond. For example: privileged access abuse, account compromise, an endpoint attack, a firewall configuration change.
Data residency
Deployment model, cloud and on-premise constraints, data sovereignty.
Data and volume
Telemetry ecosystem, data volume, retention, search requirements.
Detection
Ready-made vendor detection content and the ability to build your own.
Response
SOAR and automation, SOC maturity, integrations.
Economics and operations
Licensing model and operational complexity.
What a good SIEM actually means
Can we see the activity that matters, do we detect meaningful attack scenarios, does the analyst have enough context, can we move to controlled response, and can we prove that this chain works.
Any other questions? We will definitely answer!
Didn't find the answer to your questions? Send your question below and our support team will answer it soon. We are here to help you with cybersecurity!
Ask a question!
Get a consultation!
If you want to learn more about our cybersecurity services or are not sure which solutions are right for you, leave a request and our specialists will contact you for a free consultation.
Related solutions
Complementary solutions for protecting the infrastructure as a whole and raising the overall level of information security.
EDR / XDR
Endpoint telemetry and response — one of the key data sources for detection.
PAM
Privileged access context for correlation and investigation.
Vulnerability & Patch Management
Vulnerability information for event enrichment and prioritisation.