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