RealSecurity

I was having a conversation recently with someone who just finished a project implementing a very large scale virtual environment. Once complete, their first customer said, “OK… we need 2000 servers provisioned, today.” The discussion was interesting, as was the customer’s request, and has rolled around in my head for weeks. Ultimately, I concluded that I was fascinated by the focus on “servers”, something I feel will vaporize in the near future and will have interesting implications for security – good and bad.

Virtualization is nothing new. It’s been around for several decades. The advent of VMware in the early 90’s heightened the term “server virtualization” by creating a guest platform, BIOS and all, where the user can install an operating system. In simple terms, virtualization of this nature is abstraction of hardware from the guest OS allowing multiple virtual servers to run on a single physical platform supported by a base OS running the VMware software…pretty straight forward.

Moving forward, we now have a lesser need for a supporting operating system to install and run the virtual software (i.e., Hypervisor) on which we stack guest virtual servers. Today, hypervisor technologies are becoming more and more integrated at the hardware level as well as driving the development of purpose-built, tiny OS’s – like Ubuntu’s Xen build (now Ubuntu Enterprise Cloud distro) – that exist to offer hardware abstraction working with embedded (chipset level) virtualization capabilities. In other words, the layers “below” the virtual server environment are becoming increasingly compressed and driven further into the hardware.

On the opposite end of the spectrum we have applications (software). Going back a few years, applications were virtualized via their existence on a virtual server, yet the abstraction between the OS and application was nil. It was, by most accounts, a virtual server (i.e., OS) supporting an application no differently than if the OS was running directly on the hardware. However, this has evolved to a point where applications are becoming more fluid and floating over the virtual server environment, offering slightly more decoupling between the OS and the application, but not what I would call complete abstraction between the application and the OS. Within this context, think of the application as a round peg and virtual servers as field of round holes where the application can consume one or more holes and move between them as needed (i.e., elasticity). However, the “scope” of the application (i.e., the radius of the round peg) is generally fixed and relative to the round hole represented by the virtual server. In short, the application is quantified by the existence of the platform it is running on – or across – at any given point in time. This is the fundamental reason why the customer needed 2000 servers. The application could only fit on “a” server and the number of users dictated the number of instances, which was translated into the number of servers… simple... round peg… round hole… one to one – but, fundamentally ridiculous when you think that this is a virtual environment – anything goes.

Taking this simplistic view and extrapolating, one can see we have compressed, and will continue to do so, the underlying structure of virtualization (i.e., hardware hypervisors) and are beginning to increase the separation and fluidity of applications from the underlying environment. However, the bit in the middle – the virtual server/OS – remains as the common kernel that remains relatively untouched… for now.

In cloud computing terms, I can see the OS as a barrier by continuing the virtual server’s existence. When you think of this from a theoretical perspective, all we’re doing is taking a comprehensive approach and limiting it by applying a very old concept of “server”. Why bother with servers at all? An oversimplified and obtuse statement, but looking out over the next decade I think the question is valid. If we can abstract the hardware it is presumable that we can abstract the services an operating system provides to an application.

An OS is quite comprehensive because it must address a wide range of potential uses and supporting applications is simply one element of its overall capability. In many ways, this is a waste of resources – I only need what is necessary to run the desired application. I can easily see a world where Oracle creates a database platform that is hypervisor-aware eliminating the need for an OS. Or Apache creating system service call capabilities that tie into the hypervisor running in a chip-set. In fact, I can envision a world where chip-sets can be constructed to embody traditional OS-level application service methods becoming hardware modules added to a base system to support database cloud services (PaaS) or application cloud services (SaaS) without the OS.

I’m not talking about the approaches we’re seeing evolve today, because what I’ve said is happening in different ways in specific areas. What I’m saying is that the OS and all this implies go away and applications and databases – core driving features of IT in the business – will become intertwined with the hardware. The features of the OS necessary to support applications will be absorbed into the application and the hardware, eliminating the need for the OS altogether. The bonds between the hardware and the application (together acting as a replacement of the OS) will be feature oriented and protocol-based, meaning that applications will not be aware of or even care about physical attributes. In this scenario the application simply runs “in the cloud” and there is no need for “2000 virtual servers” acting as some 20th century leftover principle limiting scale. Moreover, the protocol nature of the bond provides for complete abstraction. In the long-term applications will run in a virtual “space” that is empowered by packaged “system calls” that are spread across a highly diverse environment. In this world, the concept of memory and processors are completely abstracted from the application. The application may see one processor, but in reality it is hundreds if not thousands of processors all over the world, or even in space. Frankly, this is nothing more than grid computing-zilla.

It’s worth adding that this isn’t embedded software, like in a smart grid meter, PLC, or printers. This is still separation of hardware and software, but without the OS. From a purely business perspective, we don’t care about the OS, only that is it the mechanism to get a computer to do what we want. I’m using Word to write this… not Microsoft 7.

From a security perspective, this can be seen as a huge advantage. Purpose built interactions between hardware and software eliminate the vastness of the OS. This does not mean less complexity, but certainly a more refined scope of requirements thus reducing the number of potential avenues for failure. This is analogous to turning off unused services in an OS, but in this case I want to turn off everything except what is specifically needed. Putting aside that the OS provides some security services, like authentication and access control (and even that could be argued), the OS is a hindrance from a security perspective. It needs to be patched, updated, configured, and maintained – all so you can run an application or database that is actually what is providing the business service – what I truly want to protect. In this light, the OS is in the way.

Granted, the OS exists for a reason and therefore its removal constitutes the inclusion of a replacement – in this case the enhancement of hardware and software. Logic demands that we question the security of the replacement strategy… are we simply robbing Peter to pay Paul? The negative side to the security argument is that we’re adding complexity and relying heavily on application sophistication. Today, thousands of applications – small and large – are launched everyday; the world is a sea of applications and all of them could have been developed more securely. Not only are applications insecure in how they function, such as technical vulnerabilities, but also present logic vulnerabilities. Therefore, increasing the complexity of applications (software) and hardware, or more accurately the capability of hardware through embedded application services, does represent an unknown. Nevertheless, although OS’s provide some degree of predictability and there is a vast framework of methods and tools that are used to secure and maintain OS security, the enhancement of hardware and applications in coming together in the cloud is greatly reducing the spectrum of possibilities and offers more control.

In general, and in simple terms, the cloud has ushered in new ideas and with it new opportunities within the realm of technology. I think the concept of a server – and by association the OS – is something worth questioning within the spectrum of cloud computing. Anything is possible.

(As an epilogue, this should not be read as me being “anti-OS”. OS’s will always exist in some form, at least for the next 15-20 years. What I’m saying that in the cloud the concept of a “server” and by association the OS, is an area that is worth questioning. We’re seeing massive developments at the application and hardware layers, but not digging into what is in the middle.)