Security is undeniably the buzzword of the day. Vendors are demonstrating everything from firewalls to spam-blockers, to intrusion detection systems. We have a constant barrage of system updates to fix a seemingly endless stream of security issues. And yet, the incidence rates of security breaches is on the rise, despite the preponderance of new equipment and techniques. One reason for this seemingly paradoxical situation can be found by examining the current operating system development cycle. The focus of most vendors has been on creating patches to fix vulnerabilities, one at a time. This philosophy might best be summarized as:
However, this approach has several shortcomings. For example, it assumes that administrators will patch their systems as soon as a patch becomes available. But frequently this simply isn't possible on a live enterprise system, or at least is not immediately practical. This, combined with the reality that there are an increasingly large number of patches to apply, we consider the current operating system deployment and patch process to be broken.
The problem of flexibility
A key issue with operating systems today is not a bug; it's a feature! It's the ability to configure everything on the fly. But operating systems have made it so easy, and applying patches has become so common that it now constitutes a potential hazard. This is demonstrated by the frequent flurries of e-mails purporting to come from Microsoft, claiming to contain security patches.
(see:
http://www.hiwaay.net/support/faq/index.cgi?view=1&id=292&catid=88)
If I buy a computer with a standard operating system, that operating system is designed to work with thousands of programs. I will only need it for a few, but the potential is there for it to run any program - including viruses, worms, trojan horses, etc. This makes modern computers a very inviting place for hackers.
How does a novice administrator keep up? With less money being spent for more computers these days, administrators are doing their jobs with less and less training. Is there some way that a novice administrator can have a system that just works, with a minimum of fuss, without having to worry about their system being hacked the moment they put it on the Internet?
The Appliance Model
An increasingly common response to the problems presented by the standard model is to adopt the appliance model. Appliance systems are designed for a single purpose, and therefore tend to be more resistant to change. If there's only enough RAM on a device for a simple firewall, you don't need worry as much about a hacker placing his own software on it. Plus, appliance systems tend to have physical access controls that stop a user from changing anything fundamental about the system unless they have physical access to it. This takes care of a large portion of remote security vulnerabilities, right off the top.
However, the appliance model represents the ultimate in vendor lock-in. Not only is your computer tied to a certain vendor, but you will never get anything else to work on that system. Also, these devices tend to be designed with obsolescence in mind, as their release schedules are designed to make ensure that you will want a newer version in a year or so.
That said, computer professionals can take several lessons from the appliance model. Because they're designed with a single purpose in mind, they're much less susceptible to compromise. Their strength is their simplicity, not their flexibility. Fulfilling that single purpose is usually accomplished with minimal requirements.
Defining Appliance Computing
What is appliance computing? There is no, one definition, but they do share some common features. In particular, the appliance model differs from the standard model in the following ways:
- While the standard model supports an almost unlimited array of software applications, appliances generally support only a very narrow set of applications.
- Appliances have a very clear distinction between what constitutes it's software, and what constitutes the user's data and configuration. The standard model doesn't typically make such a clear distinction.
- Appliances have software deployed as a single “chunk” that can exist independently of a user's configuration. Standard computers tend to divide software into as many interdependent pieces as possible, to facilitate independent development of these pieces.
- Appliances are built to work together, hardware and software. Its software isn't designed to function on any other hardware. Standard computers tend to try to separate the software from the hardware, by creating abstraction layers.
- Appliances give the user very little access to how the system works. Standard computers typically give the user access to everything.
- Appliances tend to have simple security systems: they have a clearly defined administrative space and a clearly defined user space. The deepest levels of access control are closed to the user entirely, except in an administrative mode that commonly requires physical access to the device. Standard computer systems, on the other hand, tend to have very complex security models. These user-controlled models are many and varied, and frequently problems in security result from their inappropriate use. There is also no real administrative mode: all functions of the computer can be changed and updated at all times, it's simply a matter of access controls.
There is one system that rests comfortably in the gap between these two different spaces. Linux is currently the most popular operating system for appliance computers, and it has nearly everything built into it to operate as an appliance. Yet, it's also designed to operate as a desktop system, a server system or as part of a cluster. As such, it's an ideal platform for a new computing model: "Partially Embedded Computing”. This is a system that has most of the flexibility of the Standard Model, but is designed around a single purpose or set of purposes
Partially Embedded Computing
This computing model takes the best features of both the appliance and standard computing models, and combines them into a hybrid system. This system should have the following characteristics:
- Flexibility: as flexible as a desktop system, in that any software can run on it.
- Predictability: as predictable and stable as an appliance system, in that a only the software that you want to run on it will run there.
- Operational Modes: has a modal interface, allowing different kinds of permissions in administrative mode, or in non-administrative mode.
- System Separation: clearly separates the operating system from configuration and user data, and from applications that run on it.
- Low Application Dependency: A reduced dependence on the operating system by the applications running on it.
- Hardware Independence: the operating system runs seamlessly on a wide variety of hardware.
Together, these characteristics create is a different kind of computing environment. Instead of applications being tied to the operating system, each application runs in an independent environment. Applications do not alter the operating system, and the operating system does not alter the applications. And a more clearly defined user space and administrative space are created, allowing a better separation of application functions and administrative functions. In short, a partially embedded system operates more like and embedded device, without sacrificing the ability to run any application required by the user.
The Ramifications of Partially Embedded Computing
There are a number of benefits and drawbacks to the Partially Embedded model. It isn't suitable for all application deployments, but a large number of applications benefit from this type of environment.
Some differences in practical use:
- Configuration changes made explicit
When you must specifically commit configuration changes, there is more overhead created. However, if an organization is following good IT practices, every configuration change should be logged. The partially embedded computing model formalizes this process, and therefore, encourages best practices. By acknowledging or authorizing a change, the audit process is made explicit.
- Rollbacks are easier
When operating system changes create an audit trail, you have a much easier time with functions that require either looking at previous configurations or rolling back to some previous configuration. This is a huge boon when changes have unintended side-effects or create compatibility issues.
- Upgrades are safer
Upgrades take about the same amount of work as with the standard model and a partially embedded environment. In a partially embedded environment, however, rollbacks are easily achieved. This makes upgrades much safer, as changes can be undone, more or less instantaneously, with much less effort. This doesn't, of course, mean that backups aren't still essential, as data can change or become corrupted. However, knowing that you can easily go back to a previous configuration can be quite liberating.
- Virtualization inspires flexibility and compatibility
Because of the high level of separation between the OS and application space, much more flexibility is achievable. This is most immediately apparent in systems where there are multiple versions of the same application or libraries running simultaneously. In a partially embedded computing environment, different libraries and full operating environments do not conflict with each other, as long as they're effectively managed to enable sharing of resources on the system (such as Memory and IO). And, with the ability to run multiple concurrent virtual environments, compatibility can be maintained by running both the old and the new software in parallel.
- Audits are easier and more meaningful
If you have a completely standard software image upon which to base an audit, that audit becomes much easier to accomplish. With a standard computing environment, there is so much more that needs to be verified in an audit. In a partially embedded environment, the number of operating system "Knowns" is much larger, making the unknowns that much more obvious. Thus, the amount of time spent collecting data for audits is reduced, and the large number of knowns makes the gathered data set smaller and more targeted.
- Ad-Hoc changes by software are effectively blocked
One security flaw of traditional computing environments is that all changes are accepted by the operating system. With the addition of administrative and non-administrative modes, many ad-hoc changes can be effectively blocked. Methods for engaging this mode could range from the simple, such as setting immutable bits on files and directories, to the more complex, requiring a (USB) security device to be plugged-in. This means that misbehaving software cannot perform changes to the OS, the implication being that no changes to the OS can take place outside of an administrative mode. Additionally, this means that not only does an attacker have to break-in and escalate their permissions, but they must also change the box to an administrative state.
- The operating system can be made more resistant to unauthorized changes.
One of the main security flaws of a traditional computing environment is that changes are never re-verified. Access control is verified only at the moment a change is enacted, and is never re-verified for validity or authentication. With the addition of change control, one can add authentication data (such as a digital signature) to the configuration data itself, which is verified before it is used. This requires each change to have a valid signature, and it means that unauthorized changes can only be saved if an authorized signer is tricked into approving them. Also, the decision about what pieces of the operating system can be altered can be re-verified before they are used, meaning that even authorized changes can be barred from altering certain key files.
Suitability of Partially Embedded Computing
There are a number of applications that can benefit from partially embedded computing strategies. These include:
- Internet Kiosks
- PBX systems
- Audio/Video Editing Stations
- Web servers
- Firewalls
- Mail servers
- Database Servers
Additionally, any remote, unattended system is ideal, as these systems tend to be in the "line of fire", during an attack. Other places where this environment excels are clusters and distributed computing. Having highly standardized software and a hardware abstraction make it much easier to ensure the high degree of consistency and reliability required for a cluster of computers. In fact, most server applications, especially where a high degree of reliability and standardization is required, would benefit from a partially embedded computing environment.
Conclusion
The Partially Embedded model combines the best features of the Standard and Appliance models, while maximizing its resistance to attack. The following tables summarize both characteristics: