Gaining additional security services is one benefit of moving legacy applications to a Platform as a Service (PaaS) public cloud offering, or legacy data into a Software as a Service (SaaS) application. However, cloud adoption usually increases an enterprise’s -- particularly the development team’s -- security responsibilities and brings new risks. Some of those risks and responsibilities are common to all public cloud types, while some are unique to SaaS or PaaS providers.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Whether PaaS or SaaS is chosen, data will be moved outside of the enterprise firewall, bringing “greater opportunity for catastrophic events to happen,” said Dan Cornell, principal, San Antonio, Tex.-based Denim Group, a software security consultancy. Hackers have become more focused on data, as opposed to defacing systems, and have become more sophisticated and innovative.
Putting data in a shared public cloud can also produce some justifiable paranoia about other folks using the same service, said Carl Brooks, analyst, infrastructure and cloud computing, Tier1 Research, a division of 451 Research. Before migrating data, ask SaaS vendors how they keep information from leaking to another customer. Is someone else going to be able to modify my data?
Parrying the paranoia, analyst James Staten likens personal security to cloud security. “It's easier to rob you at your house than to try and find you in a stadium. Cloud offers security via obfuscation,” said Staten, vice president of Cambridge, Mass. Forrester Research. Likewise, it’s easier for a hacker to get at a single company’s data than to find that company in a public cloud population. That’s one of the characteristics that make public clouds more secure, he said.
Hold public cloud providers accountable for physical and network security in service-level agreements (SLAs) because those are two areas where the enterprise can exert little control, experts said. Then, recognize that the enterprise itself bears primary responsibility for security. The key best security practice lies in development; that is, building in security requirements during all phases of application development and deployment, said Brooks.
Daily enterprise security practices count, too. “Leave all ports open, and expose all IP addresses, and enterprise data is more vulnerable in the cloud than in the data center,” said Staten. “But that's your own fault, not the fault of the cloud.”
Public cloud security buck stops at development
Development teams have the greatest influence on enterprises’ security posture, both on-premise and in the cloud, Cornell said. They know the vulnerabilities of their applications best, as well as which weaknesses can be exploited in shared environments.
Ironically, public cloud mainstreamed when enterprise developers’ security duties had decreased, thanks to automation, IT staff specialization and mature data center security systems, experts said. Now, cloud is pushing development teams – including QA and DevOps contingents – into traditional redundant security coding and more expansive security testing.
A superset of super-sized testing practices must be created for cloud security. Standard enterprise testing, typically designed for single-tenant Web applications, is inadequate for multi-tenant public clouds, said Cornell.
SaaS data and application security
Application access is the security hotspot in SaaS clouds. When testing against multi-tenant SaaS applications, authentication and authorization testing take precedence. Responsibility for access security lies on both the SaaS provider and enterprise.
Testing and development teams must vet providers to make sure that they are implementing the proper controls, said Cornell. Set testing rights and responsibilities in stone in SaaS service-level agreements. Know what tests each party will do before, during and after data is moved into a SaaS cloud application, said Brooks.
Cornell has seen organizations stipulate in SLAs that their teams will have the right to test SaaS provider’s security. For example, he said, they’ve reserved the right to send penetration testers in quarterly to try and break into the SaaS system and require that any vulnerability they identify be fixed.
In the SLA, detail SaaS providers’ responsibilities for running tests and fixing flaws, said Brooks. Without the written document, it may be hard to get vulnerabilities fixed. “Otherwise, the customer has no leverage, other than customer satisfaction, to make the provider take action,” he said.
The good news is that SaaS is a mature technology with many mature providers. Also, SaaS providers have a much higher security budget than most individual organizations.
PaaS security in a bandwagon market
PaaS is a platform for hosting applications, storage and development labs, all areas where data protection is critical, experts said. PaaS vendors’ encryption, data availability, and API key security capabilities – all traditional enterprise developer responsibilities -- must be carefully analyzed before adoption. Make sure that the PaaS providers’ framework, code vault, defect tracking, versioning and other application lifecycle management tools are compatible with the enterprise, experts said. Also, the PaaS provider should offer a roadmap for improving these processes, which should be set in an SLA.
While tests of PaaS providers’ security capabilities are important, studying its stability and character should take center stage. Compared to SaaS’s maturity and well-established vendor base – think Salesforce.com – PaaS is the Wild West. “On the one hand, you’ve got PaaS start-ups with 20 guys sitting in one little room, eating Cheetos and working 20-hour days, and doing some innovative work, and Google and Amazon on the other,” said Brooks.
The stability and financial strength of organizations can be a deal-breaker, and Cornell has seen organizations having to pass up a PaaS startup, even though it offered a strong solution for their specific business problems.
“Smaller PaaS providers usually don’t have the financial stability of a giant like Amazon,” said Cornell. “This is not to say smaller providers are less secure, simply that there is a different financial stability risk equation.” To counter this risk, enterprise developers must codify if and how to get their code off a bankrupt provider’s systems. Also, Cornell advises building smaller applications on a PaaS service before leaping into custom, mission-critical application development there.
More resources on PaaS providers
Some PaaS offerings are just virtualized systems wearing cloud clothing. “They are repurposing technologies that weren’t intended to run in clouds,” Brooks said. It’s common to see them modifying systems that were formerly used by a single user or organization.
“Most of these technologies were intended to be used where everything was running inside the firewall, is trusted or at least at the same level of trust,” Brooks said. They often focus more on providing features that let developers run their code than on people uploading malicious code to their part of the PaaS. “That malicious code goes looking around to see if it could see other legitimate users' data, or manipulate the processes that are running for those legitimate users,” he said.
The bottom line for development teams?
Development teams will be doing the technical reconnaissance and daily work of securing applications in the cloud. Experts say any enterprise using or evaluating public cloud services must bring its development team up to speed on cloud security issues, technologies and practices, especially the differences in securing data and applications in multi-tenant environment and moving data from the enterprise to the cloud.