Open Stack

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> 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
> 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/20140611/670a65f0/attachment.html>