One security platform
Helxis HEDE brings every security module onto one platform: from endpoint protection and endpoint detection and response to estate-wide event collection, correlation, extended detection and data protection. One data model, one console, one incident queue — what the endpoint saw is joined here to what the estate saw.
Endpoint security, EDR, XDR, DLP and SIEM are not five products competing for one budget. Each name says where a defence sits and which question it answers. Reading them as alternatives is the shortest route to paying twice for one capability and leaving another uncovered entirely.
Endpoint security is the pair that lives on the machine itself. EPP judges files on the machine itself and stops what it finds: a file is checked when it is written and when it is launched, and on Linux the verdict is reached before the process starts. An attack stopped here leaves little damage behind to investigate. EDR assumes something already ran, and keeps the record that can answer what it did — which process started which, what it wrote, where it connected.
| Discipline | What it watches | The question it answers |
|---|---|---|
| EPP — endpoint protection | The file, when it is written and launched | Should this file be allowed to run? |
| EDR — detection and response | Processes, memory and connections on the machine | What happened on this host, and who started it? |
| SIEM — event management | Logs from every source in the estate | What did the whole estate see? |
| XDR — extended detection | Endpoint, identity and network signals together | Is this one attack, or separate incidents? |
| DLP — data loss prevention | The movement of sensitive data | Where is this data going, and should it be? |
HEDE stands for Helxis Endpoint Defense Engine. All five modules are parts of one platform: one data model, one incident queue, one console — so a process on the endpoint and an authentication in the estate meet on the same screen. Modules are enabled per deployment: a customer starts with what they need and adds the rest to that same console, with no second system and no second pane of glass.
SIEM on real screens · EPP on real screens · Prices per module and the calculator are further down
Every security tool sees only its own event: antivirus sees a file, the firewall a connection, the WAF a request. None of them knows what the others saw. An attack passes exactly between them.
The platform does not replace them — it builds one layer of observation, detection and accounting above them. A single query works across every source, because events are reduced to one model: a field with the same name means the same thing whichever vendor produced it.
So search, correlation rules, dashboards and reports are not tied to a source type. Adding a new vendor does not mean rewriting the rules.
| Stage | What happens |
|---|---|
| Ingest | Source verified, buffered to disk, duplicates and losses accounted for |
| Processing | Parsing, normalisation to the single model, categorisation, enrichment with context |
| Detection | Correlation rules, behavioural profiles, alerts raised |
| Presentation | Incidents, dashboards, reports and forwarding to external systems |
Four console screens: a kill chain analysis, a Windows event explained, an attack chain and a map of alert sources. These are working screens of the product, not mock-ups.
How attacks progress through the MITRE ATT&CK stages on a three-dimensional scene: time, stage and host (or user, or source address). A line joins the steps of one attack, and the deepest chains are listed on the right.
Windows event 4625 as a readable analysis: which account, from where (country and provider of the source), by what method and why it was refused. Status codes come with their meaning.
Alerts are grouped into chains by MITRE ATT&CK stage: the list of incidents, a graph of the links (steps, source addresses, accounts) and a step-by-step account of what happened.
A map of alert sources: country, city and provider (ASN) come from a built-in database, with no calls to outside services. On the right, countries by number of events and highest severity.
The screens were captured in a test environment with real data: a Windows Server 2022 domain controller that receives real password-guessing attempts from the internet, and a Linux web server. Source IP addresses are shortened and the addresses of the hosts themselves are replaced.
Four screens of the endpoint protection console: the dashboard, an endpoint card, detections and quarantine.
Fleet state on one screen: endpoint status, detections over the day by severity, protection coverage by component, endpoints needing attention and the most active threats.
One endpoint: identity, agent and engine versions, protection state, actions (scan, update, restart the agent, apply a policy) and platform modules, including the SIEM module.
Every detection with its evidence: threat and verdict, endpoint, file and path, detection type, confidence, the action taken and status.
Isolated files: path and SHA-256, threat, endpoint, time and state (quarantined, restored, deleted). The content never leaves the endpoint unless it is submitted for review.
The screens were captured on demonstration data: a sample fleet of 24 endpoints prepared for the purpose. The interface is the product’s real console.
An event moves between tiers by age, by tier volume or by space used. Retention is set per source class; events that entered an incident follow their own policy.
| Profile | Hot | Warm | Cold-archive |
|---|---|---|---|
| Short · 30 days | 7 days | 23 days | — |
| Base · 90 days | 14 days | 76 days | per policy |
| Extended · 180 days | 30 days | 150 days | up to 365 days |
| Annual · 365 days | 30 days | 180 days | 185 days |
| Long · 1825 days | 30 days | 180 days | 1615 days |
The profiles are example configurations. Typical compression on text logs is 6–12×.
Functionality is identical across all four options — only image delivery and the scaling mechanism differ.
| Option | Delivery | Scaling |
|---|---|---|
| Physical | RPM / DEB packages, ISO image | Adding nodes and disk shelves |
| Virtualisation | OVA / QCOW2 / VHDX images | Changing VM resources, cloning |
| Private and public cloud | VM images, IaC templates | Scaling groups, object storage |
| Containers and hybrid | OCI images, Helm charts | Changing replica counts, StatefulSet |
For multi-site infrastructure a central-node / remote-site scheme applies: a Helix Collector at the site receives events locally, buffers them for 1–72 hours and forwards to the centre over TLS 1.2/1.3.
The price follows the number of devices, the modules you choose and the licence term. Every module can be bought on its own (DLP alone, say, or SIEM alone) or together with others; choose XDR and EDR comes with it. Prices for up to 200 devices are shown here; for a larger estate a sales manager prepares an individual offer.
Minimum order: 20 devices with SIEM, 10 devices for every other module. The volume discount does not apply to SIEM.
Helxis HEDE: price calculator Devices: 50 Modules: EPP Term: 1 year Total excl. VAT: $1,035.00 Due incl. VAT: $1,159.20
No. EDR shows in depth what happened on one machine, but it only sees that machine. A SIEM sees the whole estate, but only knows what the sources sent it. An attack usually leaves a trace in both: a process on the endpoint, an authentication and a connection in the estate. That is why they sit side by side in one console.
An antivirus mostly looks for the signature of a file already known to be malicious. HEDE’s pre-execution scanner reads the file’s structure instead: which combinations of calls the import table asks for, section entropy, whether the signature is genuine, and the YARA pack — and it records the evidence behind every point it awards. That is how it can judge a sample nobody has seen before, and show why it judged it that way.
No — deliberately. The endpoint module judges a file itself, on the machine; the other modules collect the events of the tools you already have, join them and raise an incident. Those tools keep doing their job, and the platform closes the gap between them.
The base distribution carries ready parsing rules for 600+ source types. For anything outside that list a decoder is written as configuration — product code is not changed and components are not rebuilt.
No. The agent is used on endpoints where it is needed; network equipment, security tools and cloud services are collected agentlessly — over Syslog, REST API, WMI, SNMP or the provider's API.
The source record is stored unmodified, a checksum is computed for each record and included in a block hash chain. Tampering or deletion is caught by scheduled background verification, and an integrity report can be produced for a period.
That depends on your event volume and retention period. Typical compression on text logs is 6–12×, and storage is split across three tiers — the expensive NVMe is only needed for hot. An exact figure follows once your stream has been measured.
An annual licence per device. The modules are independent: EPP, EDR, XDR, DLP and SIEM can be bought on their own or in any combination. If you choose XDR, EDR is not charged separately, because it is part of XDR. A volume discount applies as the device count grows, and a term discount for 2- and 3-year licences; the steps are shown in the calculator. Prices exclude VAT, which is shown on its own line.
The calculator prices up to 200 devices. For a larger estate a sales manager prepares an individual offer based on size, rollout plan and service terms. An enquiry sent from the calculator arrives with the configuration you chose.
We establish which sources, what volume and what retention you need — then give a precise proposal for components and storage.
