Information availability requirements will dictate robust business continuance (BC) strategies (complementing traditional disaster recovery processes) based primarily on backup/recovery (B/R) implementations, with unified management. By 2004/05, most data center BC plans will include Unix/NT disk replication capabilities. Through 2005/06, because of intelligent storage for primary B/R services, highly parallel tape solutions will be relegated primarily to archiving functions.
As a result of tighter IT budgets through 2002, IT organizations (ITOs) have refocused their attention on total cost of ownership (TCO). Many ITOs are investigating how infrastructure inherited from e-commerce projects deployed during the dot-com boom (with little concern for cost) can be shared or consolidated with existing infrastructure to reduce the overall TCO.
By sharing the new and old infrastructures, ITOs are attempting to reduce costs by either increasing infrastructure utilization (e.g., resources in a storage-area network [SAN]) or reducing operations personnel costs (e.g., backup and recovery [B/R], enterprise system management [ESM]). Before attempting infrastructure consolidation across firewall zones, ITOs must understand the impact on security by evaluating how infrastructure architecture affects firewall policy.
By 2005/06, fewer than 30% of ITOs will have successfully consolidated infrastructure across the demilitarized zone (DMZ) and the data center zone (DCZ), due to the security problems caused by the architecture of fiber channel SANs, B/R tools, and ESM products.
Q. Can existing B/R infrastructure in the DCZ back up servers in the DMZ?
A. There are three ways to back up data on servers in the DMZ. The first is to use the B/R infrastructure already deployed in the DCZ (e.g., B/R tools, tape libraries) to back up servers in the DMZ. Because this reuses existing infrastructure and has a low impact on people and process, it has an attractive TCO. However, depending on how the B/R tool initiates connections across the firewall, it can require changes to the firewall setup that breach good security policy.
However, because the backup is of data stored in the less secure DMZ, the quality of the backup is unknown. That is, the data may already be compromised and so even if a successful backup is taken, the backup is invalid. For this reason, this is not the preferred method. Through 2002, B/R vendors will begin to improve the firewall friendliness of their products by requiring only a small number of known ports to be opened, instead of the current practice of using a large range of port. By 2004, most vendors will realize that using callback ports, which require a permanently open port from the lower trust zone to the higher trust zone, is unacceptable and will modify their products appropriately.
The second option is to put local resources (e.g., tape drives, B/R servers) in to the DMZ. The use of a totally separate management point in the DMZ avoids compromising the firewall but increases complexity and operational workload.
However, although leveraging the central backup manager reduces complexity and work, it may breach good firewall security practices. This option has lower sharing than the previous option and still suffers from the problem of compromised data; therefore, it is not recommended.
The third, and preferred, option is to have the systems in the DMZ built from a source that is located in the DCZ. This is commonly used for Web farms and read-only databases located in the DMZ. As a best practice, we recommend that volatile information be stored in a database in the DCZ rather than in the DMZ (e.g., make Web servers stateless and push persistent state into a database in the DCZ).
With this configuration, the B/R tools used in the DCZ can be used to back up the source system. This does not require changes to firewall security policy and has good reuse of existing resources. It has the additional benefit that systems in the DMZ can be rapidly recovered by pushing the information from the source systems, avoiding a slower tape-based restore. The use of disk-based recovery solutions (evolving through 2004/05) will simplify this recovery and provide a quick and robust method for building additional systems in the DMZ (e.g., adding new Web servers).
Q. Can I share a SAN across systems in the DMZ and DCZ?
A. Although the sharing of a SAN across systems in different security zones has measurable TCO benefits (e.g., increases resource utilization, reduces staffing costs), it bypasses firewall security and creates a new security weak point. ITOs must recognize that a SAN is a network and any system on the SAN potentially has access to all the resources on that network. The fiber channel protocol does not address security, and once a system in the DMZ is compromised, it can be used to access data on the SAN. Although this requires complex device driver coding, tools will evolve to assist hackers.
Currently, SANs have logical unit number (LUN) masking and zoning (limiting the scope of data accesses). However, implementing security using these features becomes increasingly complex as the size of the network increases. Although SAN vendors such as Brocade and FalconStor have introduced additional security measures, and SAN management tools (such as EMC Control Center and Veritas SANPoint Control) simplify the use of LUN masking and security, truly robust SAN security will not emerge until end-to-end authentication, authorization, and encryption are agreed to and implemented by host bus adapter, switching and array vendors.
Until more robust and manageable security is available for the SAN, we recommend using separate SANs in different security zones.
Q. Can I share a network-attached storage (NAS) device across systems in different security zones?
A. To ensure the integrity of the most sensitive data on the NAS device (i.e., the data that should be limited to the more secure zone), the device must be installed in the most trusted zone. However to enable systems in the DMZ to access their data, ports for CIFS or NSF must be opened in the firewall from the lower trust zone to the higher trust zone, violating good firewall security design.
Although the firewall can be configured to limit the access to just the NAS device and hence minimize exposure, the other data on the device is still at risk to attacks on the NFS or CIFS implementation. One of the benefits of NAS (vs. SAN) devices is that NAS has built-in volume and file-level security that can be used to authenticate and control access.
Before sharing a resource across security zones, ITOs must understand the resources communication architecture to determine the impact sharing will have on the firewall policy and hence the security.
Business Impact: Overzealous attempts to reduce the total cost of ownership of e-commerce projects can expose core application to unacceptable security risks.
Bottom Line: Before sharing infrastructure across security zones, IT organizations must carefully evaluate the impact of the product architecture on the firewall security.
Copyright
