In a recent column, my Security Manager's Journal counterpart, Mathias Thurman, wrote about securing virtual desktop environments. My company is going through the same exercise of evaluating VDI as a replacement for traditional desktops. As Mathias pointed out, the concept of virtualizing the applications that run on the system does not substantially change the threat landscape, nor does it modify the countermeasures we put in place to protect against those threats.
This is true in the server world as well. Physical servers are being replaced in our data center by virtual machines, but these VMs look and feel like any other server platform from the security perspective. Whether the server is real or virtual makes no difference from the network point of view. They all look the same on the wire.
But what about Internet-based services? Cloud computing and software-as-a-service (SaaS) are beginning to proliferate in my company's network, and I find myself struggling with trying to apply the best practices we are using inside our network perimeter to outside companies beyond our control. I believe that the risks associated with Internet-based SaaS services are a combination of those risks associated with traditional data center environments in addition to those of Internet-based services, added to a new set of risks that arise from the convergence of private and public environments.
We are using SaaS-based services, including the well-known Salesforce.com and Google Docs, other Web services, and outsourced third-party support and staffing services that connect into our network over the Internet. These services need to access some of our internal network infrastructure in order to work, such as our Active Directory authentication systems. Yet we don't really know that these outside companies will treat that access with the same care and caution that we use, and how do we know they are safe? All we really have is contractual reassurance. That's why I insist on a SAS70 certification from every potential SaaS vendor before we start any discussions about connecting to their service. While SAS70 may not completely guarantee that a vendor's service is safe, it at least establishes that the vendor has given some thought to protecting its customers' information assets.
When evaluating the security of SaaS services, I am concerned about some additional factors beyond traditional data center computing that need to be addressed. For instance, knowledge and control of the location of data are important for many reasons, with regulations being near the top of the list. In the past, service providers knew exactly where their customers' data resided, because individual servers were housed in specific data centers with minimal interaction from the providers. But in newer, distributed cloud environments, providers have many data centers and leverage virtualization of servers, network, and storage to provide elastic environments that can be scaled on demand. This means that finding the physical location of data can be difficult, and it can move around without warning.
And where is my data? I'm concerned about service providers commingling my company's sensitive and private data with that of other customers. Service providers typically store data from multiple customers on the same hardware. They state that controls are in place to provide logical separation of data for different customers, but validating that competitors can never access our data either intentionally or accidentally may not be possible. And how do we that ensure our data is completely removed in the situation where we want to terminate our contract with the cloud provider?
I'm also concerned about whether a service provider's physical servers are located in different places, especially when those locations are outside the U.S., and possibly even in risky locales. Ensuring the integrity and confidentiality of data when the infrastructure resides physically in other countries, especially those hostile to the U.S., can be impossible.
Mission-critical services require some thought and planning around redundancy. An established practice is to assume that any given service will fail, and plan appropriately by using redundant providers. But if the service itself goes down, we typically have defined SLAs that are published by the service providers with a provision for a cash refund or service credit based on the cost of the service, not the cost of losses due to business downtime. SLAs for SaaS services are also affected by Internet reliability -- if our Internet link goes down, access to data is impossible and there is no remediation, and our people can't work. So the Internet itself has become a mission-critical application that our workers can't live without, and it needs to be highly available, otherwise work will stop when there is no offline alternative.
Despite these challenges, my company, like many others, continues to march forward toward virtual hardware and software services, so I'm doing the best I can to secure them. There's always a new challenge in my security world, which is why I like my job. It seems like there's never a dull moment.
This week's journal is written by a real security manager, "J.F. Rice," whose name and employer have been disguised for obvious reasons. Contact him at firstname.lastname@example.org.
To join in the discussions about security, go to blogs.computerworld.com/security.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.