Server audits and compliance frameworks
Running server_audit_notify.sh does not make a server compliant with any framework. It produces dated audit files and emailed summaries, which can be one piece of evidence that you review your systems on a schedule.
This page explains how the script relates to common frameworks. It is not legal or compliance advice. Ask your auditor or assessor what evidence your environment needs.
What the script gives you as evidence
Each run leaves a set of files in /var/log/server_audit named with the run time, plus an email in the recipient's mailbox. Together they show that a scan ran, what Lynis warned about, and what the server looked like at that moment.
The script does not map findings to controls, track whether anyone fixed a finding, or protect its files from change. Anyone with root on the server can edit or delete them.
HIPAA Security Rule
The HIPAA Security Rule includes an audit controls standard at 45 CFR 164.312(b). It reads: "Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information."
A scheduled audit that records failed logins and system state is one way to examine activity. Recording activity in detail usually needs more, such as the Linux Audit System (auditd) and central log collection.
PCI DSS for payment card data
The PCI Security Standards Council says PCI DSS "provides a baseline of technical and operational requirements designed to protect payment account data." The requirements themselves are in the standard, which is available from the PCI SSC Document Library. Your Qualified Security Assessor decides what counts as evidence.
NIST publications
NIST publishes free guidance that many organizations use as a reference:
- SP 800-123, Guide to General Server Security, on planning, securing and maintaining servers.
- SP 800-92, Guide to Computer Security Log Management, on building log management across an organization.
- SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations, whose control families include Audit and Accountability.
SOC 2 and ISO/IEC 27001
SOC 2 reports are based on criteria from the AICPA, and ISO/IEC 27001 is an international standard for information security management systems. Neither names a specific audit tool. A scheduled server audit with retained reports can support a control about reviewing system security, if your control description says so.
What Lynis says about compliance
The Lynis README lists "Compliance testing (e.g. ISO27001, PCI-DSS, HIPAA)" among the uses of the tool. Lynis warnings point to settings worth reviewing. They are not a pass or fail for any framework.
Limits to keep in mind
- The script sends the email over TLS and verifies the SMTP server certificate. After that, the report sits in the mailbox of each recipient as plain text.
- The report directory is readable by root only (mode 700). The script does not write the SMTP password to disk.
- Mailboxes get cleaned out, so treat the email as a notification. Keep the files in
/var/log/server_audit, or copy them to storage you control, for as long as your policy requires. - The script covers one server per install and has no central view.
Proving what code a server runs
Some audits need proof that the production server runs the code that was reviewed. The Forward Email team works on that problem in two separate projects. Attestium is a remote attestation library, and Audit Status is a tool built on it that publishes verification reports. server_audit_notify.sh does not use either one.