5 PaaS security best practices to safeguard the app layer

[Pelican Press 0]

5 PaaS security best practices to safeguard the app layer

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.

Let’s look at the main PaaS security challenges and threats, along with key best practices around how to overcome them.

PaaS security challenges

One main source of complexity is that PaaS is often part of broader application development, either to support internal business applications or software and services that businesses offer to customers or partners. For example, organizations might use PaaS for the following:

• To streamline the development of RESTful APIs.
• To provide application services.
• As an architectural methodology for moving logic closer to end users.
• To implement commonly used services — e.g., relational databases — in an implementation-agnostic manner.

Supply chain practices — and their security challenges — apply to PaaS to the same degree that they apply to other software and services. This includes contractual negotiations with providers; review and validation of vendor environments and processes; and review of their validation bona fides, such as ISO 27001 certification, appearance on the CSA STAR registry, SOC 2 or similar. This might also include identification of security models in use and security-relevant tools available to the customer.

Unlike other cloud models, certain security measures are particularly useful specifically for PaaS — for example, areas where security teams need to focus on the application itself. This makes PaaS much more challenging to secure than other cloud models — first because application security isn’t an area where cybersecurity has fared particularly well historically, and second, because specific measures aren’t cookie-cutter, but instead need to be aligned to the specific use case.

PaaS security threats

PaaS faces many of the same security threats as other cloud environments, including system and resource isolation, user level permissions, user access management and protection against common cloud attacks, such as malware and ransomware.

PaaS also has a few differences from a threat — and threat mitigation — perspective.

First and foremost, consider the numerous security-relevant configuration settings and options of which security teams need to be aware, know what they mean and understand how they interact with each other and the application. Teams need to understand the risk profile they are targeting and how the settings they choose either bolster or interfere with that risk profile. It is not unheard of for some settings to be less intuitive than expected. In some cases, this can translate into weakened security posture. Additionally, security teams need to keep abreast of changes to the service — including deprecated functionality, changes to implementation and notifications from the service provider. Any of these can affect security, so pay attention.

Second, in most PaaS situations, teams have less opportunity to address security considerations at lower levels of the stack. In an application fielded to a host directly controlled by a company — for example, a virtual workload at an IaaS — teams can choose to target lower levels of the stack to make up for areas of concern at higher levels. Because the organization does not have control over the lower levels of the stack in PaaS, its opportunity to put these stopgaps in place is no longer there.

Third, PaaS is software, and all software can have vulnerabilities. It’s a bit of a tradeoff: PaaS implementations mean organizations don’t have to worry about the administrative overhead associated with patching and security updates, but organizations are now using a whole new set of services that implement the PaaS that could have software issues.

Lastly, as mentioned, PaaS is often used to directly support application building. This means any number of design, logic, coding and implementation issues can come about. These of course are specific to the application being built — and would be the case regardless of what stack the application is built on.

5 PaaS security best practices

PaaS security strategies 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.

Threat modeling helps identify potential PaaS security issues.

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. Evaluating application components and associated risks enables threat modelers to 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.

2. Encrypt data at rest and in transit

Most PaaS offerings either enable or require customers to encrypt data in transit. This is 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. Depending on the application being developed and its risk profile, teams should prevent data exposure to the extent possible beyond prevention measures from the service provider personnel that administrate the service. This helps ensure data is protected even in the event of a compromise of the underlying service provider.

One way to help support those goals is to use encryption. Wherever possible, encrypt stored data — whether it is customer data or configuration or session information. In a PaaS context, encrypting data at rest could 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.

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. Creating and consistently updating a comprehensive diagram of interactions is critical. This process also supports PaaS security best practice Step 1, because threat modeling involves creating a data flow diagram to represent how components interact.

To ensure all elements are fully covered during ************ testing, infosec teams should systematically test each element holistically and in isolation. Using

This is the hidden content, please

• Sign In
• or
• Sign Up

can help with this process.

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, 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 can seldom “drop in and replace” from one PaaS to a competing platform due in part to the underlying platform APIs. 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.

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. Customers must understand what options are available and, where possible, enable them. Some platforms might 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 take advantage of them.

It is also critical to maintain an identity and credential management strategy. 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.

Ed Moyle is a technical writer with more than 25 years of experience in information security. He is currently the CISO at Drake Software.

This is the hidden content, please

• Sign In
• or
• Sign Up

#PaaS #security #practices #safeguard #app #layer

This is the hidden content, please

• Sign In
• or
• Sign Up