Features

This page describes the features that have shipped. Some read an engine you run: they say so, and the page concerned says “not configured” until it is. What a client sees also depends on its service offer.

Incidents and alerts

• One queue for the alerts of all your connected sources and of the API.
• My queue: one button shows your cases still to handle.
• Deadline on every open item: the time left before the client’s resolution target.
• Saved views: the list’s filters are kept under a name. They are also in the page address, which can therefore be shared.
• Group several alerts into a case.
• Reopen an alert wrongly dismissed as a false positive.
• Mandatory reason to resolve or close an incident.
• Notes internal to your team, or visible to the client.
• MITRE ATT&CK coverage of the scope: techniques covered by the detection rules, real activity over 90 days, blind spots, and a sheet per technique.

SOAR

Automation is native, with no external tool.

• Rules: they watch new alerts (severity, source rule level, source, rule ID, ATT&CK technique, tags, title, clients) and chain actions: open a case, notify the team, run a playbook.
• Test before enabling: a rule is created disabled and can be tested on the last 7 days, with how many alerts it would have caught, per client and per day.
• Visual editor: each rule is drawn as a flow (trigger, conditions, scope, control, actions) and edited on the diagram.
• Playbooks: a built-in catalogue, and custom playbooks built on the same diagram. A step that starts long-running work (analysis, collection) waits for its result before the next one.
• Runs: the list of every run, followed live. Re-run, resume at the failed step, or stop a waiting run. A run keeps the playbook version it started with.

The guardrails are in the server:

• no isolate, kill or block action;
• a collection on a host waits for an administrator’s approval and runs under their name;
• collections only read; containment always stays a human task;
• a rule acts at most once per alert, within an hourly limit;
• everything is written to the audit log.

Some steps rely on an engine: Cortex for analysis, a threat intelligence platform for sharing indicators, a forensic collection tool for collection on a host. These last two work with a compatible engine (list on request).

Reports

• Incident report as a PDF.
• Per-machine report as a PDF: identity, system, exposure, accounts, services, vulnerabilities and recommendations.
• Monthly report as a PDF (Dashboard, Export): a written synthesis compared with the previous month, alert handling, notable incidents, commitments, the team’s actions, recommendations.
• In French or English, password protected. Appearance of your choice: light, dark or print.
• A section whose source cannot be read says so instead of staying empty.

Intelligence

• Indicator watchlist: an address, domain, hash or URL, pasted as is from a bulletin. It is searched at once across the client’s 90 days of alerts, then every hour. A new sighting tells the client and the team.
• Observable analysis with Cortex analyzers.
• Threat intelligence from a compatible intelligence platform.
• Cyber news from the official CERTs, and which recent critical vulnerabilities concern your estate.

Estate monitoring

These pages rely on the data of a compatible event store and endpoint manager (list on request, see Existing engines):

• Events: search through the alerts, restricted by the server to the user’s scope;
• Threat map;
• Assets: each monitored machine, its system, listening ports, accounts and vulnerabilities;
• Vulnerabilities, actively exploited flaws (CISA KEV catalogue) first;
• Posture: the real state of the hardening checks, machine by machine;
• Collection health: agents connected or not, last event received, state of the connected sources. When the SIEM does not answer, the state is said to be unknown, never “all good”.

Tickets and messages

• Tickets with an agreed deadline and followers, and a board to move them along.
• Messaging between your team and each client, with search and files.

Notifications

• In AarView: a bell. Several critical alerts arriving together give a single entry.
• By e-mail, if mail is configured: each user chooses (critical incidents, all incidents, tickets assigned to them, daily summary) and can send themselves a test e-mail.

AI assistant

Optional: it needs a connected AI service (see Existing engines). Its proposals are suggestions: an analyst decides. A proposed SOAR rule goes through the same validation as a hand-written one and is never saved without the analyst.

Audit log

Actions are written to an audit log. An organisation’s administrator reads their organisation’s log; the super administrator, the global log. Exporting needs a recent sign-in.

Languages

The interface, reports and e-mails exist in French and English.