Managed SIEM and Incident Response in Romania

What we collect and how we correlate it

A useful SIEM starts from sources, not from the dashboard. We collect logins and sudo events from your servers, application logs, requests blocked by the WAF, network events, database access, VPN connections and configuration changes. We normalise them, correlate them and map detections to MITRE ATT&CK tactics, so an alert says what was attempted and not only which log line appeared. Retention follows your audit requirements and the data stays in the EU.

• Logins, privilege escalation and new SSH keys
• Requests blocked by the WAF and abuse patterns on APIs
• Configuration changes and installed packages
• Database access and unusually large exports
• VPN connections, admin sessions and panel access

AI-assisted correlation and triage

Volume is the real problem: a few servers produce millions of lines a day, and an intruder who holds valid credentials and uses tools already installed looks like normal activity. Attackers also use AI models to automate reconnaissance and phishing, so attempts arrive more often and look cleaner. For defence we use AI-assisted correlation and triage: related alerts folded into one case, context scores and a summary of the path taken. The model proposes a hypothesis, a deterministic rule fires, and a person decides whether to isolate a server.

NIS2 deadlines and the response playbook

The response plan is written before the incident, not during it: who isolates the server, who rotates keys, where the backup is restored from, what is communicated and to whom. If you fall under NIS2, transposed through OUG 155/2024 and DNSC orders, the deadlines are short: an early warning within 24 hours and a notification within 72 hours, while non-compliance brings administrative sanctions and mandatory corrective measures. The correlated logs and timeline kept in the SIEM are exactly what a report to DNSC needs.

What the monthly hours cover

Collectors, detection rules and dashboards are requested from the DevOps Services section of the client panel. The monthly allowance depends on the plan: 1 h on cPanel from Advanced up, 1–8 h on VPS, 5–10 h on dedicated servers by plan and 10 h on GPU servers. It covers rule maintenance, noise reduction, alert reviews and one restore exercise. A major incident needs more; hours beyond the allowance are billed separately once you accept the estimate, and unused hours do not carry into the next month.

How we work

1. Request from the panel

   Request the SIEM rollout in the DevOps Services section: tell us which services you run, how long audits require logs to be kept and who receives the alerts.

2. Scoping and log sources

   We inventory the sources, agree retention, severity levels and escalation channels, and fix the delivery date you proposed.

3. Deployment and tuning

   We install collectors, write Sigma rules for your stack and tune thresholds over two to three weeks, so that alerts stay actionable.

4. Handover with runbooks

   You receive dashboards, documented rules and response runbooks, plus an exercise on a realistic scenario so your team knows every step.

Use cases

Technology stack

• Wazuh
• Suricata
• OpenSearch
• Grafana Loki
• Sigma
• Filebeat
• TheHive
• MITRE ATT&CK

Frequently asked questions

• What is a SIEM?

  A system that gathers logs from the whole infrastructure, normalises and correlates them, then raises alerts from detection rules. Without one, each server keeps its own journal and nobody sees the pattern that links them: the same IP address, the same account, the same sequence of commands.

• What is the difference between managed SIEM and a managed SOC?

  A SIEM service collects, correlates and alerts, and ours adds detection engineering and a response plan, delivered through your monthly hours. A managed SOC adds a staffed monitoring centre that triages alerts continuously. Ours is not that: we make sure your alerts are accurate and the runbook is ready.

• XDR or SIEM: which one do we need?

  A SIEM is log-centred and covers any source, including your own applications. XDR starts from agents on endpoints and servers and correlates their telemetry. On hosted infrastructure a SIEM with detection agents on the servers covers more, because it includes the WAF, databases and the network.

• Which open-source SIEM can I run?

  Wazuh covers host detection, file integrity monitoring and correlation, while Suricata adds visibility on the network. We run them on your infrastructure with OpenSearch for search and Grafana for dashboards. You remain the owner of the data and the rules, with no licence charged per gigabyte.

• How fast must I report an incident to DNSC under NIS2?

  The NIS2 regime, transposed by OUG 155/2024, expects an early warning within 24 hours of becoming aware of the incident and a full notification within 72 hours, followed by a final report. That is why we keep the timeline, evidence and list of affected systems ready in the SIEM.

• Where are my logs stored?

  On our infrastructure in the EU, at Frankfurt, under an Article 28 GDPR data processing agreement and standard contractual clauses if a transfer ever occurs. You choose the retention period to match audit needs, and access stays limited to named people.