Open Stack

All,

Thank you so much for the great input and discussion!  I made edits to the document based on feedback received including:

  *   Added a note indicating that the Oslo implementation path is the community desired implementation path to date.
  *   Removed the concept of an Oslo Config option to disable log security (which would have enabled logging of some sensitive data).
  *   Don't log URI or full request objects which could contain credential or data location information.
  *   Added a discussion point, based on feedback, about the possibility of enabling AUDIT log setting to log some sensitive data (AUDIT would not be a recommended production setting in this form obviously).

Thanks!

https://wiki.openstack.org/wiki/Security/Guidelines/logging_guidelines



From: Priti Desai <Priti_Desai at symantec.com<mailto:Priti_Desai at symantec.com>>
Date: Thursday, June 12, 2014 1:00 PM
To: "Kuvaja, Erno" <kuvaja at hp.com<mailto:kuvaja at hp.com>>, "Bryan D. Payne" <bdpayne at acm.org<mailto:bdpayne at acm.org>>, Paul Montgomery <paul.montgomery at rackspace.com<mailto:paul.montgomery at rackspace.com>>
Cc: "openstack-security at lists.openstack.org<mailto:openstack-security at lists.openstack.org>" <openstack-security at lists.openstack.org<mailto:openstack-security at lists.openstack.org>>
Subject: Re: [Openstack-security] Secure Logging Recommendations

I agree on making logs in (2) only readable by root/admin. It might be tricky to enforce it for already deployed services.

I would like to add an item on collecting DEBUG logs for a particular request. I did not find any notion of START and END of log messages in Keystone which makes it very hard to troubleshoot, also adds complexity in Monitoring and Notification of services.

Cheers
Priti

From: <Kuvaja>, Erno <kuvaja at hp.com<mailto:kuvaja at hp.com>>
Date: Thursday, June 12, 2014 12:37 AM
To: "Bryan D. Payne" <bdpayne at acm.org<mailto:bdpayne at acm.org>>, Paul Montgomery <paul.montgomery at rackspace.com<mailto:paul.montgomery at rackspace.com>>
Cc: "openstack-security at lists.openstack.org<mailto:openstack-security at lists.openstack.org>" <openstack-security at lists.openstack.org<mailto:openstack-security at lists.openstack.org>>
Subject: Re: [Openstack-security] Secure Logging Recommendations

Hi all,

I do agree with Bryan that it would be better not to log point 2 at all and I would suggest that if we provide this functionality to turn such on we should also make those logs at that point root/admin readable only.

I would also like to add an item to Sensitive/Confidential data list. One should never log any URI or full request object. These might contain user sensitive information like credentials, data locations etc.

Just a side note on the log levels. Lots of OPS are telling that currently getting anything valuable from the logs, they need to run the services on DEBUG log level. Based on this I really like the statement that DEBUG level should still never compromise the security of the information.


-          Erno (LP: jokke)

From: Bryan D. Payne [mailto:bdpayne at acm.org]
Sent: 11 June 2014 17:00
To: Paul Montgomery
Cc: openstack-security at lists.openstack.org<mailto:openstack-security at lists.openstack.org>
Subject: Re: [Openstack-security] Secure Logging Recommendations

Paul,

I really like this.  Here's a few additional thoughts:

1) On the implementation side, doing this in Oslo seems like a good plan.  At least doing as much of the security sensitive filtering stuff there.  This is something we are basically asking all projects to do, so Oslo is the right answer.

2) On this point:

"If confidential/sensitive data MUST be logged for root cause analysis, create an Oslo Config setting that disables security features, vividly informs the operator of this fact and make sure that the description accurately describes that this option should not be used for normal production purposes."

I think that it would be nice if we just didn't do this at all.  But, I understand the realities and we are likely to be more successful in our goals here if we can accommodate something like this.  To that end, I could say that when the system is operating in this mode, we should prefix EVERY log line with a short string that makes it clear that this mode is for debug/test and that it shouldn't be used for production purposes.

3) CADF is interesting and appears to be getting some traction.  I am not too familiar with this standard, though.  It may be useful to have these logging guidelines reviewed by someone who has more familiarity with CADF to make sure that everything lines up nicely.

4) OSSG hasn't traditionally been through a process of "blessing" a document such as this.  However, I would argue that it would be a good idea for us to figure out how to do this.  I think that providing guidelines such as this are a valuable "next step" towards increasing influence and interactions with the dev teams.

Cheers,
-bryan


On Fri, Jun 6, 2014 at 8:00 AM, Paul Montgomery <paul.montgomery at rackspace.com<mailto:paul.montgomery at rackspace.com>> wrote:
I created a first pass document describing some potential solutions to OpenStack sensitive data logging leaks (such as credentials or auth tokens):

https://wiki.openstack.org/wiki/Security/Guidelines/logging_guidelines

I would appreciate reviews and discussions in order to gain approval of the OSSG and the security-minded community before making recommendations to other projects (especially in the "Possible Implementation Options" section).

Thanks!
---paulmo


_______________________________________________
Openstack-security mailing list
Openstack-security at lists.openstack.org<mailto:Openstack-security at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140613/c2406d6e/attachment.html>