Requirements for security audit logs?

Requirements for security audit logs?

[Joseph Reynolds]

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

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.

Re: Requirements for security audit logs?

[Andrew Geissler]

> 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.
> 

Re: Requirements for security audit logs?

[Joseph Reynolds]

On 5/13/20 3:38 PM, Andrew Geissler wrote:
>
>> 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.

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).

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.

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.

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.

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

>> 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.
>>

Re: 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@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.