This tip is part of SearchCloudSecurity.com's Cloud Security School lesson, Cloud application security best practices....
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
Visit the lesson page for related course materials. For more information security learning courses, visit our Security School course catalog page on SearchSecurity.com.
Much has been written about the different levels of security control available to an organization based on the type of cloud service being consumed. The general rule of thumb is this: The higher up the “as a Service” stack you go, the less control the organization has over security.
At the Platform as a Service (PaaS) level, an organization can build custom applications without the overhead of purchasing and managing an entire network infrastructure (or managing one through an Infrastructure as a Service (IaaS) provider). Development teams can focus on functionality, not server configuration management. Some of the most well-known PaaS offerings are Amazon BeanStalk, Microsoft Azure and Salesforce Heroku.
But, as with all things cloud, PaaS does offer some security concerns because many of the underlying security features are outside of the customer's control. In this tip, we’ll provide a short list of security areas that affect the risk profile of deployed applications, and provide some advice on how to increase cloud application security amid the increasing enterprise interest in PaaS clouds.
PaaS security linked to PaaS control
When outsourcing to a PaaS provider, keep in mind that some elements of security are outside of the customer’s control. For example, physical security responsibility resides with the provider. This is not to say the customer doesn’t have influence. A purchasing organization can ask the PaaS provider for proof of its physical security controls before signing an agreement. A few worthwhile questions to pose to the provider might be:
- Does the data center require employees to badge in and badge out?
- Is access to systems restricted on a need-to-know basis?
- Are monitoring cameras in use? Is there a backup power system or another form of HA support?
The PaaS vendor also controls the network, meaning it too is out of the customer’s control. Customers should ask questions of their vendors up front to get a feel for what kind of network security is deployed. Those questions should include:
- Are VMs in use? If so, what kind of intra-VM monitoring is in place?
- Who will you be sharing your hypervisor with?
- Are systems firewalled?
- What kind of network traffic monitoring and security event logging is being done, and does the provider have an incident response plan?
The same goes for the underlying operating system:
- Are there hardening procedures for the OS?
- Is there a patch management plan in place to ensure the OS and apps running on it are not vulnerable to known attacks?
- Is two-factor authentication required for remote administrative tasks?
Make sure you document the answers to those questions and any others you have in a service-level agreement (SLA) or receive some validation of providers' operating and physical security in writing.
There are some additional baseline security considerations to take into account before signing on with a PaaS. Determine whether the provider has passed any certifications, like SSAE 16 (formerly SAS 70), PCI DSS or ISO 27001. Beyond the obvious compliance ramifications of using providers that aren't certified, such certifications are often an indicator of the rigor of a provider's security processes. Ask whether the provider has completed assessments against common cloud security control models, like FedRAMP or the CSA Cloud Controls Matrix, both emerging industry standards for cloud security.
Look at the stability of the provider as well. The providers mentioned above are components of large organizations and likely pose little risk of disappearing overnight, but there are smaller PaaS providers that don’t have the financial stability of a giant like Amazon. An enterprise that builds custom, mission-critical applications on a smaller provider’s platform must be able to get its code off the provider's systems should the provider file for bankruptcy. This is not to say smaller providers are less secure, simply that there is a different financial stability risk equation.
PaaS and the software development lifecycle
Once an enterprise has done everything it can to vet and manage the provider side, it is time to concentrate on securing the software development lifecycle. Organizations with strong secure software development and Web application testing programs should investigate how to extend those practices and processes into the cloud. This shouldn’t be too difficult, but there may be small learning hurdles if the PaaS uses a different language or framework than the enterprise's developers work with. Or if the PaaS uses a different code vault, bug tracking or versioning tool.
Check to see if the PaaS supports static and dynamic scanners, or better yet if it provides any as part of its platform offering. If the enterprise has invested significant resources in tuning scanners for application testing and they can’t be used on applications in the PaaS, it may be necessary to purchase new scanners or look for a different provider.
PaaS is an excellent way for organizations to leverage the cloud for custom application platform support so development teams can concentrate their efforts on making great applications. A PaaS should have a strong set of information security management processes for aspects of the infrastructure that the enterprise customer can’t control, like physical, network and operating system security. And for the parts of the stack that the enterprise does control, namely the applications and the SDLC, don’t forget the critical touch points in the process where security can be built in during requirements, design, implementation and testing.
About the author
Diana Kelley is a partner with Amherst, N.H.-based consulting firm SecurityCurve. She formerly served as vice president and service director with research firm Burton Group. She has extensive experience creating secure network architectures and business solutions for large corporations and delivering strategic, competitive knowledge to security software vendors.