Incident and breach response

Who does what

Cenovel runs on the district’s own appliance, so an incident on it happens in the district’s environment. The district leads the response: it decides on containment, on notices to staff, families and regulators, and on when the appliance returns to service.

• The district names an incident lead (usually the network or security manager) and a deputy, and keeps the district’s own breach procedure and contacts. Its data privacy agreement and state law set its notice duties.
• Cenovel the vendor has no access to the appliance and receives no telemetry, so it cannot detect an incident there. When the district asks, it helps investigate (log guidance, the audit-chain check, support bundles) and fixes any fault in Cenovel itself.

Cenovel’s commitments to the district: notice within 72 hours of confirming a security incident in Cenovel’s own systems or support copies that affects district data, and within one business day of confirming a vulnerability in Cenovel that is critical or being exploited.

Signs to act on

• Audit entries nobody recognizes: sign-ins from unknown accounts or addresses, permission changes, credential or settings-key changes, an unverified certificate override on a server.
• The audit chain does not verify, or cenovelctl diagnose reports a fault you cannot explain.
• cenovelctl release verify-current fails: the installed files are not the signed release.
• A server or switch reports a changed certificate or SSH key that nobody replaced.
• A report from staff, a device vendor or a district security tool.

Treat a sign as an incident until it is explained. Write down the time you noticed it, in UTC, and who noticed it.

Contain it

1. Keep the evidence. Do not restore a backup over the appliance, roll back, or rebuild it until the evidence below is copied. If the hypervisor allows it, take a snapshot of the VM first.
2. Narrow who can reach it. Limit inbound HTTPS (443) to the workstations of the people handling the incident at the district firewall.
3. Remove access that may be misused. Lower or remove the affected accounts’ access in Settings › People and departments, and block their sign-in in Microsoft Entra ID.
4. Change the secrets it holds. Change the device credentials in Monitoring › Access on the devices first, then in Cenovel. Rotate the settings key with cenovelctl settings-key rotate. Replace the Entra client secret, mail, webhook and Mist credentials it uses.
5. Take a fresh backup with cenovelctl backup create, and keep it apart from the normal rotation.

Collect the evidence

The audit log is the record of who changed what, when and from which address. Export it and check its integrity chain before anything else changes (see Audit history and evidence). Then collect:

• service logs: cenovelctl logs api --lines 2000, and the same for worker, proxy and database;
• a support bundle: cenovelctl support-bundle. It masks secrets and holds no database content, so it can be shared with Cenovel support;
• the release check, cenovelctl status --json and cenovelctl diagnose --json;
• firewall and Entra sign-in logs for the same period, from the district’s own systems.

Store the copies off the appliance, with the date, who collected them and their SHA-256 digests.

The 72-hour notice and other messages

Most student data privacy agreements (including the SDPC National Data Privacy Agreement) ask for notice within 72 hours of confirming a breach, and state laws add their own clocks. The district’s counsel decides which apply. Facts that help them:

• Cenovel holds staff and equipment data: staff names and work email, sign-in and audit records, building contacts, and network and asset records. It holds no student records, and no staff passwords for Entra sign-in.
• The audit log shows which records an account read or changed, and when.

If you believe the cause is a fault in Cenovel, contact Cenovel support with the support bundle and the times involved. Do not send database exports or backups unless support asks for a specific record.

Recover and review

1. Fix the cause: install the fixed release, close the network path, or remove the account.
2. Return the appliance to service only after the audit chain verifies and cenovelctl diagnose is clean. If you restore, run cenovelctl restore preflight on the set first.
3. Within two weeks, write a short review: timeline, cause, data involved, notices sent, and what changes. Keep it with the incident evidence.

See also: Security & data · Backup & restore · Audit history and evidence