18:00:41 <bdpayne> #startmeeting OpenStack Security Group
18:00:42 <openstack> Meeting started Thu Nov 21 18:00:41 2013 UTC and is due to finish in 60 minutes.  The chair is bdpayne. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:43 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:45 <openstack> The meeting name has been set to 'openstack_security_group'
18:00:52 <bdpayne> good morning / afternoon / evening everyone
18:01:17 <bknudson> hi
18:01:18 <sriramhere> good morning!
18:01:31 <bdpayne> any others here for the OSSG meeting?
18:01:41 <bpb> hi
18:01:48 <sriramhere> me here
18:02:07 <nkinder> hi
18:02:57 <bdpayne> ok, let's get started
18:03:10 <bdpayne> last week we did some post summit wrapup
18:03:22 <bdpayne> and I suggested a lot of ways for people to get involved
18:03:33 <bdpayne> this week, I'm happy to report that several people have stepped up to help out
18:04:03 <bdpayne> nkinder will be our community manager
18:04:07 <bdpayne> welcome nkinder
18:04:13 <nkinder> thanks!
18:04:16 <sriramhere> first order business - congratulations to nkinder!
18:04:42 <bdpayne> we also have some momentum on the OSSNs with people volunteering to help and/or edit them
18:04:47 <bknudson> nkinder: what does community manager do?
18:05:03 <nkinder> bknudson: that's a good question that I'm trying to figure out. :)
18:05:09 <bdpayne> ha
18:05:14 <randy_perryman> here
18:05:25 <nkinder> I think a big part is coordination with the projects around security
18:05:27 <bdpayne> here's the simple description I put together "As the Community Manager, Nathan will take the lead on ensuring that the work happening in OSSG is known by others in the community.  And he'll help us focus our involvement in conferences and other such events."
18:05:43 <bknudson> ok, that sounds great
18:06:07 <bdpayne> clearly nkinder will need to get up to speed on all things OSSG
18:06:15 <nkinder> I'm looking at doing more than just organizing communication as well.  Helping to improve our processes and expand what we do.
18:06:21 <nkinder> yeah, there's a lot to learn.
18:06:26 <bdpayne> but please feel free to pick his brain, and leverage him as a resource for communicating what we do
18:07:13 <bdpayne> I have also heard from someone ineterested in being an editor for the book... so hopefully that comes together
18:07:18 <bdpayne> more details soonish on that, hopefully
18:07:49 <sriramhere> that's great - bryan - what does it require to be the editor for the book?
18:08:09 <bdpayne> good writing skills
18:08:10 <bdpayne> :-)
18:08:12 <sriramhere> :)
18:08:21 <bdpayne> well, that and some knowledge of the domain
18:08:27 <sriramhere> no, does it need any company affiiliation/ partime / full time etc
18:08:28 <sriramhere> ?
18:08:42 <bdpayne> oh, certainly not anything like that
18:09:06 <bdpayne> in my email yesterday, I just reached out looking for some book editors to help cleanup the book and make it a more polished read
18:09:17 <nkinder> so we'll take what we can get :)
18:09:17 <bdpayne> sriramhere you want to help? :-)
18:09:25 <sriramhere> Yes Bryan
18:09:39 <bdpayne> excellent, I'll be in touch about that
18:09:46 <sriramhere> i missed that email, but would like to help.
18:09:47 <sriramhere> thanks
18:10:05 <bdpayne> so, with that length intro
18:10:14 <bdpayne> anything that people want to discuss today?
18:10:30 <sriramhere> got update and a followup question
18:10:38 <nkinder> OSSN/OSSA publishing is a topic I'd like to discuss
18:10:53 <sriramhere> update : following nkinder, me working on https://bugs.launchpad.net/ossn/+bug/1227575 OSSN
18:10:55 <bdpayne> ok
18:10:55 <uvirtbot> Launchpad bug 1227575 in nova "DoS style attack on noVNC server can lead to service interruption or disruption" [High,In progress]
18:10:56 <bknudson> if no other topics -- are you guys familiar with nist / fips standards ?
18:11:20 <sriramhere> nkinder - u go first. didnt mean to interrupt the OSSN updates
18:11:22 <bdpayne> bknudson we can discuss that a bit at the end
18:11:30 <bknudson> bdpayne: thanks
18:11:31 <bdpayne> #topic OSSN updates
18:11:43 <nkinder> Ok, so I have one OSSN that is ready for publishing
18:12:02 <nkinder> being that it's my first OSSN, I'm not sure what lists we usually send them to.
18:12:27 <bdpayne> I think that they have gone to just openstack@lists.openstack.org in the past
18:12:39 <nkinder> ok, just the main user list?
18:12:44 <bdpayne> yeah
18:12:51 <bdpayne> but... wide coverage may make sense
18:12:53 <bknudson> and -announce?
18:12:58 <nkinder> alright, I'll send that out today.
18:13:12 <bdpayne> in the past, not -announce
18:13:13 <nkinder> perhaps.... that brings me to the larger topic I want to discuss
18:13:24 <bdpayne> but, yeah... I know where nkinder is headed... so go ahead
18:13:41 <nkinder> It seems like the notices can get missed easily with just sending them out to the main mailing list.
18:14:04 <nkinder> I think we might want a separate list just for advisories, and putting them up on a wiki/webpage would be great too.
18:14:30 <nkinder> That starts to get into the format of the advisories/notes too.
18:14:31 <sriramhere> Can we work with Stef on surfacting this up to COmmunity Newsletter?
18:14:51 <sriramhere> we talked about a 'Security Corner' in the newsletter
18:14:53 <joel-coffman> what about the dev list too?
18:15:02 <nkinder> the newsletter would be good.
18:15:13 <sriramhere> Links to the wiki/ webpage can go in that 'Security Corner' updates
18:15:17 <bdpayne> I think that posting to dev and the main list is typically discouraged
18:15:30 <nkinder> The more broadly distributed the better I think, but there should be a way to easily be notified without a lot of other noise.
18:15:33 <bdpayne> I think that something like this is perhaps best placed on a webpage / wiki
18:15:46 <bknudson> blog
18:15:46 <bdpayne> with a feed, perhaps
18:15:53 <nkinder> I'd like to get things into a structured format, like CVRF.
18:15:59 <bdpayne> and then we could announce that we are doing that via the newsletter, for example
18:16:33 <sriramhere> i like the idea of adding to a blog/ wiki and surfacing up to newsletter
18:16:56 <nkinder> I'm starting to investigate that.  If we have the advisories in CVRF format, we can then generate other formats for wiki/e-mail/newsletter too.
18:17:24 <bdpayne> nkinder that sounds reasonable
18:17:32 <bdpayne> should certainly coordiate with VMT people on this
18:17:37 <nkinder> Definitely
18:17:41 <sriramhere> gr8
18:17:43 <bdpayne> would be nice to have a parallel publishing setup for OSSAs
18:17:59 <nkinder> I'm doing some initial investigation, but planned to write something up to discuss with VMT
18:18:02 <bdpayne> but for now, just a post to the mailing list is a good start
18:18:06 <nkinder> yep
18:18:37 <nkinder> ok, I'm good on that topic.
18:18:58 <bdpayne> thanks
18:19:00 <sriramhere> ok, i want to followup on threa model
18:19:10 <bdpayne> #topic threat model
18:19:17 <bdpayne> take it away sriramhere
18:19:39 <sriramhere> thanks to Shohel, we have the wiki up
18:20:00 <sriramhere> He put in to touch with couple others from his team who can coordiante while he is away
18:20:27 <sriramhere> i want to know who else is interested, so we can have a quick chat on next steps
18:20:46 <bknudson> link to wiki?
18:21:19 <bdpayne> for those that aren't aware, this is about work that is aiming to do some threat modeling on some of the key integrated projects for OpenStack (like Keystone, Nova, Swift, etc)
18:21:32 <bdpayne> https://wiki.openstack.org/wiki/Security/Threat_Analysis
18:21:52 <sriramhere> thanks Bryan. you beat me :)
18:21:52 <nkinder> I saw that there was an analysis of Keystone a few releases back.
18:22:03 <bdpayne> sriramhere any more details on the approach or what kind of expertise are needed for this project?
18:22:06 <bknudson> is the output updated books or bugs?
18:22:30 <sriramhere> prior exp. with threat modeling preferred
18:22:32 <bdpayne> output here will be bugs... and hopefully some lessons learned to improve the dev process more broadly
18:22:45 <sriramhere> even if not, let us get started with interested people
18:23:05 <bdpayne> bknudson is this a space you are interested in?
18:23:24 <bknudson> I wish I had the time...
18:23:30 <bknudson> we'll be interested in the results
18:23:33 <bdpayne> ha, I know that feeling
18:23:38 <bdpayne> indeed
18:23:41 <sriramhere> :)
18:23:43 <bknudson> and of course if there's questions about keystone I should be able to answer
18:23:52 <bdpayne> great
18:24:03 <bdpayne> sriramhere anything else on this topic?
18:24:13 <bknudson> keystone definitely has a large surface area by itself.
18:24:49 <sriramhere> looks like no one in the meeting now has bandwidth to join. so done with the topic
18:24:54 <bdpayne> ok, let's move on to our final topic
18:25:00 <bdpayne> #topic fips / nist stuff
18:25:08 <bdpayne> bknudson you had questions here?
18:25:11 <bknudson> people around here ask about this stuff.
18:25:25 <bknudson> and I was wondering if there was any community effort in this area that you knew of.
18:25:32 <bknudson> e.g., https://wiki.openstack.org/wiki/Meetings/OpenStackSecurity
18:25:34 <bknudson> oops
18:25:36 <bknudson> http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf
18:25:49 <bknudson> related to key lengths.
18:25:54 <bdpayne> ahh
18:26:01 <nkinder> EC keys?
18:26:05 <bdpayne> so the short answer is no
18:26:13 <bdpayne> this is one area that we haven't hit as much
18:26:20 <bdpayne> the book does have a chapter on compliance
18:26:25 <bdpayne> but this is a touch different
18:26:38 <bknudson> yes, I was just reading through the security book and hadn't gotten to that yet.
18:26:57 <bdpayne> I, for one, think it would be a nice contribution to have someone pull together the relavent docs and put together some best practices there
18:27:19 <bknudson> alright, well if I find out stuff related to this I'll keep the security group informed.
18:27:41 <bdpayne> one of the challenges is in just general key management / key rotation / key expiration / etc... and Cloudkeep / Barbican aims to improve this quite a bit
18:28:13 <bdpayne> but there's other challenges around understanding where an OpenStack deployment uses keys and how they should each be handled, for example
18:28:17 <nkinder> That seems to be the difficulty now.  Who is responsible for keys in general?
18:28:19 <bdpayne> this came up on the mailing list recently
18:28:44 <bdpayne> Jeffrey Walton asked the question, I believe
18:28:59 <bknudson> there's key handling stuff in keystone, in barbican ... obviously nova has some access keys...
18:29:11 <bdpayne> but the answer to "who is repsonsible for keys" is basically the cloud implementor today... with help from Barbican in the future
18:29:27 <bdpayne> I think that we should work to get all of that in one place
18:29:29 <sriramhere> are we proposing a key manager
18:29:36 <bdpayne> and I do think that Barbican is the right place
18:29:41 <rellerreller> There is a proposed KM interface
18:29:41 <bdpayne> Barbican is a key manager
18:29:59 <rellerreller> I think we should work to standarize that and eventually push that into oslo
18:30:12 <bdpayne> #topic End NOtes
18:30:17 <rellerreller> Then Barbican or whatever else KM would work
18:30:31 <bdpayne> Just a note that we won't meet next week b/c of US Thanksgiving holiday
18:30:37 <bdpayne> and with that, we are out of time
18:30:44 <bknudson> thanks!
18:30:48 <bdpayne> happy to continue the key manager stuff on the ML
18:30:52 <sriramhere> thanks, happt thanksgiving!
18:30:57 <nkinder> thanks everyone
18:31:01 <bdpayne> #endmeeting