Docs · Log review
ISO 27001 asks that logs are kept (A.8.15) and that they are monitored, with the monitoring evidenced (A.8.16). Most audits stall on the second part: the logs exist, but nothing shows that a person looked at them. Log review gives each opted-in server a queue of security-log events worth a person's attention, records each decision with who made it and when, asks for a weekly sign-off, and assembles the evidence pack an auditor can read.
It builds on log signals: the agent reads the security logs already on the host and ships counts and facts, never the log lines. There is nothing new to install.
Log review is off by default. Turn it on from a server's Signals tab, or for many servers at once from Settings → Log review. Organisation owners and admins can change it, and client owners for their own client's servers. Every change is written to the audit log, and those records are what the evidence pack uses to state each server's enabled period.
Only enabled servers produce review events, count towards the weekly sign-off and appear in the evidence pack. The Log review area appears in the dashboard once at least one server is enabled.
Every 15 minutes the platform derives events from what the agent has reported. Identical activity collapses into one event with a count. The queue opens on unreviewed events and filters by server, type, severity and status.
A successful login for a user from an address not seen for that user in the last 90 days.
Any login as root, or as an account you list as shared in Settings → Log review.
The first time a user is seen using sudo. Reported once per user.
Failed sudo or su attempts, per user and hour.
useradd, userdel, usermod, groupadd, groupmod, groupdel, passwd and chage. Needs agent 0.2.116 or later.
Failed SSH and PAM logins from one address, or against one user, above the burst threshold (50 an hour by default). Consecutive hours are one event, up to 24 hours.
The log signals findings — a blocker that stopped blocking, a failed control, a log gone silent.
Malware and rootkit hits, and file-integrity changes on system paths such as /etc, /usr and /root.
A ban spike, the ban safety cap tripping, or attacks from a country or network not seen in the previous 30 days. Counts only.
A log rotated past the agent's position, truncated or unreadable (including a journal the agent is not permitted to open), or read only in part because it grew too fast. A read that runs out of time on one run is not a gap — it resumes from the same position next run. A source that has fallen behind on every run for six hours is listed once as information, and after 24 hours as Medium. maldet's own trim of its event log (the same file cut from 20,000+ lines to its oldest ~1,000) is marked Expected automatically, and the lines it keeps are not counted again (on hosts upgraded from an earlier agent, from maldet's next trim onwards); an emptied, edited or replaced log is listed each time it happens.
Each event takes one of three decisions, with an optional note:
Decisions are append-only: a later decision supersedes an earlier one, and both stay on the record with the reviewer, their role and the time. Organisation owners and admins, and client owners for their own servers, can decide; members can read.
Rules mark known activity Expected automatically — for example your deploy user from your office range, or one event type on one server. A rule's match is recorded as a decision by that rule, never dropped silently. Rules leave HIGH events for a person unless the rule is explicitly set to include them, and rules created by client users never apply to HIGH events. A rule is disabled rather than deleted, so its past decisions stay explainable.
Weeks run Monday to Sunday in the organisation's timezone (Europe/London unless you change it). Once a week has ended, a reviewer signs it off with an optional comment. The sign-off stores the week's counts by type, decision and severity, and each server's coverage for the week.
On the 1st of each month Astrari prepares last month's pack automatically; from the Evidence tab you can generate one for any range of up to 400 days. Each pack is a PDF with a matching CSV of the events:
Each hour a server is enabled, Astrari records whether fresh agent data arrived and which log sources were read. An hour with no data — a reboot, an agent stopped for maintenance — is a gap with its dates; so is a log the agent found rotated past its position or truncated, and an hour in which a fast-growing log was read only in part. Gaps appear in the sign-off summary and the evidence pack rather than being smoothed over. The agent keeps each read small — a few seconds, at the lowest CPU and disk priority — so it stays out of the server's way; a read that doesn't finish in that time resumes from the same position on the next run. A source that falls behind on every run is listed after six hours, and raised as Medium after 24.
With client sub-accounts (Agency plan), a client's owner can review events, sign off weeks and download evidence packs for their own servers, and designate their own reviewers. A client sees events from the time each server was linked to them; a server moved between clients keeps its earlier evidence with the earlier client. Events on a server shared by several clients are decided by the organisation, so one client's notes are never shown to another. An organisation sign-off covers every client.
No. The agent already sends hourly counters and a few facts for log signals; log review is derived from those, from findings and from intrusion detection data. An event holds the type, time, count, the user, address or path concerned and, for account changes, one sample line with emails, password hashes, long tokens and comment fields masked by the agent before it leaves the server.
Nothing is backfilled: the queue starts from the moment log review is enabled, and the evidence pack states that date. Disabling a server later stops new events but keeps everything already recorded, for the retention period.
Not in place. Decisions and sign-offs are append-only, enforced in the database. To correct a decision, record a new one; the event shows its full history. Records are removed only by the retention clean-up.
The reviewed event is left as it was, and the new activity opens a continuation event marked as such. Activity that arrives after its week was signed off is flagged after-signoff, so the sign-off is never silently widened.
Failed logins arrive as bursts — one event per address or user per run of hours — and the threshold is configurable per organisation. Beyond 200 events of one type per server per day, lower-severity events are counted together in one aggregated event; HIGH events are always listed individually.
Most event types work with the agent you already have. Account and group changes need agent 0.2.116 or later, which is shipping next; on systems without an auth log file they are read from journald, where the agent also checks that the entry really came from the account tool.