Welcome to Volume 4, Issue 15 of The Internet Security Conference Newsletter, Insight. Insight provides commentaries and educational columns, authored by some of the best minds in the security community.
TISC is about sharing clue. So is this newsletter. We promise to provide something useful each issue. If we don't, flame me. If you like the issue, let us know!
Enjoy, and be safe,
Dave
Storage Area Networks are more than just volumes and volumes of disks networked together. They are networks, and as such, are subject to threats and are vulnerable to attacks like any other network. Like all the networks I've encountered, security is an afterthought. In today's column, Bill Van Emburg discusses a number of issues you must take into consideration when designing SANs.
Happy readingÖ
The amount of corporate data has grown exponentially with the advent of ERP, CRM and other enterprise-wide systems. Storage requirements are increasing proportionally. Storage Area Networks (SANs) play a key role in enabling companies to improve performance, reduce costs and make data more available to the enterprise. As SANs continue to grow and become more complicated, a key concern of IT departments should be securing the SAN.
SANs are not disks, they are networks. IT Managers face the same security issues with the SAN as they do with a LAN or a WAN. Security should be one of the key considerations in the design and configuration of a SAN; unfortunately, like so many network applications before, security for SANs is often an afterthought. Organizations are unnecessarily opening themselves to a host of problems that can most easily be solved at the onset with appropriate architectural decisions.
Early preparation helps to avoid some unpleasant outcomes for network storage. Personnel who manage and monitor the storage infrastructure must weigh the pros and cons of implementing a SAN, as well as deciding what servers should be a part of it. Is it worth installing a storage network that potentially bypasses corporate firewalls? Is the benefit of familiar networking protocols really worth increased risk of compromise? Is the cost of carefully controlling access to the SAN and carefully monitoring it for potential breaches greater than the downside risk of cleaning up after a security breach? Is the cost of adequately training your staff or paying an outsourcing firm greater than the cost of rebuilding compromised systems? Is the time and dollar investment really too great to carefully plan your SAN and consult with experts before implementing a solution? SAN security has improved considerably, but as with all security issues, it comes down to architecture, people and processes.
To design a secure SAN, you must consider several basic issues: physical and logical partitioning, protocol choices, access privileges and procedures. Every IT organization should perform a risk analysis to identify strengths, weaknesses and likely areas where security can be breached. Once potential entry points have been identified, the architecture should be designed to minimize the likelihood that any identifiable entry point can be leveraged. These are the same issues that must be addressed when securing any network.
It is a good idea to partition SANs by functionality. By separating network traffic, you eliminate bottlenecks and isolate different traffic. When different types of traffic travel over different networks, they can't slow each other down, and a compromised server can't interfere with the communications of other, unrelated servers. This makes the network more secure, improves performance and makes it easier to scale. If your web servers are not responding quickly enough, you can upgrade the speed of the network that connects them to their disks. If the application servers in this same network aren't being slowed down by the speed of their disk access, they don't have to be upgraded.
Servers should be grouped according to the access they allow. One example of this type of partitioning would be an e-commerce site, where machines might be separated into groups as follows:
Once these groups have been defined, separate SANs would be constructed for those groups where it makes sense to use SAN technology. For example, a web farm may or may not be a good candidate for a SAN, depending upon several factors, including whether the pages they serve to customers originate on disk, or are dynamically generated by application servers. An application server farm may benefit greatly from a SAN, or it may be that only the database farm really benefits from the enhanced speed and easier administration of the SAN.
Once the preferred number of potential SANs has been identified, budgetary issues must be considered. Does the budget allow for purchasing the number of fibre-channel switches required to maintain separate physical SANs for all groups? If a consolidated physical SAN is desired, is the risk that the SAN may be used to bypass an internal firewall acceptable?
Performance, scalability and budget are not the only reasons to isolate servers from each other. If a web server, which must be allowed to communicate with untrusted systems on the Internet, is not isolated from application or database servers with which it must communicate, then a breach of the web farm may more easily be leveraged into a breach of these other systems, due to the lack of firewalls and/or other protections between these different types of systems. Secure networks strive to eliminate the sharing of common resources among machines in different security classes, because some of these classes accept data from untrusted sources, which increases the likelihood of a security breach. Moreover, Security Managers should strive to ensure that discrete functions are executed on different machines. Since we don't live in a perfect world, companies must strike a balance between the needs of the business, cost and security objectives.
The rough equivalent in a SAN to VLAN (Virtual Local Area Network) technology may be considered when partitioning SANs, but VLANs alone are weak security measures. VLANs are logical separators, which provide less protection than a physical separator. Several known VLAN exploits allow attackers to jump from one VLAN to another on a data network. A detailed discussion of some of these techniques can be found in "VLAN Security Test Report" by David Taylor, 7/12/00. The same will likely be the case for SANs.
Whether the network is a LAN, WAN or SAN, you have to carefully consider the protocols that you permit to be used across the network. When SANS were first conceived, they extended the functionality of disks, so they support the SCSI protocol. SANs can also support IP (Internet Protocol). However, standard protections for IP-based networks, such as firewalls, don't exist yet for the SAN. Thus, if you run IP over a SAN, you risk incurring IP-based exploits, such as simply bypassing the data network altogether and looking for weaknesses in the IP stack used by another system on the SAN. It should be noted that IP stacks for SANs have not seen the rigorous testing of real-world use over the past thirty years. They may have security holes that have not yet been discovered. When deciding to use SCSI vs. IP, you need to weigh ease of use against security. As ease of use increases, security decreases.
This issue becomes more complex when you consider new protocols that are now available, such as iSCSI. Since iSCSI involves running your SAN traffic over an IP network, you have now potentially bridged the gap between the data and storage networks, leaving your SAN open to direct attack from network-based sources. One secure use of iSCSI is to extend the maximum distance over which you can connect disks and servers on the same SAN. It is not necessary to connect your iSCSI network to your regular data network. Instead, a private, point-to-point circuit can be set up with IP-capable routers on each side. SANs on each side of the connection would be connected to iSCSI gateways that connect to the routers. The IP network is isolated, and serves only to extend the reach of the SAN. In essence, this connects two physically separated SANs, making them one.
The most important elements of a successful security implementation are people and process. While you must accept that 100% security will never exist, you can keep up-to-date on software packages, drivers and security alerts, ensure your IT staff is well-trained in the area of security, and make certain that they review log files on a regular basis.
To realize a highly secure network, you must make sure that access control, authentication, and confidentiality are addressed. Thereafter, your IT staff should monitor and audit the security process, establishing a feedback loop to the risk analysis process mentioned earlier in this article. Security is a continuous cycle.
Lastly, your network architecture should be designed in such a way that if your network is breached, the cracker cannot leverage that breach elsewhere in your corporate IT infrastructure. Even though SANs are supposed to look like a local disk, they are not. They are indisputably part of your network.
SAN security continues to evolve, and yes, there are some serious limitations. However, SAN manufacturers continue to make important security improvements. Regardless of these efforts, there will always be security problems, so it would behoove companies to use the same security practices for SANs that they employ in the LAN and WAN. In this way, companies can prevent problems before they even occur. Stick to the basics and rely on the tried and true standard means of IT security to achieve your goals.
Bill Van Emburg is a co-founder and COO of Quadrix Solutions. He has been in the computing and telecommunications industries for the past 16 years. Bill has been responsible for architecture and/or project management in several large projects, including a complete E-Commerce system for a large retailer, an Outside Plant Engineering system for a regional Bell operating company, and a total replacement of the telecommunications infrastructure for a large regional hospital. In addition, he has been the developer for several enterprise real-time monitoring systems at large financial and telecommunications companies. Bill's expertise is in security, technology strategy, telecommunications, networking and systems architecture, project management and operations. He has a B.A. in Computer Science from Rutgers University, and is currently a member of the New Jersey Technology Council.