Home‎ > ‎


Generic Cross Domain Solution Scenario -- file transfer

posted Jan 25, 2010, 4:07 AM by Rich Johnson

This post discusses the transfer of flat files across a cross domain solution such as a trusted guard or data diode.  The task is to automatically transfer a file from an unclassified network to a classified network.  The reasons can be many.  One illustration is the updating of a secret database using files generated from an unclassified database that provides a subset of such information to the secret database.  We will not concern ourselves with the contents of the file other than to say it is an ASCII file.  The following diagram illustrates such a transfer.

When a file crosses such a solution the implementing organization has an option on how to process that file before it crosses domains.  It can be scanned for viruses.  It can be checked to ensure it only contains ASCII data.  It can be checked to ensure it is in a predefined format.  It can be checked for specific words.  Whatever the requirements are, the file to cross can be subjected to evaluation criteria to ensure it meets a predefined security policy.  In trusted guard solutions, this kind of checking is done with what is referred to as a "filter".  The filter can be a process with hard coded values or could use a configuration file that can define rules.  If a configuration file is used, it needs to be protected from tampering.  The use of trusted operating systems facilitates this task. 
A more sophisticated variation of this file transfer scenario is the passing of XML (eXstensible Markup Language) files across the domain boundaries.  In such a case, the "filter" can be very sophisticated where contents and format can be checked and even specific attribute values can be checked to ensure they fall within specific parameters.  An XML schema validator can be used as a filter in this process.  I personally have built a filter that used a modified XML schema validator.  The low side network had a database that used a routine to extract data to be copied to the high side.  The resulting query was converted to an XML format.  The filter (in this case, a schema validator) checked the contents to ensure they were acceptable.  The data was passed through the cross domain solution to the high side where a process took the file and uploaded it into another database.  The big challenge was making the XML schema validator fast enough to maintain the required throughput through the cross domain solution.  The beauty of this approach (using XML in this way) is that the filter never has to be modified.  The filter configuration file in this case is an XML schema document designed to define the format of the file to be allowed to pass through the cross domain solution. 
How does the flat file get to the cross domain solution?  And since I've not specified previously, the cross domain solution in this example includes the high side server, the low side server and the cross domain technology (we'll assume a hardware data diode).  Thus part of the solution resides on the low and high side servers.  The low side server may use secure FTP to retrieve the file from the low side after checking for new files.  Thus the cross domain solution has positive control over the whole transfer process.  On the high side, the high side server forwards the file to the target destination and the cross domain transaction is complete.
In some solutions the high side may go through similar checks as the low side such as virus checking and reapplying the filter rules.  In very robust solutions there may be a firewall set up on each side of the cross domain solution (a bit overkill in my opinion).  Subsequent posts will look further into the processes surrounding the hardware data diode or those of the trusted guard.
This type solutions can also go from high to low.  The filter in this case will ensure that data that is not supposed to be shared does not traverse the cross domain solution.  There are solutions like this that use a man in the middle approach where a person using the cross domain technology actually reviews files that sit in a queue and approve the transfer.  This approach works well with imagery since it is tough to design a filter sophisticated enough to evaluate an image.

Cross Domain Solutions Technologies

posted Jan 22, 2010, 3:20 AM by Rich Johnson   [ updated Jan 22, 2010, 4:11 AM ]

I am going to write more specifics about each of these technologies in the coming weeks but here is a list if you are curious.  These can also be found at www.ucdmo.gov.  This is the government site of the Unified Cross Domain Management Office or UCDMO.  Their function is to serve as a clearinghouse of information for government customers on current cross domain solutions techologies.  Their list however is not necessarily conclusive and if you are a commercial entity, there may be solutions you may not see there.  Check this site from time to time to see an expanded list.
The initial batch of technogies I'm going to list are as follows:
The BAE Systems DataSync Guard (Data Sync Guard) also known as the DSG.  It operates on a very special platform known as the XTS-400.  The XTS-400 runs the STOP operating system.  This is unique in that it was had the highest available security rating that you could buy based on the old "Orange Book" "Trusted Computer Systems Evaluation Criteria (TCSEC), a Department of Defense standard.  See this article in Wikipedia for a description:  http://en.wikipedia.org/wiki/Trusted_Computer_System_Evaluation_Criteria.  For you CISSP certified folks out there this should be familiar!.  Though the ratings go to A1, the XTS-400 had a B3 rating.  That was the highest for an operating system.  I personally worked on it as a developer (maintenance related tasks) and I also wrote filters for the DataSync Guard application that ran on this platform.  More horn blowing, I put together much of the accreditation documents for various customers.    Anyway, a good technology.  More later.  http://www.baesystems.com/ProductsServices/bae_prod_csit_xts400.html.
Information Support Server Environment (ISSE) Guard, Trusted Transfer Agent (TTA).  The ISSE Guard has been deployed in dozens of locations and is maintained by a program at the Air Force Research Labs in Rome, NY.  It's a good product that executes in a Trusted Solaris environment.  It is very popular because it has been implemented in so many places thus the certification and accreditation (C&A) is a bit easier than for lesser known solutions.
The Radiant Mercury Information Guard by Navy SPAWAR - Space and Naval Warfare Systems Center, San Diego (SSC San Diego).
Tenix Data Diode by Tenix PTY Limited (www.tenix.com) from down under.
Owl Computing Technologies Dual Data Diode (www.owlcti.com)
Trusted Computer Solutions Trusted Gateway www.trustedcs.com.
Netsec/Verizon/NewSec/Cross Domain Solutions One Way Transfer.  https://sites.google.com/site/crossdomainsolutions/products/one-way-transfer.  You are already here!
The One Way Ethernet Device.  Also found here. https://sites.google.com/site/crossdomainsolutions/products.  Simple.  Boring.  Effective.  Incredibly cheap.  Government customers probably will not like as it is too unsophisticated.  I plan on making it available to the masses (commercial users who do not want the overly complicated solutions that the government will use). 

Discussion of the One Way Transfer

posted Jan 22, 2010, 2:41 AM by Rich Johnson

Created by NetSec (later acquired by MCI then Verizon Business), the One Way Transfer (OWT) is a hardware enforced cross domain solution.  Using a custom build chip, this solution allows data to flow in one direction only.  Unlike other solutions using optical tranceivers, the OWT has a distinct transmitter on the sending side and a distinct receiver on the receiving side.  A customized UDP application allows data to traverse from the sending side to the receiving side.  The OWT "transmitter" is a device that runs on OpenBSD stripped down to the bare essentials.  The same with the receiving side is true.
The OWT system allows the end user organization to configure channels known as "conduits" allowing several concurrent streams to be set up thus several processes pushing data from one side to the other are possible.  The following diagram illustrates the conduits.
This portion of the OWT cross domain solution covers the hardware aspect of the solution.  More sophisticated solutions have been designed and implemented using a controlled interface (on a server to each side of the device).  The controlled server can perform such activities as virus checking, encryption, integrity checking, authentication, content checking and relaying the heartbeat of the OWT (the OWT can send heartbeat data without the controlled interface).  Thus the OWT "solution" can perform the more sophiticated functions of a "trusted guard" while still using hardware to enforce domain separation.  SEE ONE WAY TRANSFER

Background on Cross Domain Solutions

posted Jan 20, 2010, 2:21 AM by Rich Johnson   [ updated Jan 22, 2010, 4:42 AM ]

Currently cross domain solutions are used by U.S. Government and the U.S. Military. Cross domain Solutions are employed when there is a need to share information across network boundaries (generally of differing classification levels) without information traversing in the wrong direction. This one way or universal transfer of information is generally handled via software based solutions (trusted guards) or hardware based solutions sometimes known as data diodes. The software based solutions are generally applications that run on trusted operating systems such as SELinux, Trusted Solaris or other proprietary operating systems that are designed for robust security. Hardware solutions use hardware to ensure that traffic flows uni-directionally. Both types of solutions have proven extremely reliable. Currently the U.S. Government’s Unified Cross Domain Management Office is the repository of the latest and greatest cross domain solutions used by the government.

The problem with these solutions is they are very expensive. And though they are considered somewhat “off the shelf”, these solutions generally require some customization for a particular implementation. Further adding to the cost, these solutions must be accredited. This means they go through a rigorous implementation specific accreditation to connect to a network. This involves extensive certification and accreditation processes (C&A) in accordance with the Federal Information Security Management Act (FISMA) for non defensive related implementations, and the Defense Information Assurance Certification and Accreditation Program (DIACAP) for Department of Defense related applications. Accrediting a solution may take months or years and is very costly.

There are many possible uses for cross domain solutions in the commercial world. A company may segregate its networks into proprietary and nonproprietary segments where the proprietary segment does not interface with the internet or nonproprietary segment for security reasons. In some instances data that needs to traverse the boundary may be brought over via thumb drive, cdrom or some similar “sneaker air gap” solution. There may be instances in digital video surveillance where the network handling video data is isolated to insure that it is not compromised but the need to share the data with another network would require a similar sneaker air gap solution or a temporary connecting of networks. A cross domain solution could be set up to share information across such boundaries without compromising security of the previously isolated network.

1-4 of 4