PaaS is a cloud model through which service providers deliver an environment where customers can develop, run and manage applications. Because PaaS providers host the hardware and software on their infrastructure, customers aren’t burdened with having to do so in-house.
This sounds simple enough, but when it comes to security, things can get a little complex.
PaaS use is part of a broader enterprise application development exercise. Organizations use PaaS to streamline the development of RESTful APIs, application services and components that provide business logic. While some definitions include traditional web hosting — or elements of it — in the PaaS bucket, from a practical, security-oriented point of view, securing PaaS use is closely tied to securing the underlying application supported by PaaS.
To start, every PaaS security checklist should include contractual negotiations with providers and review and validation of vendor environments and processes. This should also include identification of security models in use and security-relevant tools available to the customer.
Note that other cloud use cases involve similar security precautions — these are not unique to protecting PaaS. However, on top of these, security teams need to focus in equal measure on the application itself. This is what makes PaaS so much more challenging to secure than other cloud models.
PaaS security strategies will vary to accommodate the enterprise environment, business context and industry usage. However, there are five PaaS security best practices that can be applied in almost every situation. Incorporating the five steps below can help guarantee applications are built and run safely with relatively little investment.
Best practice #1. Start with threat modeling
Application security, PaaS or otherwise, should start with threat modeling. This systematic process deconstructs an application design into component parts and analyzes how those parts interact through an attacker’s eye lens. In evaluating application components and associated risks, threat modelers can outline mitigation steps to remediate any uncovered vulnerabilities.
Regardless of which PaaS providers are in use or for what purpose, creating a systematic threat model adds value. If necessary, infosec teams can update application security testing methods to extend the threat model to microservices and mesh architecture.
Best practice #2. Encrypt data at rest and in transit
Most PaaS offerings either enable or require the customer to encrypt data in transit — with good reason. REST APIs, which communicate using HTTPS as the transport, are the gold standard architectural style in application development today, especially in a cloud context.
Stored data, in contrast, is less ubiquitously addressed. Where possible, encrypt stored data — whether it is customer data or configuration or session information. In a PaaS context, encrypting data at rest may require security teams to adopt tools specific to the PaaS providers’ APIs.
After encrypting data at rest and in transit, pay attention to secrets management. This applies to the keys created and used to implement at-rest encryption, as well as passwords, API tokens and other artifacts that need to be kept secure.
Best practice #3. Map and test interactions across the business flow
Using multiple cloud providers is no longer the exception, but the norm. This is as true with PaaS as it is with other cloud use cases. For example, one enterprise might employ serverless at the edge for A/B testing, AWS Lambda to implement business logic, Heroku to serve the UI, and more for other tasks. Thus, creating — and consistently updating — a comprehensive diagram of interactions is critical. This process can also support PaaS security best practice #1, since threat modeling involves creating a data flow diagram to represent how components interact.
To make sure all elements are fully covered during penetration testing, infosec teams should systematically test each element holistically and in isolation. Using Open Web Application Security Project’s Web Security Testing Guide can help teams with this process.
Best practice #4. Consider portability to avoid lock-in
One unique challenge with PaaS is that supported features, such as underlying APIs, security services and even language choice, can depend on the specific PaaS in use. For example, one PaaS provider might support Java and Python, while another might support Go, C# and JavaScript.
PaaS customers are seldom able to “drop in and replace,” due to the underlying platform APIs. Thus, it is important to employ a language that is commonly supported across different providers. This helps maximize portability and minimize lock-in. This is particularly true when considering smaller, more niche providers. Frequently used languages, such as C#, Python and Java, are typically supported across providers. Create wrappers around niche APIs to implement a layer of abstraction between an application or service and underlying niche APIs. Doing so means that, if changing providers, only one change needs to be made, rather than hundreds or thousands.
Best practice #5. Take advantage of platform-specific security features
Just as PaaS offerings differ in language choice and underlying APIs, they also differ in the security features they provide. It is incumbent on the user to understand what options are available and, where possible, enable them. Some platforms may provide a web application firewall or application gateway that can be turned on to better protect applications and services. Others might offer enhanced logging and monitoring capabilities. Infosec leaders need to identify which security options are offered and then take advantage of them.
It is also critical to maintain strong identity and credential management. Implement the cloud identity and access management, authorization and authentication models offered by the PaaS provider. Make sure to integrate them into back-end processes for administration or developer access, as well as into the application itself.
5 PaaS security best practices to safeguard the application layer