Protect Your Cloud-Native Apps from Common Security Failures

author_profile
Tricia Nagar
Tuesday, Dec 6th, 2022

The shift to cloud-native app development on Kubernetes is in full force. Today, cloud-native has become the strategy of choice in the software industry. There are plenty of reasons the industry is preferring cloud-native software development over legacy approaches.  
 
The cloud-native approach complements an agile DevOps-based model that incredibly accelerates the software development lifecycle (SDLC) to produce apps with the highest quality and lowest cost in the shortest amount of time. Augmented by microservices, cloud-native apps are highly scalable and exceptionally flexible due to automation embedded across their entire lifecycle in a continuous delivery environment.  

The Question of Security 

As such, embedding failsafe security controls into the SDLC stays central to protecting these applications from the possibility of a breach or cyberattack. In theory, security challenges of cloud-native infrastructures are as formulaic as on-premises infrastructures. And yet, they are vastly different given the relative novelty and infrastructural complexity of cloud native. In practice, every part and layer of a cloud-native application’s architecture needs security controls. Even the smallest error or security loophole in SDLC is subject to massive exploitation by today’s sophisticated threat actors. ‍ 

Why Does Security Fail in Cloud-Native Environments?  

Let us look at some reasons why security fails in cloud-native environments: 

  • Access Control or Authorization Flaws: Broken access control is the most common vulnerability in modern cloud-native apps. Without properly enforced access restrictions, hackers can masquerade as authorized users and request privileged access to highly confidential resources that are typically reserved for privileged users only. Once access is obtained, hackers are armed with the power to bypass security controls to exfiltrate sensitive information or deploy malicious payloads that can harm the entire application hosting ecosystem. Another common flaw is to implement user-level authorization, leaving behind objects and data with security gaps that are waiting to be discovered. 
     
  • Misconfigurations: The problem of misconfigurations is quite pervasive in Kubernetes container orchestration environments. Improperly configured access control policies can leave container data inadvertently exposed, providing malicious actors with unauthorized access to the application residing inside the container along with its dependencies, libraries, and other components. Often developers do not realize that not all security settings for a new container are activated by default leading to configuration oversights that create the most significant risks to cloud-native environments. Every overlooked configuration on the nodes or hosts, clusters, runtimes, and resources can open the door to a laterally moving attack that can cause substantial damage to the SDLC.  
     
  • Injection Flaws: Most vulnerabilities arise from an application’s source code, with injection vulnerabilities being the most classically dangerous ones. Code injection vulnerabilities become possible when developers fail to follow secure coding practices from the outset and are left with defective or insecure code that is subject to easy exploitation. Hackers exploit the insecure code by injecting it with their own malicious code to execute unintended commands that result in data loss, leaked secrets, disclosure to unauthorized parties, denial of access, a loss of confidentiality, integrity, and availability, and sometimes a complete host takeover.  
  • Software Supply Chain (SSC) Flaws: Software supply chain vulnerabilities are a wake-up call for security teams. These vulnerabilities can be broadly classified as an accidental security flaw (such as the infamous Log4Shell) that is discovered in a trusted open-source package, or it can be malicious code intentionally introduced into trusted open-source packages. DevSec teams must react quickly, usually within a brief period, to patch the supply chain vulnerabilities and prevent the possibility of an attack. Often the teams that struggle to react fast enough lack an up-to-date inventory of their software bill of materials (SBOMs) and the ability to find assets infected with malware.   
  • Container Runtime Threats: Containers are one of the most popular ways of deploying applications. Any type of security risk that can set back workloads hosted in running containerized application environments can be labeled as a runtime threat. Most commonly, runtime threats occur when images are compromised with malware within containers or when misconfigured containers fail to isolate compromised workloads. Runtime security vulnerabilities can be damaging as they hijack running applications, steal critical data, and negatively affect the application’s performance and availability. 

While this is by no means an exhaustive list, the security issues cited above are some of the most important reasons that keep application development teams up at night. 

Minimize Security Fails in Your SDLC

The possibility of security failures in your application development lifecycle can be minimized by proactively anticipating where the dangers lie, then taking preventive measures to forestall them. Below is some food for thought about taking approaches that outmaneuver the security issues discussed above. 
 
The foremost thing to do to minimize access control risks is to ensure least-privilege access is set-up and enforced per CWE-248 guiding principles in your Kubernetes environments while authorization checks are implemented on a granular level, this can for example, be per user, resource, or role. Consider using multi-tenant role-based access control (RBAC) to restrict access to applications, and its metadata. Assign granular permissions that are super specific to user roles, such as read-only or edit access to an asset or capability. A common flaw is to implement user-level authorization, leaving objects/data security with security gaps waiting to be discovered. 

When dealing with multi-cloud Kubernetes workloads, scanning for misconfigurations is an important necessity. Harden your Kubernetes environment by confirming against CIS benchmarks that provide several helpful configuration checks to lower the risk from cyber threats. Consider enforcing policy-driven security configurations and governance to make sure the essential orchestration layer of your cloud-native apps is watertight.

Keeping code clean is key to finding indicators of compromise such as code injections among many others. Mandate vulnerability scanning to ensure proper code-construction while staying away from using suspicious third-party packages with unknown components. Ensure that attempts to add unknown components or inject code into running workloads are blocked at all costs to prevent drift from originally trusted images or artifacts. 

A software bill of materials (SBOM) is essential to preventing SSC vulnerabilities because without one, it is difficult to know which components are vulnerable to attack and need updating or patching. In fact, different security standards are being put forth to identify practices that enhance the security of the software supply chain, including Google’s SLSA. The Biden Executive Order has clearly mandated compliance with the NIST Secure Software Development Framework (SSDF) and the NIST Software Supply Chain Security Guidance as a set of practices that create the foundation for developing secure software. To secure your software supply chain, follow the best practice of generating an SBOM during the build stage. Compare against the SBOM to root out known vulnerabilities in development, testing, production, and runtime. Scan your SBOM to look for open-source components so you can flag the ones that carry risk. 

And lastly, as previously said, any alterations to running workloads despite their originating images or artifacts must always be stopped. Enforce the software design principle of immutability to protect your containerized application environment from getting corrupted. Make sure updates are pushed only through the CI/CD pipeline and allow no patching in runtime. 

Final Thoughts

Forrester recently revealed that organizations across the United States are set to modernize their software development landscape at unprecedented rates, making it the new normal. The move to cloud-native is synonymous with the growing rise in adoption of container environments, making the Kubernetes orchestration platform the de facto standard.  

Above, we have highlighted some common reasons why security fails in cloud-native environments. As you navigate the SDLC of your modern application, consider taking the approaches we’ve discussed in this article to avert threats and optimize security.  


Did you know? Panoptica is Cisco’s cloud-native application security solution that simplifies enforcing security controls for frictionless DevSecOps collaboration. With Panoptica, you can innovate your modern cloud-native applications faster and reduce time to market by driving security automation through the entire application development process. Visit Panoptica.app to learn more. You can try it for free for an unlimited time by signing up here.  

Popup Image