Building security into storage networks


For Ted Barlow, chief security officer at McAfee, a provider of security products for networking and computer environments, security was an integral part of the SAN implementation process.

However, for many other IT organizations the need to address storage security as part of an overall IT strategy is not so clear-cut. Instead, the general tendency is to focus on extending the SAN, not making sure that storage networks are truly secure.

This is in sharp contrast to network security, which continues to rank high atop IT priority lists (see "How secure is your storage network?", InfoStor, September 2004, p. 1).

Click here to enlarge image

For a variety of reasons, including the assumption among many users that there isn't any real need or urgency to secure storage networks, SANs today pose increasing security risks, according to security consultants.

"The assumptions that people have today [about storage networks] are very dangerous," says Himanshu Dwivedi, a managing storage architect for @stake, a consulting firm in Cambridge, MA, that focuses on data and network security.

Symantec, a recent entrant into the storage security market, last month announced its plans to acquire @stake. Of particular interest to the company was @stake's application security experience. The deal is expected to be finalized this month.

In May, Symantec formed a separate business storage security division-Symantec Enterprise Administration (SEA)-to address the security aspects of today's storage environments. The company's security umbrella now spans systems, security, and storage management (see "Symantec moves into storage, systems management," InfoStor, June 2004, p. 10).

The advent of storage networking, says Dwivedi, has created a web of storage security issues that are not being adequately addressed by either vendors or users. Storage vendors aren't building appropriate security functionality into their products, and users, in turn, aren't adequately educated about potential security risks, according to Dwivedi.

Dwivedi says that users often wrongly assume that the data on their storage networks is safe because it is behind a firewall or because it is "isolated" from the regular network and generally unknown to the public. The problem is that unless the storage is direct-attached, the storage environment is rarely secure, according to Dwivedi.

"Getting access to a Fibre Channel network is fairly trivial," he says. "[In fact, a potential hacker] is just one operating system away from getting access to the storage network. The Exchange server or the SQL server, for example, is the gateway to the SAN itself."

Click here to enlarge image

If the storage is indeed protected, isolated, and direct-attached, then Dwivedi says there is no reason to talk about security in the context of storage. But if it's not-and it usually isn't-then storage should be a rising priority.

Storage networks typically aren't isolated (they're connected to the regular network in multiple locations), and they aren't protected (data runs through them in clear text), according to Dwivedi.

Users, he says, need to make sure that all devices touching the SAN are secure, and that means making sure users have addressed security issues at the application, transport, files/record, block aggregation, device, and management layer (see figure).

"Our concern was with where the storage pieces connected to the local network," explains McAfee's Barlow. "We were putting in a SAN, and we knew that our SAN [because it bridged our production network] had the potential to be a security hole."

Barlow says that while McAfee had intended to build a network that was completely separate, or isolated, from the company's regular network, backup requirements forced it to bridge the networks in certain areas.

To help the company secure these areas, Barlow called in @stake, for which he formerly worked as a consultant. Barlow says that @stake approached the company's storage security issues from a design and configuration perspective. "They came up with best-practice configurations," says Barlow. "They made some changes to the design, involving management, configuration, and authentication."

Click here to enlarge image

McAfee did not invest in any third-party storage security layers per the recommendation of @stake. "Storage security is not just about buying [an encryption] box or implementing the latest version of Brocade's security software, or installing a firewall or anti-virus software," says Dwivedi. "It is a process." Instead, @stake recommends that users look at storage -security as a multi-layered process analogous to the Storage Networking Industry Association's (SNIA's) Shared Storage Model-that involves software/hardware product features as well as header fields in data packets and data frames, and not as a single-box fix (see figure, above). The foundation of this process is authentication, authorization, and encryption.

In general terms, @stake defines storage security as "the collection of security controls, settings, and values that are used to ensure that access to storage resources is allowed only through secure communication channels to authorized users and/or trusted networks."

In specific terms, it "encompasses classes of security and how they may or may not apply to the storage industry, and emphasizes access, authorization, communication, and controls as they apply to storage networks, devices, and protocols."

By applying security to storage networks in this fashion, @stake believes that IT organizations can not only prevent unauthorized access to, and traffic on, the storage network, but also make them "more functional, stable, and available, while creating a secure platform to support the growth of the business."

For more about @stake's Security Storage Model, see the research report, "Securing Storage Networks," at www.atstake.com.

This is the second article in a four-part series on storage security. Next month, we'll focus on specific products and technologies to help you secure your storage.

This article was originally published on October 01, 2004