Security Standards

Storage networks have become critical components of corporate computing environments. Regardless of the type of storage technology, these networks have been designed as if the storage environment and all of the components are already secure because security is provided by other networked systems. Most storage vendors, storage application developers, and storage network designers/engineers operate under the false and dangerous assumption that storage networks are both safe and protected from malicious activity. What's true is that storage networks are just as safe as any other unprotected network. It takes only a single exposed entry point for an attacker to gain access to a storage network and compromise everything the organization is trying to protect.

Elements of Security

There are several basic elements to consider when discussing security. The typical security elements that must be addressed by any secure solution are authentication, authorization, auditing, integrity, encryption, and availability/stability.

Most storage product vendors support these elements to some degree, but not in any uniform, standards-based method. Typically, product vendors focus on only a single component of a storage network, so they only provide for selected elements of security based on a single scenario. This limited focus has a direct impact on the user's environment as a whole.

A complete and secure storage solution must address each element of security. The solution must also address the growth and evolution of the storage environment. In order for products to function together, the newer versions often operate in some form of backwards-compatibility mode. This effectively reduces the security of all of the storage products to that offered by the oldest, and most likely, the weakest version.

The problem doesn't end with backwards compatibility. The storage network environment includes network and host elements that are part of the overall corporate computing environment and may even provide backbone functionality (in the case of switches). These elements are often overlooked as part of the overall security posture.

Overlooked items in terms of security include the storage products themselves as well as any other networking or host equipment that is used to make the environment function. If any one of these elements can be replaced, Trojaned, or subverted, then the entire environment is at risk. While lesser degrees of security may be applied to an environment that is fully contained or localized, the decision to do this and the assumptions made about the design must be understood and recorded. Otherwise, future environmental and functional design changes may fail to take previous design assumptions regarding security into account.

Security and the SNIA Shared Storage Model

By addressing security in the context of the layering scheme of the SNIA Shared Storage Model, we can easily identify areas where the elements of security can be applied.

If we break the model down into its component parts we can begin to identify where elements of security should be applied to the SNIA Shared Storage Model (see Figure 1). Determining whether or not one or more of the elements of security may be required for the individual layer and how that security is going to be achieved is the important part.

Applications
Applications are used to run storage devices, manage storage components, move data, and perform any one of a host of other functions needed for the devices and products in a storage network to function. In effect, every component that makes up a storage network is made up of applications. Therefore, each application must be examined in the context of its ability to be used to attack or defend the storage network. The determination of how security applies to individual elements of the storage network will most effectively be made at the application level.

File/Record Layer
Without proper authentication, authorization, auditing, integrity, and availability the components of the file/record layer would easily allow an attacker to bypass security in a number of ways.

Typically, the components of the file/record layer have many of the elements of security built into them. The issue is that the elements of security within these components can be safely ignored if functionality is the only consideration. Databases and file systems are often configured "out of the box" with little in the way of applied security options enabled. This is due primarily to the fact that default installations do not require that either the database or the file system it uses be configured in any way other than simple defaults.

Whether CIFS, NFS, SQL, FTP, or some other proprietary protocol is used, there are risks with the types of communication that are routinely established in the file/record layer of storage networks. These protocols are integral to the file/record layer components and their security components for their ease of deployment and with which disparate systems can be integrated into a shared environment.

Block Aggregation
The interoperability and compatibility issues that come from integrating disparate host, network, and device components often introduce new security challenges within the block aggregation layer. Each of these components requires some level of security to function safely and properly. These components must address security at both an individual as well as a unit level. These components may all come from different vendors that have made different design assumptions. The overall storage network design may call for certain component level capabilities that simply do not exist within the component used.

Storage Devices
By themselves, storage devices are basically inert objects that await commands from some form of controller (disk, server, storage, etc.). Yet they can understand device drivers, they can understand function calls, and they can establish communication to other devices. Therefore, it is important to understand how these devices function and how they could be compromised. For example, an attacker could use this capability to install rogue applications in virtually any location on a storage network - because that rogue application could interface directly with the storage devices.

Authentication
Authentication methods for storage networks like Simple Name Servers, basic end-user authentication, and hard-coded username/password combinations are simplistic and easy to defeat.

Authentication should encompass not only the users of storage systems, but also the devices and applications with which the storage system interacts. In many environments, any component of the storage network can be replaced or added without authentication. And in others, storage applications can be introduced into the environment with no form of authentication other than communicating with the appropriate protocol or utilization of an accepted SDK or API.

Storage networking components can be easily attacked due to weaknesses within their authentication mechanisms. Even environments that have deployed advanced forms of authentication can be attacked if the implementation of these mechanisms is faulty. The strength of any authentication mechanism is based on the quality of the implementation and the strength of the credentials. If the credentials are weak, or if authentication data is exposed due to faulty implementation, the mechanism itself can and will be defeated.

Authorization
In the case of pure networking components, the authorization components are built into the networking gear and may or may not be tied into the advanced authentication/authorization systems that are in common use in larger networks today. In the case of multi-vendor storage networks, there is a wide variety of authorization implementations due to the wide variety of storage hosts, storage devices, and the file system and database components.

User, application, and system authorization are all critical to the security of the overall storage environment. Administrators must ensure that authorization information is not lost during transit from the originating system (the storage client) through some form of intermediary (a storage controller, caching engine, etc.) and eventually to some form of storage device. It is also important to ensure that the credentials that are associated with user access are appropriately understood by all elements of the storage environment and that they can be acted upon (i.e., user rights, disk quotas, or specific file system attributes).

Authorization works best when it reflects discrete roles, which encompass users, devices, and applications within the environment. Controls around authorization must be designed with the overall environment in mind. This makes it difficult for administrators of existing storage networks, especially early adopters of storage technologies, as many of the components that currently exist may have been inherited and therefore may not be fully understood.

Failure to identify how and when objects or resources need to be accessed during design will result in lax or non-existent access controls or authorizations. For example, access to critical files, especially log, temp, cache, configuration, and database files must be closely guarded and limited to privileged accounts. If these files are not protected with proper access controls, or if the access controls can be bypassed in some way, users can essentially gain access to data that may allow them to elevate their privileges.

Auditing
The ability of the systems within the storage environment to capture and retain log information pertaining to access and modification of data is paramount to the security of the overall environment.

All storage network components must be able to capture and maintain log information, either remotely or locally; this includes networking components, hosts, storage devices, and storage applications. While these various components of the storage environment may capture and record log information in different ways, they must have the capability to log pertinent information in context.

Additionally, the ability to log both remotely and locally is important for trend analysis and shared security infrastructure. In order to understand security threats and manage security breaches, the administrator should create a mechanism to allow containment of a remote logging device for the storage network to identify trends, anomalies, and suspicious activity. Most storage products today relegate logging and log reporting to other components of the storage network. While many storage applications and storage products have some capability to capture and display log information, standards and formats are inconsistent, and the amount and quality of detail vary widely.

Many systems are completely proprietary in nature, making the import and export of logging data into a third-party system difficult. As with other networks, many storage network environments support only limited logging capabilities, and administrators tend to accept the default configuration. In other cases logs are not properly protected or may be accessed by users, even those with limited privileges. Malicious attackers know this, and take advantage of both the product's default logging features (which are limited) and the average administrator's reluctance to change them. As a result, attacks sometimes go unnoticed. This dynamic presents opportunity for attack of both storage technology (hardware and software) as well as the networking gear that supports the storage network (routers, switches, and hosts).

Sometimes the simplest solution is the best one. Since the de facto standard for logging of information throughout the computing industry is syslog, it would be ideal for storage network components and applications, in the future, to have some means of delivering log information in this format.

Integrity
It goes without saying that storage security must not in any way compromise the storage environment or the data it manages. This requires that the system provide some means to confirm that integrity has been maintained over time. While storage solution vendors provide some means for ensuring integrity through their product offerings, the integrity of the system remains open to compromise because there is no accounting for the integrity of the networking or switching components that provide the storage system's foundation.

To the trained security professional (or malicious attacker), these network components are obvious attack points. If the storage vendors don't provide helpful security guidelines for the secure deployment of their components, their customers are at risk.

The integrity of the components of the storage network and the configuration of those components is just as important as maintaining data integrity. If an attacker can Trojan or replace a component of the storage network, then he/she can force nearly any change that is desired into that network, up to and including capture or destruction of data.

Encryption
Data encryption for storage networks is still in its infancy. Few storage network architectures take advantage of the benefits of encryption, which can be blamed to some degree on design considerations and functionality tradeoffs when encryption is put to use. The process of encrypting data can be very costly and the tradeoffs significantly impact the performance of any network. Encryption brings with it the requirements to both protect encryption keys and escrow them in the case of a catastrophic system failure. While a malicious user may attempt to steal an encryption key and thus be able to steal usable information from a storage network, it is a far greater risk that in the event of a system failure the loss of an encryption key could render all data upon a given disk array completely irretrievable.

Assuming design considerations and functionality issues are resolved, encryption is not a security panacea. Encryption can protect against data theft, prevent certain forms of hijacking of data, protect network traffic, and even prevent attacking systems from successfully communicating with intended targets. However, encryption cannot protect against the willful destruction of data, which can still be deleted or tampered with in a fashion that will render it useless.

As a security best practice, storage environments must have the ability to encrypt data both in transit and at rest. Since storage environments can be used in many different ways and can have many different customers, steps should be taken to ensure that data is encrypted before it even reaches the storage network. This does not remove the responsibility for providing this capability from the storage vendor, but it is also good practice on the part of the eventual end-user of the environment. This is especially important for users of shared storage environments.

Availability/Stability
Availability and stability of systems are hallmarks of successful products. Unless alternatives are limited or non-existent, users will not put their faith in products that are regularly unavailable or are often thrown into an unstable state. Many storage solutions are susceptible to simple denial of service (DoS) or flooding attacks. The likelihood of these attacks occurring is reduced only by the location of the storage network. As storage networks proliferate, they have a tendency to migrate towards the edge of corporate networks, increasing the likelihood that they come under attack. Furthermore, DoS attacks and flooding attacks are common methods used to force systems into an unstable state or force systems to invoke a down-level protocol. This can be part of a larger attack that necessitates the target being weakened in some way. Smart attackers can target relatively unprotected storage networks in order to compromise other corporate information networks or assets.

Overall system security is a requirement for any environment in order to guarantee availability and stability. If the environment cannot resist even simple attacks, then it cannot be maintained in an available state. In the case of some storage network and some storage product designs, availability is addressed by simply supplying more of the same resource to the resource pool. This will not protect the storage environment from automated attacks or malicious mobile code; it will simply result in more of the same type of resource being damaged. The end result will still be a storage network that is unavailable.

Elements of Storage Design

Storage network design must take security of both the environment and the data into account. Figure 2 describes a simple storage design that spans multiple networks, and presents configurations that enable communication for this type of network along with potential security risks.

Storage Network Design
As the demand for storage technology increases, it makes economic sense to combine the benefits of storage networks with those of existing network investments. Without proper planning, doing this can actually have negative effects on the security of the existing enterprise network.

Some aspects of a storage network design may look similar to an Out-of-Band (OOB) management network. In these cases the storage network may effectively transit many different security zones, providing attackers with access to a transit network that bypasses security from externally attached networks into the core. Most attackers understand the basics of network management, of which storage solutions may be considered a part, and know how to take advantage of the protocols and applications used to communicate between these systems and environments.

As stated previously, the storage devices and applications may not be the ultimate target of attack, but their vulnerability to attack may make it easy for an attacker to reach resources on the attached enterprise network. In this case, attackers rely on the fact that administrators may cut corners in order to make multi-vendor networking and storage technologies work together.

The converse may also be true. In environments that have grown to depend on storage technology, it is quite possible to introduce connectivity into the storage environment from unanticipated sources. This is a danger in any network, but even more so in storage networks, as many of the components of storage technology within them are critically dependent on the security of the storage environment being maintained.

Product Functionality/Interoperability
Interoperability and functionality are issues that have plagued network and host systems for years. In the case of storage networks it is again an issue of balancing security needs with system requirements of stability, functionality, and performance. Some storage products require such specific configurations that the introduction of some security technologies has a deleterious effect on system performance. In the case of a localized storage network the risks of allowing some protocols or some types of system configuration are relatively limited as the environment is known and well contained. But, when an environment of this type is expanded or connected to other networks, the previously acceptable risks become security nightmares.

Many storage products actually introduce considerable security risks to a network if all of the functionality of the product is enabled. Some simple examples of this are Web-based management, SNMP-based management, and the use of a large number of ports for communications between product components. Fortunately, each of these issues is easily resolved, but in some cases they require additional layers of protection and design. Many of these issues could easily have been prevented by the vendors through more secure product design.

Additional issues arise when product vendors base their product design on third-party solutions. For example, storage controllers are dependent on the base operating system upon which they run. If that OS is taken down frequently due to patch administration and upgrades, the stability and functionality of the storage solution are reduced.

The problem of product maintenance quickly becomes extremely complex. If the vendor is responsible for support of both the storage component and the supporting infrastructure (the OS) component, then that vendor must devote resources to both understanding the patch cycle of the components and managing each product's maintenance schedule. The vendor must also develop methods of updating the product in a fashion that is easily understood by the eventual end user, who may be a storage operations engineer or a systems engineer.

If the vendor product team is not responsible for the maintenance of the component, then both the component and the storage product are exposed to those attacks to which the component may be vulnerable. Unfortunately, it takes only a few days or weeks for attacks to spread among attackers, often leading to a simple attack vector becoming executed against every buyer of a given product line, while the victim companies await the fix or patch from the vendor.

Applications
Storage applications cover the implementation of everything from commercial off-the-shelf (COTS) applications to proprietary applications developed in-house, to software development kits (SDKs) and application programming interfaces (APIs) used to enhance storage solutions. These applications represent major components of the inner workings of the storage environment. As a result, they are all the more attractive to attackers and have become the favorite targets.

Application attack techniques have advanced exponentially in the last few years. Unfortunately, quality engineering, testing processes, and security awareness within software development teams has failed to keep pace. Developers of storage solution software and storage applications, both commercial developers and in-house development teams, often fail to consider what would happen if an attacker gained direct network access via the storage application or device.

Conclusion

Security plays a vital supporting role in enterprise storage networks. As storage networks proliferate and become more integrated within the enterprise network, companies need to put appropriate security plans in place to adequately protect intellectual property. By viewing security as a system of interconnected processes and technologies, companies can still provide appropriate support for requirements such as functionally, throughput, and design simplicity.

This security storage provides a foundation for security professionals who need to understand security issues as they pertain to storage networks. The Security Storage Model puts security in the context of storage and makes it easier for the average storage administrator to include security issues in the design, creation, implementation, and maintenance of any storage network without incurring unnecessary overhead, negatively impacting functionality or compromising the integrity of the data.

Add Your Feedback

In order to post a comment you need to be registered and logged in.

Register | Log in

Please wait while we process your request...