The adoption of DevOps principles and cloud-native application development pipelines are driving cultural and technological change by helping organizations become nimbler and increase speed to market. Apart from faster developments, these technologies also offer improved user experience, easier management, higher reliability, and lower costs. In contrast to cloud-enabled applications, cloud-native applications are built and deployed in the cloud. They use containers and microservices architectures to offer quicker application development and delivery, along with greater flexibility.
By 2022, IDC predicts that 90% of new enterprise applications will use cloud-native application development pipelines, agile methodologies, and API-driven architectures. As per a survey report, around 6.5 million active cloud-native developers worldwide and about 4 million developers use serverless architectures and cloud functions. And, 92% of organizations now use containers in production.
Can Existing Security Approaches Work for Cloud-Native Architecture?
While the benefits are compelling, cloud-native architectures also introduce various new types of security risks and potential sources of vulnerabilities. Existing approaches to application security are not designed for this new paradigm. The DevOps teams instead need a new approach that can help them better identify the potential risks and enable them to integrate vulnerability management into their development and delivery pipelines.
Software development was considered a linear process earlier, but the rise of cloud-native architectures has resulted in highly dynamic application environments. Here, change is the only constant. According to research, 61% of organizations believe that their environment changes once every minute or less. The dynamic nature of cloud-native, container-based environments and the need to keep up with the speed of agile development makes detecting vulnerability and managing application security much harder.
According to a survey report, during the first half of 2020, there were 160 daily attacks against honeypots. 95% of these attacks were designed to hijack resources, whereas 5% designed to launch network denial-of-service attacks. The same research reveals that microservices, containers, and Kubernetes have created application security blind spots for 89% of CISOs.
Challenge with Detecting and Managing Vulnerabilities
Traditional security practices simply aren’t designed for this environment. As a matter of fact, cloud-native architectures are fundamentally breaking application security. Conventional approaches to vulnerability management cannot keep up with these dynamic environments because traditional methods can only offer a static view of a single moment in time. This makes them increasingly ineffective and prone to blind spots. Here’s why.
Cloud-native applications are developed with continuous streams of code that are constantly updated and deployed into the environment. Rapid software release cycles allow for every component of a microservices application to be updated daily. This incremental development creates a large attack surface for both known and unknown vulnerabilities. Security teams may find it challenging to secure these deployments without slowing down their release cycle.
Impermanence of Location
Traditional applications always have an attached server or a virtual machine (VM), which allows the application to retain the same IP address and location at all times. But, cloud-native applications neither have such permanence of location nor any clear perimeters.
In traditional applications, multiple software functionalities or processes would run on one virtual machine. Whereas now, each process or capability is packaged as a separate container, in turn exposing each entity to the vulnerability of compromise. It needs to be protected throughout the development lifecycle.
A Shift from Constant Operation to On-Demand
The rise of microservices has seen the rapid shift from constantly running applications to ones that spin up and down as needed. In these environments, as per the usage, the infrastructure turns on and off again to support digital services.
The infrastructure also allows every component to be independently and automatically spun up or down, multiplied or spun down in one place, and spun up in another. While this increases the operational efficiency of applications, it also makes securing them and managing vulnerabilities with traditional or manual approaches almost impossible.
Lack of Prioritization
The conventional method of securing applications lends a major focus on identifying and mitigating code vulnerabilities before they’re exploitable. For example, before moving an application to production, the security policy might require fixing all critical vulnerabilities, and only then would it allow you to proceed to the next step.
But assessing cloud-native applications based on the relative risk involved and the criticality for thousands of vulnerabilities is time-consuming and difficult. Besides, the lack of prioritization when dealing with a proliferation of vulnerabilities in the cloud-native supply chain and infrastructure slows development and does not position DevOps teams to mitigate overall risk.
Incomprehensive Vulnerability Scan
Vulnerability scans in cloud-native applications are often only conducted in the pre-production stage. Hence, missing out on what is running in the production stage increases the risk of vulnerable libraries running in cloud deployments. Without the ability to differentiate between potential vulnerabilities or real-world exposures, they create a mountain of alerts on every possible vulnerability. This increases the organization’s struggle to understand the risk impact of their exposure because of the sheer volume of false positives.
Uniqueness of Vulnerability
Cloud-native systems encompass a wide array of public and private clouds, application architectures, and cloud services. Each architectural pattern might have its different and unique vulnerabilities and security requirements. Security teams are required to understand these complex attack surfaces and find solutions for securing each different architecture.
Best Practices for Cloud-Native Security
When it comes to cloud-native applications, security can’t be an afterthought. Instead of relying on bolted-on solutions and approaches, security must be integrated into the continuous integration and continuous development (CI/CD) pipeline. Adopting a risk-based approach is critical, but it’s not the complete solution.
A complete solution combines this with various other layers of security that move beyond detection and assessment to remediation or mitigation. These include shifting security left, applying perimeter security at the function and container level, securing application dependencies, enforcing minimal roles and privileges, and leveraging shared responsibility for security.
One of the first implementations of this integrated pragmatic security could be by taking a risk-based approach to cloud-native development. This allows the DevOps teams to detect, evaluate and fix vulnerabilities in the artifact pipeline as an integrated component of the development process. It will also allow you to maintain ongoing monitoring of how containers behave once deployed.
The risk-based approach allows you to prioritize.The approach scores the vulnerabilities to assess how dangerous each vulnerability is. A comprehensive risk-based approach must ensure that the risks are analyzed and mitigated before the code is allowed to go into production. Hence, the security controls must be shifted into the development pipeline, and the focus should be on the artifact pipeline. This change minimizes the organization’s attack surface at runtime.
The system of cloud-native applications is broken into multiple, callable components that accept event-driven triggers from various sources. This gives attackers a larger choice of targets and many vectors for malicious activity. An important practice to safeguard against such attacks is to use API and application security tools that are built for a cloud-native environment. The general approach beyond that is to enforce perimeter security at the function level. Identify functions that are triggered by an unusual source and monitor for anomalies in event triggers.
It is imperative to ensure security at multiple levels in containerized environments. This can include orchestrator control planes, physical hosts, containers, and pods. Security best practices for orchestrators like Kubernetes include isolating nodes, using third-party authentication for the API server, and limiting and monitoring the traffic between containers.
Assigning Minimum Privileges
Since there are numerous and frequent interactions between cloud-native resources, the ability to assign a unique set of permissions to each container provides an excellent opportunity to enhance security. As a result, if any element in the cloud-native architecture is compromised, it shall cause minimal damage and prevent privilege escalation to other components.
Securing Application Dependencies
Cloud-native application code often includes packages with dependencies. And to protect your application’s dependencies, you need specific automated tools that include a comprehensive database of open-source components and their vulnerabilities.
You will also need cloud-native orchestration tools that can trigger application security activities during the development process. By running the tools mentioned above continuously, you can prevent the inclusion of vulnerable packages in a function or container running in production.
Where is Cloud-Native Security Going?
As cloud environments become more and more dynamic, organizations will have to ensure maximum coverage of applications to help avoid blind spots, detect vulnerabilities in real-time, and gain information to assess risks. A new approach to security will be required over the long term. John Morello, Palo Alto Networks vice president of product, believes that these new approaches should include:
- Securing application programming interfaces (APIs)
- Navigating the new cloud-native security metrics and culture
- Turning toward machine learning and open-source software
APIs are the most common way of linking microservices and containers, and that is what hackers target to suck down data and introduce malware into the system. Unfortunately, APIs themselves are inherently insecure and are attacked because programmatically, they’re easily accessible. As such, you will need a good security model and the right tooling to protect those microservices.
For long term and secure operation of cloud-native architecture, Morello strongly suggested making use of DevOps metrics. Because from a security standpoint, the most important metric is not the number of vulnerabilities within the environment but rather how long it takes to patch or remediate those vulnerabilities.
Detecting and managing vulnerabilities is a complex and labor-intensive task. And in the era of everything as code, security automation is a strong trend. It applies especially well for detecting misconfigurations and vulnerabilities, upgrading components, automating code reviews against security best practices, and shutting down compromised pods.
Hopefully, these best practices will help you make a safe and secure transition to a cloud-native model.