All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Geissler <geissonator@gmail.com>
To: Joseph Reynolds <jrey@linux.ibm.com>
Cc: openbmc <openbmc@lists.ozlabs.org>
Subject: Re: Requirements for security audit logs?
Date: Wed, 13 May 2020 15:38:51 -0500	[thread overview]
Message-ID: <4DD0C271-0081-4E9D-9733-F9DA101D7CF8@gmail.com> (raw)
In-Reply-To: <87f78066-22d5-6f15-56a2-134388844a66@linux.ibm.com>



> On May 13, 2020, at 11:56 AM, Joseph Reynolds <jrey@linux.ibm.com> wrote:
> 
> What are our requirements for Security Audit Logs?  The main idea is to add a new BMC logging service to hold security-relevant events.
> 

Def hoping we can work this into our audit design:
https://github.com/openbmc/docs/blob/master/designs/phosphor-audit.md 

I’m not sure how much progress has been made with implementation but
we spent a good chunk of time reviewing/discussing it and it seems to
hit a lot of the items below.

> Considerations:
> - The log holds *only* security-relevant entries (and no irrelevant entries).
> - 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 logging.)
> + 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:
> Network:
> - New connections via HTTPS (se BMCWeb below), SSH, use of the serial line to access the BMC's shell, etc.
> BMCWeb:
> - 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.
> Services:
> - 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:
> https://en.wikipedia.org/wiki/NIST_Special_Publication_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
> https://docs.google.com/document/d/1b7x9BaxsfcukQDqbvZsU2ehMq4xoJRQvLxxsDUWmAOI
>> 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.
> 

  reply	other threads:[~2020-05-13 20:38 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-13 16:56 Requirements for security audit logs? Joseph Reynolds
2020-05-13 20:38 ` Andrew Geissler [this message]
2020-05-13 22:54   ` Joseph Reynolds
2020-05-14 13:35     ` Ivan Mikhaylov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4DD0C271-0081-4E9D-9733-F9DA101D7CF8@gmail.com \
    --to=geissonator@gmail.com \
    --cc=jrey@linux.ibm.com \
    --cc=openbmc@lists.ozlabs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.