MyZapp protects its security journals against modification: the audit journal, the access denial journal, the API call journal, the sensitive data access journal and the login journal. Each line is chained to the previous one by a fingerprint that the database computes when the line is written. A line of these journals can be neither modified nor deleted from the application, and a change made directly in the database is detected by the check.
Integrity check
The Audit log integrity screen is in the Administration › Instance and operations › Audit menu. It is reserved for Administrators by default.
It shows the last check (date, scheduled task or started by hand, result), then one line per journal:
- State: Intact, Intact, earlier lines being chained, Broken, Not chained or Could not be checked;
- Chained lines: lines written since the protection was put in place;
- Earlier lines chained afterwards and Earlier lines still to chain: lines that existed before the protection was put in place, chained in batches by the check task;
- First faulty line: its number and the kind of fault (line deleted or inserted, content modified, link to the previous line broken, detail modified, detail erased without an erasure record, table protection removed or disabled, line written around the protection).
Verify now runs a full check and shows its result. The AuditIntegrityCheck scheduled task runs the same check every night; it fails when a journal is broken, and the fault is also written to the application log as an error.
A broken journal cannot be repaired from the application: the reported line was modified outside it. Keep the database as it is and report it to the person in charge of security.
Erased detail
When a person's personal data is erased, the detail of the audit journal lines about them is emptied. The fingerprint of that detail stays in the line, so the chain can still be verified. The line's detail then shows Detail erased on followed by the date, and the erasure itself is recorded.
External anchors
When the operator has configured it, MyZapp regularly exports the latest fingerprint of each journal outside the database, to storage that cannot be erased. These anchors contain only fingerprints and identifiers, no personal data. They protect against what the check alone cannot see in the database: the deletion of a journal's last lines, or its complete rewrite by someone with full access to the database.
The External anchors section of the screen shows:
- Matches the database and the number of Anchors compared;
- An anchor does not match the database, with the journal, the position and the cause: the journal was rewritten, or lines were deleted. Keep the database as it is and report it to the person in charge of security;
- that the anchors could not be read: the comparison was not done, which is not a fault in the journal;
- that no anchor is configured: a warning also appears in the instance health status;
- the Last export, and whether it Failed.
With a hosting provider, it is often the provider's own tool that compares the anchors with the database, so that your instance never has access to other customers' anchors. The screen then shows Compared by the host, with the date of its latest comparison. If it has not submitted anything yet, the screen says so; without a recent comparison, a warning appears in the instance health status.
After a backup is restored, anchors more recent than that backup no longer match: the operator sets them aside with the Audit:Anchor:NotBefore setting.
Retention
By default, no line of these journals is ever deleted. The instance operator can set a retention period per category (administration operations, sign-ins and access denials, sensitive data access, API calls). Every night, older lines are then purged, always starting with the oldest, and the purge leaves a trace: the chain remains verifiable and the screen shows, for each journal, the number of lines purged and the date of the last purge. A line less than one day old is never purged.
Signed export
The Signed export card downloads one journal over a period (without dates: the last 7 days) as an archive. It contains one line per entry with its fingerprints, never the content of the details, a signature by the key of this instance and the public key to verify it, and a file that describes the export and gives the verification command. Any change to a line of the export makes the signature invalid. The export is recorded in the sensitive data access log. It is refused if the instance has no usable identity key, or if the period contains too many lines: shorten it.
Sending to the SIEM
When the operator has set it up, new lines of these journals and security alerts are sent every minute to the security monitoring tool (SIEM) of the organization. The Sending to the SIEM card shows, for each journal, the number of lines waiting, the date of the last sending and the oldest line waiting. If the tool cannot be reached, sending resumes where it stopped, without losing any line.