Data security for shared file systems is becoming an issue of increasing importance. As data is distributed over SANs, and now sometimes WANs, should the security of the data itself become an issue? I believe it is a critical issue, and I do not think I am alone.
In my “real” job, one of our customers started looking at the security issues surrounding a WAN connection to a shared file system. The systems included:
- Three different types of servers, each with different variants of UNIX
- A shared file system so that each Unix server would see the same file system
- Two different HBA vendors, with different firmware loads for one vendor
- Metadata communication over IP using three different Gigabit Ethernet NICs
- Dual redundant Fibre Channel switches
- HBA failover
- Terabytes of RAID storage
- High performance tape drives
- As part of the file system, hierarchical storage management (HSM) for controlling the tapes and migrating data to/from large tape robots
The customer wanted to know how they could connect the system to a WAN and what the resulting security issues would be. As there are all types of WAN connections, this became a interesting topic of discussion. Was the customer going to use:
- Dark fibre and run FC
- FC to Dense Wave Division Multiplexing (DWDM)
- FC to IP
- FC to SONET
- Something else
To add to the requirements, the customer said they also wanted a high level of data security and actually wanted to run MLS (Multi Level Security), which is often used by the government, banks, and other organizations that require a high level of security. So I thought it might be useful to review some of the security gaps for these types of environments when using shared file systems in a heterogeneous environment, as well as what happens when you want to share the file system over a WAN.
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.
What Does Not Work
There is so much that does not work. I am unaware of any end-to-end total solutions that have:
- MLS support for access control within the operating system
- MLS support within a file system that supports high performance IOPS and streaming I/O
- MLS support for a heterogeneous shared file system
- The ability to perform encryption within the file system
- Authentication for every path to the device (HBA, Fibre Channel switch, IP router, RAID, and tape)
- Standard encryption for access control of every device (HBA, Fibre Channel switch, IP router, RAID, and tape)
- Support for HSM encryption or backup encryption to/from tape
- Support for WAN encryption
- Support for encrypted remote mirroring of the RAIDs (if required)
What I'm outlining is the requirement for total data security from the time data is moved into or created within the system until the time data is destroyed — i.e. security through every aspect of all of the systems within a heterogeneous environment. Of course, this will have overhead, and in many cases these requirements might be overkill given that some systems contain no sensitive data.
We are a long, long way from having total end-to-end data security. The operating system is the critical path to the development of a truly secure system. Most vendors are looking at host-based solutions, and I am unaware of any modern file system (the next level) that meets all of the security requirements. Of course, having a file system is much more difficult in a heterogeneous environment, but while a homogenous OS could provide the basis of this security nirvana, this is something most experts believe is not on the short-term horizon.
A shared file system with MLS capabilities that supports heterogeneous access, HSM, and data security is the ideal, but it remains a pipe dream for now. The operating systems vendors need to develop truly secure MLS systems that can interoperate, which is not going to happen anytime soon. As a result, what we are currently left with are various band-aids for shoring up security in the areas where we are most vulnerable.