In the May 10, 2010 issue of Newsweek magazine senior editor Daniel Lyons published an article entitled “The PC Counterrevolution”. In this article he describes how today’s corporations are moving computer infrastructures on the desktop from PCs to desktop virtualization – primarily due to attempts to standardize and control the applications running on the desktops. Lyons cites a Microsoft study stating an annual savings of $81 per PC per year. So far so good, yes? Well, what is not discussed (and usually isn’t) are the security vulnerabilities introduced by this approach.

Lyons mentions pilot program at a Canadian telecom company that delivered virtual desktops to remote workers. The IT department now “installs patches and updates in the data center, rather than on all those separate machines.” This description is common, as is the comparison of virtualized desktops to the use of dumb terminals. But are these really dumb terminals? Is it really safe to abandon patching of the clients because the desktop is now running in the data center?

Typically the answer is no. The clients are usually still PCs running Windows or some other full desktop operating system and it’s not safe to ignore securing and patching those systems. These clients typically handling removable media, provide USB “pass-through” back to the virtualized desktops, and handle the complex graphics rendering of modern desktop applications. The end result is that there is much that can still go wrong on the client. Anything that goes wrong is a potential security impact.

The situation is still worse when you consider the growing number of corporate network infrastructures that rely on physically separated networks for security (this is common in organizations that are complying the credit card processing PCI security standards for example). A user’s desk may have a primary PC on one network, another PC (or a dumb terminal) connected to another network, and perhaps even more desktops and networks. Great…no problem. But companies or users may desire to migrate to a new operating system on the local PCs or even consolidate these separate desktops to a single system. This may be the case for many reasons:

· Windows 7 on their desktop may offer better reliability and support (but their Windows XP applications won’t run on it);

· The System administrators do not want to support so many desktop PCs (but regulatory mandates make it tough to implement a better solution); or

· The company has studied the costs to provide power to all of these PCs and determined that it is not cost effective and should consolidate (but security restrictions limit the consolidation of PCs).

So what we have here is a combined environment where user functionality, corporate desires to efficiently support and control the growing PC environment, and security all must be addressed –while maximizing user productivity. As we have discussed addressing user functionality and corporate control of the desktop can be done via desktop virtualization. It is a great way to achieve these ends. All of a sudden the user may have one client on their desktop – and again it is likely to be a full PC.

However, in this scenario the risk at the client is even greater. Removable devices and graphics processing are still a risk, but now seemingly mundane features such as copy-and-paste become a security risk. Desktop PCs are just not designed to maintain separation. So are there good ways to control this? Not with the desktop virtualization software or operating system software commonly available.

So what to do? This is the exact reason Tresys developed VM Fortress. VM Fortress runs on Red Hat Enterprise Linux and uses VM Ware Workstation to provide desktop virtualization capabilities. Users may run Windows 7 or Windows XP on different networks in individual virtualization sessions and the functionality and centralized control is there as before. That’s great! But…what about security? VM Fortress provides the capability to lock down the base operating system on which the virtualization sessions are running and enable administrators to configure, manage, and control the local PC, data transfer between virtualization sessions, local devices such as USB drives, and more. All while running on an operating system and security controls that enable mandatory access controls and allow compliance with some of the most stringent operating environments in the world. Basically we get real local PC security along with the user functionality and centralized support and control.

Dave is a technology acquisition specialist for a large manufacturing firm. The major competitor to his firm has recently discovered a break-through technology that will revolutionize the industry. He has been tasked to “acquire” the information related to the new technology so that his firm can remain competitive. Dave contacts a man known only as “Bill” (via an online chat service) seeking assistance. The following includes a partial transcript of their online conversation:

Dave: I need information about the new technology being developed by the BR manufacturing company on their high tension mental processing.

Bill: That can be arranged, for a fee. How soon do you need the information?

Dave: Within the next two days.

Bill: Just a minute…

Bill: OK. I can provide the information you need. I will send you a URL to a temporary website containing the information you seek along with the bank account that will receive your fund transfer. The website will only be up for a two hour period after you receive your instructions and will include two files. The first will include enough information to convince you that the data is what you have requested. The second file will contain the remaining information and will become accessible to you after the money has been received.

Dave agrees to the transaction. Bill proceeds to signal the chips covertly embedded in the firewall of the BR manufacturing company to collect the desired information. The firewall surveys individual systems on the internal BR network by contacting cooperating covert chips in the network controllers of each workstation. The BR company network monitoring tools are running on computers that also include covert cooperating hardware which ignores the network traffic caused by the external scan and thus no red flags are raised with the security team monitoring the network. With minutes the sought after information is found and copied to the external website created by Bill. Bill sorts through the information and creates the two files that he promised Dave. He then signals Dave and watches for the funds to arrive in his bank account.

Obviously the above scenario is completely fabricated and could never occur, or could it? In February 2005 the Defense Science Board Task Force on High Performance Microchip Supply provided a report to the Office of the Under Secretary of Defense for Acquisition, Technology and logistics. In the cover letter attached to their report they stated:

“We urge greater than usual speed in implementing the recommendations of our study. The nation’s security and economic well being demands it.”

One of the major findings of their report indicated that “Trust cannot be added to integrated circuits after fabrication; electrical testing and engineering cannot be relied upon to detect undesired alterations…” [Report of Defense Science Board Task Force on High Performance Microchip Supply (February 2005)]

We have for the past 30+ years focused a large amount of effort on increasing the security of the software used in our systems to protect and control the sharing of data. Even with that effort we have fallen behind as applications and software components have become more capable and thus more complex. As a result, there has been an increase in the number of intentional and unintentional side effects that lessen the amount of trust that can be placed in these systems. As the software components became more complex, the hardware components also advanced and became more complex. With each advance in micro technology came an increase in the number of functions that were built into the underlying hardware components. As a result, the opportunity for malicious or erroneous functions in hardware has increased dramatically. As indicated earlier, if malicious code is contained in the hardware components of a system the trust of the entire system is undermined, no matter what software is used on the system.

The creation of “trusted foundries” for hardware components has helped to address part of the concern by limiting the ability of outsiders to introduce hidden functions into hardware components used in high security systems. However, this does not address the issue of unintentional flaws in the logic of these components which can be discovered and exploited by users or organizations with malicious intent. It also does not address the vast majority of systems sold by all system suppliers that include components that were not created in a “trusted foundry”. Also of concern is the inclusion of one or more malicious components to a system that is made up of otherwise trustworthy components. As in the fabricated example provided above it only takes one cooperating malicious chip in each system to completely bypass all of the security that can otherwise be added to the system.

The Common Criteria (CC) is an international security standard used to evaluate security or Information Assurance (IA) products. The National Information Assurance Partnership (NIAP) Common Criteria Evaluation and Validation Scheme (CCEVS) is the U.S. program responsible for the oversight and administration of CC evaluations and results. The NIAP program and the CC have evolved through the years such that CC evaluations are here to stay. The recent announcement by NIAP to revamp the U.S. Government Protection Profiles (PP) demonstrates a strong commitment to continue CC evaluations in the U.S. After almost 10 years of being in existence, how much has been learned from past experiences and does NIAP’s plan for the future address the concerns of CC nay-sayers?

The criticisms of the CC and NIAP are typical if you look at past and existing security evaluation schemes. Vendors complain that the evaluation timeline takes too long, potentially resulting in an obsolete product before it makes it to the validated products list. Consumers complain that the evaluated products are too constrained, such that one configuration change can put the product outside the evaluated configuration. Evaluation labs complain about the undocumented criteria they have to follow to pass an evaluation. Furthermore, vendors complain that the Protection Profiles are not realistic and too difficult to achieve. Through the years, NIAP has made many policy decisions to address these concerns. Most recently, the announcement of new PPs to reflect current functional requirements, directly addresses the problems with today’s PPs.

Although NIAP has made progress in improving aspects of CC evaluations, some issues still remain. Most notable is the number of evaluations that NIAP CCEVS can accommodate. As the oversight authority, NIAP CCEVS validators are needed to monitor evaluations and ensure that the CC and Scheme policy are appropriately followed. Because NIAP is government run, it doesn’t have the resources and funding to accommodate all requests for evaluations so vendors with no explicit government sponsor cannot participate. Unlike other CC schemes, NIAP CCEVS doesn’t require a fee for oversight. I believe the current restrictions for the kind of evaluations that will be allowed (PP compliant ones) may help to reduce the number of vendors in the evaluation queue. However, the push to require CC-evaluated IA products in the federal government and the demand for more PPs, will actually increase the demand for evaluations. The revamping of PPs is a positive sign that CC evaluations are here to stay. However, NIAP CCEVS needs to prepare for the influx of evaluations that is sure to come.

FIPS 140-2 certified USB flash drives satisfy a longstanding desire of mine. In the decades I used and observed the development of cryptographic products, I (and many others) always longed for a way to protect information with a portable and affordable product. I know that there were some expensive and luggable (for me) products available to protect data that were impractical for the average user. It seemed like this technology would never miniaturize like others to meet my desires, probably due to its lack of market pressure. But finally the pressures of protecting intellectual property, financial, personal and other information provided a business case for these products leading to the announcements of certified products by vendors. Now for a few hundred dollars (see I am not really cheap), we can protect large amounts of information in a product that easily fits in a pocket.

FIPS 140-2 Level 3 certification of USB flash drives indicates that the cryptographic module implementation passed an evaluation by a certified lab of the product’s ability to meet the requirements of the standard. This means that these module implementations will protect information well enough to meet Government security assurance requirements. These certified modules also provide individuals and companies that use these algorithm implementations the same assurance. Note that most of the products certified contain additional non certified functions and cryptographic algorithms.

So let’s just buy a few USB flash drives and all of our security problems for our information evaporate right?

Don’t we wish?

Like all products evaluated to conform to a security product certification, the certified USB flash drives only claim to perform the functions cited in their certification. This means that they protect information stored in the USB flash drive but not any information outside of its boundaries. They don’t guarantee that:
• Stored information contains no malicious code such as viruses or spyware
• The computer actually writes the information selected by users for storage to the flash drive
• The computer that reads the flash drive does not keep a copy of the unlocking password, data retrieved or the history from web sessions
• Back up of the stored information

So when I purchase my certified flash drive, I must and will employ good and responsible computer security practices to ensure I am not a part of the problem.

Security always sounds like a good idea until you try to implement it.

“Out with old, in with the new” seems to be the new motto from the National Information Assurance Partnership (NIAP) Common Criteria Evaluation and Validation Scheme (CCEVS) who just recently announced a new policy for Common Criteria (CC) evaluations in the United States. In a nut shell, NIAP is revamping their Protection Profiles (PP) and asking vendors to comply with these new PPs. If no PP is available that “fits” the vendor’s product features, the vendor is still allowed to submit a Security Target (ST) but requires government agency sponsorship. PPs are used by the US Government to specify security requirements for a particular technology or solution. Vendors build products to satisfy PPs thus meeting the security needs of the US Government. More information on PPs can be found here. I’m excited about the new PPs because they reflect security requirements that are achievable. One of the major criticisms of US PPs is that they were setting a bar for future products thus making it difficult to impossible for vendors to show PP compliance with their current products.

The NIAP program has been around for close to a decade and we’ve witnessed many changes in its organization, policies, and the CC itself. The NIAP CCEVS is the U.S. Government’s program for overseeing CC evaluations that are conducted by commercial labs. Vendors submit their products for evaluation either to show compliance to a PP or to have it evaluated against a ST with no PP. A successful evaluation results in the product being placed on NIAP’s validated products list. The mandate for CC-evaluated Information Assurance (IA) products prescribed in NSTISSP #11, DoDD 8500.01E, and DoDI 8500.2 has caused the demand for CC evaluations to increase drastically. Although a potential boost in sales for vendors, the NIAP program still struggles to keep up. NIAP has been the producer of the PPs. These policies assume the validated products list is rich in product choices and even more so that these products are PP compliant. Showing compliance to a PP means there have to be PPs available for various technology areas and if there is a PP, it has to reflect requirements that are achievable. The last few years have shown us that there aren’t enough PPs and of the ones that are available, many vendors are not able to demonstrate compliance.

The announcement to rethink PPs and essentially have a do-over is a smart move by NIAP. They are addressing the need to have comparable and repeatable results and to have functional requirements that are inline with current implementations. The inclusion of soliciting comments from vendors and stakeholders is also a positive step forward. I believe vendor buy-in is a must towards achieving PP acceptance by the CC community. NIAP will be issuing PPs in two ways referring to them as Interim PPs and Standard PPs. However, the announcement has vendors anxious because they don’t want to start a new evaluation knowing new PPs are soon to be posted. The next challenge facing NIAP is expediting the publication of the new PPs to get rid of the old.

Now that the details of Google Chrome OS are finally starting to emerge after months of speculation it’s possible to look at some of their thoughts on security. The official page for the open source Chrome OS has good general introductory material – you probably want to start with the overview video . The features that Google views as highlights are clear:

• Incredibly fast – boots in 7 seconds to login prompt
• Internet focused – simplifies the user interface, reduces maintenance, and removes the need for backup (everything is stored online already)
• Security – the simplicity and legacy-free nature of the system allows deep security integration

A lot of this is compelling, especially for a certain class of casual home user. There is a lot of good news in terms of security as well.

Google is building on the separation and isolation ideas that went into the Chrome browser and, by reducing the system down to just supporting the browser, they’ve made it possible to harden the underlying system to reinforce those features. Will Drewry – one of their security engineers – is even talking prominently about the use of Mandatory Access Control in this overview video on the Chrome OS security features. It’s hard to draw conclusions on what the security of the final version will be at this point, but I’m optimistic. The focus on identifying threats is the right first step and many of proposed ideas for dealing with those threats are reasonable.

Unfortunately, it may not be all good news, especially for improving the security of all Linux systems, not just Chrome OS. Most worrying is the discussion on their security page of creating a new LSM. The Linux Security Module (LSM) interface was added to the Linux kernel to allow different access control mechanisms to be plugged-in to the kernel. In some ways LSM allowed security to move forward in Linux because it allowed advanced access control mechanisms to be merged without getting everyone’s agreement – which would have taken years if it happened at all. The downside is that LSM fractured Linux security into several competing mechanisms (the whole AppArmor vs. SELinux fight is still echoing around the internet today). This splits the limited security development effort across several solutions and, more importantly, makes application developers reluctant to add integration that could greatly improve security. Most application developers don’t want or have the knowledge to choose between several competing mechanisms and almost never want to invest the effort into integrating with all of them.

Google choosing to create a new access control mechanism through an LSM would worsen this problem. It means they aren’t investing in improving any of the existing solutions and are further fragmenting the security space.

They also hurt themselves because they don’t benefit from the research, testing and real-world experience of the current LSMs such as SELinux. There is a fine line between innovation and the not-invented-here syndrome. Unfortunately the ideas on new LSMs that they’ve posted so far seem too mundane to represent true innovation.

The bigger picture security concern is of course the internet-focused, all your data is stored in the cloud concept that is at the heart of Chrome OS. Many of the early comments on Chrome OS are from those that don’t want to trust their data to others – a view that I understand. On the other hand, most users and even businesses are much worse at data security than the top tier internet services. Ultimately it’s not a question of whether the cloud is secure in a general way – that’s a question that is so broad that no meaningful answer is really possible.

The real problem with cloud security is that there is no satisfying way for users to know whether the specific service that they are using is secure today and tomorrow. This is true in the most casual sense; users typically don’t have enough information to know whether a service is one that provides good security or one that will lose an entire container full of un-encrypted backup tapes . It’s also true in a more formal sense; our security standards and evaluation procedures are just not good enough. Just try to imagine the Common Criteria evaluation of Gmail. CC, like most security standards, was designed to evaluate individual components (e.g., a database or an operating system for example) not entire interconnected solutions delivered via un-trusted network connections. Even standards that are trying to answer some of the questions posed by the cloud – such as the PCI Data Security Standard that most payment processing systems follow – don’t have answers on how to evaluate the risk to your personal computing life or business posed by using a service.

These problems are not new. The security community has been struggling with evaluating complex systems built from components from the beginning for formal security evaluation. The cloud, with its complex connections and rapidly evolving technology, just make the problems that much harder. While Chrome OS doesn’t provide any answers it doesn’t really make things worse. It just points to a possible future when the question will be much more important.

To help assist in simplifying the process of certifying and accrediting Linux systems, Tresys Technology integrated a ‘standardized’ security verification mechanism into CLIP (our Certifiable Linux Integration Platform). The verification mechanism relies on the Open Vulnerability Assessment Language (OVAL) to perform detailed security checks on every component of the operating system. For more information about OVAL, read ‘An open source security language: What is OVAL?, written by Ed Sealing.

Since certification and accreditation is an important component of securing systems within the federal workspace, Tresys based all security checks on the Unix Security Technical Implementation Guide (STIG), provided by DISA. The output of these checks is a report generated in the form of a webpage that shows what STIG checks have passed or failed.

Reductive Labs – the organization behind the Puppet IT configuration management tools – recently announced that they have received $2 million in funding to “expand the company and further enhance its flagship offering – Puppet”. It’s exciting to see this type of investment and how it will accelerate the development of Puppet.

Part of why its interesting to Tresys and the open source community is because we’ve begun using Puppet as part of the CLIP project to simplify system configuration and lockdown. The way we are using Puppet within CLIP is very exciting and the interest that we’ve gotten from the government security community seems to confirm this.
 
The goal of CLIP is to transform a vanilla enterprise Linux distribution into a locked down system that meets stringent security requirements including all of the DISA Stigs and the NSS 1253 (which will likely be subsumed by the recently released 800-53 draft). The lockdown is difficult because it requires touching a large portion of the system to tighten file permissions, configure many of the OS security features(such as PAM and the audit system), and set security options on many other applications and services. Previous versions of CLIP did this lockdown using a variety of hand written scripts.
 
While effective, we were never really happy with the scripts. At a basic level the scripts simply replicated the steps that an admin would do by hand to transform a stock system. They were like a very long, complex recipe: set the permissions on this file, add this line to a configuration file, delete this line from some other configuration file.

It was very difficult to track back all of these obscure, low-level actions to the security requirements because you needed to know not only the action that was being taken but what the system looked like before the action was taken.

This approach also made the configuration scripts very brittle because they depended on the system being in the exact right starting state that the scripts expected. This also meant that the configuration scripts could only be run once and there was no way to check whether a system was properly configured. At the end of the day, this means that creating, customizing, and maintaining a CLIP system was, while dramatically easier than by hand, still too time consuming and difficult.

Puppet takes a fundamentally different approach. Instead of focusing on what low-level steps should be performed, Puppet lets you describe how you want the system to look at a higher level. This makes the puppet configuration clearer and easier to track back to a set of high-level requirements. It puts the focus on the outcome rather than how to achieve that outcome. To actually apply the configuration, Puppet compares the current state of the system to the description of the desired state and automatically figures out what steps need to be performed. This means that you can apply the configuration many times and only the steps that
need to be performed are done. It also means that you can check to see if a system is still configured correctly.

When I first learned about this approach to system configuration I was blown away. In some ways switching the emphasis to describing the outcome instead of how to get there seems like a small change, but the implications are huge. It lets administrators and developers think about the fundamental issue and shifts the tedious and error prone parts of the problem onto smart tools. It’s definitely improving CLIP and our approach to system lockdown.

I’m not the only one excited by the Puppet approach – there is an increase in interest in Puppet from around the globe and across many large and small organizations. The Reductive Labs funding is just a confirmation of the momentum. The time – and therefore cost – savings of using Puppet will continue to drive it’s broader adoption.

The recent SMM cache poisoning vulnerabilities released by the Invisible Things Lab team are a regular topic of conversation with customers lately. These vulnerabilities are definitely important, but they are not (currently) a huge practical threat, especially for non-virtualized system. They are an excellent reminder, though, that hardware – just like software – is not perfect and vulnerabilities are inevitable.

First, though, a little background on the vulnerabilities. System Management Mode, or SMM, is a privileged Intel CPU mode used for a variety of management functions, such as turning on fans when the processor gets hot or making a USB keyboard and mouse look like PS/2. SMM is a bit like the human brainstem: it’s an old part of the CPU that it ends up having enormous control because it’s responsible for handling all sorts of little low-level details. And just as the brainstem handles controlling our breathing or the pumping of our heart without involving the higher-level parts of our brains, SMM does its work in the background below the notice or control of any system software, such as an operating system (OS) or hypervisor. SMM offers unlimited access to all hardware and software on a system.

Not surprisingly, SMM is attractive to attackers because of all of this low-level access. Running a rootkit in SMM would make it both invisible to and in complete control of any system software or applications. An SMM rootkit could subvert even the most highly assured, formally verified OS. The hardware designers at Intel fully understood this power and the potential for attack, so they took steps to tightly control what software runs in SMM. That code – which is provided by motherboard or system vendors – is supposed to be loaded by the BIOS and then never modified. To prevent modification – the main mechanism used to prevent the introduction of rootkits – the SMM code is stored in special read-only memory.

Interestingly, the SMM vulnerabilities have nothing to do with breaking any of the read-only protections. Instead, the vulnerability is with the interaction with the CPU cache. Modern CPUs cache both code and data in very high-speed memory on the CPU itself in an effort to deal with the fact that CPU speed is increasing far more rapidly than memory. It turns out that it is possible to cache the SMM code in the CPU cache and the CPU will incorrectly run the cached copy on entry to SMM mode. Since the CPU cache is writable, this has the same effect as bypassing the read-only protections

This is a classic type of vulnerability. The designers were focused on protecting the access that they thought would be used for an attack and overlooked other avenues of access. The result is that a sufficiently privileged application (e.g., a root application on Linux) can change the code that runs in SMM to inject a rootkit or some other malicious application.

In the case of a traditional OS, such as Linux or Windows, this is an interesting but somewhat impractical vulnerability. These OSs correctly limit the access needed to manipulate the CPU cache to very privileged applications, so if you are to the point where you have enough access to launch the attack there are a million more straight-forward attacks that you can use.

The vulnerability is much more interesting in the context of virtualization using a hypervisor-based architecture. Typically, a hypervisor should be able to prevent the exploitation of one guest operating system from spreading to the entire system, including the other guests and the hypervisor. However, these SMM vulnerabilities, because of the hardware access that they leverage, allow the complete takeover of a virtualized environment from a single guest. For virtualization, this is a worst case vulnerability.

The impact on virtualized systems is what seems to have gotten peoples’ attention. Especially since these attacks offer a path to defeat the next-generation Intel technology aimed at, among other things, securing virtualized systems.

Again, I think that they are an excellent reminder that CPUs and other hardware are a source of vulnerabilities just like software. Many people – myself included – tend to focus on software vulnerabilities almost exclusively. Likely because there are so many software vulnerabilities and because the tools used by most developers so effectively hides the hardware details required to fully understand, discover, and leverage hardware-level vulnerabilities. These SMM vulnerabilities are a huge wakeup call reminding everyone that hardware vulnerabilities can exist and when they do they are likely to have devastating consequences.

In a way, it’s a testament to the engineering work of Intel and AMD that most software developers treat CPUs as infallible. Just like the floating-point math errors in early Pentium chips, these SMM vulnerabilities cause us to look at hardware with renewed skepticism. And once you start looking you realize that things are just as tough for hardware security as they are for software security. As more security features, such as TXT, are pushed down into hardware I expect that there will be more focus on finding vulnerabilities from the good and the bad guys. And I have no doubt that scrutiny will expose more flaws.

So you learn that your critical systems can be attacked by viruses and malware introduced through a common and heavily used interface like USB devices.  And you know that traditional anti-virus software alone can’t fix the problem…these are highly sophisticated and often specifically targeted attacks.  At the same time, you know that USB devices provide an important pathway for sharing information and commands between different security domains and even between coalition partners.  In other words, you don’t want to have to live without USB devices but you can’t tolerate the threat they now pose.

So what do you do?

If you’re the US Government, you ban the use of USB devices in as many places as you can and allow only very judicious exceptions where you can’t find a reasonable workaround.  Then you get busy making USB devices safe for use again.  With unlimited time and resources, there are a lot of ways to approach this kind of problem.  But with critical operations in the balance, time was of the essence and traditional development methods simply weren’t an option.

Fortunately, the government has access to a proven operating platform with precisely the kind of security tools and underlying architecture needed to support rapid development of a highly secure solution.   Starting with Red Hat’s RHEL 5 and the highly regarded Security Enhanced Linux (SELinux) as a foundation, Tresys and the government were able to design, integrate, and field prototype appliances to address this challenging threat in about 10 days.  Without that trusted underlying foundation, solving this kind of problem in a meaningful way could take an enormous amount of time and money.  Read more about the solution at http://www.tresys.com/usb-cleaning-kiosk.php.

So what was it about RHEL and SELinux that made this work?  For one, Linux (by design) provided the ability to plug into very low level parts of the system to detect and safely handle devices.  (Linux also supports a huge variety of the GOTS and COTS applications that were generating the files on the USB devices.)  Also, RHEL’s modular design allowed engineers to use just the parts of the OS that were needed to address the problem…critical in making the solution run as a true appliance.  Finally, the proven security controls in RHEL and SELinux allowed safe integration of GOTS and COTS software and enabled real device isolation…absolutely critical for this solution.

The fact that these controls already exist and had been thoroughly vetted and verified by the USG meant that, by building on RHEL and SELinux, a solution could be developed and fielded very rapidly and at low cost.  Is it a model that can be repeated?  Time will tell but one thing is certain…the pace and sophistication of attacks will continue to increase and the window for an effective response will continue to shrink.  Using a proven foundation like this should reduce the time to market for these critical solutions.