Many IT divisions are beginning to adopt cloud-native infrastructure. This new stack embraces containerization and open-source platforms like Kubernetes and is founded on the idea of rapid software release cycles. The cloud-native approach is set to modernize enterprise software architecture — but what are the security implications of cloud-native?
This may come as a surprise to some, but cloud service providers (CSPs) are not fully responsible for the security of the applications and data they host. CSPs like AWS, Azure, or GCP primarily focus on securing the underlying infrastructure for computing and storage upon which an application is built. Depending on how an application functions, what it exposes online, and how access control is configured, there is still plenty of room for cloud-based software to introduce security risks.
Within the cloud-native paradigm, there is the potential for misconfigurations, insecure defaults, broken authorization, leaky APIs, and over-permissive states. There’s also the risk of zero-day vulnerabilities around open-source software projects. Below, we’ll dig deeper into these cloud-native risks to consider as we enter this new era.
1. Insecure Defaults
Not all cloud-native tools are secure by default — some ship with more flexible settings. Insecure defaults makeup 48% of security violations for cloud-native architecture, according to a study by Accurics. Although lax conditions might help developers get started quickly, insecure defaults pose a risk of exposing administrative privileges if left unchecked.
Most people involved in the community around Kubernetes, the popular open-source container scheduling platform, acknowledge that default settings are “too open.” 85% of participants requested the community to focus on secure defaults, according to a recent Cloud-Native Computing Foundation security microsurvey conducted by the Cloud-Native Computing Foundation (CNCF).
Another potentially insecure default setting is encryption. 81.8% percent of cloud service providers encrypt data in transit, but only 9.4% of cloud providers encrypt data in rest. The good news about insecure defaults is that they’re relatively easy to change.
2. Misconfigurations
Cloud misconfigurations are another potential threat to keep in mind. The NSA recently declared that misconfigurations are the most common cloud vulnerability. Aqua Security similarly found the problem to be quite pervasive — fewer than 1% of enterprises fixed all misconfiguration issues, while only 8% of SMBs did so.
In the cloud-native serverless world, it’s extremely easy to quickly spin up new servers and create new containers. But, without guardrails, you could end up with permissive network access, allowing ports for anyone to access. Aqua Security found that more than 40% of organizations have at least one misconfigured Docker API.
Application developers themselves often make configuration changes or even write configuration policies to apply to a whole suite of applications. Misconfigurations in the DevSecOps process could easily result in leaving data storage exposed or creating vulnerable workloads.
3. Broken Access Control
You’re probably tired of hearing about multi-factor authentication (MFA) by now. I know I am. But the fact remains that passwords aren’t working that well — they’re easily forgotten, aren’t too hard to guess, and, when reused across multiple applications, increase the overall attack surface. More authentication and authorization control are required to protect sensitive data, but unfortunately, many access control systems aren’t doing enough.
One report found that 60.8% of organizations had MFA disabled. OWASP, a leading security research group, now positions Broken Access Control as its topmost common vulnerability.
Proper access control is vital to ensure the requesting party is verified — without it, you run the risk of creating over-permissive states that expose sensitive information to unauthorized parties. These risks are probably why Github now requires all code contributors to use two-factor authentication.
4. Leaked Secrets
Six million passwords, API keys, and other sensitive data were leaked in 2021 alone. Credentials stolen in bulk from an organization’s database can put end users at risk, not to mention lead to hefty penalties. Leaked administrative credentials can be just as devastating — an accidental API key exposure, for example, could lead to the unauthorized use of internal and third-party software.
The problem is prevalent — on average, three out of every 1,000 commits on GitHub leaked a secret, reports Dark Reading. With nearly 30 million public repositories on GitHub alone, the issue is endemic. Thankfully, it’s becoming common practice to scan for secret leaks upon every code push.
Interestingly, studies show an increase in credential leaks on holidays and weekends, coinciding with when engineers are working on personal projects. (Stay vigilant, even after hours!)
5. Software Supply Chain Vulnerabilities
Just as traditional products have a supply chain, software products have one, too. From designing code to delivering it to a production environment, countless third-party frameworks and distribution models make it all possible. However, software supply chain attacks tripled in 2021, and many of these involve open-source software vulnerabilities.
Amid exploits like SolarWinds, Log4j, and Spring4Shell, we’re witnessing the fragility of packages upon which the global software supply chain rests. 38% of organizations have known unpatched vulnerabilities, found the State of Cloud-Native Application Security. Unpatched known vulnerabilities for compromised pipeline tools could be the result of a failure to track and respond to exploits promptly.
6. Shadow APIs
APIs come in two flavors — those that are documented and those that aren’t. These unknown “zombie APIs” might persist from some deprecated software. It could be shadow IT made to connect disparate software. Or, perhaps, a company has undocumented endpoints or older versions running on the public web.
Forgotten APIs could open a backdoor into internal systems. Thus, plugging up these gaps is becoming more mission-critical as API attacks rise. In fact, Salt Labs found that API attacks increased by 681% in the last 12 months. With hackers constantly brute-forcing millions of requests into all web-based systems to perform reconnaissance, they are bound to discover undocumented APIs.
It’s only a matter of time before insecure “private” integrations become public exploits. The issue underscores the need to audit your API holdings and set upfront plans for versioning and retirement. Square is a prime example of an API-first company with a transparent mission for lifecycle management.
Final Thoughts
In 2018, IBM reported that 53 percent of applications are cloud-native. This figure has already increased manifold — by 2023, over 500 million digital apps and services will be developed and deployed using cloud-native approaches.
Above, we’ve highlighted some of the top risks to consider in the move toward cloud-native software. These vulnerabilities could lead to privilege escalation and even remote code execution. Cloud-native risks need to be mitigated, as they could leak sensitive information and severely interrupt digital services.
While our list is by no means exhaustive, hopefully, it provides some introductory insights to better equip your organization as it leverages a modern technology stack.
Want more cybersecurity insights? Visit the Cybersecurity channel:
