An overview of threats and best practices in all stages of software development in the cloud.

Photo by Daniel Páscoa on Unsplash

The future of application security is in the cloud. Software development and application deployment continue to move from on-premise to various types of cloud environments. While the basics of application security (AppSec) carry over from on-premise, the cloud introduces new areas of complexity and a new set of requirements.

AppSec best practices for the cloud are somewhat different from standard AppSec best practices. Cloud applications tend to be more segmented into different services and are more likely to use other cloud services, delivered via API, to compose application functionality. AppSec teams may need to coordinate with security and ops teams from cloud service providers (CSPs) to ensure proper coverage and to adapt cloud-specific best practices. This blog covers AppSec cloud best practices and offers a basic framework on how to think about cloud AppSec.

A Quick Definition of Cloud AppSec

Cloud application security is the discipline of securing application code running in public, private, or hybrid cloud environments. Logically, this means threat modeling for cloud environments and deploying tools and controls to protect applications running in the cloud.

It also involves creating policies and compliance processes that may be different from traditional application security practices used for legacy on-premise application deployments. More specifically, traditional security for applications has focused on the network and infrastructure layer. In the cloud, because applications tend to be more accessible to third-parties via API and incorporate third-party code and services, more care must be taken to secure the application code and application environment itself.

Why Cloud AppSec is Shifting Left

For cloud applications, software development is more likely to involve rapid iterations pushed through Continuous Integration / Continuous Deployment (CI/CD) pipelines. This dynamic is causing security to “shift left” with developers increasingly responsible for writing secure code and DevOps teams responsible for testing code with security tooling prior to code submission. For this reason, the AppSec team has an expanded role in defining cloud security best practices but also teaching developers and DevOps teams how to better secure applications at the code and CI/CD pipeline stages.

Cloud Responsibilities: Who Owns What

It is critical that AppSec teams understand and plan for their level of responsibility in guarding applications. The different types of cloud environments determine who is responsible for security. In a private cloud, the organization owns full responsibility for the full stack.

For applications running in public cloud service provider (CSP) environments like Amazon Web Services, Microsoft Azure, and Google Cloud, responsibility for application security starts at the operating system layer. That said, AppSec teams should still factor in the risk of compromise of lower layers of the CSPs’ multi-tenant environment.

For Platform-as-a-Service offerings like RedHat OpenShift or Heroku, security teams are primarily responsible for security of the application code and data.

For SaaS applications, AppSec teams do not need to be involved as full responsibility is on the vendor. The only exception is if a SaaS application integrates directly into a cloud application, in which case the AppSec team must be mindful of the risks of this integration and apply controls against those risks, e.g., data loss protection or payment gateway abuse. The reality is that in an era of microservices and APIs, application security rarely stops at the application or cloud edge.

What Threats Do Cloud Applications Face?

Cloud applications face the same threats as on-premise applications plus several additional risk types. The list of threats that AppSec teams must guard against includes:

• Forced or Insider Unauthorized Access: Malicious parties accessing cloud applications to corrupt functionality or steal data
• Account Takeover: Attackers using stolen credentials, brute force or social engineering to gain access to and take control over cloud application accounts
• Misconfigurations and Inadvertent Exposure : Cloud applications have complex policy and security configuration requirements. As we have moved to self-service provisioning of cloud resources for application development, the burden of properly configuring all resources has fallen to developers, resulting in more instances of misconfigurations and inadvertent exposure of internal data or code.
• Unauthorized or Accidental Secret Leaks : Cloud applications and infrastructure leverage so-called “secrets” — shared credentials or other means that are used to access secure resources. Secrets are often the target of attackers and development teams often inadvertently expose secrets when they leave them hard-coded in repositories or in manifests for configuration files (YAML, etc).
• API Abuse and Attacks : Cloud applications invariably have APIs that are exposed to the public Internet or to partners and third-parties or external services. Attackers target APIs to exfiltrate data or conduct fraud. Because APIs are designed to be interfaces, they are often more lightly defended. APIs are generally harder to secure without impacting actual user or customer performance.
• Distributed Denial of Service : Massive flows of data and requests can cause service interruptions and take cloud applications offline. This can often be an indirect result of attacks either on CPS or on other applications living in a multi-tenant infrastructure.
• Supply Chain Attacks: Cloud applications rely heavily on the software supply chain and are constantly at risk of corruptions to this supply chain. These risks are present in third-party code and APIs included in application code, in the CI/CD pipeline where external tools are used for security and formatting checks, and in production when applications rely on third-party services to deliver application functionality.

A Quick Guide to AppSec Cloud Best Practices

For best results, think about your cloud AppSec practice as segmented into stages. The first stage, application development, requires a certain set of best practices. The second stage, formal application security, requires an overlapping but slightly different set of practices. The third stage, DevOps and production, requires yet another overlapping set of practices. The three stages do tend to blend together in rapidly iterating application development organizations but this remains a useful guide to building a cloud AppSec best practices playbook.

Cloud AppSec at the Development Stage

For developers responsible for “shifting left” application security, key considerations and best practices include:

• Writing secure code and learning secure coding practices. This ranges from training on how to write secure code
• Scheduling frequent code reviews. This is already a given but it stands to be emphasized considering that cloud application code tends to ship more frequently, making timely reviews more of a challenge.
• Running all code through linting, formatting, exposed secrets and other basic checks. This should be done frequently, even during development prior to submission but at a minimum as a pre-condition for submission.
• Running software composition analysis (SCA) or static application security testing solutions (SAST) against code before submission. This is common in mature products and services for enterprise clients who demand secure software. It is increasingly common across all software development initiatives as threats at the application layer increase, and as organizations shift security responsibility to the left.

Cloud AppSec at the Pre-Deployment / App Security Stage

AppSec teams often conduct their own security reviews on top of existing efforts by development teams. As advanced security practitioners, AppSec teams should apply a broad range of security measures and best practices more appropriate to a discrete security discipline. Specifically, AppSec working with the network security and operations teams should put in place and or at least verify and help configure solutions for the following:

• Threat modeling and threat monitoring: Part of the role of AppSec teams is to identify the most important security risks and prioritize controls and configuration setting to address those risks. This is sometimes called threat modeling and risk-based management. AppSec teams also should work closely with security operations teams to monitor for Indicators of Compromise or other signs that a threat is active and dangerous.
• Automated security testing: This should include SCA, SAST and sometimes DAST. In addition, AppSec teams should apply the same linting and formatting checks to code as well as fuzzing, when appropriate and when properly resourced.
• Role-based and Identity-based access management: This should limit the ability of unauthorized parties to access cloud application components and services, and to deploy application code or push code through CI/CD pipelines without proper authorization.
• Data and traffic encryption: AppSec teams need to ensure that all sensitive data is encrypted in storage and while moving through the application business logic. AppSec teams working on microservice deployments may also be tasked with ensuring that traffic is encrypted; in Kubernetes and microservice environments, encryption and certificate management becomes the responsibility of developers and, often, the AppSec team.
• Policy and privacy compliance: Cloud applications that use sensitive customer data, such as health data or financial account data, have stricter levels of regulatory compliance. They also have greater risk for business and reputational damage if compromised. AppSec teams must put in place and monitor policy engines and controls to validate and enforce policies. This includes privacy regulation compliance to ensure that data is properly used and breaches are properly disclosed.
• Application pen testing and other security audits: The AppSec team should periodically execute penetration tests against code as a reality check and insurance policy against configuration or security testing drift and failures.

Cloud AppSec at the DevOps Stage

DevOps manages CI/CD solutions and controls application code deployment and lifecycle. DevOps is responsible for implementing any of the elements of AppSec practices that work at the CI/CD level. This may include:

• Ensuring code passes security checks and testing prior to deployment: DevOps can apply enforcement policies to the CI/CD pipeline that automatically prevents code from being pushed live unless it is flagged to have passed the proper security checks and tests.
• Maintaining the integrity and security of DevOps tooling: DevOps teams are the keepers of this part of the tool chain, which, if exposed or breached, can allow attackers to insert malicious code into applications.
• Working closely with the AppSec team to ensure that policies and configure guidelines are followed: DevOps can help AppSec ensure that best practices are applied prior to code deployment. This reduces risks and emphasizes the proper proactive approach to cloud AppSec. This is particularly important in cloud security, because deployments are so frequent and changes to code and configurations may also be more frequent.
• Creating a business continuity plan: As the owner of deployment and infrastructure, DevOps should also create a Plan B and Plan C in case an application is compromised and an outage or unacceptable latency occurs. This can mean planning to move to alternative cloud providers or rolling back to the last known secure version of an application.

Conclusion: Cloud AppSec Best Practices and the Future

Cloud AppSec practices will continue to evolve. What we have detailed here is a starting point. Because cloud and cloud services are changing so rapidly, it is important to review cloud AppSec best practices and playbooks frequently. Just as the lines of responsibility between networking, development and operations have blurred, in cloud AppSec the lines have also blurred. Cooperation between all stakeholders is essential, however.

Responsibility for security is shifting left but the AppSec team remains the quarterback and the ultimate accountable party for ensuring that cloud applications remain safe and performant. Creating a detailed runbook for cloud AppSec and the responsibilities of the different stakeholders will help clarify your cloud AppSec approach and create a practice guide you can follow to continuously evolve and improve your cloud security.

To shift left and get started with cloud AppSec in the development stage, create a free account with a modern static analysis tool. A single scan from ShiftLeft CORE finds vulnerabilities in custom code, CVEs in open-source code, and hard-coded secrets. It is delivered as SaaS so it is easy for DevOps to integrate into your CI/CD and, because it never takes source code off of your servers, it is a safe alternative to on-prem tools.