To state the obvious, information isn’t worth much unless it can be shared and acted on. But most meaningful exchanges of information require data to transit domains, and in doing so bring a host of security concerns into play. So any exchange of information involves a measure of risk management. Where the risk is high, like in government models, rigid, format specific cross domain solutions (CDS) are typically used as gatekeepers to let the good stuff pass and stop bad things from happening.

There is certainly an enduring role for this traditional CDS approach. However, given the pace of emerging threats, it’s a good time to rethink the process of building and deploying CDS’s with an eye toward dramatically reducing development costs and time to market. …see Tresys’ new XD Solutions series as an example. It’s also a good time to rethink the approach to cross domain in general…what it means to both government and commercial organizations (especially critical infrastructure) and how the fundamental requirements to protect data can be met in a stronger, more effective manner.

More to come…

The recently de-classified attacks on DoD networks via USB devices are a great example of where this kind of emergency fund could have been helpful. In late 2008, the attacks were detected and the source and vector for the attacks isolated…we knew the malicious code was introduced through USB devices. An immediate ban was instituted that barred the use of all USB devices without a specific waiver, causing all kinds of operational delays and problems. Within weeks, the USG responded by funding and developing a solution that not only prevents these attacks, but also provides the means to identify malicious content on many other kinds of removable media. That solution was developed and made available as a working prototype within weeks, allowing a few select locations to bring their USB based operations back on line.

The rub is that nobody else could get their hands on those devices. Why? Because they had not programmed money to do so…something that would have needed to occur years earlier. In other words, to have the money available to deal with an emergency like this, agencies would have needed to anticipate the emergency and request and set aside funds for it years before it occurred. Unlikely to say the least. So today, as organizations look for ways to begin using USB devices again in the face of an established threat, they attempt to scrape together end of year funds or reduce other discretional spending to come up with the funds needed to buy and field the USB solution. Worse, they ignore the threat and proceed as usual.

There is good work being done across the DoD to streamline procurement practices for IT, bringing the procurement cycle more in balance with the pace of technology.  If we can couple an emergency fund for cyber security with streamlined procurement, agencies would have a way to more effectively deal with emerging threats as they occur.

Having a new threat emerge that is unforeseen is understandable. Having a solution available that mitigates that threat for critical systems but being unable to field that solution for months or years after the threat emerges is unacceptable.   Let’s create a FEMA-like fund, governed by an appropriate board, and accept applications to make much needed security solutions available in real time. This is, in fact, a case where only money will help.

It is worth noting that the USB attacks really serve to point out that there many different avenues to effectively target critical systems. While focusing on active, network-based attacks was the right starting point, many organizations stopped there. Attacks through USB thumb drives is solid proof that attackers will come in through any door you leave open, even if it isn’t a direct attack path.

Perhaps more important is what often makes these kinds of indirect attacks possible: hiding malicious content in files and other data. While most people are often savvy enough to not run unknown software, we all open all kinds of documents with little or no knowledge about where it came from (and no, the from line on the email is not a good way to tell you who sent that email). These kinds of data-borne attacks are very difficult to protect against and seem to be gaining favor…just ask Google and the 33 other companies recently targeted with a PDF attack.

Preventing these attacks requires a means to inspect content at a very deep level and to do it in real time. Ditto for outbound disclosures of classified or confidential information ala the WikiLeaks incident. We simply have to be able to get at the goodies in files carried on physical devices, in email attachments, and on networks in general, and look inside those ‘carriers’ for the kinds of content that characterizes the attacks we are seeing today. We’ve been working on this for years (and have products that do this type of inspection), but preventing these attacks requires a concerted effort along with the recognition that the attacks themselves differ substantially from broad brush viruses.

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: 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 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 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.

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.

• 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.

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.