Securing Data Across SANs, WANs, and Shared File Systems: Page 2
Most of the server vendors either have or are planning to have operating systems that support mandatory access control to various system resources and data using MLS. MLS operating system vendors generally submit their software for review to a standards body (or bodies), many of which are within the U.S. Government or, in some cases, are U.S. Government-certified reviewers (see http://niap.nist.gov/ for details). This does not mean that every file system supported by every vendor also supports MLS — much to the contrary. In fact, most vendors with MLS-supported operating systems only have one file system that is supported.
There's no real standard for MLS-based operating systems, so each vendor has a completely separate implementation. Since the major Unix operating system vendors do not document file system and virtual memory interfaces, this means that having a shared file system across multiple operating systems running MLS is basically impossible today.
What Sort of Works
Things are a big better at the networking level than at the operating system level. Different standards are emerging. Of course, the standards for SANs and the standards for WANs are totally different, but that is to be expected. Most SAN environments are local, so at first glance one might wonder if security is even important, while security for WANs is obviously a big issue in today’s world. For WANs, the large IP router companies all have encryption solutions, and IPv6 will add more encryption functions. So, basically for IP, you have multiple solutions available.
At the Fibre Channel level for SANs, a standard has emerged based on the Diffie-Hellman Challenge Handshake Authentication Protocol, commonly called DH-CHAP. This standard was certified by the Fibre Channel Security Protocol standards group (FC-SP), and as of April of this year, version 1.1 has been released by the ANSI T11 committee. Most vendors for switches, HBAs, and RAIDs either support DH-CHAP or will be supporting it soon.
The current standard provides far more authentication than it does data encryption. The authentication process is encrypted, but the data moving through the system is not encrypted, which means someone could still tap the Fibre Channel line and monitor data. Of course, this is difficult given the performance requirements for collection and the fact that data is often striped, so the infiltrator would have to tap more than one FC. Still, just because it is hard doesn't mean it's impossible.
A proposed part of the standard that was not adopted is Fibre Channel encryption. I am unaware of any HBA, switch, tape, and/or RAID vendor that would support this proposal. I have heard a number of reasons why this will not be implemented, including:
- Cost – The technology to provide encryption in chips that support full duplex 2 Gb/sec Fibre Channel is not available at a reasonable cost, and given the cost of an HBA, switch port, and RAID or tape connection, this is a big issue
- Availability – Chipsets that support encryption at 2Gb for Fibre Channel are not readily available
- Market – In discussing the issue with a few vendors, most of them simply do not see the market demand at this point
On the other hand, a number of emerging vendors are beginning to provide products that address the issues of data encryption over Fibre Channel. A few of them are Cipheroptics, Decru, NeoScale, and Vormetric. Some of the vendors support tape drive, some support RAID, and some both. Additionally, host-based products as well as hardware channel-based products exist. A myriad of issues and requirements need to be taken into account to ensure that host-based products will work in your environment with the other software you have installed.
As most of the products are new, as are the companies, your mileage may vary, but there is enough market momentum based on the requirements that products are going to have to be developed and sold to meet the market demand. Will the first set of products from these vendors meet all of the requirements, or perhaps some subset, but not all, of the end-to-end requirements? We'll have to wait and see.
I put these products and solutions in the “sort of works” area because:
- The Fibre Channel standard is for authentication not encryption
- The vendors currently creating products only solve one small aspect of the problems that we face for data security
I am not saying these products and standards do not work; rather, I'm saying they do not completely solve the problem.