<div>This was February 2012, so it is also a bit out of date and may suffer from CEOptimism (a common enough affliction :-).  </div><div><br></div><div>I'm more aware of the and some of the design changes this group is recommending after participating in the doc sprint, but I'd also argue that a deployment team has a better chance of hardening OpenStack over the proprietary or open-core alternatives.</div><div><br></div><div>It also depends on the use case for the deployment.  Behind their corporate firewall for internal use only, OpenStack is probably much safer than their existing IT infrastructure.  Nothing like clear-text VNC sessions to improve security.</div><div><br></div><div>The talk should try to score base OpenStack deployments for different use cases, summarize deployment recommendations for each, and talk about current and future efforts planned by the community.  </div><div class="mailbox_signature">—<br>Sent from <a href="https://www.dropbox.com/mailbox">Mailbox</a> for iPad</div><br><br><div class="gmail_quote"><p>On Wed, Jul 31, 2013 at 10:51 AM, Clark, Robert Graham <span dir="ltr"><<a href="mailto:robert.clark@hp.com" target="_blank">robert.clark@hp.com</a>></span> wrote:<br></p><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><p>Interesting deck although I think it's a mistake to believe that OpenStack

<br>itself is made out of 'defensible' technologies and the only requirement

is to turn on the correct 'switches'.

<br><br>This is certainly the case in a lot of the technologies used and a large

<br>degree of what the security guide addresses is exactly this - flipping the

<br>right switches to secure your deployment. However there are a bunch of

<br>design decisions that need to be revisited because the security impact is

significant and the effort required to fix can be very high.

<br><br><br>On 31/07/2013 13:51, "Brian Schott" <brian.schott@nimbisservices.com>

<br>wrote:

<br><br>>You can find the talk here:

<br>>https://cloudsecurityalliance.org/events/presentation-material/

<br>>https://cloudsecurityalliance.org/wp-content/uploads/2011/05/RSA-CSA-Chris

<br>>-C-Kemp-Keynote-February-2012.pptx

<br>>

<br>>I agree with you on some of the default configuration choices were made

<br>>without security in mind, but the point I was trying to make is on slide

<br>>35.  OpenStack is made up of defensible technologies, but the

<br>>responsibility is on the deployment.  In some ways, I see this as no

>different than other web frameworks in their default deployments.

<br>>

<br>>Brian

<br>>

<br>>

<br>>

<br>>On Jul 31, 2013, at 6:53 AM, "Clark, Robert Graham" <robert.clark@hp.com>

<br>>wrote:

<br>>

<br>>> I've not seen the slides so I'm only speaking to your description but I

<br>>>don't think I completely agree with the point that Chris was making back

<br>>>then. There are certain design decisions such as unauthenticated RPC

<br>>>over AMQP that have significant security impact and need to be

>>addressed, some of the 'Glue' that Bryan mentioned below.

<br>>> 

<br>>> It'd be great to see the deck and see which ideas we can bring forward

<br>>>and where we need to highlight the areas of OpenStack that go beyond

>>'hardening any other IT system'.

<br>>> 

<br>>> 

<br>>> From: Brian Schott

<br>>><brian.schott@nimbisservices.com<mailto:brian.schott@nimbisservices.com>>

<br>>> Date: Wednesday, 31 July 2013 05:44

<br>>> To: Bryan Payne <bdpayne@acm.org<mailto:bdpayne@acm.org>>

<br>>> Cc: Robert Clark <robert.clark@hp.com<mailto:robert.clark@hp.com>>,

<br>>>"openstack-security@lists.openstack.org<mailto:openstack-security@lists.o

<br>>>penstack.org>" 

<br>>><openstack-security@lists.openstack.org<mailto:openstack-security@lists.o

<br>>>penstack.org>>

<br>>> Subject: Re: [Openstack-security] develop a common State of OpenStack

<br>>>Security briefing

<br>>> 

<br>>> Chris Kemp had some good holistic overview slides at one of the summits

<br>>>that talked about the strength of OpenStack in terms of its plugin

<br>>>architecture and that it is made up of stuff no different than hardening

<br>>>any other IT system.  No magic fix for security, no major barriers for

<br>>>securing deployments, but probably better than your average public

<br>>>facing IT system out of the box.  Good positive message with a dose of

<br>>>there is no such thing as a free lunch.  This could get done in 4-5

<br>>>slides.  The first slide in this section should be almost a stand-alone

>>summary of the 4-5 slides.

<br>>> 

<br>>> We could have a single service overview slide with a services report

<br>>>card kind of table.  Then maybe have a single status slide for every

<br>>>service and hit those top-level bullets very briefly with a reference to

<br>>>the appropriate hardening guide section or wiki.  We don't have to

<br>>>completely reimplement the security guide, but should then some slides

<br>>>behind each summary slide that tunnels into each of those top-level

<br>>>bullets?  That might be too much.  Things like security bugs can get

>>very stale fast.

<br>>> 

<br>>> 

<br>>> On Jul 30, 2013, at 12:31 PM, Bryan D. Payne

<br>>><bdpayne@acm.org<mailto:bdpayne@acm.org>> wrote:

<br>>> 

<br>>> I think that it's useful to talk about the "glue components" (e.g., the

<br>>>message queue, database, etc) and current thinking on best practices

<br>>>there.  Also, on best practices for deployment and keeping everything up

<br>>>to date.  Finally, I think it's important to highlight both the good

<br>>>things that we have today, but also the gaps / areas where improvement

<br>>>is needed.

<br>>> 

<br>>> -bryan

<br>>> 

<br>>> 

<br>>> On Tue, Jul 30, 2013 at 5:00 AM, Clark, Robert Graham

<br>>><robert.clark@hp.com<mailto:robert.clark@hp.com>> wrote:

>> I¹d certainly be happy to throw some time into this.

<br>>> 

<br>>> Things I¹d expect to see in the deck:

<br>>> 

<br>>> ·        Holistic overview, general security posture

<br>>> 

<br>>> ·        Service overview, perhaps restricted to core IaaS services or

<br>>>wider

<br>>> 

<br>>> o   Covers secure configuration

<br>>> 

<br>>> o   Especially new options, improvements

<br>>> 

<br>>> o   Security Bugs

<br>>> 

<br>>> o   Design issues

<br>>> 

<br>>> ·        Review of recent security issues and OSSNs

<br>>> 

<br>>> ·        ?

<br>>> 

<br>>> From: Nicolae Paladi

<br>>>[mailto:n.paladi@gmail.com<mailto:n.paladi@gmail.com>]

<br>>> Sent: 30 July 2013 07:25

<br>>> To: Bryan D. Payne

<br>>> Cc: 

<br>>>openstack-security@lists.openstack.org<mailto:openstack-security@lists.op

<br>>>enstack.org>

<br>>> Subject: Re: [Openstack-security] develop a common State of OpenStack

<br>>>Security briefing

<br>>> 

<br>>> Great initiative, I'd be glad to "test drive" such a presentation at

<br>>>our next OpenStack meetup in September;

<br>>> 

<br>>> Just my 2 cents: would be good to have a slide or two on the state of

<br>>>VPN support in Neutron, as well as what the capabilities of security

<br>>>groups are

<br>>> 

<br>>> /nicolae

<br>>> 

<br>>> On 29 July 2013 23:56, Bryan D. Payne

<br>>><bdpayne@acm.org<mailto:bdpayne@acm.org>> wrote:

<br>>> This sounds very valuable.  What kinds of information would you guys

>>like to see in this?

<br>>> 

<br>>> Also, I'm thinking the slides could be setup in a way that suits either

>>30 min or 60 min presentation lengths.  Does that seem reasonable?

<br>>> 

<br>>> -bryan

<br>>> 

<br>>> On Mon, Jul 29, 2013 at 12:24 PM, Brian Schott

<br>>><brian.schott@nimbisservices.com<mailto:brian.schott@nimbisservices.com>>

<br>>> wrote:

<br>>> I was thinking that it would be great if we could collectively have a

<br>>>common "State of OpenStack Security" that Stackers could give at local

<br>>>OpenStack MeetUps or other venues.  This topic comes up all of the time

<br>>>and a good executive overview briefing would raise the awareness of what

>>OpenStack is doing in this space.

<br>>> 

>> Is there interest in OSSG in pulling together such a briefing?

<br>>> Brian

<br>>> 

<br>>> -------------------------------------------------

<br>>> Brian Schott, CTO

>> Nimbis Services, Inc.

<br>>> brian.schott@nimbisservices.com<mailto:brian.schott@nimbisservices.com>

<br>>> ph: 443-274-6064<tel:443-274-6064>  fx: 443-274-6060<tel:443-274-6060>

<br>>> 

<br>>> 

<br>>> 

<br>>> 

<br>>> _______________________________________________

<br>>> Openstack-security mailing list

<br>>> 

<br>>>Openstack-security@lists.openstack.org<mailto:Openstack-security@lists.op

<br>>>enstack.org>

<br>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security

<br>>> 

<br>>> 

<br>>> _______________________________________________

<br>>> Openstack-security mailing list

<br>>> 

<br>>>Openstack-security@lists.openstack.org<mailto:Openstack-security@lists.op

<br>>>enstack.org>

<br>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security

<br>>> 

<br>>> 

<br>>> _______________________________________________

<br>>> Openstack-security mailing list

<br>>> 

<br>>>Openstack-security@lists.openstack.org<mailto:Openstack-security@lists.op

<br>>>enstack.org>

<br>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security

<br>>> 

<br>>

<br><br></p></blockquote></div><br>