“Insanity: doing the same thing over and over again and expecting different results.”
As a security architect, I’ve come to truly loathe the endpoint security space. The “answer” seems to be an unending stream of “yet another agent” to layer onto an endpoint, usually just to supplement another tool that’s insufficient. Rarely, if ever, can I remove one of these tools (like AV! I still have AV after all this time?!), which means I get to encounter all sorts of conflicts and problems, and for what benefit? Why am I investing hundreds of thousands for incredibly small incremental gains? Insanity…
Part of the challenge with endpoint security is the problem state. As it stands today, we’re typically stuck in a traditional general purpose OS environment with very little useful segregation. We deploy tools that live inside this general environment and then hope that a) they keep functioning, b) don’t introduce more problems, and c) are somehow able to get enough visibility to assert reasonable control. Sheer folly. It’s like trying to estimate the size of an infinite universe from an ant’s perspective.
Putting aside specialized solutions deployed to endpoints for solving non-endpoint problems (like monitoring or controlling data movement)… the core focus of endpoint security /should/ be focused on monitoring for state changes. Unfortunately, in a general OS environment, this is very difficult because there are rarely clean, clear boundaries that can be watched for these state changes. In the mobile world we see this problem moving to a slightly more tenable position wherein wrappers and containers can be deployed to better define boundaries, which then enables watching for state changes. We’re also starting to see this in production applications that leverage a container-based micro-services architecture. All of which leads me to an interesting thought:
The root problem here is directly related to the prevalent architecture in play in general OS environments. Yes, the OS has a kernel, but almost everything is loaded and/or run external from the kernel. Apps all exist within this general operating environment with very little boundaries. We’ve seen some boundaries introduced, such as around memory management and protection, but these don’t go far enough.
The solution to endpoint security is to change the overall architecture, leveraging off key attributes such as strict boundaries and immutability. We hear a lot about immutability these days in other areas (such as micro-services), and it should be no different for endpoints. At the end of the day, the general purpose OS should go away in favor of a very tight unikernel that includes a container management function. The unikernel should have well-defined boundaries, which will allow it to be monitored for state changes that violate immutability principles.
On top of the unikernel, all applications must then run inside containers. As mentioned in the intro above, this is somewhat common in mobile operating systems, though not consistently and not to the extent that’s necessary or desirable. Every application should be well-defined and well-contained. The containerized environment should essentially be immutable. After all, the app itself shouldn’t generally change while running. If you’re upgrading the app, then that will be a controlled event.
Containers themselves should have extensive APIs available, and the unikernel should provide some form of gating mechanism to ensure that, where necessary and appropriate, only authorized queries are run against the APIs. Having rich APIs, comparable to how Docker containers exist today, is key to the next part.
Security will be provided by sidecar containers. Sidecars will be able to perform a number of duties, from simple state monitoring, to more extensive interrogation and interdiction. These sidecars will be comparable to what we see around Docker containers today, but the sky is increasingly the limit for what all could be done here. More importantly, though, is that the arms race should largely spin down, because the changed operational model greatly reduces the attack surface and attacker opportunity.
A few other notes:
- Immutability is key! In case I’ve not highlighted it enough, containerizing apps (and, essentially, the core OS in the unikernel) introduces immutability as a key attribute, which then means you can more readily monitor for state changes.
- Everything is IoT. The unikernel is essentially an IoT firmware that happens to include a container manager. BTW, this essentially kills the primary OS. Intel could embed a unikernel into their hardware and you’d never need to install an OS first, just pull the apps that you need.
- Transparent, dynamic load shifting. In this containerized world, your endpoint could have a limited hardware profile and then dynamically and transparently move workloads between the device and the cloud. Doing a compute-intensive operation? Move it to the cloud in the background. In fact, your entire container could move dynamically to the cloud and you wouldn’t necessarily notice a blip at all.
- Network needed. Yes, you can run some apps in an offline mode, just like you can do with Surface or iPad or your favorite smartphone, but more often than not you will want and need a network connection. And, for that matter, you’ll want a speedy network connection, since you’ll increasingly rely on cloud computing resources.
- Cloud storage needed. As is already the case today, you’ll have some local storage, but it will generally be limited. As such, you will absolutely need cloud storage (and a subscription model to support that). Cloud storage should have resilience built-in so we can stop talking about the need for backups, time machines, etc, etc, etc.
Challenges & Opportunities
On the basis of this new architecture (unikernel+containers+sidecars=yay!), there will be a few challenges and opportunities:
- Still a security market. In this architecture, there is still a market for security solutions. They just generally shift to sidecars, are easier to deploy, and easier to rip-n-replace. However, I think this also opens the door on a whole new world of innovation.
- Competitive unikernels. In addition to maintaining a (small) security market, there will also be an opportunity for competing unikernels. Provided standards for hosting unikernels on hardware, and standards for containers/container management, then everyone can compete on writing the best unikernel, including embedding security attributes within it.
- Need for container standard. A container standard will quickly become an absolute must!!!
- Containerizing apps. One key challenge will be transitioning to containerized apps. Again, for mobile devices, this is largely already doable with built-in capabilities (though the APIs for making sidecars a reality aren’t necessarily there). However, for traditional platforms and applications, there will still be some work required to containerize apps. Thus far I’ve not found any solutions to role out containers to a traditional Windows or OS X environment.
- Still need to write secure code/apps. Secure coding and application security will still be important. While this model should dramatically raise the bar on how an endpoint can be compromised and what can then be done with that, there will still be concerns around compromising credentials and compromising data. That said, wrapper technologies have an opportunity to come into play as a layer around the apps, but inside the containers. Or, for that matter, the containers themselves could come with additional security wrapper capabilities (as long as they meet container standards:).
- Still need data security. Similarly, data security will still be imperative, as will encryption and key management. Some interesting sidecar technologies could potentially come into play here, though, such as around opportunistic encryption, secure key management, and even a small-scale version of those cloud gateway products that encrypt data for you.
This is a game changer! The cliche is overused, but I believe this fundamentally alters the endpoint security space such that most, if not all, attack classes go away. Malware issues should be largely eliminated. Real-time monitoring and reporting becomes dramatically easier. An entire frontier of innovation opens up. We can definitively get rid of some broken operating models. If you can’t tell, I think this is an exciting concept that could be easily deployed in the near future.
This is a Security Bloggers Network syndicated blog post authored by Ben Tomhave. Read the original post at: The Falcon's View