Alerts

Protection → Alerts (administrators; subscription, open during the beta) lists over 30 days, new ones first marked: the security notices (a threat stopped for a device — malware, phishing, scam —, one a day by device and name, the name only for a minor's device; a device that behaves as an infected one, looked for every hour, see the security report), the bypass tried by the children (tools blocked, device gone or silent during a cut), the new devices of the network (after the first day of Warda, with a hardware address), the data leaks through DNS (free, see Data leaks through DNS), the look-alike names (free, see Look-alike names), the threats (free, see Threats in the names and the answers), the channels of data out told or blocked (Warda Business, once a day per device, name and action, see Data loss prevention), from 0.8.0 the mining pools, the automatic blocks of the learning, the known data breaches, the exposure on the Internet and the restricted mode of the objects (free, see the table below), from 0.8.2 the domains decided by their reputation (free), the devices on mobile data at home and the connections probably shared from them (subscription, see Protection outside the home), and the sites of the monitored categories. The dashboard says how many are new. The page groups them: Security, Bypass, New device and Monitored (the categories). GET /api/v1/notices?days=30 ({"notices": [...], "unseen": n}), POST /api/v1/notices/seen {"up_to": id}; an adult reads their own devices no longer protected with GET /api/v1/me/unprotected. The notices are kept 90 days, deleted with the person, and those about a minor go when they become an adult. They stay out of backups. The notices of a bypass (bypass) and the alerts of the monitored categories (alerts) are functions of the subscription, checked by the service and not only by the pages: without it, the list holds every notice but those of a bypass (the new devices and the free security notices of the table below), and the alerts of the categories answer 402. During the beta they are open to every installation. After the beta, the box itself refuses the routes of the page (GET /api/v1/notices, POST /api/v1/notices/seen, GET /api/v1/category-alerts and the decisions below) with 402 without the subscription, and the menu leaves the page out (see Plans).

The alerts of the monitored categories are new until read, as the notices (from 0.8.5; those kept before were marked read by the migration): POST /api/v1/notices/seen takes categories_up_to (the last id of the alerts of the categories read) beside up_to.

Decisions on the alerts (from 0.8.5, function alert-decisions of the catalogue, subscription, open during the beta; internal/admin/decisions.go). Each alert of the page, notices and alerts of the monitored categories alike, offers up to four decisions:

• Accept the risk: the allow that fits its kind (the table below) is made, and the decision recorded with its date and its author;
• Refuse the risk: the block that fits it (a rule, or the quarantine of the device);
• Keep watching: nothing changes, but the alert is told again at most every 14 days while its cause goes on (store.WatchEvery);
• Read (for the kinds no rule answers, and always possible).

Each decision marks the alert read, is shown under it ("Risk accepted on … by …", "Watched since … (…): told again at most every 14 days while it goes on"), goes to the administration log and can be undone (Undo): what it changed is put back as it was, unless someone changed it since (a rule changed or removed meanwhile, a device let out of quarantine: left as it is); the alert stays read and has no decision any more. One decision per alert (409 "this alert already has a decision": undo it first). Before Accept the risk and Refuse the risk a dialog says what will change ("Allow wetransfer.com for PC-Léa", "Put Console-Dylan in quarantine (only updates and security software get through)").

An alert without a device (or without a name in its detail) offers only what applies to it. Rights: deciding needs the reports written (the administrators, or a role that changes them); accepting or refusing also needs the right to change what it changes — the devices (a rule of a device, the quarantine), the rules (a rule of the network, the exemption of rebinding) or the network (an exposure acknowledged) — otherwise 403, and the same right to undo it.

Kept under watch. An alert watched is not recorded again within 14 days of the last one of the same key (its kind, device and detail): the checks that tell it again by themselves (a threat asked again, a monitored site visited again) are let through once every 14 days. The alerts of a lasting condition, told once by their own check, are told again by the task Alerts watched (alerts.watch, every 6 hours, shown only while an alert is kept under watch): an exposure still found and not acknowledged, an address still watched and still in the breach. At most 500 watches are looked at by a run. A decision of another kind on a newer alert of the same key ends the watch.

Administration log: alert.accept, alert.refuse, alert.watch, alert.read (notice #12 bypass.tool device 4: block_device vpn.example: the source, the id, the kind, the device, the effect and the names) and alert.undo (notice #12 bypass.tool: refuse), with the changes they make under their own names (device_rule.allow, device_rule.block, device_rule.undo, rule.allow, rule.block, rule.delete, device.quarantine.on and device.quarantine.off, network.exposure.acknowledge and network.exposure.unacknowledge, the settings of the threats for the exemption of rebinding).

Stored: the table alert_decisions (source notice or category, the id of the alert, its key, the decision, the time, the author and what it changed, to undo it), one decision per alert; out of the backups (a restore empties it, as the alerts themselves).

API (the reports written): GET /api/v1/notices and GET /api/v1/category-alerts give for each alert actions (accept, refuse: the effect offered, allow_device, block_device, allow_network, block_network, quarantine, acknowledge, rebinding_exempt or keep; accept_area and refuse_area: the right each needs; names; watch) and decision (decision, time, actor, effect) when it has one; POST /api/v1/alerts/decide {"source": "notice" | "category", "id": 12, "decision": "accept" | "refuse" | "watch" | "read"} answers the decision; POST /api/v1/alerts/undo {"source": "notice", "id": 12}. 400 for a decision the alert does not offer ("no rule answers this alert: read it or keep watching it", "this alert is told once: it cannot be watched"), 409 when the device of the alert no longer exists or the finding of the exposure is no longer found.

The kinds of notices of the administrators, with the severity given to the SIEM export (CEF, 0 to 10) and to the security center (7 and more serious, 5 and 6 important, the others minor):