EMC ControlCenter 6.0 Security Guidelines ... This white paper is intended for use by EMC ControlCenter administrators and IT staff responsible for application, data, and network security

EMC ControlCenter 6.0 Security Guidelines Best Practices Planning

Abstract

This white paper provides advice and information on practices that will enhance security when setting up EMC ControlCenter® 6.0. Topics include securing managed objects, securing the ControlCenter environment, and using firewalls.

September 2007

Copyright © 2007 EMC Corporation. All rights reserved.

EMC believes the information in this publication is accurate as of its publication date. The information is subject to change without notice.

THE INFORMATION IN THIS PUBLICATION IS PROVIDED “AS IS.” EMC CORPORATION MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND WITH RESPECT TO THE INFORMATION IN THIS PUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Use, copying, and distribution of any EMC software described in this publication requires an applicable software license.

For the most up-to-date listing of EMC product names, see EMC Corporation Trademarks on EMC.com

All other trademarks used herein are the property of their respective owners.

Part Number H2994

EMC ControlCenter 6.0 Security Guidelines Best Practices Planning 2

Table of Contents Executive summary ............................................................................................5 Introduction.........................................................................................................6

Audience ...................................................................................................................................... 7 Security management in EMC ControlCenter: Users and actions..................7

Designing the ControlCenter authorization policy........................................................................ 8 Authentication of ControlCenter users and host users ................................................................ 8

The ECCAdministrators group ................................................................................................. 9 Limiting use of the eccadmin account .................................................................................... 10 Creating user groups to define job roles ................................................................................ 11 Creating authorization rules ................................................................................................... 12

Authorization using user-defined (object) groups ...................................................................... 13 Creating user-defined object groups ...................................................................................... 13 Controlling object groups: The ChangeMembership permission ........................................... 13

Authorization for ControlCenter Agent Management................................................................. 14 Controlling agent operations: The Agent Management permission....................................... 14 Agent security......................................................................................................................... 14 Security considerations for ControlCenter agents.................................................................. 15

Auditing: Examining logs............................................................................................................ 16 Using log files and Command History .................................................................................... 16 Using Command History to see login history ......................................................................... 17 Symmetrix Activity Log ........................................................................................................... 19

Summary.................................................................................................................................... 19 Securing the storage infrastructure elements................................................20

Array security ............................................................................................................................. 20 Setting up Symmetrix Access Control (SYMACL).................................................................. 20 SymACL considerations when upgrading from ECC 5.2 SPx to 6.0 ..................................... 22 Symmetrix SID lock ................................................................................................................ 22 Securing SYMAPISRV ........................................................................................................... 23 VCM database restricted access............................................................................................ 24 iSCSI ...................................................................................................................................... 24 CLARiiON and Navisphere..................................................................................................... 24 Storage agent for HDS configuration ..................................................................................... 25 StorageWorks STEAM Agent configuration ........................................................................... 25

Switch/fabric security ................................................................................................................. 25 McDATA ................................................................................................................................. 25 Brocade .................................................................................................................................. 26 Cisco....................................................................................................................................... 26

NAS security .............................................................................................................................. 27 Host security .............................................................................................................................. 27 ControlCenter repository server (Oracle listener) ...................................................................... 27 Summary.................................................................................................................................... 27

Controlling network access to ControlCenter components .........................28 Component configuration within a secure perimeter ................................................................. 28 Isolating the ControlCenter traffic network................................................................................. 29 VPN considerations ................................................................................................................... 30 Encryption .................................................................................................................................. 30


Citrix Terminal Services ......................................................................................................... 30 Using the ControlCenter Console from outside a firewall .......................................................... 30

Citrix Terminal Services ......................................................................................................... 30 Securing Ethernet ports.......................................................................................................... 31

Using ControlCenter 6.0 with firewalls....................................................................................... 31 Summary.................................................................................................................................... 31

Conclusion ........................................................................................................32 Appendix: Frequently asked questions ..........................................................32


Executive summary Securing an automated networked storage infrastructure environment has a variety of aspects and components to consider. Security risks impact all possible access points. Access paths from hosts and networks need to be controlled. Authentication and authorization of management access need to be enforced with policies and rules.

Host & Network Access

Storage Management

Remote ServiceAccess

TAPE OR DR SITE

Business Continuity

STORAGENETWORK

Figure 1. Automated networked storage infrastructure environment Traditional risk assessment methodology applies to a storage environment as well.

Risk = Threat * Likelihood * Impact What is the likelihood of an attack? The likelihood of an attack is an assessment of the traditional

security risk elements. Security threats are applicable to the solution (spoofing identity, information disclosure) Likelihood of occurrence of an attack (specific to the solution environment) Business impact of an attack (cost, reputation, policy, or regulation violation)

Implementing security guidelines helps reduce the risks by diminishing the likelihood of occurrence of attacks. Figure 2 shows how security guidelines help reduce risk.


Storage Management Infrastructure

Console or CLI

Console or CLI

Array Array

Host Host

Agent

Host

Switch

Host Host

Console

IP Network

Spoofing host or user identity

Spoofing user identity

Elevation of user privilege

Agent

Host

Host

Host

Storage Infrastructure

Spoofing host identity

Tampering with data

Information disclosure

Figure 2. Implementing security guidelines helps reduce the risks

Implementing security guidelines also helps balance security, accessibility, and performance.

Figure 3. Reasonable security

No firewall

No access control

Properly managed

security controls No Internet connection

Reasonablesecurity

Total security No accessibility

No security Total accessibility

Introduction The EMC® automated networked security guidelines are a practical approach to support and enforce information security policies in the storage environment of an organization. This white paper focuses on the subset of the automated networked storage security guidelines that are relevant to protecting storage management access to storage in an EMC ControlCenter® environment:


• The “Security management in EMC ControlCenter: Users and actions” section covers authentication

and authorization for ControlCenter users as well as logging of operations. • The “Securing the storage infrastructure section expands mechanisms available to protect access to the

array and other components of management operations. • The “Controlling network access to ControlCenter components” section looks at different network

architecture scenarios to control network access to ControlCenter components, including remote storage administrator access and the use of ControlCenter with firewalls.

Overall network security is beyond the scope of this paper, and the advice and information presented should not be taken as definitive security recommendations. Many factors are involved in securing a network, and each network is different with unique security requirements. For problems unique to your site, seek the advice of professional security consultants.

EMC does not assume responsibility for network security and recommends that as a best practice, ControlCenter components be installed on a dedicated, single subnetwork that is isolated from outside networks. EMC Customer Support personnel will offer troubleshooting and configuration assistance intended to ensure correct operation of components on a specific subnet. If your infrastructure includes routing and/or firewall functionality, additional EMC resources will be needed to troubleshoot communication issues, and you will need to provide details of your network topology and security configurations. While EMC will provide support on a best-effort basis, EMC does not guarantee operation for any installation that involves firewalls or Internet work transmissions.

This white paper does not address guidelines for securing host access to the networked storage. For more information on storage security in a SAN environment go to the Web for guidelines..

Finally, “Appendix: Frequently asked questions” provides answers to frequently asked questions on ControlCenter security.

Audience This white paper is intended for use by EMC ControlCenter administrators and IT staff responsible for application, data, and network security. Fundamental knowledge of storage and security concepts, as well as a working knowledge of ControlCenter and other EMC technologies, is required to understand the material presented. Implementation of the suggestions outlined in this paper requires advanced knowledge of the technologies described herein.

Security management in EMC ControlCenter: Users and actions Controlling the administrators who configure the storage environment is a critical part of automated networked storage security. Controlling administrators’ actions requires enforcing the following general security rules:

• Each administrator must have an individual account; there should be no shared accounts. • Each administrator must be positively authenticated before performing any management action. • Strong password policies for administrators should be enforced; passwords should be complex and

regularly changed. • Administrators should be authorized to perform only the management actions required to perform their

job. • Administrator actions should be audited. The following sections review ControlCenter capabilities available to implement those steps.


Designing the ControlCenter authorization policy ControlCenter provides a highly customizable authorization policy based on the storage administrator’s job functions. To set up and design an authorization policy for ControlCenter, it is recommended to apply the following rules:

• All storage administrator profiles should be defined to manage the necessary parts of the storage network. Each storage administrator profile must correspond to a set of operations that one or several storage administrators must perform in their job duties.

• Each storage administrator profile will be represented in ControlCenter by a user group. The section “Creating user groups to define job roles” on page 11 details the process of creating user groups in ControlCenter.

• Authorized operations for a storage administrator profile can be defined at the storage element level, such as a switch or a storage array. To facilitate the management of ControlCenter authorization policy, storage elements can be grouped in object groups. For instance, all storage arrays within a SAN that are administered by a given storage administrator profile should be grouped into a ControlCenter object group. The section “Creating user-defined object groups” on page 13 details the process for creating object groups in ControlCenter.

• Finally, authorized operations on storage elements for a storage administrator profile are defined by rules, which tie together users or user groups with permissions onto ControlCenter objects or ControlCenter object groups. The section “Creating authorization rules” on page 12 details the process of creating ControlCenter rules.

It is recommended to use user groups rather than individual users when defining ControlCenter rules. This directly supports role-based authorization policy where detailed permissions are configured once, and day-to-day employee turnover management is done by managing user group membership without changing the underlying authorization rules, as shown in Figure 4.

Authorization rule

Authorization rule

Users

Usergroup

Objectgroup

Objectinstances

Object types

Permissions

Figure 4. ControlCenter authorization model

Authentication of ControlCenter users and host users It is important to differentiate between host user accounts and ControlCenter user accounts. ControlCenter supports three types of host user accounts:

• Local Windows user accounts created on the ControlCenter server


• Windows domain user accounts • User accounts in an LDAP directory A ControlCenter administrator can add these host user accounts to ControlCenter under Administration > Security Management > Users. This authorizes the user to log in at the ControlCenter Console.

A host user account does not need to be a ControlCenter user account. Therefore, it is possible to delete a ControlCenter user account while retaining the corresponding host user account. This means that the user may still log in to the machine but may not log in to a ControlCenter Console.

ControlCenter login uses Secure Socket Layer (SSL) to encrypt login and password information between the ControlCenter Console and Server. When LDAP is used as the authentication mechanism, SSL is also used to protect that transaction.

The ECCAdministrators group A ControlCenter user is a person who is allowed to log in to the ControlCenter Console and perform actions based on the authorization rules that apply to that user. When ControlCenter is first installed, there is a single user called eccadmin. This single user is a member of a predefined user group called ECCAdministrators. The ECCAdministrators group in turn is granted authority to perform any action on any object through the default ECCAdministrators Rule (Figure 5). The main user management tasks of a ControlCenter administrator are to add other ControlCenter users, create user groups, place users into user groups, and create authorization rules for users and user groups. The number of ControlCenter users should be limited to those who require ControlCenter access to perform their jobs. Membership in the ECCAdministrators group should be very strictly limited. The ECCAdministrators user group cannot be renamed or deleted.

Figure 5. Initial setup for ControlCenter with an eccadmin account


Limiting use of the eccadmin account The eccadmin account is an anonymous account. Anyone logging in to it can perform any function without giving away their identity in log files. For this reason, it is desirable (but not necessary) to limit or eliminate use of this account as a ControlCenter login account. This can be done in several ways.

One way is to eliminate the eccadmin account as a ControlCenter user account. When ControlCenter is first brought up, it is recommended someone log in as eccadmin, create a new ControlCenter user, and place that new user in the ECCAdministrators group (Figure 9). Note that the new ControlCenter user must already be a valid account on the ControlCenter Server host (or in an accessible domain, or LDAP directory). Once this is done, the eccadmin account is no longer needed so it may safely be removed as a ControlCenter user account. To do this, log back in as that new user in the ECCAdministrators group and delete the eccadmin account from the list of ControlCenter users. The corresponding host user account for eccadmin may be left in place for use by Customer Support, or it can be disabled or even deleted. Figure 6 shows that eccadmin has created a user Lara and made her a member of the ECCAdministrators group. (The EMC ControlCenter 6.0 Administrators Guide has detailed information on how to create users and make them members of user groups.)

Figure 6. New user in ControlCenter ECCAdministrators

After logging out and logging back in as Lara, eccadmin may be deleted from the list of ControlCenter users, as shown in Figure 7.

A second way to limit use of the eccadmin account is to use Windows (or LDAP if appropriate) user management. Two actions are possible and either or both may be done. First, the password for the eccadmin account may be changed, and the new password held as a secret known to very few people. Second, the account itself may be marked as disabled, so that it cannot be used to log in. Before the account is disabled, another user must be added to the ECCAdministrators group. Once the account’s password has


been changed or disabled, the account may be left as a ControlCenter user account, renamed, or removed, as described earlier.

One final way to eliminate use of the eccadmin account is to remove the account as a ControlCenter user account and delete the account from the server host machine. Before doing this, be sure to add a new user to the ECCAdministrators group, as described earlier. If the eccadmin account is deleted from the host machine, Customer Support may have to re-create it in order to perform certain maintenance procedures.

Figure 7. Deleting the anonymous eccadmin account

Creating user groups to define job roles The authentication mechanism also allows users to be formed into user groups for easier definition of security policy. Users should be placed into user groups whose authorization rules are appropriate to the jobs performed by the users. Users should be given enough authority to do their jobs, but no more.

ControlCenter ships with a simple set of user groups that can be used to categorize users according to broad job descriptions. You can see these groups in Figure 7. They are:

• ECCAdministrators: Users with overall responsibility for managing ControlCenter, including defining security policy (creating ControlCenter users and authorizing them to do things). This group should be kept as small as possible since anyone with the power to create authorization rules has, in effect, access to all functions provided by ControlCenter and all devices managed by ControlCenter. The ECCAdministrators group may not be renamed or deleted.

• SAN Manager: Users with responsibility for managing switches, fabrics, and so on. • Symmetrix Configuration Manager: Users with responsibility for configuring Symmetrix® storage

arrays. This includes functions like Symmetrix Dynamic Reallocation (SDR), business continuation volume (BCV) definition, logical device definition, and others.


• Symmetrix Data Protection Manager: Users with responsibility for data replication. This includes

functions like Symmetrix Remote Data Facility (SRDF®) and TimeFinder®. • Symmetrix Performance Manager: Users with responsibility for tuning performance. This includes

functions like Symmetrix Optimizer and Quality of Service Controls. These groups are initially defined to grant their members authority to perform the functions over all objects of a given type. For example, the Symmetrix Configuration Manager may perform the authorized functions on any Symmetrix storage array. While this may be acceptable in smaller installations, the best course of action is usually to group Symmetrix storage arrays and other devices into user-defined object groups that correspond to organizational or departmental divisions, and then create user groups and authorization rules to give members of those user groups authority over only the objects in a specific object group. For example, suppose the Accounting department has its own set of Symmetrix and CLARiiON® storage arrays. These could be placed in a user-defined object group called Accounting. A user group called Accounting Environment could be created for people whose job it is to manage these devices, and then an authorization rule could be created that grants selected actions to the Accounting Environment user group on the devices in the Accounting object group. Similar groups and rules could be created for the other roles. In this way, people are given the appropriate amount of authority only over those devices for which they are responsible.

In general, you should only make user groups and object groups that are needed to define your security policy. If you make too many user or object groups, it becomes easy to forget exactly what your security rules allow.

If the default user groups provided by ControlCenter are not used, then they should be deleted. In general, it is good practice to delete user groups that are not being used since this will prevent them being used by mistake.

Creating authorization rules The authorization mechanism allows an administrator to create rules for an individual user or for a group of users. These rules grant users permissions to perform actions on specific devices or groups of devices. User groups should generally correspond to specific jobs or roles in an organization; rules for the groups define what people in those jobs may do, and users should be added to user groups that correspond to their job functions. If a user requires some kind of unique access, a rule specific to that user may be created. Users should be given only as much permission as needed to do their jobs. For a complete description of the rule creation mechanism, refer to the EMC ControlCenter 6.0 Administrators Guide and online help. Figure 8 displays the authorization rule for user and object groups.

Figure 8. Authorization rule for user group and object group


Authorization using user-defined (object) groups The following procedure describes the authorization when using user-defined groups.

Creating user-defined object groups Object groups are an optional feature designed to both simplify administration and limit who can manage objects within the group. These groups may consist of any mix of hosts, switches, storage arrays, and so on. An example of an object group might be a group of hosts with a common operating system, such as Windows or UNIX, and the storage arrays or devices and Fibre Channel switches that support that environment. Groups could be created to align with business cost centers managed by different groups or other organizational structures that affect the management of the computing infrastructure.

Controlling object groups: The ChangeMembership permission When forming groups of objects for use in authorization rules, it is important to limit who has the authority to change the membership of these groups. This is because anyone who can change the membership of an object group used in a rule will change the set of objects to which the rule grants permissions. The ability to change the membership of an object group is controlled by the ChangeMembership permission (refer to the EMC ControlCenter 6.0 Administrators Guide for details). Generally, only ControlCenter administrators should have the authority to change the membership of object groups. However, the authorization system does allow this permission to be granted to other users. If an administrator does grant this permission to another user, the administrator should be aware that they are delegating some of the power to define authorization to that user.

As an example, suppose an administrator creates an object group called Accounting and creates an authorization rule granting user Joe permissions that allow Joe to do TimeFinder and SDR commands on any Symmetrix arrays in that group. The administrator then populates the Accounting group with one Symmetrix array and three CLARiiON arrays. Joe can now perform TimeFinder and SDR commands on the Symmetrix array. Joe does not have the ability to change the membership of Accounting because the administrator has not granted Joe the ChangeMembership permission on that object group. Let’s suppose the administrator trusts Joe enough to delegate the authority to decide which Symmetrix storage arrays belong in the group Accounting. The administrator could do this by creating an authorization rule that grants Joe the ChangeMembership permission on Accounting. This is a very powerful permission because Joe can now perform TimeFinder and SDR commands on any Symmetrix array that Joe decides to put in that object group. The administrator has, in effect, delegated to Joe some of the authority to create security policy because Joe can now decide which Symmetrix arrays he controls.

Figure 9. Authorization examples for user-defined group


Authorization for ControlCenter Agent Management The following procedure describes the authorization for agents.

Controlling agent operations: The Agent Management permission ControlCenter 6.0 includes a new authorization permission that can be used to limit access to operations that affect agents. This permission is the Agent Management permission. It controls the following agent operations:

• Install • Upgrade • Start • Stop • Uninstall • Restart Master Agent • View Install Logs • Apply Patch Only ControlCenter users with this permission may perform these operations.

Agent security For technical reasons, agents must run as root. However, agents do not perform active commands as root. This is why agents require username/password verification to execute commands. Agent root privilege is used for the limited purpose of allowing the agent to assume the identity of the logged-in ControlCenter Console user. So, agents do not compromise the underlying security of managed objects because of their root privilege. For example, if the Oracle database must be updated, the updater must still be an authorized Oracle user.


Security considerations for ControlCenter agents Table 1 summarizes for each type of ControlCenter agent the impact of an intruder taking control of the agent on the storage system, and proposes countermeasures to limit such impact.

Table 1. Security considerations for ControlCenter agents

Type of ControlCenter agent Intrusion impact Countermeasures

Storage Agent for Symmetrix* Take control of the array.

Install agent on a private management network isolated from the main LAN.

Storage Agent for Symmetrix: Configure SYMACL and SYMAPI Server to limit host management access to the array.

Storage Agent for CLARiiON Take control of the array.

Restrict host access to SECURE XXX NAVI CLI.

Restrict access to array by configuring Navisphere® agent in array storage processor properties

Storage Agent for CLARiiON: Configure SYMAPI Server to limit host management access to the array.

Storage Agent for HDS Take control of the array.

Restrict host access to vendors CLI.

Storage Agent for StorageWorks Take control of the array.

Only discovered by SMI-S Provider

VMware Agent Log in the Virtual center.

Enforce general security measures like password changes, length, and composition restrictions.

Fibre Channel Connectivity Agent*

Take control of the Fibre Channel switches.

Install agent and Fibre Channel connectivity devices on a private management network isolated from the main LAN.

SDM agent Gather data about WWNs.

Storage Agent for Symmetrix: Configure SYMACL and SYMAPI Server to limit host management access to the array.

NAS Agent Gather data about NAS devices.

Celerra® enable secure shell.

Connect management LAN port to management LAN.

Configure SNMP ports and set up firewall filters.

Host Agent Take control of the host.

Enforce general security measures like password changes, length, and composition restrictions. Limit host access to storage with LUN masking, zoning, and SID lockdown.

Oracle Agent* Read database metadata.

No access to database content.

None necessary.

Common Mapping Agent* Read host and database metadata. No access to database content.

Configure symapisrv to allow access from trusted hosts only.

Do not enter license keys. They are not needed for ControlCenter.

EMC Solutions Enabler Take control of the array.

If possible, install Solutions Enabler on a private management network isolated from the main LAN. Add required licenses only.

* Requires Solutions Enabler.


NOTE: ADD ESS, Invista®, EMC Centera™ and SMI agents are new or not listed previously-- currently passive only.

Auditing: Examining logs ControlCenter provides both a log of user activity, stored in log files of the ControlCenter Server and in the agent directories, and a Command History of user actions, which is stored in the repository.

Using log files and Command History The log files and Command History are always important sources of information when security is a concern, especially if there is a suspected intrusion or suspicious management activity. The ControlCenter Command History is accessible from the Monitoring menu (Monitoring > Command History). It presents the user a table with Command ID, name, operation name, command outcome, command state, object, user name, start and end date, and task detail and information.

The ControlCenter log files end with a trc suffix and are found in the data directory under the installation root. These files give detailed messages about ControlCenter activities ControlCenter.

When examining a log, there are some general actions to look for:

• Users doing unusual things (for example, performing operations outside their expected authority). This could indicate a flaw in the way a security policy is set up; a user may have been inadvertently granted more authority than is desirable.

• Users doing authorized things at unusual times. This could indicate that someone else is using the user’s account (and perhaps stolen the user’s password).

• Repeated access denials. This could indicate someone who is attempting to break into a system or is testing the limits of an account.

Let’s suppose the system has three Symmetrix storage arrays with the identities 000184600314, 000185400145, and 000185400217. (For simplicity, we refer to these by the last three numbers: 314, 145, and 217.) Suppose that the authorization rules grant Cate permission to perform TimeFinder operations on 314. If she performs an Establish command by right-clicking 314 and selecting Data Protection > TimeFinder > Establish, then the Command History shows a screen like in Figure 10.

Figure 10. Command History after a successful command

The server.trc file shows the corresponding entries1: SVR 14:40:18 L P I TcpConnection(tcp:// 1xx.21.133.74:30750->tcp:// 1xx.21.133.74:17663) EccCommandManager:

- Execution thread started for command: BCVCommand, id = 1027

SVR 14:40:25 L P I Command_BCVCommand,_id_=_1027 SymApiPassThruCommunicator:invokeSymapiCall:

These entries show that the command was submitted and executed successfully. The timestamp information and the command ID (1027) tie these log entries to the entry in the Command History.

Let’s suppose Cate tries to do the same command on 217, to which she has no access. This command fails because Cate is not allowed to perform it. The Command History looks like Figure 11. 1This is a simplified presentation of the log. Because other users may also be doing things at the same time, many other messages could be interspersed. The IP addresses used in this example are fictitious.


Figure 11. Command History after access denied

The corresponding entries in the log are:

SVR 14:40:57 L P I TcpConnection(tcp:// 1xx.21.133.74:30750->tcp:// 1xx.21.133.74:17663) EccCommandManager: - Execution thread started for command: BCVCommand, id = 1028 SVR 14:40:57 L P I Command_BCVCommand,_id_=_1028 AuthorizationChecker: - Access denied. User: Cate, Permission: TimeFinder Base, Controlled Object type: Symmetrix - Device, Object Persistent Id: [com.emc.ecc.dl.persistent.symmetrix.SymDevice,21836] SVR 14:40:57 L P I Command_BCVCommand,_id_=_1028 AuthorizationChecker: - Access denied. User: Cate, Permission: TimeFinder Base, Controlled Object type: Symmetrix - Device, Object Persistent Id: [com.emc.ecc.dl.persistent.symmetrix.SymDevice,21686]

Notice that two access denied messages are present because the command acts on two devices, neither of which Cate has access to.

Using Command History to see login history To see the history of logons and logoffs, select the Command History view and choose the ControlCenter Server’s host (Figure 12). Command History also includes all User Management commands and Authorization Rule replacements.


Figure 12. Command History showing logon/logoff

For an example of command history and log files, let’s suppose a user ls\rbaenzig tries to log in to ControlCenter. The server.trc log file contains an entry like this:

SVR 11:17:42 L P W Logon_Call_Handler UserAccountManager: User authentication failed for user ls\rbaenzig SVR 11:17:42 L P D Logon_Call_Handler ECCUser: Creating Special user <ls\rbaenzig> SVR 11:17:42 L P F EvMgr.NotifyPool::Thread-34 EccAlertManager: EccAlertManager eventNotification called SVR 11:17:42 L P F EvMgr.NotifyPool::Thread-34 EccAlertManager: - EccAlertManager notified about event: ecc.security.user.AuthenticationFailure.ls\rbaenzig: - Username ls\rbaenzig is invalid or unknown SVR 11:17:42 L P F EvMgr.NotifyPool::Thread-34 EccAlertManager: - generateSecurityAlert() called on event: ecc.security.user.AuthenticationFailure.ls\rbaenzig: - Username ls\rbaenzig is invalid or unknown This entry indicates that an unsuccessful logon has occurred. An entry appears in Command History as shown in Figure 13.

Figure 13. Command History with failed user logon


Symmetrix Activity Log To see a history of operations performed on the Symmetrix array, right-click a Symmetrix object and select Activity Log, as shown in Figure 14.

Figure 14. Symmetrix Activity Log

Summary To summarize the main points of this section:

• It is recommended that access to the anonymous eccadmin ControlCenter user be limited or eliminated as soon as possible. The account’s password should be a closely held secret.

• Only named ControlCenter users should be members of the ECCAdministrators user group, or indeed of any user group. Avoid anonymous accounts completely.

• Limit the number of users in the ECCAdministrators user group to as few as possible. • Use an ECCAdministrators account to create ControlCenter users. Only people who really need to use

ControlCenter should be made ControlCenter users. • Use an ECCAdministrators account to create user groups. These groups should correspond to roles in

the organization so that users may be placed in groups that correspond to their job duties. • Remove any user groups that are not actually used. • Create user-defined groups and populate them with the managed objects according to your

organization model. Organize objects into logical groups that correspond to objects managed by the defined user groups. This ensures that users are given authority only over objects they must use to do their jobs.

• Use an ECCAdministrators account to create authorization rules for each user group, and for individual users (if needed). Each rule should grant only as much authority as people in the group require to do their jobs. Assign these groups to the user-defined groups according to your security model.

• Create only as many user groups and object groups as are needed to formulate your security policy.


• Be careful in granting the ChangeMembership permission to anyone. If this permission is granted on

an object group that is used in an authorization rule, the person who receives the permission may change the objects to which they have access.

• Use log files and Command History to determine if unusual or suspicious activity has taken place. • Use Command History of the server host to see a history of logons and logoffs. • Use the Symmetrix Audit Log to see a history of operations performed on a given Symmetrix system.

Securing the storage infrastructure elements Most storage elements implement controls that help determine which host is authorized to perform management operations of the storage elements. Enabling those management controls is a critical step in securing a ControlCenter environment; it helps restrict management access to storage devices only to the hosts running ControlCenter components.

Array security The following methods can be used to enhance array security.

Setting up Symmetrix Access Control (SYMACL) Symmetrix Access Control allows the administrator to control access to Symmetrix arrays for management and control operations. If SYMACL is enabled, then it should be used to limit the hosts that allow the Storage Agent for Symmetrix to have access.

NOTE: There is a change between the Storage Agent for Symmetrix version 5.2 SPx and version 6.0. Version 6.0 does not contain the ECC-Pin. It cannot identify itself as a member of the ECC_APP group. The ECC 6.0 agent will have the same access rights to the Symmetrix as the SymCLI or SMC on that host.

SYMACL is a SYMCLI feature of EMC Solutions Enabler. It controls access to Symmetrix operations using access IDs that are assigned to hosts. Access IDs are formed into access groups, and access groups are granted rights to perform Symmetrix operations on pools of devices. The right to run the Storage Agent for Symmetrix should be limited to the smallest number of hosts, and those hosts should, if possible, be physically secure.

NOTE: The ECC right is being deprecated and only works with the ECC 5.2 SPx Storage Agent for Symmetrix. The access right called ECC allowed a user to limit the hosts that run the Storage Agent for Symmetrix. SYMACL provides an access ID especially for the Storage Agent for Symmetrix that permits it to perform all operations as a mediator for the ControlCenter Server. Reference the EMC ControlCenter 5.2 Security Guidelines white paper.

The following example shows how to set up SYMACL to work with ControlCenter 6.0. Initial setup of SYMACL should be done by an EMC Customer Engineer. After that, a customer may use the SYMCLI to control SYMACL (from an authorized host).

Examine the access control status from the admin host. The display shows the default status after access control has been enabled on the Symmetrix unit.

admin# symacl list -acl Symmetrix ID: 000184600040 Group Name Pool Name Access Type ---------- --------- ----------- AdminGrp ALL_DEVS ADMIN AdminGrp ALL_DEVS ALL


UnknwGrp ALL_DEVS BASE UnknwGrp !INPOOLS ALL The default settings created during access control initialization allow ControlCenter agents to run on the Symmetrix unit. All hosts have the ALL access right to all devices (they are either in the AdminGrp, or they are part of the UnknwGrp, which has the ALL access right to all devices since device pools are not defined immediately after access control is enabled), so ALL hosts have access rights to run the ECC Symmetrix agent.

However, as you create access groups and device pools and customize the default access control settings for your environment, you must follow the procedure outlined in this example, or follow the directions listed in the ControlCenter online help, in order to use ControlCenter applications.

Configuring Symmetrix Access Control for ControlCenter Use the following procedure to set up each Symmetrix system to work with ControlCenter:

ControlCenter agents that are to perform active management functions against a Symmetrix array with Symmetrix Access Control enabled must be installed on a host that is a member of an access group with full permissions over all devices.

1. You will create an access group called ECC_Host and grant it full access rights to all devices. Whenever you deploy a ControlCenter agent that will actively manage the Symmetrix, you will add that host to the ECC_Host access group.

2. Each Symmetrix system that has Access Control enabled must set up an acc group for the ControlCenter agent hosts.

3. Create a host <UNIQUE ID> on each host to be added to the ECC_Host group by running the following on each host:

symacl –unique

4. Set up an access group that contains all of the Symmetrix agent hosts and give that group the BASE and ALL access rights.

symacl -sid 1166 commit -file setUpECC_Hosts.txt

Where setUpECC_Hosts.txt contains the following Access Control commands: create accgroup ECC_HOST;

add host accid <UNIQUE ID> name <HOST NAME> to accgroup ECC_HOST;

<<Repeat the above line once for each host being added to the group>>

grant access=BASE,ALL to accgroup ECC_Host for ALL DEVS;

5. When you finish, the entries in the access database display as follows: admin# symacl list -acl

Symmetrix ID: 000000001166

Group Name Pool Name Access Type ---------- --------- ----------- ECC_HOST ALL_DEVS BASE ECC_HOST ALL_DEVS ALL

Symmetrix Access Control configuration is complete. Repeat this procedure for each Symmetrix system requiring ControlCenter access.


SymACL considerations when upgrading from ECC 5.2 SPx to 6.0 There is a change between the Storage Agent for Symmetrix version 5.2 SPx and version 6.0

When planning an upgrade for the Symmetrix agents review the SymACL settings for each Symmetrix being managered. Make a note of any or all 5.2 agents that are set up with different SymACL rights from the CLI for a host Symmetrix combination. For these agents the upgraded 6.0 Symmetrix agent will have the same rights that are given to the CLI commands for the host, not the right of the ECC 5.2 Symmetrix agent. Version 6.0 does not contain the ECC-Pin. It cannot identify itself as a member of the ECC_APP group. The ECC 6.0 agent will have the same access right to the Symmetrix as the SymCLI or SMC on that host.

This makes the SymACL simpler to understand and debug. There is less likelihood of a secure hole because of the complexity. It gives the user less granularity in setting access controls for the Symmetrix agent.

The ControlCenter application has its own security authentication and authorization mechanisms that provide control over which ControlCenter functions can be performed from the ControlCenter Console. You can also create rules in ControlCenter to allow users to perform actions on groups of devices. This allows a ControlCenter administrator to limit the use of a ControlCenter Console. The EMC ControlCenter 6.0 Administrators Guide has a complete description of the ControlCenter authentication and authorization systems.

For a complete description of Symmetrix Access Control, refer to the paper Using SYMCLI to Administer Symmetrix Access Control. To obtain a copy of this white paper, go to the Powerlink® website at:

http://powerlink.EMC.com

Refer to the following documents for information about using Symmetrix Access Control with ControlCenter:

EMC ControlCenter Version User Guide EMC Symmetrix Storage Concepts Guide

Refer to the following documents for detailed information about installing, configuring, and using Symmetrix Access Control:

EMC Solutions Enabler Symmetrix Array Controls CLI Version 6.0 Product Guide EMC Solutions Enabler Version 6.4 Installation Guide

Symmetrix SID lock SID (source ID) lock is a security feature that restricts host access to Symmetrix storage arrays by adding switch source ID information to the VCM database. This feature prevents WWN spoofing when multiple hosts are connected to the same storage port. SID lock can be enabled or disabled from the ControlCenter Console for host/unidentified/storage port pairs. When a host requests data from a Symmetrix storage array, Enginuity™ checks to see if SID lock is active for the specified port pair. If SID lock is active, access is granted only if the SID value in the VCM database matches the requesting host/unidentified port's SID.

Figure 15 shows how to lock a specific WWN to a Symmetrix port.


http://powerlink.emc.com/

Figure 15. Locking a WWN to a specific Symmetrix port

Securing SYMAPISRV To enhance access control in a ControlCenter environment where EMC Solutions Enabler symapisrv is accessed from Storage Agent for Symmetrix or Common Mapping Agent, symapisrv should be configured to allow access from trusted hosts only. This is done by creating a file nethost in the config directory (/var/symapi/config/ or C:\Program Files\EMC\SYMAPI\config\) that contains entries for access from trusted hostnames/IP addresses and users.

Example nethost file:

209.64.63.51 Administrator 209.64.63.50 root The ControlCenter agents run as root or administrator.

In addition, two parameters in the options file are relevant for command execution and explained in Table 2:

SYMAPI_CTRL_VIA_SERVER=ENABLED SYMAPI_CTRL_OF_NONVISIBLE_DEVS=ENABLED

Table 2. nethost and config settings

nethost settings Option file variables Console action or alert message from proxy host

IP root UNIX host IP with user ID root

SYMAPI_CTRL_VIA_SERVER=ENABLED Discover symdg, new Symmetrix, and basic host discovery Agent listed “SYMAPI Server”

Access from unlisted server IP

SYMAPI_CTRL_VIA_SERVER=ENABLED Cannot manage <server>: SYMAPI_C_HOST_FILE_REJECTION

IP ____ blank user ID

SYMAPI_CTRL_VIA_SERVER=ENABLED Cannot manage <server>: SYMAPI_C_HOST_FILE_SYNTAX ERROR

Name root Full host name srv.lss.emc.com

SYMAPI_CTRL_VIA_SERVER=ENABLED Discover symdg, new Symmetrix, and basic host discovery Agent listed “SYMAPI Server”


nethost settings Option file variables Console action or alert message from proxy host

IP root UNIX host IP with user ID root

SYMAPI_CTRL_VIA_SERVER=DISABLE Discovers, blocks active commands

Discover symdg, new Symmetrix, and basic host discovery Agent listed “SYMAPI Server”

Default Settings:

No nethost file Default option file Discover symdg, new Symmetrix and basic host discovery Agent listed “SYMAPI Server”

For further details, consult Solutions Enabler man pages.

VCM database restricted access If access to the VCM database is restricted, hosts will not see the VCMDB device itself. Only hosts with SDM Agents would be allowed to access the VCMDB. The VCMDB device access has to be granted to these hosts (using ControlCenter masking). The command to set this Solutions Enabler metric must be issued from the SYMCLI symconfigure command where the command file contains:

set symmetrix VCMDB_restricted_access = ENABLED Hosts without VCMDB access will still be able to use Symmetrix storage, but device masking is not available to them.

iSCSI iSCSI support on Symmetrix array uses CHAP security. This must be configured via the Solutions Enabler CLI. ControlCenter does not yet support iSCSI configuration and control.

CLARiiON and Navisphere The Storage Agent for CLARiiON currently uses navicli to access a CLARiiON array. The CLARiiON SP Agent can be restricted to allow control from specific hosts with the Navisphere Agent/CLI. This configuration is a one-time configuration done via Navisphere Manager or the CLI (Figure 16).

Figure 16. Navisphere Privileged Users configuration


To add a privileged user to the SP Agent configuration file, use the following CLI command: navicli remoteconfig -setconfig -adduser <name>

Note: If the SP Agent configuration file does not include any privileged users, anyone who can log in to the management station can configure the storage system.

Storage agent for HDS configuration This agent allows you to monitor and explore supported Hitachi Lightning, Hewlett-Packard XP series, or Sun StoreEdge subsystems. You can also perform business continuance functionality on the subsystems. You can create, split, suspend, and resume BCVs for an HDS subsystem through the ControlCenter Console. Each array and vendor has its own CLI and security features and licensing requirements: • HP-XP subsystems: CommandView CLI (EMC highly recommends that you do not deploy the agent

on the CommandView Server) • Hitachi arrays: HiCommand Device Manager Server • XP128, XP512, or XP12000 arrays: LUN Security Manager XP and LUN Configuration Manager

StorageWorks STEAM Agent configuration The host running STEAM Agent must be configured to allow access from the host with the Storage Agent for StorageWorks. The password of the STEAM Agent needs to be entered during the assisted discovery process. Figure 17 shows the StorageWorks STEAM Agent configuration and discovery dialog boxes.

Figure 17. StorageWorks STEAM Agent configuration and CC discovery dialog boxes

Switch/fabric security Storage area network (SAN) security is an important part of your overall corporate security. Each switch vendor currently uses different methods. For more information on securing your SAN, refer to EMC documentation and white papers, available on the EMC Powerlink website.

McDATA The communication mechanism between ControlCenter and the Connectrix® service processor uses SNMP for switch discovery and FibreZone Bridge for zoning operations. FibreZone can be configured in secure mode during installation. These credentials must be entered in ControlCenter (Figure 18). SNMP


community strings and trap destinations (FCC agent host) are configured on the service processor. Launching the Connectrix Manager client uses MD5 encryption. McDATA sells security software called SANTegrity, although not many licenses have been sold. Firewalls must be configured with the correct ports (refer to Appendix B, “Port Usage and Firewall Configuration,” in the EMC ControlCenter 6.0 Planning and Installation Guide).

Figure 18. McDATA FibreZone secure mode

Brocade When using Brocade Secure OS, ControlCenter zoning can be executed via the primary trusted switch only. Brocade SecureOS is an add-on security feature that supports multiple policies:

• FCS policy: Use to specify the primary FCS and backup FCS switches. This is the only required policy.

• Management Access Control (MAC) policies: Use to restrict management access to switches. • Options policy: Use to restrict the types of WWNs that can be used for zoning. • Device Connection Control (DCC) policies: Use to restrict which Fibre Channel device ports can

connect to which Fibre Channel switch ports. • Switch Connection Control (SCC) policy: Use to restrict which switches can join the fabric. Newer switches like the 12000 or 3900 support secure Telnet and secure shell without the Secure OS license (firmware 4.1.1a and later).

Cisco ControlCenter communicates via SNMP with Cisco MDS switches for discovery, alerting, and zoning operations. For specific functions like VSAN creation, ControlCenter launches Cisco Fabric Manager. Cisco uses RADIUS to authenticate users per VSAN. Instead of Telnet, secure shell can be used.

Figure 19. Cisco discovery dialog box


NAS security Networked-attached storage (NAS) security is another area of consideration. ControlCenter supports protocols like SSH to enhance security. For more information on securing your NAS devices, such as the Celerra Network Server, refer to EMC’s product guides, which may be found on Powerlink. For other vendor’s products, refer to their documentation.

Host security ControlCenter authenticates active host commands to the host’s operating-system security. Windows and UNIX agents require you to enter a user ID and password for commands that alter a host or access secure information (Figure 20). Agents then save the user ID and password in a buffer and use it for subsequent commands. You should clear the buffer in the ControlCenter Console Agents menu if you want to use a new user ID or if you have completed your work with an agent. You must also have the ARM Active Commands permission to perform these commands.

Figure 20. Host-requested user authentication

Authentication information is obfuscated on the network.

Active commands to mainframe agents are authenticated with mainframe security. Console users must be mapped to TSOIDs on the mainframe. Such ControlCenter users inherit the rights of the mainframe user to which they are mapped.

ControlCenter repository server (Oracle listener) The ControlCenter 6.0 repository is based on Oracle9i. Engineering is carefully monitoring CERT advisories for security vulnerabilities and makes necessary patches available to customers. One of the recommendations to enhance security is to set a password for the Oracle listener process (tnslsnr) with the lsnrctrl SET PASSWORD command. Otherwise an attacker may use this fact to shut down the listener arbitrarily, thus preventing legitimate users from using it properly.

Summary To summarize the main points of this section: • Use Symmetrix Access Control to limit access to the Solutions Enabler and CLI commands that allow

administrative access to your storage arrays. • Control access to EMC Solutions Enabler symapisrv with the nethost file. • Secure your SAN and NAS elements according to the vendor’s capabilities and best practices. Connect

the element to the management LAN and set up firewalls to enhance security. • Consider users in the ECCAdministrator group equivalent to security administrators with all privileges;

other administrators should be assigned to other groups. • Only grant ARM permissions to administrators of Windows and open systems hosts who need access. • Only map a ControlCenter user to a mainframe user ID for an administrator who needs access. • Set the Oracle listener password.


Controlling network access to ControlCenter components To enhance security in a ControlCenter environment requires limiting access to ControlCenter components. This also requires the design of the network architecture and the implementation of network controls. Such steps include:

• Isolating the management network from the main intranet. Building a private management network is recommended for both performance and security reasons. A firewall isolates the private management network from the main network, reducing the exposure of the storage management traffic.

• Controlling remote management. Remote access is a well-known network vulnerability. When used for remote management, access from a remote console must be tightly controlled with firewalls and encryption. The use of Citrix along with VPN technology is recommended for ControlCenter.

Component configuration within a secure perimeter We first consider the situation in which no firewalls exist between any ControlCenter components (Figure 21). Firewalls are discussed in the section “Using the ControlCenter Console from outside a firewall.”

Figure 21. ControlCenter components within a secure perimeter

If a SAN is in use, the Fibre Channel connections to switches should use the SID lockdown feature in EMC SAN Manager to fix ports to specific World Wide Names (WWNs). This feature creates an association among the SID of a switch port, the host bus adapter (HBA) attached to the port, and the WWN of the HBA. This association is remembered and attempts to spoof a WWN can be foiled. Spoofing a WWN occurs when an intruder is able to substitute an intruding host with the same WWN as a legitimate host. When spoofing occurs, the WWN changes the port it is on. SID lockdown prevents a WWN from changing ports, thus foiling most attempts to spoof. Two cases where lockdown may not prevent spoofing are:

• Initial contact. The first time a host HBA contacts a Symmetrix array, that Symmetrix array doesn’t have a SID for that HBA and hence can’t lock anything. If a legitimate initial contact fails due to SID lockdown, this indicates a potential security problem (that an intruder got there first and the legitimate contact is being treated as a spoof attempt).

• Recabling. SIDs are assigned by switches and often are based on the physical switch port used. When a cable is moved to attach an HBA to a different switch port (on the same or a different switch) the SID will usually change. This means lockdown must be removed to allow recabling, and this opens a window for an intruder. Changing interswitch connections and adding a new switch also may change a lot of SIDs.

After one of these events has taken place and SIDs are relocked, you should check that the SIDs are as they expected. This requires familiarity with how SID assignment is done by the specific switches in use.


Isolating the ControlCenter traffic network You have two possibilities to enhance network security in a ControlCenter environment:

• Connection to a dedicated management LAN with multihoming (multi-NIC) • Management LAN connecting all critical storage elements and a firewall to the production network Multihoming may be used to isolate traffic from ControlCenter agents and the ControlCenter Consoles from other traffic on the corporate/production network. This kind of setup assumes that a separate network for management purposes is already set up (Figure 22). If multihoming is in use, ensure that routing is not enabled on the multihomed hosts; otherwise, they may provide an unintended path for traffic originating on the production network to access the management network.

Traffic between ControlCenter agents and between all ControlCenter components may run on an existing management network. For more information on multi-NIC for agents, refer to the EMC ControlCenter 6.0 Planning and Installation Guide.

Firewalls offer another option for isolating and protecting ControlCenter traffic by selectively allowing network traffic to cross between the production network and the management network.

Figure 22. ControlCenter on a private management network using multi-NIC

In environments where only storage and switch management are being performed, it is recommended that the ControlCenter agents be installed on a host that is on the administrative LAN and isolated from the production LAN.


VPN considerations The low network latency requirements between the ControlCenter Console (Java version) and the ControlCenter Server make it impossible to directly use a VPN to encrypt communications between the console and the ControlCenter Server. The use of a VPN between the console and the ControlCenter infrastructure can only be considered in conjunction with the use of Citrix Terminal Services (see Figure 23). The Web Console can be used with high-latency networks and VPN, however.

ControlCenter supports high network latency between the ControlCenter Server and agents. This makes it easier for ControlCenter Server and agents to exchange information over VPN networks or a link using the IPSec protocol. Refer to the latest ControlCenter Performance and Scalability Guidelines for minimum network performance required to run ControlCenter.

Note: The use of ControlCenter is not compatible with the use of Network Address Translation (NAT) or Port Address Translation (PAT).

Encryption Although ControlCenter components may be running within a secure perimeter, the intranet itself may be physically distributed and it may be desirable to further protect information using encryption. ControlCenter 6.0 uses Secure Socket Layer (SSL) to encrypt user logon from the ControlCenter Console to the ControlCenter Server; it also obfuscates logon from the ControlCenter Console to host agents. Due to performance implications, it does not provide encryption for data and commands transmitted between its components. However, encryption may be introduced using additional software or hardware like CipherOptics SG1000i IPSec gateway.

Citrix Terminal Services One simple way to encrypt traffic between a ControlCenter Console and a ControlCenter Server is to use Citrix Terminal Services. The use of Citrix Terminal Services with ControlCenter is discussed in the next section.

Using the ControlCenter Console from outside a firewall A common need is to use the ControlCenter Console from a location that is outside the secure perimeter. This means using the ControlCenter Console across an intervening firewall. There are two ways to do this:

• Using Citrix Terminal Services • Configuring the firewall to allow traffic between the ControlCenter Console and the ControlCenter

infrastructure Network Address Translation (NAT) is not directly supported for this kind of communication; if NAT is used, then Citrix Terminal Services must be used.

Citrix Terminal Services For full information on Citrix Terminal Services, refer to the white papers available at the Citrix site: http://www.citrix.com

One simple way to access a ControlCenter Console from outside a firewall is to use Citrix Terminal Services (Figure 23). This product may provide encryption using SSL/TLS technology depending on its installation options. See your local Citrix administrator for details.


Figure 23. Citrix Terminal Services configuration

Clients running outside the firewall can remotely run a ControlCenter Console application session through Citrix Terminal Services client (terminal emulation) software.

There are some limitations on using the ControlCenter Console in this way:

• Memory requirements — Each ControlCenter Console you run will require additional RAM on the Citrix server. Refer to the Performance and Scalability Guidelines for information.

• Remote sessions not recommended on ControlCenter Server host — EMC does not recommend use of Citrix Terminal Services if the ControlCenter Console and ControlCenter Server are running on the same host (referred to as single-host configuration).

• Port use — If security is a concern, use other commercially available mechanisms for controlling access to ports used by Citrix Terminal Services. For example, use a firewall that employs user-based authentication. A firewall that grants access based on an IP address allows users through if the IP address of the Citrix Terminal Services server (ControlCenter Console host) has been granted access.

Securing Ethernet ports Ethernet switches may be configured to restrict traffic through the switch port by specifying the media access control (MAC) address of the Ethernet card of the end device connected to that port. If configured this way, only those Ethernet frames that have a specific MAC address as the source MAC address will be allowed to travel on to their destination.

Using ControlCenter 6.0 with firewalls For more information on port usage, refer to the “Port Usage and Firewall Configuration” appendix in the EMC ControlCenter 6.0 Installation Guide, Volume I. The appendix will provide more detail on port numbers and possible configurations.

The discussion contained in the installation guide is based on the use of a stateful firewall. Stateful firewalls will allow connections to listening ports and all traffic in both directions on that connection for as long as the connection exists. ControlCenter supports configurable, fixed listening ports in its components with dynamically assigned client ports.

Summary To summarize the main points of this section:

• Use Citrix Terminal Services to access a ControlCenter Console from outside a firewall. • Lock Ethernet ports to MAC addresses on all directly attached switches.


• To use one or more firewalls in a ControlCenter environment, refer to the port information in this

chapter. Only open ports that you know you will use.

Conclusion This paper provided an overview of security practices that you can use to secure your managed objects, the ControlCenter components, and the use of ControlCenter components in a distributed environment. Each section ended with a summary of important points that you should consider when setting up a ControlCenter 6.0 installation. Some of the more important suggestions are:

• Physically secure access to critical components including the ControlCenter and Solutions Enabler software media so that rogue installations cannot occur.

• Set up your ControlCenter Security Management permissions carefully. • If possible, put critical elements and ControlCenter components on a private management network. • Use Citrix Terminal Services with encryption for remote management. • Configure firewalls between elements on the management LAN and public networks. • Enable the vendor-provided security features of components.

Appendix: Frequently asked questions Is it possible to set up password policies for a ControlCenter user? Yes. ControlCenter 6.0 relies on either a Windows directory or an LDAP directory to authenticate storage administrators. Both Windows Active Directory and LDAP directories support a mechanism to define password rules such as minimal length, complexity, and others.

Is the storage administrator password sent encrypted between the ControlCenter Console and the ControlCenter Server? Yes. The storage administrator password is encrypted using SSL with a 128-bit cryptographic algorithm between the console and the ControlCenter Server.

Are host passwords sent in clear text to the ControlCenter agents running on the host? No. They are obfuscated by ControlCenter before being sent on the network. The obfuscation algorithm is proprietary to EMC.

The Symmetrix Agent requires Solutions Enabler to be installed, but I do not want the users of these hosts to run Solutions Enabler commands. How can Solutions Enabler be locked just for use by the Symmetrix Agent? Symmetrix Access Control can be configured on the Symmetrix array to allow only commands from the Symmetrix Agent; commands from the host command line are rejected.

Is it possible to set up an equipment group that can only be managed by several users? All types of managed objects can be grouped together, and the security rules can be set up for the user-defined group.

Is it possible to get around the need to enter the Oracle sys password into ControlCenter when I install the Oracle Agent? Yes. For instructions to manually run the Database Agent for Oracle without providing the sys password, refer to the section, “Step 18: Plan for Database Agent for Oracle,” in the EMC ControlCenter 6.0 Planning and Installation Guide.

Can a VPN be used to encrypt the traffic between the ControlCenter Console and the ControlCenter Server? A VPN between the console and the server can only be used in conjunction with the use of Citrix or Microsoft Terminal Server. The ControlCenter Console requires very low network latency that cannot be met by a VPN. However, the Web Console can be used via VPN and high-latency network.


Can SNMP frameworks modify data stored in the ControlCenter infrastructure? Integration between ControlCenter and enterprise management frameworks (for example, Tivoli) is achieved through an optional component called the Integration Gateway Agent. The Integration Gateway acts as an SNMP Agent that can be accessed by enterprise management tools such as Tivoli. The Integration Gateway has two functions:

• It provides read-only access to ControlCenter information via SNMP get and getnext commands. Authentication is based on SNMP community strings. The SNMP community can be set in the Integration Gateway INI file.

• It sends SNMP traps to the enterprise management console. These are SNMPv1 traps that do not require any SNMP authentication.

In both cases, data stored in the ControlCenter infrastructure cannot be modified via the Integration Gateway Agent.

SNMPv1 is perceived to have several weaknesses. Does ControlCenter implement SNMPv3? The ControlCenter architecture is not based on SNMP: SNMP is not sufficient to implement most of the SAN management functions that have been implemented in ControlCenter, although several agents are using SNMP for certain functions. The Integration Gateway Agent uses SNMP to notify a management framework of alerts. The Fibre Channel Connectivity (FCC) Agent uses SNMP to listen to traps from connectivity elements as well as for some basic discovery. Cisco switches are managed with SNMP. The NAS agent listens to traps from NAS devices.

The FCC Agent implements the manager side of the SNMP protocol and communicates with an SNMPv1 Agent embedded in the Fibre Channel switch. Currently, switch vendors like McDATA do not yet support SNMPv3 on their entire product line.

Is the Microsoft Windows 2000 Server operating system secure enough to host a ControlCenter Server? Windows 2000 Server security level is at least as good as its competitors.

Microsoft Windows 2000 Server has been evaluated by an independent and accredited agency against the Common Criteria at the level “EAL4+”. The Common Criteria are maintained by the U.S. government to judge the security of computer systems. They replace similar evaluations such as the U.S. Orange Book C2, B1.

Any operating system security requires a stringent patch management process.

Viruses and worms usually exploit operating system vulnerabilities that are well known weeks or even months before the virus or the worm appears and for which patches are usually available. As for any other application server, the ControlCenter Server must be regularly updated with the latest security patches and maintained according to industry best practices.

As part of its deployment guidelines, EMC recommends to deploy the ControlCenter Server in a private management LAN isolated from the corporate intranet by a firewall. This optimizes ControlCenter performance, and protects the ControlCenter Server against unwanted network traffic or attacks.

Where will I find ControlCenter firewall documentation? This is documented in Appendix B, “Port Usage and Firewall Configuration,” of the EMC ControlCenter 6.0 Planning and Installation Guide.

Can I rely on basic router ACLs to restrict access between my ControlCenter infrastructure and my agents? No. Generally router ACLs must be configured with both source and destination IP addresses and port numbers. ControlCenter uses dynamic client ports connected to fixed server (listening) ports. This works well with stateful firewalls, but not with router ACLs.


Does ControlCenter support access to ControlCenter from home? Not directly, however, Citrix or Terminal Services (in conjunction with a VPN) may be used to access the ControlCenter Console. Refer to the firewall discussion in the EMC ControlCenter 6.0 Planning and Installation Guide for more details. However, the ControlCenter Web Console can be used via VPN.

Must I still apply an Oracle patch to the ControlCenter repository in order to use fixed, configurable listening ports? No. Starting with release 5.1.2, the Oracle patch is included as part of the released code. If you have previously applied this patch, it will not be applied again. EMC is working closely with Oracle to integrate necessary patches into the ControlCenter software.

How does ControlCenter protect communication between ControlCenter components? Passwords are not sent in clear text between the ControlCenter components. The main storage administrator password is encrypted using SSL with a 128-bit cryptographic algorithm between the console and the ControlCenter infrastructure. In addition, a VPN may be used to further protect the communications between the ControlCenter infrastructure and ControlCenter agents, providing that ControlCenter minimum network performance requirements to run ControlCenter (as defined in the latest ControlCenter Performance and Scalability Guidelines) are met. The use of a VPN between the console and the ControlCenter infrastructure can only be considered in conjunction with the use of Citrix Terminal Services. The ControlCenter Web Console uses native support of SSL with HTTP-S for protecting communications to the ControlCenter Web Server.

How does ControlCenter protect the information it stores? Storage management information is stored in the ControlCenter infrastructure in an Oracle database and is only accessible by an Oracle account associated with ControlCenter. In addition, sensitive information such as passwords is stored encrypted.


Documents

EMC ControlCenter 6.0 Security Guidelines ... This white paper is intended for use by EMC ControlCenter administrators and IT staff responsible for application, data, and network security