When companies talk about securing their container infrastructure, they’re almost never referring to securing their containers. Instead, they’re focused on network security, application security testing, or patch management. We’ve covered why those things don’t actually work for securing containers with open source dependencies, but that won’t stop companies from focusing their dollars on the wrong things. Let’s take a look at the high-level approaches and overall methods of container security and what actually works.
Effective cyber security is more than just a secure network, especially for environments with containerized infrastructure. Investing in network security is justifiably good, but hackers have figured out how to breach networks quickly. Because they’re using social engineering and other attack vectors, security teams need to think beyond the network perimeter and resolve application security issues.
A good application security posture begins with understanding what and where the weak points are in your application environment. It doesn’t matter if you’ve built a network with the strength of Fort Knox and have a really tough firewall; if your application is talking to outside systems (e.g. ecommerce systems) and has application vulnerabilities, hackers will find a way in.
As of 2021, 60% of companies don’t even scan their containers to understand their software attack surface and existing code vulnerabilities. Whether they want to admit it, these companies are willfully ignoring issues in their applications. There’s practically no excuse for it; container scanning tools have been available to generate software bills of materials (SBOMs) for years now and they’re quite affordable. Instead, companies are spending money tightening their network security thinking it’s enough to stop a hacker from exploiting an application vulnerability.
Organizations need to focus their security efforts and policies on software attack surface management (SASM). When production applications are deployed with known vulnerabilities, they can be breached regardless of their broader security posture. Comparing application security to network security - important as it may be - is like comparing apples and oranges. They’re different and need their own methods of protection.
Unless you can completely eliminate the application vulnerabilities from your production containers, you can be breached. And if 60% of companies don’t use container security scanners or follow container hardening practices, they’re sitting ducks. Perhaps worse, the 40% of companies who are scanning are only fixing the critical- and high-severity vulnerabilities in their scan results, and only if a patch exists.
Even if companies wanted to truly secure their containers, it’s a nearly-impossible task without container hardening software. Most containers - even golden base images - have hundreds or even thousands of vulnerabilities. Let’s say a developer deploys an app into a golden base image. The golden image started with a few hundred vulnerabilities, then the app and all its dependencies add a couple thousand vulnerabilities, many of which have critical or high severity ratings.
Then the developer runs a container vulnerability scanning tool and generates an SBOM showing all of the known vulnerabilities. They’re most likely to sort the list by severity or CVSS score and start remediation efforts at the top of the list, which we’ve already shown is a losing battle. There’s just no way one developer - or even a full team - can resolve the thousands of vulnerabilities in a single application..
Hackers use cheap, unsophisticated tools and basic scripts to gain unauthorized access to private networks. They break in, sneak around, sit undetected for weeks or months, and leave with valuable, sensitive information. They have no sense of which vulnerabilities are sitting in an application container and they don’t know what the CVSS scores are. Hackers see a potential target and then run simple tools to see what works.
This is where application developers and security experts go wrong: They either forget or are unaware that the CVSS score doesn’t indicate the probability of being attacked or breached. The score merely describes how much damage can predictably be done in case of an exploit. Developers may spend hundreds of hours fixing all the highest CVSS vulnerabilities, but not all of the vulnerabilities have a high probability of occurring. After fighting uphill for some time, devs negotiate with product management and security leaders. “Do we really need to fix all these vulnerabilities? Can we make an exception?” Then they release a product that’s not secure.
Ultimately, it’s a huge waste of time and money. In a sense, people are fooling themselves with half-hearted, inefficient measures.
In other situations, organizations make huge investments in containerized infrastructure and orchestration platforms like Kubernetes. If it’s not configured correctly, Kubernetes can be easily compromised and completely open to hackers. If it’s not used properly, Kubernetes replicates vulnerable containers into different areas for performance and availability, increasing the software attack surface for that organization. If a bad actor gets into part of K8s, it’s very easy for them to propagate malicious code.
If the vulnerability is in a majority of containers propagated throughout the Kubernetes cluster, it becomes the lowest common security denominator. Unless it’s addressed, organizations are opening themselves up for a ransomware attack or IP theft.
These are the problems with current methods and approaches to container security. Teams put huge amounts of time, money, and energy into efforts that don’t actually pay off.
Our industry needs to shift focus to proper container security and real-deal remediation. In other words, we need to actually eliminate the vulnerabilities that put our infrastructure at risk. But we can’t do that by brute forcing our way through thousands of vulnerabilities one container at a time. We have to use the right container security software.
This is where RapidFort’s tools and our Rapid Risk Score (RRS) come into play. We actually remove the irrelevant code that has vulnerabilities so the remaining code vulnerabilities can be appropriately prioritized.
The RRS calculates the probability of a security exploit proof of concept (POC) becoming available within the next 90 days. Using the RRS, you can prioritize the few relevant vulnerabilities and know what’s worth fixing. Our software eliminates up 99.9% of vulnerabilities within a software container.
Container security scanning tools are a great starting point for container security, but there’s a lot of information they don’t provide. For example, an SBOM gives you no sense of whether a vulnerability exists in the execution path. It just says, “Hey, we discovered these vulnerabilities. It’s up to you to figure out what to do from here.”
RapidFort, on the other hand, knows the pain of vulnerability remediation. We built the app specifically to address the application security woes we’ve faced time and time again. Our CTO Rajeev Thakur spent six months in a previous role trying to launch a product, but couldn’t get it to market because there were too many vulnerabilities in the infrastructure. It became an interminable problem.
There’s no sense treating all vulnerabilities equally. Some have higher severity, some have higher risk of an upcoming POC, and most have no reason to exist in your workload.
Most of today’s security practices (e.g. *AST, SIEM, shift left, XDR) do very little to actually secure the applications that run in containerized infrastructure. No amount of network security investment is going to make an application secure. It’s apples and oranges.
Instead, use a security solution like RapidFort, the world’s first software attack surface management platform. Use our free tier to secure hundreds of containers right away.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。