Open Stack

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
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/20140612/8da49ebe/attachment.html>