Services / Security and hardening
Detection, edge, recoverySecurity you can operate and account for
Wazuh collects signal from hosts and applications. OpenVAS closes vulnerabilities in a backlog. Cloudflare holds the edge. Our own traffic analysis system watches the network. Dual-path backup gives recovery when the rest fails. On-call, playbook, and a change audit trail.
How it fits together
Five layers, one picture of an incident
Tools without correlation are five consoles and zero decisions. Cloudflare and traffic analysis see the edge and the network. Wazuh sees the host. OpenVAS says what can be used. Dual-path backup is the last line, independent of the same identity and network.
- OpenVAS feeds the remediation backlog and rules for detecting exploit attempts.
- A failed backup, loss of immutability, or a retention change goes to the same on-call.
A SIEM that has an owner on-call
Wazuh collects logs from systems, containers, cloud, and network devices. It watches file integrity, configuration baseline, and MITRE rules. An alert has priority, context, and a playbook, not only a syslog dump.
Sources
Agents on Linux and Windows, logs from Kubernetes, cloud trail, syslog from firewall, VPN, and from Cloudflare.
Detection
FIM, SCA, rootkit, brute force, permission change, execution outside a known path, an exploit attempt after an OpenVAS scan.
Response
Active response where it is safe. Isolation, block, artifact collection. Escalation by SLA.
Accountability
Retention, who saw the alert, what was done, when it closed. Material for ISO 27001, DORA, and internal audit.
Vulnerabilities in a backlog, not in a PDF on a shelf
Greenbone OpenVAS scans the network and hosts on a cycle, including authenticated scans. The result is a remediation queue with an owner, a change window, and verification after the patch. Critical gaps do not wait for a quarterly review.
Scope
Systems, network services, panels, databases, staging and production environments. Separate policies for DMZ and LAN.
Rhythm
A standing scan plus a scan after change and before a patch window. A rescan after closing the ticket.
Priority
CVSS together with exposure. A public origin and card data go before a host with no internet traffic.
Coupling with detection
An open gap gets a rule in Wazuh. An exploit attempt does not vanish in general IDS noise.
An edge whose origin does not expose itself
DNS, proxy, TLS, WAF, bot limits, and DDoS. The origin address stays private. Admin panels enter through Access, not through an open port. Edge logs go to Wazuh so an attack on the WAF and an attack on the host are one thread.
Exposure
Only what should be public. The rest behind identity, mTLS, or VPN. No RDP and SSH on 0.0.0.0/0.
WAF and limits
Rules for the application, not only a managed ruleset. Rate limit on login, API, and expensive endpoints.
DDoS
Layer 3 and 7 at the edge. Origin does not hold the attack. A playbook for status, communication, and DNS failover.
Zero Trust
Cloudflare Access to Grafana, cloud panels, and staging. One identity, a short session, a log of every entry.
The network has a profile. A deviation has an alert.
Cloudflare sees internet traffic at the edge. Wazuh sees a process on the host. Between them remains traffic in the LAN, between VPCs, to object storage, and to ASNs the application never calls. Our system builds a baseline per service, port, peer, and time of day.
Telemetry
NetFlow, sFlow, mirroring, eBPF where the host allows it. Without full pcap permanently, with a window capture on alert.
What we catch
Scanning, cyclic C2 calls, unusual DNS, volume exfiltration, traffic between hosts after compromise, connections outside a known contract.
Context
The alert says who, where, how much, and whether it is a known service. Not only a port number. Correlation with login, pod, and a Wazuh rule.
Boundary
This is not another SIEM. It is a network layer that feeds the SIEM. Baseline tuning is part of on-call, not a project once a year.
Two paths you can compromise separately
One backup on the same account as production will not survive ransomware or an IAM mistake. We run two paths: a copy close by, for a short RTO, and a copy outside the site, on separate accounts and keys, with immutability. Restore is on the calendar, not an assumption.
Path A
Close, fast
Snapshots and a copy in the same location or region. Short RTO, a restore test of a single system and of the whole application. A retention policy separate from path B.
Path B
Far, separate
A second provider or a second tenant. A different key, a different network, object lock or air-gap. This path does not use the same service accounts as production and path A.
Data scope
Databases, volumes, IaC configuration, secrets in vault outside the application backup, mail and files where that is part of the service.
RPO and RTO
Written per system. A backup without a successful restore does not count as a copy. The test report goes to you and to audit.
Signal
A failed job, shortened retention, lock turned off, bucket policy change. This is an alert in Wazuh, not a silent cron email.
People
Who restores, in what order, with which DNS and secret. An offline playbook, because the catalog on the same network may not come up.
Operations
From map to on-call
First an inventory of exposure, identity, and copies. Then a baseline and layer deployment. Finally a rhythm: review of alerts, scans, restore, and changes. One escalation channel.
- Map Systems, origin, panels, backup accounts, network flows, who has the key.
- Baseline Hardening, WAF, Wazuh agents, a first full copy on both paths.
- Detection Rules, noise, priorities, linking OpenVAS with Wazuh and traffic analysis.
- On-call SLA, playbooks, weekly report, and material for audit.
Talk
We will discuss exposure, detection, and restore
On that basis we will prepare a scope: layers, scan rhythm, on-call, and a restore test.
Contact us