Security OPENions

Wikipedia defines cross domain solutions (CDS’s) as a ‘necessary evil’. An unflattering comment on an important part of the security fabric, if I ever heard one.

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 disconnect between the pace of emerging cyber threats, solutions to counter those threats, and funding to buy/field those solutions is crippling. We are in real need of a cache of funds reserved specifically to address fast paced threats to our critical and classified systems across government and, I would argue, across our nation’s critical infrastructure.  Reserving resources to address unforeseen emergencies is not a new concept…it’s what FEMA does to provide relief following natural disasters, as an example.

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.

In the September/October issue of Foreign Affairs, William J. Lynn III, the Deputy Secretary of Defense discusses the Pentagon’s Cyber Strategy. In that article, Mr. Lynn highlights the previously classified 2008 USB-borne attacks on US Defense systems and the operation to counter the attacks. He points out that while it is not the first time US systems have been penetrated, it was the ‘most significant breach of US military computers ever.’

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.

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.