Home > Storage Magazine > Features > Protect your SAN from attack, part 2
EMAIL THIS LICENSING & REPRINTS
Storage Magazine

  CURRENT ISSUE  

  FEATURES  

  TOOLS, TRENDS & ANALYSIS  

  COLUMNS  

  ARCHIVES  

  SUBSCRIBE/RENEW  
 

Protect your SAN from attack, part 2
by W. Curtis Preston
Issue: Sep 2003
printer-friendly
licensing & reprints
< PREV PAGE   |   1  |   2  |   3  |   NEXT PAGE  >

Isn't hard zoning the same as port-based zoning?
No, it's not. Given Brocade Communications Systems Inc.'s predominance in the market, I'm blaming them for this wide misconception. Consider the following quotes from the Brocade Zoning User Guide (Version 2.2 for the SilkWork 2800): "In a hard zone, sometimes referred to as a port zone, zone members are specified by physical port number ... In a soft zone, at least one zone member is specified by a [world-wide name] WWN."

However, they also say that in soft zoning, "the switch does not control data transfer, so there is no guarantee against data transfer from unauthorized zone members."

This sure sounds like Brocade thought that soft zoning and WWN-based zoning were the same (as well as confusing hard zoning with port zoning). While they are still separate concepts, it's true that up until now, Brocade only offered hardware enforcement (hard zoning) in a port-based zone. You couldn't do hardware enforcement with a WWN-based zone. Therefore, while the two pairs of terms weren't synonymous--they were inseparable.

Consider these restatements of the above manual quotes to bring them in line with what I've been writing: "In a hard zone, sometimes incorrectly referred to as a port zone, zone members are specified by physical port number [because Brocade didn't offer hardware enforcement of WWN-based zones] ... In a soft zone, at least one zone member is specified by a WWN [therefore, if you specify a WWN name as any member of a zone, you will get soft--or nonenforced--zoning because Brocade didn't offer hardware enforcement of WWN-based zones]."

However, in the recent releases of Brocade switches, this is no longer the case. As shown in the specification sheet for the Brocade 12000, you can now specify hardware enforcement based on a WWN, port or even a LUN. Therefore, you can now have hard zoning with a WWN-based zone.

Although SANs can be designed in a secure manner, chances are that your SAN wasn't designed that way. Why? Neither soft zoning nor WWN-based zoning offer bulletproof security, and using them together is an invitation to disaster. And yet, most SANs use both, because that's what your SAN vendor told you to do.

This second part of my series on SAN security will explain the real differences between hard and soft zoning, as well as the differences between soft zoning and WWN-based zoning because the two are often confused with each other. Let's start with a quick review of my previous article, "Protect your SAN from attack," in the August issue of Storage.

There are five aspects of security: authentication, authorization, encryption, integrity and auditing. Authentication makes sure that a server requesting a block of data really is the server that it says it is. Authorization verifies that this server is allowed to view that block of data. Encryption ensures that if authentication or authorization are somehow defeated, the data won't be used by the wrong party. Integrity ensures that when the server gets the block of data it requested, that block actually contains valid data. Lastly, auditing allows for the verification of all of the other aspects, looking for possible security breaches.

This article is mainly concerned with authentication, because without it, there's no way to verify integrity, not much point in encrypting the data and almost no point in giving different servers different authorization. If any server can masquerade as any other server, what's the point?

In the old days of direct-attached storage (DAS), there was no reason to secure the storage. You couldn't get to the storage unless you went through the server. Authorization was built into SCSI, but it was only done to ensure that requests for data were sent to the correct device. No efforts were made to verify that the entity sending or requesting the data was allowed to do so. SCSI assumed that the request was coming from a valid server because someone would have to physically disconnect the SCSI cable from Apollo and plug it into Elvis' SCSI card in order to be able to access Elvis' storage. However, in storage networks, if you don't configure things correctly, it's possible for any server connected to the SAN to see any other server's storage.
< PREV PAGE   |   1  |   2  |   3  |   NEXT PAGE  >





TechTarget Storage Media
Storage Magazine View this month\\'s issue and subscribe today.
Storage Decisions Apply online for free conference admission.
SearchStorage.com
HomeNewsMagazineTopicsLearningMultimediaWhite PapersBlogsEventsAbout Us

About Us  |  Contact Us  |  For Advertisers  |  For Business Partners  |  Site Index  |  RSS
TechTarget provides enterprise IT professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective IT purchase decisions and managing their organizations' IT projects - with its network of technology-specific Web sites, events and magazines.

TechTarget Corporate Web Site  |  Media Kits  |  Reprints  |  Site Map




All Rights Reserved, Copyright 2000 - 2008, TechTarget | Read our Privacy Policy
  TechTarget - The IT Media ROI Experts