incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@tumbolia.org>
Subject Re: CloudStack Security Team
Date Tue, 25 Sep 2012 11:06:06 GMT
The way we manage this on CouchDB is that we have a separate, and private,
security@ list.

This is where we ask users to submit CVEs to, and where we discuss fixes.

We get the fix into a release, along with anything else that needs to go
out.

Once the release is made, we disclose the CVA in the changelog on master,
and in JIRA, and announce.

I do not think that we open JIRA tickets for CVEs, but we probably should
once they are announced, even if we close them immediately.

We don't strictly need the security@ list, but it allows non-PMC members to
work on the fix.

On Thu, Sep 20, 2012 at 11:54 PM, Clement Chen <clement.chen@citrix.com>wrote:

> Hi John,
>
> Thanks for bring this topic up. I think you lay out the scope of the
> security team very well. Just want to comment a little bit on the current
> status of security work on CloudStack:
>
> 1. On the source code review front, Fortify has been run on CloudStack
> code since 3.x. Currently license is shared so it is great that you got a
> dedicated license for CloudStack. Going forward I think it is worth to
> consider integrating Fortify with Jenkins so newly check-in codes will go
> through Fortify and potential issues can be assigned automatically. Of
> course Fortify also needs to be fine-tuned to lower the number of false
> positives.
>
> 2. On the security testing front, webapp security testing tools such as
> IBM AppScan has been used to scan the management server. Vulnerability
> scanners such as Nessus have been used to scan the system VMs. Also a
> limited amount of manual pen testing has been performed on 3.x.
>
> Many bugs have been filed as the result of the above activities. But most
> of the bugs are "private" due to security reasons. David suggested that we
> opened up fixed security bugs and obtained CVEs for them. I think doing so
> will improve the security posture of CloudStack in the long term but in the
> short term it might put some users at risk. So I guess my question to the
> community is "do you think we should open up security bugs (fixed or
> unfixed)?"
>
> Thanks.
>
> -Clement
>
> -----Original Message-----
> From: John Kinsella [mailto:jlk@stratosec.co]
> Sent: Thursday, September 20, 2012 8:50 AM
> To: <cloudstack-dev@incubator.apache.org> <
> cloudstack-dev@incubator.apache.org>
> Subject: CloudStack Security Team
>
> As this topic came up again, I wanted to discuss it without stealing from
> the IRC channel discussion.
>
> Basically - should CloudStack have a "security team" as a formal group? I
> see real and marketing value for such a thing, but I don't want to create
> structure/overhead that isn't needed. So really I guess my question to the
> community is "Do you feel the need for such a team?"
>
> One news point that hasn't been announced, yet: In the last week or two
> I've managed to get HP to donate a license for Fortify on Demand to the
> CloudStack community. I've run into some small technical bumps in preparing
> the code to be scanned but hoping to have a preliminary scan done in the
> next week or so. My goal is to get a scan done and catch any low-hanging
> fruit before the 4.0 release, but I'm not quite ready to commit to that
> yet. We'll see... :)
>
> I'll lay out what I consider the scope of such a team to be:
>  * Provide application security expertise - As ACS produces a software
> product, most of the work would be here, so I'll break this one out:
>    * Code review - A security team would participate in performing manual
> or tool-assisted security reviews before major releases or after
> significant changes were made to the code base.
>    * Secure coding assistance - either in general practice or when issues
> found during a review need to be remediated, the security team would
> provide guidance to the development community on best practices in writing
> secure code.
>    * Architecture and design review - when new functionality is being
> added, security team could provide guidance (input sanitization, encryption
> algorithms, API key management comes to mind)
>  * Incident response - In the event of a issue being found in ACS software
> or the website/etc, this team could help respond and interact with other
> Apache groups to respond to issues.
>  * Define security best practices - Along with having common network and
> infrastructure architectures, ACS should also recommend best practices for
> setting up management servers, hosts, and the like. This sounds like a
> small category, but I suspect there could be a lot of use cases to cover
> here.
>
> Others I'm probably missing, but you get the gist.
>
> Presuming this may go forward, I'd love to hear from others who have a
> security background (or decent exposure and want to grow) and would be
> interested in being part of such a team.
>
> John
>



-- 
NS

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message