Polymorphic Linux is unusual. It’s not how people do security. There’s no detection, learning, response. Usually you have to “do security.” Polymorphic Linux simply “is security.”
You intuitively know you want it. You love it. You’re excited at seeing a real buffer-overflow completely stopped in its tracks. You’re excited that the demos are on real-life bring-your-own attacks. The install demo was simple.
But… now what? What next? How do you tell someone all of this? How do you sleep better with your decision to install it? If you’re evaluating it for your machines/organizations, what next? Traditional cybersecurity follow-ups don’t work — are you going to look for how many threats it detected? It doesn’t detect. Are you looking for how many threats it responded to? It doesn’t respond.
This is a crucial time in cybersecurity history. Almost at the same level as when Edward Jenner first discovered that people who are exposed to cows with cowpox are immune to smallpox. How do you know that you are immune if you never face symptoms? Treatment gives us a sense of agency, not seen in immunization.
So… let’s take the next step with Polymorphic Linux!
I love breaking things apart. I love simplifying them. I simplify Polymorphic Linux into three distinct prongs.
This prong is the most unusual part of Polymorphic Linux.
The question to ask is, “Knowing that there is a buffer overflow vulnerability existing somewhere in my entire system, does Polymorphic Linux stop an attack?”
The reason this prong takes a while to wrap our heads around is because Polymorphic Linux is a security validation like no other. Our minds are so trained for detecting attacks that we look for the obvious questions, “What attacks does it detect?” or “What attacks can it scan for?”, etc. All of this depends on knowing the attack (not the vulnerability).
If you’re asking your security friend for validation, or a gut check, or whether you’re looking for a review from your InfoSec team, the best way to get a quality answer is to ask this question.
This prong is also slightly counter-intuitive, because Polymorphic Linux does not become “less secure” the easier it feels. A lot of times, easy equals insecure. Usually, a quick and easy install is just the beginning of a complex chain of policies, rules and configurations.
Polymorphic Linux maintains the same flat security posture no matter how easy or difficult you make it to install. So we just keep it easy.
The best validation here is to ask a person who runs lots of servers: “These instructions, knowing they don’t compromise security, do they work for you? How easy is this?”
Business value isn’t only for “businesses” and “enterprises” and “corporations.” When everyone is rushing to patch, being responsible for security can be a vicious business of oneupmanship, teasing and competition. Everyone is the “first!” to patch, or respond or have that clever mitigation.
Now the benefit may be very little, but the loss can be terrible. Being the person in the room who has to say, “We’re just going to watch for a patch; not much we can do” can be a serious comment.
In my opinion, however, the real impact isn’t even social or technical. It is disruption. Every time there’s that next important “must-have” patch out, it is insanely disruptive for everyone to struggle to work with code that was written overnight in a rush, and deploy it to, ironically enough, the most critical machines in your infrastructure.
NOT having to do that is one of the biggest benefits of Polymorphic Linux.
As usual, remember that not only do we provide the product, but also excellent tools to open up the underlying technology. Transparency and simplicity from a cybersecurity offering can definitely sound unusual, but it’s the only way security can ever work.
Stay secure my friends. More so, stay relaxed. We got this.