Hi all,

I'd like to use this opportunity to introduce myself: My name is Clement Chen 
and I am a member of Citrix's Central Security Team. I work on the security of 
CloudStack (CloudPlatform) as well as other cloud related products here at 
Citrix.

I started working on CloudStack when Citrix acquired Cloud.com in July 2011. 
Since then I have tried to build security into every phase of CloudStack 
development cycle, activities included threat modeling, source code analysis, 
security testing and security response. My mission is to ensure that CloudStack 
is as secure as possible. And I am looking forward to having more eyes looking 
into the security of CloudStack.

I have about 10 years' experience in system security, database security and 
application security. Before Citrix, I worked on Oracle's Global Product 
Security team, handling vulnerabilities in Oracle database and middleware.

Community effort is new to me and I am very excited to be part of the 
CloudStack community.

Thanks.

-Clement Chen



-----Original Message-----
From: Clement Chen [mailto:clement.c...@citrix.com] 
Sent: Thursday, September 20, 2012 3:54 PM
To: <cloudstack-dev@incubator.apache.org> <cloudstack-dev@incubator.apache.org>
Subject: RE: CloudStack Security Team

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:j...@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

Reply via email to