It was an offer I could not resist. A colleague from an emerging startup company approached me asking whether I could participate on a panel at RSA 2010 Europe titled "Comprehensive Perspective on Virtualization Security and Compliance." A few weeks later I was on a plane headed to London Heathrow. The RSA conference in Europe is a modest one relative to the US but has a refreshing international breeze to it. Being in the center of London certainly helps. 

I'll post something about the panel I was on soon, but in the meantime, I'd like to point out another interesting session I had the opportunity to attend titled, "Outsourcing Software Development - financial success or security failure." The panel included senior security functionaries from leading companies in the financial service industry, the IT industry, and the health care industry. Though this was a very interesting session, I was a bit disappointed in the lack of awareness and acknowledgement of the risk of outsourced developers being brought into an organization and given the access of a privileged users.

It's a common belief that developers do not tend to think about security while building applications. This is even more likely when dealing with external developers that are outsourced by organizations to deliver quick and cost effective applications. Most of the discussion was focused around the risks that may be introduced to the application, and the need to manage the IP. This starts with communicating requirements as they relate to security, as well as functionality. You cannot expect the developer to think about the security requirements on his own without the context of the organizational policies. It is important to define who is responsible for any security issue remediation, end of life of the software and the secure off-loading of the application and its data gracefully.

In essence, Governance of the process is where the most failures are found. How do you govern your provider to manage the risks associated with software development and production?

What was disappointing to me was that none of the panelists proactively referred to the risk of the outsourced developer as a privileged user. The developers need to have privileged access to the dev, test and some time production environments for support. This privileged access can be leveraged maliciously. Also, there are accountability and audit challenges that need to be considered especially when an external provider is involved. I asked the panel of their thought on how this risk is addressed and mitigated.

The panel agreed that this was a recognized risk. Naturally, having separate environments and limiting access to only dev and maybe test is a minimum requirement, also relying on secure VPN access is a must. But also entitlements management is imperative. Questions to consider: Do the outsourced developers need full privileged access to the environment? Can controlled or limited privileged access be provided?