AVOID CONTAMINATION IN
YOUR LINUX ENVIRONMENT.
AVOID CONTAMINATION
IN YOUR LINUX
ENVIRONMENT.
Containers. Whether they be Kubernetes, Docker, or something else, there’s no question as to the level of flexibility they’ve provided for the Linux DevOps space, in part because they are thought to be a safer form of deployment since they are a way to contain and monitor the operations happening within.
But from a security perspective, the best way to picture containers is as your home. Let’s say you invite a few friends (or your third-party vendors) over to have a great game night. (Yeah, we’re nerds.) Except, your third-party vendor friend Joe has a big mouth (or log4j vulnerability) and winds up telling a bunch of strangers about the party you’re throwing. Next thing you know, there are a ton of people you don’t know in your house, there’s a keg in the living room, someone broke Great Aunt Mabel’s teapot, and two guys just crashed through the bay window having a fight. And your game night has been ruined by container contamination.
WHAT IS CONTAINER CONTAMINATION?
For containerized environments running on cloud servers like AWS, Azure, or Google, a container does a decent job keeping the application within it from accessing the host. But if a malicious actor can get inside the container, the application will be disrupted. And, on a public-facing server, the potential for this type of intrusion is extremely high. While you may be doing everything correctly in terms of vulnerability patching, and coding best practices (or in our analogy’s terms, not opening the door to strangers), can you feel confident that every other developer for third party applications you leverage are behaving the same way? It’s highly doubtful and can easily result in a bunch of strangers in your house. On top of that, we’ve also seen attackers able to pivot from container to container and attacking the host for maximal damage.
HOW DOES ZEROLOCK SPC HELP PROTECT?
Ensure that no matter the insanity that may be happening in your software supply chain, your house (containerized environment) stays safe. Vali Cyber has created ZeroLock Self-Protecting Containers to act as a bouncer for your containerized network. With our SPCs, the correct processes and functions that should be happening in your container are automatically determined and defined, and then ZeroLock SPC takes over the rest. Upon any intrusion or differentiation from those processes, ZeroLock SPC can:
-
- Alert you to a change in operations within seconds of it happening
- Stop the change in operations in real-time
- Remediate any changes that were made due to the change of operations
ZeroLock SPCs are embedded with the Zerolock Application Sandbox, a runtime protection that automatically monitors the applications running in your containers for exploitation attempts and malicious compromise. The ZeroLock Application Sandbox has minimal memory overhead, averaging only 25MB per container, and minimal CPU overhead as proven empirically by SecurityPerf.
WHERE CAN I FIND ZEROLOCK SPC?
ZeroLock SPC is the “Sec” in the DevSecOps bridge your security team has been looking for.
RedHat Trial
RedHat Licensing
Extend your use to a full year via the Red Hat Marketplace: ZeroLock Self-Protecting Container on Red Hat Marketplace – United States.
IronBank
If you have access to IronBank, you can also visit our partner page there.
Not a part of those communities but want to learn more? Join our waitlist.
We’re planning to release to more environments soon, so fill out the form to join our waitlist!
TECH SPECS
OS
Linux, kernel v3.5 or higher. Distribution agnostic.
Processor
x86-64, ARM-64 (coming soon)
Memory
25MB
Disk Space
50MB
Kernel Mods.
No kernel modification or modules required.