The advancement of cloud technologies has enabled a more rapid evolution of applications and, as such, much faster creation of business value. Along with opportunities, however, came certain challenges that required a rethink of traditional security strategies. In this article, we will talk about the risks and threats of cloud environments and the security challenges of modern cloud-native apps.

What is a cloud-native application?

As we deviate from traditional on-premise and virtual machines to a more cloud-native approach, we think of a cloud as a new place to write software. Cloud-native applications are initially designed for cloud architectures. Moreover, they are designed to run in a cloud and benefit from its inherent features: elasticity, limitless, and serverless.

 

Features of cloud-native apps:

 

  • Pay for what you use.
  • Dynamic procurement and resource allocation.
  • Microservices architecture.
  • Container-based.
  • Shorter application lifecycles.

Security considerations for cloud-native apps

Cloud-native apps are designed, built, maintained, and deployed differently than traditional software. But the main difference between the old and new approach to creating an app lies in continuous change: cloud-native software is delivered and evolves continuously. So how does this impact security, and what new challenges are posed?

Security challenges of modern apps

  1. Speed of changes. Modern cloud ecosystems make it possible to tremendously accelerate processes: we’ve gone from being able to build functionality in months to days or even hours. From a security point of view, this is a major challenge. Frequent code updates, fast delivery to production, and running multi-cloud make it difficult to ensure the right controls are in place. We need a different toolset that will allow us to move fast while staying secure.
  2. Restricted visibility. If we were thinking about 10-15 machines previously, today, infrastructures could potentially contain thousands and thousands of containers. With new functionality only a few clicks away, cloud systems tend to sprawl and grow in complexity. We need precise visibility tools and mechanisms to figure out where everything is.
  3. Networking. In cloud-native ecosystems, networks are much more dynamic, and we have less insight into them. For example, workloads running serverless functions have no IP addresses anymore, and the network underlying them is completely ephemeral: you can’t manage it or secure it with a web firewall. So as cloud networks evolve, we need new ways to protect them.
  4. Configuration flaws. Modern apps have a lot of small components connected to each other. Lack of visibility leads to a poor understanding of which resources interact with one another. This can result in misconfigurations and applying excessive permissions from one resource to the other. The outcome of this may be data breaches and leaks. Therefore, we need solutions that will constantly check our stack for misconfigurations.
  5. Poor code quality. You are only as secure as your weakest code: the smallest function or container running some arbitrary code can ruin an app. Security scanning at the code level helps to ensure that the code carries no risk and makes a safe path to production.
  6. Vulnerability of open source. Potential attackers can leverage the fact that your code is likely to contain third-party modules and libraries and try to exploit their vulnerabilities. As developers use more open-source components, we must test them for potential security flaws before applying them.

Ways to protect modern apps

Modern cloud apps require a holistic approach to security that covers broad technology stacks. The diagram below depicts a multi-layered security strategy implemented across all levels of applications’ components. Let’s have a closer look at each of them.

 

A multi-layered security strategy implemented across all levels of applications’ components diagram — SHALB — Image

 

Layer 1 (Foundation) – Posture management

 

Aim: Improve security and compliance posture management.

 

Lots of cloud security breaches result from misconfigurations. To improve our security posture in the cloud, we can focus on correctly configuring our systems, examining configurations for potential flaws, and evaluating them against security compliance.

 

This stage includes constant security scanning of platform configuration (cloud, Kubernetes, or serverless) and code (container images and serverless deployment packages) to ensure everything is deployed securely and there are no misconfigurations.

 

Means of protection:

 

  • Security scanners like Trivy can find vulnerabilities and IaC misconfigurations, check third-party components, scan the cloud, discover Kubernetes security risks, and more.
  • Kubernetes cluster scanners like Popeye help discover and report potential issues with deployed resources and configurations.
  • Use integrated solutions for a comprehensive security approach like Cloud-Native Application Protection Platform (CNAPP) from Prisma Cloud.

 

Layer 2 – Strong Network Security

 

Aim: Create network security within the container or serverless application itself.

 

In modern cloud apps, the network is no longer as critical for overall application security as it was previously. Still, it remains an important component of security strategy as the first frontier of our application.

 

Firewalling. As the notion of networks changes, traditional ways of protecting them are no longer enough. Cloud network firewalls were designed to address the security challenges of cloud-native apps while considering the specifics of their operation profiles.

 

Cloud firewalls are applications and services that run directly from your cloud. These tools provide a visualized topology of containerized applications and hosts by automatically discovering all the entities within your environment.

 

Cloud-native firewalls perform two basic functions: protecting the cluster’s outer perimeter and securing connections within the cluster (communication between containers, pods, and namespaces).

 

Means of protection:

 

  • Default security from a cloud provider. Most cloud container platforms come with built-in security and firewall functionality, for example, security groups and network access control list (ACL) to protect traffic across different VPCs and subnets in AWS.
  • Cilium CNI network plugin. This allows for the building of network connectivity between container workloads based on least privilege. It includes awareness of Layer 7 communications to enhance the network security further.

 

Visibility. Modern apps have a lot of endpoints that potential attackers can use as a way to disrupt the application. Therefore, securing a single perimeter no longer guarantees safety.

 

Solution: Focus on network visibility at a resource level, monitor every individual workload, and continuously monitor cross-region and services.

 

Microsegmentation. An effective strategy of protecting internal traffic by isolating individual workloads and defining network security policies for each of them separately. Automation enables us to do this at scale and have security policies reconfigured for every workload after every change, thus saving a lot of human labor.

 

Microsegmentation uses network virtualization instead of physical firewalls. By bounding detailed security policies to individual workloads, microsegmentation software reduces the chances of an attacker abusing internal traffic even if they penetrate a network perimeter.

 

Layer 3 – Workload Runtime Security

 

Aim: incorporate threat prevention into the application workloads for continuous protection and enhancing DevSecOps.

 

This stage is about applying behavioral analysis to modern workloads while respecting the fact that our apps are much more dynamic. Therefore, we should focus on baselining and modeling so we can whitelist good behavior for workloads. For example, if there’s a Kubernetes cluster with instances of containers moving around, we need to focus on how to model all this behavior and whitelist good things.

 

At the same time, we still need blacklisting. There are common attack methods and patterns that we understand and can prevent by blacklisting some abnormal behavior.

 

Apart from that, we need to scrutinize all data we have about our workload connections and the behaviors and processes inside the workloads. We must analyze all this data across VMs, containers and Lambda functions to build the best time security profiles for our workloads.

 

Means of protection:

 

  • Adopt the principle of least privilege and provide minimum privileges and capabilities to users and resources.
  • Define a user with restricted privileges to run container images; never run container images as a root user unless you have a good reason.
  • Apply SecurityContext to Kubernetes manifests.
  • Use tools like Falco to observe the runtime security of your containers.
  • Adopt Pod Security Admission to put restrictions on the behavior of the pods.

 

Layer 4 – Threat detection & response

 

Aim: add an intelligence layer to identify and remediate suspicious traffic.

 

In a world of transient workloads and numerous small resources, we need a strong intelligent layer to deal with incredible amounts of data. We should not only look for suspicious traffic and behavior patterns but also have strong forensic tools to analyze them.

 

Another thing is that traditional analysis tools like SAST, DAST, and RASP that perform well on machines will not function on ephemeral workloads. So instead, we need to collect this data somewhere in a security appliance and analyze it to find patterns and other trails.

 

Means of protection:

 

  • Deep defense tools like ThreatMapper to discover threats in your production platforms.
  • Host Intrusion Prevention System (HIPS) solutions to monitor servers for suspicious activity and shield against malicious traffic.
  • Applying static application security testing (SAST) and dynamic application security testing (DAST) on CI/CD level.

 

Layer 5 – Anti-malware scanning

 

Aim: Continuously scan the codebase for malware.

 

In the context of modern apps, anti-malware analysis relates more to how a workload is deployed. So we need to perform it at a codebase level and scan the running images and inside the workload during deployments.

 

Means of protection:

 

  • Solutions for anti-malware scanning of cloud workloads, including default tooling from a cloud provider.

Conclusion

Modern security strategies require a holistic approach to protect an application across all levels effectively. The current tendency is to focus more on code quality and per-resource monitoring. Not sure how to organize the process properly? Contact our IT security experts for professional advice. Security hardening is among our priority areas. Our skillful team will help you adopt the latest protection techniques and minimize your organization’s attack surface.