SecStack in Havana

I am just back from Summit. Where I ran into a bunch of wonderful folks both new and old. OpenStack is getting awesome. The security front is about to get REALLY interesting. HP, Nebula, and a few others are showing serious interest in building out continuous integration methodology to help protect the OpenStack community. I’ll of course be doing my part.

And that’s where the flowchart comes in.

The image above is a variant of a traditional approach to a security audit of an application, basically modified for use in the OpenStack world. I’ll probably do some more work on this modeling as the year progresses and I get input from the OSSG and VMT.

Anyways, you can see that need for compiling an understanding of current known vulnerabilities and risks. This site kind of fills that gap. But to be blunt, it’s not good at it. When I was doing some data analysis for the summit, I realized that there was no single authoritative source for OpenStack threat resources. The OSSA’s are only released in e-mail and the e-mails themselves are not in a parseable format. They also have changed over time. In addition to that the CVEs don’t always have corresponding OSSAs, and vice versa. Currently there is very little in the way of decent attribute data for vulnerabilities that stem from secondary dependencies, and entire dependencies are untracked as far as the OpenStack community is concerned.

During the day job I have been helping with building out our OpenStack packaging toolchain. One of the things I need to do during a release cycle is to verify we have a fully patched package set. In addition to that we need to respond to OSSAs by patching many supported release package sets. As such I have begun to build such a database. As the project progresses I will share the code, the data, and I’ll stend up an experimental API. Hopefully by the end of the Havana release cycle I’ll have something that we can integrate into the OpenStack development cycle.

So I am probably going to begin laying off of the posting of OSSA vulnerabilities from here on out. However, I will begin releasing a comprehensive JSON set as I enter further into the investigation and cataloging of datasets. As part of that effort I will also be building tools to help me harvest that data.

Read on to the next section for further insight into this work effort.

As far as how this site is concerned. I’ll continue to highlight security concerns in the OpenStack community but I will do less copy-paste posting of OSSAs and CVEs. In fact, I have a couple of pending posts I need to finish writing for you guys.

In terms of Security in OpenStack. Havana stands to be a really break out release. I’m giddy with anticipation.

The OpenStack Vulnerability Database

A sample OpenStack CORE vulnerability datastructure: vulndb.json

I have exported a couple of CSV’s from that : here

I have a sample 3d.js render of one of the csv files here: here ( showing vulnerability reports by company )

This should wet your appetite for what I have planned.

The next steps are diagrammed here:

Basically, as you can see in the JSON I have already begun investigation and cataloging of datasets.

I am not happy with the schema I am currently working with. I’ll follow up this post with a new schema break out post as I get further along and solicit input from the community at large. AKA you and the OSSG.

Glossary

VMT

The VMT is the Vulnerability Management Team.

This is a VERY small team of trusted contributors whom receive new vulnerability reports. Currently there are three members of this team. New reports start out as embargo’ed. That is to say, if there isn’t a previously existing launchpad bug that is already public, a new security tagged bug will be created. Visibility of that bug will only be opened up to those folks who are brought in to help patch / fix the bug.

During the embargo period some vendors trusted contacts are informed of the vulnerability and provided access to patch sets that address the issue and will be merged later at time of public disclosure.

Eventually the bug is disclosed publicly in two formats. OpenStack releases an authoritative OSSA and will file corresponding CVEs if they do not exist already.

OSSG

The OSSG is the OpenStack Security Group.

While the VMT is a purely reactive security measure, the OSSG is a pro-active security measure.

The OSSG is a restricted team, meaning unlike the VMT it is not limited to a very small number of individuals. Currently there are 42 members. However, the team is gated for relevancy.

The OSSG performs many functions. They will assist the VMT at their pleasure as well as assist in the issuance of OSNs.

OSSA

An OSSA is an OpenStack Security Advisory. OSSA’s are issued by the VMT team and are intended to advise the OpenStack community of vulnerabilities as they occur and are addressed.

OSN ( OSSN )

An OSN or OSSN is an OpenStack Security Note. Security Notes addressing security concerns that do not justify an OSSA, or extend upon an OSSA providing further information for deployers and developers to help them avoid any potential security risks addressed therein.