Requirements for security audit logs?

Joseph Reynolds jrey at
Thu May 14 02:56:34 AEST 2020

What are our requirements for Security Audit Logs?  The main idea is to 
add a new BMC logging service to hold security-relevant events.

- The log holds *only* security-relevant entries (and no irrelevant 
- Consumed by a security auditor (currently the Administrator Role).  
The log is likely to contain sensitive and possibly personal information 
(such as IP addresses), so it must be protected from reading.  Perhaps 
only the admin can read this.
- Entries must be available, so the admin should not be able to delete 
the log or any entries.
- Log can be held on BMC persistent storage (like flash) or streamed off 
the BMC, just like any other log.
- Low-level design: any BMC service can write a security log entry when 
it encounters a security-relevant event.  (In addition to its regular 
+ Note that security holes exist.  I would like to keep these outside 
the scope of this initial discussion except to note that examples shown 
below ought to generate a security log entry. Examples:
+A: root SSH access can do whatever it wants to the security log
+B: factory reset clears the logs

Examples of security-relevant events:
- New connections via HTTPS (se BMCWeb below), SSH, use of the serial 
line to access the BMC's shell, etc.
- All authentication attempts (login, basic auth, etc.)
- When accounts are locked out or reset
- Attempts to use REST APIs that require Administrator access. NOTE: 
This covers a large number of functions and may overlap with services 
provided by D-Bus daemons.  Example: LDAP config, local user config.  
Example: when an admin uses their authority to change a user account 
- Password changes (in phosphor-user-manager)
- BMC rebooting or power on
- Host state transitions
- Firmware update (BMC or host)
- BMC Factory reset

We can consider a more formal set of requirements given by NIST SP 800-92:
with additional controls as specified by NIST SP 800-53.

- Joseph

This topic was previously discussed as agenda item 3 in the 2020-04-29 
Security Working Group results
> 3. Requirements for security audit logs.  Access, deleting, APIs.
There was general support for the ideas that the BMC should have 
dedicated security audit log that could not be deleted or cleared. This 
log would have only security-relevant events.

More information about the openbmc mailing list