You are here

You are here

Cloud security sucks. Unikernels will fix that

Russell Pavlicek Open Source Evangelist and Consultant, Pavilcek Consulting

You don't need to be a security expert to realize that the state of cloud security falls short of the ideal. As I write this, headlines just hit the wire about the compromise of information from a major US political party by crackers residing in a foreign power. According to, recent hacks of major organizations include insurance companies, major retailers, banks, airlines, government agencies, and much more. And those are just the incidents we know about! The number of breaches that have never been admitted in public is anyone's guess.

We like to pretend that the state of security of the IT industry is pretty good overall, punctuated only by the occasional failure. But even a brief look at the names represented on the InformationIsBeautiful website should give us pause. The number of major data breaches has soared in recent years. Clearly, we have a substantial problem that is growing at an alarming rate.

We need to re-evaluate our thinking regarding security. We need to build our applications so they are less vulnerable to attack at their core. Unikernels can help make that happen.

[ Learn how to optimize your Enterprise Service Management in TechBeacon's Guide. Plus: Find out in this Webinar if ITSM and ESM are one and the same. ]

Security: Defense in depth

Security is normally implemented in a series of logical rings. Typically, an application might have an internal security structure (passwords, rights, etc.) to protect data. Then the server on which the application resides would sit in an operating system ring of rights and privileges, possibly secured by a surrounding ring of SELINUX or equivalent system-wide lockdown. This would often reside in a LAN that has its own security protocols and (in the pre-cloud world, at least) a firewall to guard the entire structure from the wolves roaming the Internet.

With such a structure, one would hope that these security rings would ward off evildoers successfully. The concept is sound, but with the advent of the cloud, we find that we need something more, something that heightens security at the core of the matter.

[ Get up to speed on IT Operations Monitoring with TechBeacon's Guide. Plus: Download the Roadmap to High-Performing IT Ops Report ]

A Swiss cheese stack of software

Rings of security are wonderfully useful when constructed correctly. But testing the total effectiveness of these security rings as implemented is neither trivial nor failsafe. If one ring is misconfigured ever so slightly, a smart predator may be able to slip in unnoticed. Given the precipitous rise of penetrations in the past decade, we need to consider tightening the ring at the last line of defense: the application's core.

All of the current rings have one thing in common: Security is introduced after functionality. At each ring, security has to be manually introduced through rules that have to allow business to take place while (hopefully) filtering out the activity of potential enemies. That means each ring is subject to misconfiguration, insufficient testing, or just plain lack of time before deployment. In the cloud, where security defects can no longer be obscured behind a corporate firewall, we need something more: a workload that decreases its attack surface by nature rather than by election. That's where unikernels come in.

Unikernels: A naturally smaller attack surface

As I discussed in my earlier article, unikernels are a new type of cloud workload. Borrowing lessons learned in the embedded programming space and applying them to the cloud, unikernels represent the current high bar for programming minimalism. They omit the thousands of utilities, hundreds of unused libraries, and dozens of unneeded drivers that populate most application stacks today. In fact, the operating system itself is gone; in its place are just a few necessary libraries required to give the application life.

In all cases, this results in a serious reduction in size. Some results are particularly stunning, such as a fully functional web server that has a virtual machine (VM) image size of less than 1 MB, using less than 25 MB of actual memory once running. But the security benefits are equally stunning.

Should a malefactor penetrate a traditional workload, he would generally be greeted by an arsenal of tools left at his disposal by the creators of that workload. In addition to a fully functional command shell environment, he is likely to encounter thousands of flexible utilities, scripting languages, configuration information, system log files, unused databases, and even unneeded drivers that he can turn to his advantage.  

Think unneeded drivers are no big deal? Look at the recent hubbub that occurred because the QEMU had an exploit in its floppy driver that left millions of VMs vulnerable, whether they used floppies or not!

But in a unikernel, this same malevolent hacker will find no command shell, no utilities, no scripting languages, no configuration information, no system-level artifacts, no unused databases, and no unused drivers to leverage. The evildoer may have successfully exploited a flaw in the application, but he has no tools at his disposal to obtain high-value targets such as private data or secret designs.

This has a cost, of course. The wonderfully flexible computing platform on which our traditional applications sit needs to be sacrificed so that we can reduce the attack surface. This idea may not appeal to some people, but we need to reprioritize security in production over the comfort of some folks.

The traditional software stack: How did we get here?

The classic concept of the application software stack did not arrive written on stone tablets; it was developed at a time when the economics of computing was entirely different from today. Once upon a time, computers were massive beasts that were extraordinarily expensive. A single machine was used to service all the needs of a department, school, or organization.

When I was in college (shortly after the dinosaurs roamed the earth), we had one DEC PDP-11/34a computer that had to serve the needs of every student who was taking a course in math or computer science. The system had 248 KB (not a typo) of usable memory and about 25 MB of total storage to meet the needs of about 200 to 300 students in any given semester. I don't know the total cost of the system, but it was definitely into six figures in US dollars. Since the machine was so ferociously expensive, it had to include a wide range of software, covering just about every need imaginable at the time. And security amounted to not letting someone see the six-character password you had to type to log in to the system.

As we fast forward to the modern day, we find that computer hardware is both cheap and plentiful. A $500 smartphone has several orders of magnitude more computing power and storage than my old college computer system had. We routinely embed cheap single-purpose computers in just about any device that uses electricity. Special-purpose computers are found everywhere, from routers to wristwatches, from children's toys to rice cookers.

And yet, in the data center, we still build computers like we did in 1980.

When someone finds a way to hack most single-purpose embedded devices, the story gets buried in a blog somewhere because it is of little consequence to anyone; the embedded device contains just enough information to get its job done—nothing more. When someone breaks into a data center machine, you might get a letter in the mail stating that your identity has been compromised and you find yourself engaging in an expensive, prolonged battle to get your life back.

Let's harden the web

If we were to take just the web-facing systems and employ an embedded-style approach with unikernels, we could greatly reduce the impact of malevolent hackers. If we reduced their attack surface and eliminated access to unneeded (but potentially valuable) data, while maintaining the current rings of security already in place on the network, we could raise the bar on security.

Let's face it: The security status quo sucks. It's too dangerous to continue doing things the way we have been so far, with the number of major breaches rising every year. Bolt-on security measures have proved to be insufficient; there is too much room for human error and negligence. We need to up our game by making our workloads more secure at the core by employing technology that makes them less friendly by nature to intruders. Unikernels will be the key.

Image credit: Flickr

[ Learn how to roll out Robotic Process Automation with TechBeacon's Guide. Plus: Find out how RPA can help you in this Webinar. ]