Knowing about Fibre Channel security issues -- how to test issues, how to mitigate them and
I would say it's a growing concern. The reason it's not a high concern is not because of the exposures -- the exposures are there. Fibre Channel itself is a specialized skill set, not everyone knows about it. As people learn more about the technologies and its security controls, they will see that the exposures in the Fibre Channel SAN can actually be worse than what they see on the network, TCP/IP world. It's not a huge concern now, but that's because of this lack of knowledge on how to perform these attacks and their impacts. A chief information security officer (CISO) is probably not aware of Fibre Channel security issues. They aren't worried about it, simply because they don't know about it. They are definitely aware of Web applications or Internet services. What iSCSI SAN security issues should resellers be aware of?
There are tons of iSCSI risks, and I would prioritize them higher because they are attached to a network. The attack surface -- meaning the ability to perform an attack -- is huge because it's all TCP IP. With iSCSI, once you're plugged in, that's the network where a person's laptop could access its storage array. Which security vulnerabilities are most frequently attacked in a SAN?
There are two attacks that I would worry about most. One is authentication. The authentication used by both iSCSI and Fibre Channel SAN is very weak; these are very dated authentication methods and open to many attacks. If I were an attacker, that's what I would go after. While authentication may or may not be enabled, if it is, it's still vulnerable to a trivial attack; people can get the password and log right in.
Often times, authentication is not enabled, so the other attack is simply something called spoofing. If you spoof your identity and you claim to be the authorized server to access the SAN, the SAN trusts the client. That attack can be done quite simply. Spoofing would probably be the top attack that I would worry about. How can a reseller help protect their customers against these SAN attacks?
There are zoning practices you can do on the Fibre Channel side, as-well-as enabling mutual authentication. The same thing applies to iSCSI. Try to use encryption when possible; although encryption has a lot of performance issues. If encryption is not possible, there's something called secure domain which basically prevents the iSCSI or the SAN from trusting the client with just its identity, using some mutual authentication and some encryption -- if possible. Do specific security vulnerabilities usually go unnoticed when people first set up the SAN?
Most of the time people aren't even aware that something has happened unless the system goes down. Because these attacks are pretty basic, an attacker could probably do this without getting caught, because no one's really looking at the SAN or focusing on it. When things do happen, it's often accidental. It's one thing to talk about attackers, but it's another thing to allow people to do things that are potentially dangerous and could cause system downtime. A big aspect of security is ensuring things like a SAN aren't disrupted in terms of performance or uptime. Oftentimes when there is a mistake, it's because someone did something that they should not have been able to do, because there was no security on the system. You want to make sure that people are only doing things that are safe in the environments, which entails limiting their controls and access unless they really need it. How can resellers help customers avoids these SAN-setup scenarios?
The first step is proper configuration, and using port-based zones or hard zoning; use authentication, if possible, and encryption in key aspects of the environments. Turn on logging to make sure everything is logged and there are proper files documenting what happens, if something happens.
At a generic level I would recommend these basics to anyone. It's amazing how those things are often never used in storage. No one has really thought about it. Fibre Channel is a relatively new industry: When all these startups started building, they tried to get product to market; security was seen as slowing down the process and an afterthought. Security wasn't considered in terms of the original design it's something that people had to do later on -- if their customers started asking for it. What are the best methods to find security vulnerabilities in a SAN?
There are a lot of undocumented methods. Usually I recommend a program I wrote called the Storage Network Audit. It is a generic audit program used to check for major security issues in your SAN. It's a question-and-answer format, and depending on your answers, it tells you best practices. If you are using a NetApp filer, there's another tool I wrote called SecureNetApp that will look at the configuration of that filer and tell you what settings should be changed and what should not be changed. There's network scanner, but they are built for operating systems and Web servers and don't tend to be focused on an EMC or NetApp storage. What do systems integrators or resellers need to watch for in customer shops when it comes to SAN hacking?
They should be more worried about accidents. They should look at the systems and make sure they're secured and locked down from anyone who isn't authorized to make changes or destroy or copy data. Put more emphasis on what they do know -- the exposures and weaknesses that can be fixed and locked down -- as opposed to what they don't know -- the attackers. Whether a hacker is trying to delete data or a legitimate user makes a mistake, these problems can be prevented with proper hardening and security. What are the greatest SAN security faux pas you've seen?
We had a customer deploying a SAN and giving people storage space. One of our other customers was using an ASP environment and they connected their Fibre Channel switch to the vendor's Fibre Channel switch. These things were designed in a way that all the configure information between both switches were shared. Suddenly our customer was able to see all their data, as well as all the other data sitting on the SAN. They were able to manage it, delete it, overwrite it, mount it; these fabrics all get connected together and they all speak together. This is nice for performance, but if you have a customer connecting to an environment that should be separated, you will be able to see their data unless there are security protections installed on the system.
Another scenario involved a user entering a command that they shouldn't have had access to; when they entered this command, they overwrote some volumes and damaged some data that wasn't recoverable, because it was the SAN, which was the backup itself. I don't know how many hours of downtime they had because someone entered a simple command and accidentally destroyed data.
Accidents are more of a problem right now, and a lot of time is spent on that. When you have that much sensitive data wide open, a lot of bad things can happen. Is there anything we haven't covered that you would like to add?
My main thing is about risk. I try to tell people, here's the risk, you can accept it or not, but I want the customer to make that decision. But what I see more often is people thinking everything is ok, thinking that their Net App Filer is more secure than the Windows operating system and that's not true. If people understand their risks, they can make decisions based on that knowledge. Can you recommend resources for those interested in learning more?
There is a security forum called the Storage Security Industry Forum. They do a lot of research and white papers around storage security.