A single vulnerability in one of the code dependencies can put an entire application at risk, yet 48% of organizations knowingly push vulnerable code into production regularly. With a heavy reliance on open source software to build applications, patching a myriad of vulnerabilities has become an extremely hard and time-consuming task. It’s not always possible, at least not in a timely fashion, to fix vulnerabilities in the code itself. That’s where vulnerability shielding comes in, providing a compensating control in running applications for known vulnerabilities detected in your container images.
What are the challenges of mitigating vulnerabilities in runtime?
Multiple developer teams regularly build container images using different OSs and programming languages along with many open source components, libraries, and packages required to run the application. Given the sheer complexity of the environment, security teams can quickly lose insight into, and control of, their security risk posture.
Beyond that, with a vast list of dependencies to these third-party components (many of which developers may be unaware of), vulnerabilities can increase exponentially. In large environments, security teams and developers have a huge list of vulnerabilities that they need to parse, prioritize, and remediate. The reality is that even with a prioritized list in hand, it’s not uncommon for vulnerabilities to number in the thousands. Building in-house cloud native security expertise to manually remediate so many issues is an enormous challenge.
Basically, you have only three options when addressing vulnerabilities in your applications:
Fix the vulnerabilities in-house
- Takes time away from development to remediate the issue
- Requires an upgrade, patch, or complete code rewrite to omit vulnerable component
- Requires development work and a complete cycle of tests to ensure functionality and security
- Requires security expertise to apply the proper runtime controls
- Leaves the door open for attackers until it’s fixed
Acknowledge the risk and proceed without changes to the artifact
- Requires a deep understanding of the vulnerability in context of the application, and an acceptance that standardized risk severities/scores may not be accurate or relevant in the given scenario
- Can lead to exploitation if the information upon which the decision to accept the risk was incorrect, or if additional risk factors come into play in production
Wait for the vendor to fix it
- Your security risk posture is dependent on the security adequacy and effectiveness of a third party
- The fix is on the third party’s timeline, not yours
Traditionally, remediation requires manual intervention by developers, who are already busy trying to meet tight software shipping deadlines. But in fact, this remediation is only possible when a patch or upgrade is available, if the application is refactored with vulnerable components omitted, or with mitigating factors or compensating controls in place.
How does vulnerability shielding help?
To reduce the risk of running with known vulnerabilities and make it easy for organizations to mitigate vulnerabilities in runtime, Aqua has developed Aqua vShield, a runtime tool to secure vulnerable artifacts when no fix is available, or when patching is not a viable option.
Aqua vShield automates vulnerability mitigation for containers without having to rebuild the image, change any code, or redeploy the application and suffer downtime. Developers don’t need to intervene and mitigate manually, as “virtual shielding” acts as a compensating control against the exploitation of the vulnerabilities. You can apply it automatically, which greatly reduces the risk to your production environment consequent to delayed or unfeasible remediation.
How does it work? As one of the fundamental technologies behind Aqua’s vShield, Aqua’s threat intelligence system runs an algorithm against each vulnerability to determine potential attack vectors and the consequent mitigation strategy. For example, if the vulnerability can be exploited by accessing a specific port over your network, Aqua will determine that preventing network access via that port can be a viable mitigation strategy or countermeasure.
The solution can then automatically generate Aqua vShields that pre-emptively secure the artifact against such activity, allowing security professionals to avoid the onerous work of runtime vulnerability mitigation mentioned above.
Common examples of mitigation strategies from Aqua’s threat intelligence system include:
- Network attacks: Some vulnerabilities can be exploited via specific ports. For example, CVE-2019-11331 uses port 123, even for modes where a fixed-port number is not required. That makes it easier for remote attackers to conduct off-path attacks. Aqua’s threat engine finds these vulnerabilities and provides controls to block inbound and outbound connections to those ports.
- Files and executables: Aqua’s threat engine discovers the files, libraries, and executables that are required to exploit the vulnerability. Based on this discovery, Aqua provides a mitigation plan that includes stopping all access to these files and executables and then audits the respective events. One example is CVE-2019-6715, where sns.php enables attackers to read arbitrary files from the server’s filesystem via the SubscribeURL field in SubscriptionConfirmation JSON data.
Another example is CVE-2019-14697, which was found in musl Libc up to 1.1.23. It has been classified as critical vulnerability with an unknown functionality of the file math/i386/. The manipulation with an unknown input can lead to a memory corruption vulnerability, which can have an impact on data confidentiality, integrity, and availability.
In the example below, even though these vulnerabilities exist in musl package, the Aqua system identifies what the controls are so that Aqua can block and mitigate the vulnerability.
- Block package: Sometimes Aqua vShield might completely block package access. This type of control employs a wider scope and is more useful in audit mode when certain users/roles are notified of a relevant event. Thus, they may verify the use of the package and, based on that, choose the appropriate follow-up actions.
Wait, can’t other runtime protection measures prevent exploits?
Sure they can. Within the Aqua platform we have multiple layers of runtime controls, including drift prevention, network controls, file and volume controls, behavioral allow-listing, and threat mitigation controls that target specific behaviors such as port scanning. Any one of those could prevent exploits of known vulnerabilities, sometimes in several stages of execution – but… those controls are not tied back to a specific CVE, so cannot be considered direct compensating controls and don’t really help you prioritize which CVEs to fix first, unless you start researching the attack vectors and mitigation options of each – which is unrealistic.
Aqua vShield reduces risk from specific known vulnerabilities by allowing you to detect and prevent exploit attempts without the need to rebuild the image and with zero downtime in your environment. It’s also a valuable tool for prioritizing and automating the application of patches, giving security teams more opportunities to fix vulnerabilities.
For compliance teams, Aqua vShield is a demonstrable compensating control that allows organizations to expand their ability to reduce the risk from known vulnerabilities well beyond the ability to fix them at the source.
In summary
Relying solely on manual remediation of vulnerabilities can be time-consuming, prone to errors, and it requires a high degree of security proficiency to be effective. Even then, the current volume of vulnerabilities regularly incorporated into containers makes it impossible to remediate them manually at scale. Aqua solves this problem for organizations with automated virtual shielding, allowing for consistent, repeatable enforcement of mitigating factors and compensating controls.
With Aqua vShield, security administrators maintain control and have everything they need to act before a vulnerability is exploited, regardless of developers’ ability to address the vulnerability or the availability of a patch. In addition, compliance teams and auditors have a reliable compensating control that serves as attestation of security preparedness.
