Public cloud provides a wide spectrum of services, from Infrastructure-as-a-Service (IaaS), Platform (PaaS), through to Software-as-a-Service (SaaS). SaaS is likely the most familiar, since the vast majority of organizations have consumed a SaaS application in one form or another. While traditional hosting services have evolved away from bare metal to form IaaS, and generally up the stack to PaaS, including security as part of the service will change as security gets baked-in closer to the infrastructure.
Starting with SaaS, it’s natural that security is part of the offering. Most SaaS offerings are accessed via a web browser. Everything that comprises the service runs in a datacenter. Large organizations may quiz the provider about security before signing-up, but really, how many companies ring-up the likes of Salesforce.com to delve into their security practices? It’s taken for granted that the data is secured; in-fact, a good portion of the reputation of the provider rests on this perception.
Another familiar SaaS is consumer webmail. Yes, even Gmail is a SaaS, it’s just that you don’t pay for it (well, with money, at least). Personally, I moved from a different webmail, and stuck with Gmail, simply because Gmail had less spam clogging my inbox. Certainly, there are lots of other things that attracted folks to Gmail. For example, I can keep all of my email for handy searching forever. The point is that nobody would sign-up for any webmail offering today without an expectation of basic security. Protection from unsolicited and malicious email is part of the service. It’s curious that privacy isn’t, but that’s another story.
The same could be said for hosted Exchange, human resource applications; you name it. Trying to sell SaaS without security would be impossible. However, the SaaS providers (especially smaller ones and newer ones – think Netflix) themselves are moving to using datacenters that are operated by other organizations. The SaaS providers are consuming IaaS or PaaS, and have expectations of security from those providers. There are obvious things like the datacenter of the IaaS provider being SAS 70 compliant, monitoring the network so that malicious or neglectful ‘neighbors’ on the same service don’t affect others, and so on.
I find the email server and mailbox examples quite interesting. It was not that long ago that even a small organization would balk at the idea of someone else controlling the anti-spam levers and gauges. It was perceived as too risky (what if false positives block email from our customers? What if we can’t send Word documents with macros?). To bridge this gap, providers could give control of the security to the customer, but that is largely unnecessary today; the customer doesn’t want to, or simply can’t spend time dealing with it. In the provider world, this is key; take security off the table by baking it in.
The emerging market of Desktop-as-a-Service (DaaS) and the related movement of MSPs (Managed Service Providers) to IaaS offers some interesting insights. The MSP market is struggling with customers driven by SMB, who don’t want to own stuff. That means that they have to relocate on-premise services, such as email and file-sharing servers, and end-user devices, off-premise, yet still provide management value. MSPs would therefore like to have cookie-cutter services that they can bundle and manage for their customers.
I purposely mix DaaS and MSPs because there is a common theme; use of IaaS, and the struggle for value-add at low cost. From IaaS, SaaS, and DaaS, MSPs will look for solutions that they can bundle and provide to end-users. Think of it like a restaurant. IaaS is the kitchen, SaaS and DaaS are the cooks, and MSPs are the waiters. If a customer would like a main course of financial application, with a side of human resources, served on a tablet-accessible plate of DaaS, the MSP must bring it all together as a table d’hôte.
In that analogy, the MSP needs to keep their thumb out of the soup, but they will rely heavily on the IaaS, DaaS, and SaaS to provide secure offerings as part of the base stock. In an ‘everything-as-a-service’ world, security will naturally get closer to the kitchen. The out-the-door footprint that the MSP wants is minimal; they want to collect services with security baked-in, not try to clean the offering at the last step. Enterprise IT departments that are ahead of the game should already be figuring-out how they can do the same.
There will be mixed roles for sure. What I mean by that is SaaS will know how to best secure the part of the stack (the application) that they own. It will never make sense for the IT group of an organization to put a web application firewall in front of a SaaS solution, clearly. However, it may make sense for the IaaS that is providing services to the SaaS, or DaaS to provide basic security such as network IDS/IPS or endpoint anti-malware to the MSP. It is analogous to anti-spam in email-as-a-service; it’s so basic (mature, ubiquitous, and commoditized) that it is expected within the service. The best position to apply the security is not the direct consumer of the service – it is at the lowest common provider. Only security that is tailored to the end-service should be applied at the end-service delivery point (web-app firewall in front of a SaaS by the SaaS, not their customers).
Though it is tempting, and reasonable to conclude that there is quite a bit of security that will flow down the stack and end-up at the lowest point of service (or, from the perspective of the end-customer, the highest aggregation point of their services – and as far away from their concern). Ultimately, that is the IaaS provider. If the IaaS provider creates offerings that climb the stack into PaaS and onward, it is the nature of their business to push functionality (as security can be considered) down to the lowest common denominator to enhance economies of scale across their offerings. As things stand today, that means security from the hypervisors on which IaaS provides their offerings.
Ultimately, there are two flows. One is services climbing up the stack, which creates more complete service offerings. The other is security that we have tended to think-of as outside of the stack moving in, and rapidly down, the stack. Will SQL injection attacks ever be dealt with at the hypervisor level? I don’t know, but I have seen stranger things in restaurants.