Requirements for security audit logs?

[Ivan Mikhaylov]

On Wed, 2020-05-13 at 17:54 -0500, Joseph Reynolds wrote:
> On 5/13/20 3:38 PM, Andrew Geissler wrote:
> > > On May 13, 2020, at 11:56 AM, Joseph Reynolds <jrey at 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.

Not so much for now, little too busy on april.

> 
> Thank you, I had forgotten about that design. :-)
> 
> I think the phosphor-audit design can perform security auditing. The 
> "low-level design" in my email below is not needed and is replaced with 
> phosphor-audit.  Here are some ideas and questions how the  
> phosphor-audit Configuration can work:
> 
> 1. We can have a "security" configuration that identifies 
> security-relevant events (as listed below).

This is whitelist/blacklist part. Any security-relevant event should be in
whitelist. Or we talking about some 'security list'?

> 
> 2. Can an event be handled in two different ways?  We need all security 
> events to be logged n omatter what else happens because of that event.  
> For example, if a server powers off, we should log that as a 
> security-relevant event, and also send a SMS to the operations staff.
> 

This is post-process in 'User actions'.

> Then if you don't fully trust your admin:
> 
> 3. Security logging should NOT be configurable by the admin and should 
> be always on.  If the BMC admin can prevent security logs from being 
> generated, it is too easy for a bad admin to hide their tracks.

I assume it is possible with additional list for such events. This list will not
be configurable and always on with their configuration. Also, what about
generation of these logs from BMC admin? If so, then we need to care about some
trust on transaction level for such events.

> 
> 4. The admin should NOT have a function to delete security log entries.  
> The security log should instead automatically delete older entries after 
> the prescribed (configured?) retention period.
> 

Any ideas where it can be stored?

> If we need a way to configure security audit log settings, for example, 
> to satisfy more strict auditing schemes, we can create a new security 
> administrator role.  For example, a new distro feature 
> SEPARATE_SECURITY_ADMIN adds a Role called SecurityAdmin, with 
> Privileges that do NOT include admin privileges but can configure the 
> security settings.  If this feature is not defined, the SecurityAdmin 
> Privileges would go to the Administrator role.
> 
> Those are my initial ideas ... probably need to be kicked around a bit.  
> Staging: I would be happy if we got 1&2 working and we allow the admin 
> to configure security settings.  Items 3&4 can be developed later.
> 
> - Joseph


Thanks.