In my last blog, I gave you some insight into some of the starting steps for adjusting your security strategies for a SaaS-enabled world. Here, I explore some of the additional adaptions to consider with PaaS.
Traditional IT organisations have seen significant gains in adopting Platform as a Service (PaaS) solutions. In this blog post, the second in a series looking at the ways to adapt your security operations to reflect the new technologies of cloud solutions, we’re going to look at what you should consider when implementing your security controls for a PaaS environment. As you’ll see, many of the strategies from SaaS will remain pertinent for PaaS, so make sure that you read the first part of you haven’t done so already.
Platform as a Service
PaaS shares a lot of core functionalities with SaaS, taking a similar approach to managing the vast majority of the underlying architecture. But instead of a final software product, PaaS offers a toolset for others to build products upon.
There are many big players in this market area who provide a myriad of different services including AWS Elastic Beanstalk, Google App Engine, Force.com and Microsoft Azure, but your choice of PaaS vendor may be restricted by the technology platform you wish to implement with. A lot of purchasing decisions might put security as a “lesser” concern, but that doesn’t mean it should be classed as unimportant or that you can’t build a robust security model for these services.
Adapting for PaaS
Since most PaaS products are geared toward software development, getting your development teams involved with developing your security approach is an important element of your PaaS planning. For many organizations, this may mean a change in approach as security teams have traditionally been involved primarily with post-development testing and have rarely interacted so early in the application development lifecycle. DevOps has mandated ever faster release cycles, making the need to “bake in” security earlier in the development process more important. PaaS security is an ideal opportunity to start adapting to this model.
The Skill Gap
The first challenge many security teams find is the skills gap. Security researchers with skills that cover application hardening are highly sought after and are often hard to source when searching for your candidates. There are options to alleviate this problem, though. For example, by encouraging an end-to-end security awareness in your DevOps team and by using new security automation tools that seamlessly link to existing DevOps approaches, you can make security checks just another part of the standard toolkit for your software developers leveraging PaaS.
Remember the lessons learned from your SaaS approach
Whilst most of the tools used to secure your SaaS products probably won’t directly support PaaS solutions, a lot of the philosophies still apply:
- Ensure you’ve assessed your PaaS vendor’s security track records. Leverage data security assessment programmes.
- Review your security approach alongside vendor and industry best practices guidance.
- Test your security controls internally and verify their validity for your deployment scenarios.
Valuing the PaaS Appropriately
For a lot of technical businesses, PaaS security is very close to the “crown jewels” of the business: the raw source code. As a result, the importance of securing your PaaS is, perhaps, even more important than traditional end-user applications. To help control these associated risks, PaaS will often require its own set of role-based access controls and potentially stricter account management requirements than other products. Many organizations have learned to adopt similar approaches to their DevOps’ account as they did to their on-premise Domain Administrator or Root accounts; losing control and insight into user access here has the potential to cause massive damage to your organization.
Success in DevOps’ security can prove to be a new challenge. Teams are often interested in measuring metrics around deployment frequency, change volume and automated test passes, so a successful strategy should involve “hooking” into these metrics. For example, if your build includes an out-of-date component, you might fail an automated vulnerability assessment tool’s test, or scoring the amount of security-related fixes versus proactive changes in a particular build might prove to be a useful metric that can be scored alongside existing measures. This can help not only to “sell” the security team’s hard work in improving the security of applications but also add to your DevOps stories for success.
For the final entry in this series, I’ll be diving into the world of Infrastructure as a Service (IaaS), where we will continue building on our adaptions for success in the cloud.
FURTHER READING ON CLOUD SERVICE MODELS:
- Secure Configuration in Cloud – IaaS, PaaS and SaaS
- Security for Cloud Services: SaaS Deep Dive
- Security for Cloud Services: IaaS Deep Dive