Storage Pipeline: Analysis: Storage Security

Storage is the new soft spot. If we're seeing a major loss of data at rest every few months, you can be sure smaller thefts are happening, undetected or unreported. And once again, the good guys are playing catch-up: While most now recognize storage as a vital link in the security chain, we still lack consensus on how to proceed.

One thing is clear, though: The cost of lost data and damage to systems--and the PR nightmare when leaks occur--are too much for most companies to bear without a risk-avoidance plan. A significant loss of even marginally critical information could land a small firm in such a legal mess that it may as well shut its doors.

Fortunately, it seems the message is getting through. In a recent poll of more than 600 readers, 70 percent said their organizations recognize the need for storage-specific security. The bad news? Fewer than 10 percent are very satisfied with current security systems and processes. And the age-old tension between IT groups is still in play: A lack of communication and understanding between security and SAN staffs was cited as the chief barrier to effective enterprise storage security.

The ProblemThe leaky boat that is storage should surprise no one. The simple fact is, we don't build business apps for security; we build them to facilitate business by offering data to users, customers and business partners, and for retrieving data from this same group. Security is added often as an afterthought because first the app must do what it was conceived for--otherwise security won't be necessary.

Enterprise data is primarily stored on six mediums. DAS (direct attached storage) is the hard disks in the computers at your business, and directly connected to them externally. In NAS (network attached storage) systems, data resides on file servers and NAS servers that emulate file servers, and use CIFS or NFS to communicate with client machines. Fibre Channel SAN data resides on dedicated networks that do not use IP to communicate. iSCSI SAN data resides on the network in a form similar to DAS, but it's stored remotely. Finally, tapes and optical media facilitate both network- and direct-attached long-term archival storage.

The problem begins with how security is approached on these disparate platforms. For block level storage devices--iSCSI, SAN and tape--there's a tendency to control access at the host level. That means the device housing the storage knows what remote hosts can access the storage, and that's the only true validation that occurs. The weak point here, of course, is that host-based access control is less secure than user-based access control. Who cares that Host X can see only Drives Y and Z on the SAN? That doesn't ensure that the user who just logged in to X has any right to be looking at, copying or erasing that data. So in short, existing storage authentication methodologies are worthless.

Block storage vendors argue that user-level access control is not their responsibility; it's up to the OS to make those determinations. Problem is, the storage medium is closer to the data being protected, and if access control is configured at the storage level it does not have to be reconfigured over and over, whereas if it's configured at the server level, that configuration must be merged with and replicated to all other servers with access to that array. This is inefficient and needlessly difficult to maintain, particularly in a high-turnover, heterogeneous environment.On the other hand, NAS products are based on protocols that are provably insecure. CIFS has more holes than Swiss cheese, and NFS has been broken several times. This is a simple case of the origins of these protocols: They were designed to serve up data, not to prevent access. Both can now make use of directory servers to gather security data, and both can now run with encryption over the network, but there are still serious weaknesses in both protocols. For example, CIFS advertises its presence to all who wish to listen. Although this makes life easier for IT, it's also a convenient starting point for unauthorized users who want to gain access. And unless you edit the registries on server machines, CIFS is not protected from man-in-the-middle attacks. By editing the registry you can force CIFS signing, which attempts to uniquely tag each packet of each connection to ensure man-in-the middle attacks do not modify your data in transit, but there's not yet been been a serious effort to crack CIFS signing--at least, that we know of--because signing is off by default, not simple to turn on and poorly documented. If it becomes a default setting, we're likely to see cracks relatively quickly. Meantime, if you want to use signing, you'll have to modify registry settings on each machine that needs access to a share on a "CIFS signing required" server or NAS device, and it's not yet widely supported in non-Windows NAS devices.

In addition, any physical machine can see the data on a NAS--it's only by user name and group that access to files is filtered. This is the flip side of the disk-based block storage problem, and just as error-prone. Once I can access an account that has greater privileges than I normally enjoy, I can see everything on the NAS from any machine that has a logical route to that NAS, and that the user I'm logged on as has access to. In practice, the set of machines that needs access to many NAS servers and shares is severely limited, and we should have a mechanism to reflect these limits in our security policies without having to resort to VLANs.

Tape (and CD ROM for smaller installations) is another beast altogether. Companies sending backups out of the building unencrypted may as well make a copy of all their data, label it as "complete backup" and drop it off at their local McDonalds--that's the equivalent of handing unencrypted tapes over to a shuttle or delivery service. CD-ROMs and DVDs are even easier to access. And don't even get us started on removable storage devices (see "Have Drive, Will Travel" ).

High-Tech Caulk

Encryption is often touted as the solution to all storage security woes. We'd argue it's vastly overrated. For protecting data at rest, and even data in flight, encryption will go a long way toward helping you sleep at night. But the actual user application still must have unencrypted data. That means an attacker who gets access to the box the application runs on, gets access to the data that box can see.In addition, encryption poses a growing key-management problem. As long as that data is valid, you must be able to read it, which means you must have a valid key. Most companies have data they must keep for at least seven years. There are systems that will "re-key" data so new keys work with old data, but in volume they're not practical because all the data must be decrypted, then re-encrypted.

Encryption will be the end-all solution when we can write apps that use only encrypted data. Until then, it's merely a piece of the architecture we must implement ourselves with tape-encryption devices (see "New Tape Measure"), as well as file-level encryption, database-level encryption and access-control products (see "Securely Stowed" for a product roundup).

Architectural Options

What you need to lock down your storage infrastructure today depends on your architecture.

» DAS: Last month, a Fidelity Investments employee brought to an off-site meeting a laptop containing confidential information on more than 196,000 current and former Hewlett-Packard employees. After the theft of the laptop became public, the financial services firm said it has policies in place limiting employees from taking such confidential data off-site except in specific circumstances, and added that the data should be "generally unusable" due to an expired application license. The company did not mention encryption. A word to the wise: For DAS that is likely to leave your premises, encryption is key. Strong passwords are a first line of defense, but it's easy to circumvent the password system by removing the disk and dropping it into another machine as a second or nonboot disk. Encrypted disks won't be readable even if the machine was booted from a different disk, and the attacker must figure out the password to boot into the original disk. This protection just makes sense.» NAS: This is a tougher topic. Today, most NAS devices can be access-protected with Active Directory or password files, but unless you've used VLANs extensively to section off your network for storage-only purposes (which is not possible in large, single-machine NAS environments), all machines have access to the NAS because access is controlled only at the user level, and then only by share or mount point. This means an attacker on the same network as the NAS device can list the shares available. Once it responds positively to the request--even if the list that user is authorized to see is empty--the attacker can begin an assault or try to use different user names to get at data.

There's no solid solution to this problem. The best you can do is, in an environment with several small NAS devices, set up your storage and your network so that VLANs keep machines away from data they don't need to access. This is effective in places where a small number of users and a couple of servers need direct access to the data on a particular NAS, and the rest of the organization doesn't.

» iSCSI: This particular technology rests between SAN and NAS, and holds the most hope of being solidly secured in future iterations. Because iSCSI uses IP for communications, it's possible--albeit not currently implemented--to restrict access by user name and group through access to ADS or LDAP. Today, iSCSI access is controlled in the same manner as on a Fibre Channel SAN, by hardware machine ID. The catch? Because IDs are tied to hardware, if you replace a server or its network card, you will have to modify your security configuration, but that's the price of not broadcasting data all over the network.

In addition to iSCSI hardware-based access control, you also can use OS-specific control mechanisms. Granted, these aren't the strongest controls, but they're better than nothing. By setting access rights on iSCSI volumes, you can limit users' access beyond the limitations placed on the machine they're using. This is no different than setting the "Hidden" flag (in Windows) or restricting access by group (in Windows or Unix) on a NAS or DAS.

» Fibre Channel SAN: SAN security is difficult at best. From the network layer up, a SAN has no concept of users and groups. It presents a disk to the server, and the server does whatever it wants with that disk. In this sense, you can treat it as DAS; the only problem with that approach is that there is likely to be a lot more data on your SAN than on your DAS. The mechanism that restricts which virtual disks (normally called LUNs for both iSCSI and SAN) can be seen by a given machine is called LUN masking. LUN masking has been subverted when done completely in software (called soft masking), and the storage industry is taking steps to move to a hardware-software combination. However, the combination has been shown to have similar problems.The good news is that there are no reported cases of this loophole being used to steal data--yet. Because you can't do anything about this except insist on hard masking, don't let it bother you; the risk seems minimal and requires that the attacker have already cracked a box on your SAN--meaning the attacker likely has easier ways to get at that same data. So, assume that LUN masking will restrict which machines can see which LUNs.

That leaves you with user-level security. This can be handled in one simple way if the high-performance features of the SAN are not as important to you as massive capacity and high utilization. Set up a server that will act as a gateway for one or more SAN logical disks and present them like a NAS. Because any server can share its disk space, it's easy enough to present a SAN logical disk to the world via CIFS or NFS.

Problems with this approach mirror those for NAS devices. You're actually introducing another layer of vulnerability, one that many argue is more prone to attack than the SAN layer. But one thing it will do is help prevent internal "attacks of opportunity." Being able to see an object might tempt someone. By using a NAS gateway to your SAN, you can remove otherwise good employees from the path of temptation by simply denying them rights to see things they don't need to see. But to an experienced attacker, a NAS gateway is less secure than a SAN.

» Tape: Tape leaves your building and goes who-knows-where before arriving at its destination. Your only real defense is to encrypt it and not store the decryption key on the tape. Encryption requires that you maintain keys and decryption tools for as long as you need access to the data, but that's a topic that has been admirably covered in other venues, including Freesoft.org, The GNU Privacy Handbook and "Who's Minding the Storage?". If you encrypt your tape and then store the decryption key on the tape, you're giving would-be attackers an edge.

» USB: There is a growing list of products, like Centennial Software's DeviceWall, designed to lock down USB ports. This is a difficult task that takes considerable time to manage because users' needs change over time. An employee may ask for USB port access on a desktop, and the manager may vouch for the validity of that access, but six months later does the employee still need it? Reviewing access requirements periodically is not a major imposition on managers and will help keep USB use to a minimum. The same type of lockdown would have to occur on DVD and CD-ROM drives if a lockdown on USB is to make any sense.Go the Extra Mile

In addition to securing physical mediums, there are a few big-picture things you can do. Encryption on-the-wire provides protection from packet captures if an attacker gets access to your organization's network, but it does not provide any protection at a host with access to the data. Most database encryption products decrypt before sending across the wire or at the database host in a driver--neither of which protects data at the server. Systems that encrypt data at rest don't do anything for data moving across a network.

This brings us to a corporate access policy. Using OS groups to their full advantage for file and directory access rights is an integral part of any security architecture, and should be planned out and managed as part of your security staff's daily work. Simply put, if the "busapp" account in HR is cracked, you don't want the attacker to gain access to all the public shares on the network, and limiting file access rights, though not foolproof, will help limit how much data an attacker can access in a short time. And, audit trails will help you track attackers after-the-fact.

Unfortunately, it takes time to grant and deny rights to files and directories. Most organizations that are successful at this gambit provide access rights at a high level--top-level folders or just below with access rights granted to groups of people--rather than attempt to set rights on each of the thousands or millions of files in the organization for each of hundreds or thousands of users.

Finally, IDSs and IPSs are useful to protect all systems, not just storage, against outside attackers by detecting and preventing unauthorized access. They're less useful internally for a variety of technical and social reasons.Don MacVittie is a senior technology editor at Network Computing. Previously, he worked as an application engineer with WPS Resources, a Green Bay, Wis., utility holding company. Write to him at [email protected].

Have Drive, Will Travel

The proliferation of large-capacity, removable storage devices small enough to fit in a coat pocket is becoming a problem that all security pros are going to have to wrestle with. Because nearly every PC on the market is awash in USB ports, and USB keys are cheap (or free if you attend trade shows), these devices are devilishly difficult to protect against. If you haven't put a policy in place yet, you should do so soon.

The majority of employees are upright folks who are just trying to do their jobs, but it only takes one weasel with a USB thumb drive to ruin your day, and possibly your business. No one wants to think a co-worker would risk the entire company's future, but it does happen. Sales and marketing people take contacts with them to new jobs, programmers want to hang on to that one piece of really cool code they wrote, and the list goes on. The whys are of no importance to us as security and storage folks. What does matter is how to stop rogue employees before they walk off with valuable business or intellectual property.

The most appealing way to deal with this problem is to turn off all USB ports. One of our editors even made reference to hot glue. But one of the primary precepts of security is that it cannot interfere with people's ability to do their jobs. If it does, they will find a way around it, or their managers will force a change. So what do you do?Bite the bullet and deploy USB access control. There, we said it. Sure, it's going to be ugly to implement and nearly impossible to manage, but unless you're in the enviable position of being able to turn off all USB ports across the organization--most enterprises discourage such blanket policies as too strict--you really don't have much choice.

Vendor Implementations For Tomorrow

In "Protect Your Corporate Jewels," we discussed threats and how you can minimize their impact on your organization. But the best improvements to storage security will come once storage vendors put intelligent thought into their future security systems. Simply put, we need to be able to say which machines and which users can have access to a given share or disk. On every platform. From a unified interface.

This won't be news to storage vendors; we've been beating this drum for a year or more. The crunchy security shell around our existing security infrastructure is so thin in some places that it may as well be nonexistent. Storage is the entry point that smart attackers are going to head for, and we can't reasonably keep them out with what's available today.

Storage systems must get smart enough that they validate a machine on first contact against a centralized list of machines and what data it has rights to see. Then they need to hit a centralized security repository that contains access-rights information to validate that the user has rights to see what he's trying to look at.

And, the security system must be standardized across storage platforms. It's unfortunate that the prime area of storage innovation today is iSCSI, and iSCSI is following the SAN model of "that's not our concern, the OS handles access rights." Or worse, iSCSI vendors are implementing proprietary solutions that work only with their products. We want heterogeneous support for multiple different platforms--NAS, SAN, iSCSI--and we want it to make use of the directory servers we have--LDAP, ADS. It's absolutely mandatory that storage vendors address the security woes they have wrought.Many storage products, tracing their roots from the networking world, use RADIUS for management access control. This is acceptable for the limited scope that management access control requires, but when user-level controls are put into place, access authorization must come from a repository designed to handle the volume of traffic created by storage access rights checks.

Storage vendors also need to simplify security. Today, your storage people must learn many of the intricacies of security management or the security staff must learn LUN masking and World Wide Naming schemes. Or the two groups must sit down together to make changes to the hardware security architecture. This situation is not timely and, therefore, not acceptable on a global scale. Storage staff specializes in making data available, and doesn't do security every day, while the security staff is tasked with learning enough about every system and architectural piece in the enterprise to lock things down successfully. Asking either one to learn and perform the others' job is asking for mistakes. Asking them to work together means that valuable time can be lost in cases where a quick reaction can lock out an intruder, or better yet help to identify him.

The storage staff must be able to set up names that make sense to the security staff and, instead of doing everything via WWNs or LUN IDs, storage systems must let security staff use easily recognizable names. Some vendors, like Decru, are headed in this direction with simplified naming "tags" that help security staff identify a given LUN, but we don't feel they've achieved this goal yet. And their offerings are not generally applicable to all the storage in your network.

CIFS signing is a good idea, but not the end of the road. The cost in work hours of implementing and troubleshooting CIFS signing is huge, and it doesn't limit access in a general way; it merely protects against man-in-the-middle attacks. It does have the benefit that only machines with CIFS signing turned on, or those set to the default Windows setting of auto-negotiate, will be able to communicate with storage devices that have it set to mandatory. But not all NAS devices support signing, so the effectiveness is limited. Where you can use it, turning CIFS signing on is a good idea, but do not expect to apply it to all of the NAS devices in your organization, many just haven't implemented it yet. Vendors need to take this bull by the horns as an intermediate step and provide support for this technology.

Executive SummaryAll security is risk management. To an evildoer inside your network-- either an employee or an attacker who has penetrated the outer perimeter--there is no richer lode of data than your storage systems. But this treasure trove is likely completely unsecured. NAS installations were designed to give access to the masses, and current tools don't make it easy to crack down. SAN and iSCSI limit which machines can see which disks, but they lag in user-level access control.

There are steps you can take to make your storage more secure, and we discuss them in "Protect the Corporate Jewels" and "Hard Drive, Will Travel", but as we say in "Vendor Implementations for Tomorrow", vendors must expand their thinking to embrace security as a core piece of the storage architecture, not a head-nod add-on they use to close sales.