Storage area network security

Security has always been a key advantage of Fibre Channel (FC) storage area networks (SANs). FC SANs are often deployed as isolated or air-gapped networks, reducing exposure to external threats. In addition, Fibre Channel SANs are typically deployed as dedicated and segmented networks, which can reduce exposure to unauthorized access. Zoning and LUN masking further restrict a host's access to designated storage resources, helping to limit the potential impact of a compromised host.

However, FC SANs are not immune to security threats. Mission-critical applications depend on SAN infrastructures, making it essential to protect both the network and the data it carries.

Securing an FC SAN requires a layered approach that addresses multiple security challenges across the infrastructure. Implementing security controls at each layer helps maintain the confidentiality, integrity, and availability of SAN resources over time.

In this section, we examine each security layer, beginning with management security and progressing inward to the layers that protect access to and security of the data itself.

Fibre Channel SAN security layers

The following figure shows the layers of FC SAN security.

Frontier AI and quantum decryption: Post-quantum cryptography

Legacy networks cannot contain adversarial AI tools that exploit and move laterally at machine speed, nor can they protect against future quantum decryption. To insulate your mission-critical data, your storage must reside on an unassailable foundation. Fibre Channel is widely regarded as one of the most secure storage networking technologies in the data center. Next-generation IBM Gen 8 Fibre Channel delivers a highly resilient data fabric. The network architecture combines AI-threat secure defense with quantum-safe cryptography to defend your most critical data assets today and tomorrow.

The compounding threat: Frontier AI and quantum decryption

Autonomous AI tools can launch nonstop, automated attacks that learn and exploit undetected vulnerabilities. Left unchecked, these intelligent agents can silently exfiltrate vast troves of enterprise data for future decryption — "Harvest now, decrypt later." By pairing an AI-threat secure network architecture with quantum-safe cryptography, IBM Fibre Channel ensures a complete defense lifecycle:

• Neutralize AI reasoning and scanning: Restrict the physical network fabric to deny autonomous tools the visibility they need to map the environment, render custom exploit code useless, and halt machine-speed breaches.
• Defeat quantum horizons: Ensure that even if a breach is attempted, your data remains completely hidden, insulated, and designed to resist current and emerging cryptographic threats into the post-quantum future.

This defense is built upon the most secure network in the data center for a reason. Traditional data center IP/Ethernet networks are inherently routable, highly interconnected, and plagued by a sprawling attack surface exposed to lateral reach contagion. Fibre Channel is a completely non-routable, dedicated storage layer. This architectural isolation means that IBM fabrics remain structurally invisible to network-layer threat actors and autonomous scanning tools. Taking security one step further, IBM proactively utilizes frontier AI tools to continuously scan, detect, and remediate vulnerabilities before they can impact production infrastructure. Layering AI-threat secure and quantum-safe defenses onto this isolated, AI-fortified architecture creates a data vault that significantly reduces attack exposure by today's adversarial AI and tomorrow's quantum technology. The result is an enterprise storage infrastructure that achieves the highest compliance and data defense standards possible with zero compromises to performance.

IBM Gen 8 Fibre Channel guardrails against frontier AI and quantum decryption

Physical isolation

Uses a non-routable, point-to-point architecture to naturally segment storage traffic, eliminating the lateral attack paths common to traditional IP data center networks.

Hardened attack surface

Implements strict principle-of-least-privilege access controls within the Fabric OS (FOS) software by eliminating root-level accounts, neutralizing hijacking and malware exploits.

Hardware and software validation

Embeds silicon root of trust and utilizes unique Trusted FOS Certificates to continuously verify authenticity, blocking counterfeit components or malicious firmware.

Proactive vulnerability mitigation

IBM's PSIRT maintains a robust vulnerability intake process utilizing multiple scanning tools and penetration testing methods. Leverages advanced frontier AI models and automated penetration testing to actively isolate and patch code flaws before they ever hit production.

IBM Gen 8 and FOS 10.0.x security enhancements

While IBM Gen 7 focused heavily on introducing foundational cyber resilience and self-healing automation, IBM Gen 8 shifts its primary security focus toward future-proofing the SAN against emerging cryptographic threats — specifically targeting the era of AI-driven attacks and quantum computing.

The changes to security include several architectural and operational differences.

Quantum-safe cryptography versus standard encryption

IBM Gen 7 relies on traditional, modern cryptographic standards such as AES-256 for data-in-flight encryption and standard RSA/ECC for secure boot and code signing. While highly secure against current threats, these algorithms are theoretically vulnerable to future quantum computers.

IBM Gen 8 includes Post-Quantum Cryptography (PQC). It integrates quantum-resistant 256-bit encryption and advanced cryptographic protocols natively into the hardware and Fabric OS (FOS). This prevents harvest now, decrypt later attacks, where bad actors steal encrypted data today with the intent of decrypting it once quantum computing matures.

Zero trust and access architecture

IBM Gen 7 uses standard secure management access controls, role-based access control (RBAC), and validated Secure Boot via a hardware Root of Trust to prevent unauthorized firmware modifications.

IBM Gen 8 formalizes a strict Principle-of-Least-Privilege (PoLP) architecture directly into the fabric design. Gen 8 drastically minimizes the default attack surface by strictly isolating control planes, segmenting management domains, and ensuring that connected devices or administrators only have the minimum necessary permissions required to operate.

AI-powered threat and anomaly detection

IBM Gen 7 introduced self-learning and automation primarily geared toward SAN health and reliability. It tracks telemetry data, utilizes Fabric Performance Impact Notifications (FPINs), and flags physical layer anomalies or congestion that could be exploited for Denial of Service (DoS) situations.

IBM Gen 8 enhances this with embedded SAN AI technology and Fabric Intelligence. The Gen 8 AI doesn't just watch for structural failures; it models baseline traffic behaviors contextually down to the Virtual Machine (VM) level. This allows it to intelligently detect subtle pattern deviations that could indicate data exfiltration, ransomware behavior, or hijacking attempts, initiating self-healing protocols autonomously to quarantine compromised zones.

Summary comparison

Security FeatureIBM Gen 7IBM Gen 8Cryptographic StatusStandard Enterprise Encryption (AES-256 / RSA)Quantum-Safe / Post-Quantum CryptographyAccess Control PhilosophyStandard RBAC & Secure BootPrinciple of Least Privilege (PoLP) Minimizing Attack SurfacesThreat IntelligenceTelemetry-based automated health & congestion alertsEmbedded SAN AI Engine for behavioral anomaly & malware trackingHardware FoundationHardware Root of Trust & Secure FOSEnhanced Hardware Root of Trust with PQC-validated firmware chains

Gen 7 secures your SAN against the threats of today's digital landscape by ensuring hardware integrity and automated fabric resilience. Gen 8 builds directly on top of that foundation, upgrading the cryptographic core to make your storage infrastructure resilient against the weaponization of AI and quantum computing.

FOS 10.0.x default secure switch configuration and hardening

Updated security baseline rules including mandatory SHA-512 password hashing, dual lockout enforcement (adminlockout & adminlockoutconsoleaccess), SSH key regeneration (RSA 2048 / ECDSA P521), 900s SSH rekeying, and blocking unencrypted syslog and file transfer operations.

The following section describes the secure switch configuration and hardening requirements that must be resolved before you can upgrade from FOS 9.2.2x to FOS 10.0.0x.

When upgrading from Brocade Fabric OS (FOS) 9.2.2 to FOS 10.0.0a, Broadcom enforces strict pre-upgrade checks. If any unsupported, legacy, or non-secure configurations are active, the firmware upgrade process will be explicitly blocked.

Brocade Fabric OS (FOS) 10.0.x pre-upgrade requirements checklist

This section details mandatory authentication, cryptographic, protocol hardening, and configuration prerequisites required prior to upgrading to Brocade Fabric OS (FOS) 10.0.x. Non-compliant configurations blocks the upgrade process.

---

Authentication and certificates

Certificates include the following prerequisites:

• TruFOS Certificate Requirement

  A valid, unexpired TruFOS Certificate must be installed on the switch/director prior to initiating the upgrade.

• SMTPS CA Certificate

  If Secure SMTP (SMTPS) is enabled, you must import the required SMTPS CA certificate before upgrading. The upgrade will block if SMTPS is enabled without this certificate.

---

Cryptographic and hashing algorithms

Review the supported algorithms and implement changes as necessary:

• Reconfigure auth hashing (SHA1/MD5 to SHA256)

  SHA1 and MD5 hashing protocols are unsupported in FOS 10.0.x. You must reconfigure authentication hashing to SHA256:

  authutil --set -h sha256

• Reset custom SSH host key algorithms & Unsupported Ciphers

  If custom SSH host key algorithm configurations or legacy/unsupported cryptographic ciphers are active, the upgrade fails. Revert to supported cipher groups using:

  seccryptocfg --apply -group <supported_group>

Note: For more information on seccryptocfg and supported groups, see the Brocade Fabric OS 10.0.0 Command Reference Guide and search for seccryptocfg.

---

Protocol and service hardening

Review and implement required protocol changes:

• Disable non-secure switch mode

  Switches operating in non-secure mode must have non-secure mode disabled prior to starting the upgrade.

• Remove non-secure syslog servers

  FOS 10.0.x blocks upgrades if non-secure Syslog servers are configured. Remove any non-secure Syslog destinations:

  syslogadmin --remove --ip <syslog_ip>

• Update SMTPS TLS protocol version

  Configurations using legacy TLSv1 for secure SMTP are not permitted. Reconfigure SMTPS to use a supported version (such as TLS 1.2).

Note: For more information on SMTPS TLS Protocol Versions, see the Brocade Fabric OS 10.0.0 Command Reference Guide and search for seccryptocfg, seccertmgmt, and smtps.

---

Other blocking pre-upgrade constraints

Broadcom checks the following security and group configurations prior to upgrading:

• Custom SFP and Circuit groups

  Delete custom SFP or Circuit logical groups using the following command:

  logicalGroup --delete

• Paused SFP Objects

  Restart any paused SFP monitoring objects using the following command:

  mapsConfig --config restart -type sfp -members

• FCIP Tunnel Features

  Disable FICON features on FCIP tunnels, including:

  • ficon-xrc
  • ficon-tin-tir
  • ficon-tape-pipelining
  • ficon-tera-data
  • ficon-device-acking

Management interfaces

This section describes the management interfaces provided by Fabric OS (FOS) and the security mechanisms that can be used to protect them. Because management interfaces provide administrative access to the switch, they should be secured as part of an overall defense-in-depth strategy.

Access to the management network should be restricted to authorized administrative systems and networks. Common practices include isolating management traffic by using dedicated VLANs or management networks and limiting access to only the management protocols and services required in the environment. This approach reduces the attack surface and helps prevent unauthorized access to the switch management interfaces.

IP Filter policies in FOS can be used to permit or deny traffic to the management interfaces based on defined access rules. An IP Filter policy acts as a packet-filtering firewall for the management interfaces, permitting or denying traffic according to configured rules. Secure switch management is performed through SSH and HTTPS. Administrators should configure IP Filter policies to allow access only from authorized management hosts and networks and to restrict access to only the services required for administration. In dual-stack environments, IPv4 and IPv6 access should be restricted consistently according to the organization's security requirements.

In current Gen 8 systems, unsecured management protocols such as Telnet and HTTP are disabled by default and are not intended for switch management. Although Telnet and HTTP entries might still appear in the default IP Filter policy, they are configured with deny rules. The default IP Filter policy permits secure management access through SSH and HTTPS. Administrators should further restrict access by allowing connections only from authorized management networks and by blocking any additional services that are not required in their environment.

The IP Filter policy should be used in environments where strict control of fabric access is required. As with other ACL policies, it is important to regularly review and maintain the IP Filter policy to ensure that it remains aligned with security and operational requirements.

Displaying the IP filter

To display the current IP Filter in use, run the ipfilter --show command, as shown in the following example:

IBM_8635_F88:FID128:admin> ipfilter --show Name: default_ipv4, Type: ipv4, State: defined Rule Source IP Protocol Dest Port Action ---- --------- -------- --------- ------ 1 any tcp 22 permit 2 any tcp 23 deny 3 any tcp 80 deny 4 any tcp 443 permit 5 any udp 161 permit 6 any udp 123 permit 7 any tcp 600 - 1023 permit 8 any udp 600 - 1023 permit Name: default_ipv6, Type: ipv6, State: defined Rule Source IP Protocol Dest Port Action ---- --------- -------- --------- ------ 1 any tcp 22 permit 2 any tcp 23 deny 3 any tcp 80 deny 4 any tcp 443 permit 5 any udp 161 permit 6 any udp 123 permit 7 any tcp 600 - 1023 permit 8 any udp 600 - 1023 permit Name: unified, Type: any, State: active Rule Source IP Protocol Dest Port Action ---- --------- -------- --------- ------ 1 any tcp 22 permit 2 any tcp 23 deny 3 any tcp 80 deny 4 any tcp 443 permit 5 any udp 161 permit 6 any udp 123 permit 7 any tcp 600 - 1023 permit 8 any udp 600 - 1023 permit

Note: By default, Fabric OS does not permit cleartext Telnet (TCP port 23) or HTTP (TCP port 80).

In Fabric OS (FOS) v10.0.0, Broadcom introduced the Unified IP Filter policy as the new default architecture, replacing the legacy dual-policy model used in FOS v9.x and earlier.

The primary differences between the Unified IP Filter policy and the legacy IPv4 and IPv6 IP Filter policies are related to enforcement, activation behavior, and firmware compatibility:

FeatureLegacy IPv4 & IPv6 Policies (FOS 9.x and earlier)Unified IP Filter Policy (FOS 10.0.0+)Active Policy StructureRequires two separate active policies running simultaneously (one for IPv4 and one for IPv6).Consolidates rules into a single unified policy active by default.Mutual ExclusivityDual IPv4 and IPv6 active policies coexist without disabling one another.Mutually exclusive with legacy policies. Activating a unified policy automatically disables legacy v4/v6 policies, and vice versa.Traffic Handling During Mode TransitionSwitching between IPv4 policies does not affect active IPv6 traffic rules (and vice versa).If you switch from Unified to a non-unified (legacy) IPv4 policy, IPv6 traffic is completely blocked (INPUT/OUTPUT) until an IPv6 policy is explicitly activated.FOS Downgrade RestrictionsStandard upgrade/downgrade rules apply.Downgrades are blocked if a unified policy is currently active or defined in configuration.

Role-based access controls

One way to provide limited accessibility to the fabric is through user roles. FOS includes predefined user roles, each of which can access a subset of the CLI commands. These roles are known as role-based access controls (RBACs), which are associated with the user's login credentials.

When you log in to a switch, your user account is associated with a predefined role or a user-defined role. The role that your account is associated with determines the level of access you have on that switch and in the fabric.

Default accounts

FOS offers predefined accounts:

• Admin
• Factory
• User

Although the factory account is reserved for development and manufacturing purposes, the passwords for all default accounts must be changed and secured during the initial installation and configuration of each switch.

Note: The root account was removed in FOS 9.1 and later releases and cannot be activated.

From Brocade Fabric OS (FOS) 9.0 to FOS 10.0, Broadcom significantly tightened security and account access controls, primary among which was the complete removal of raw root access.

The following table describes the major changes to default accounts and account policies across these release trains:

Updates to FOS 9.0 include several key account changes.

Removal of the root account (FOS 9.1+)

Before FOS 9.0.x, the traditional Linux root account was accessible for advanced troubleshooting, low-level system access, and vendor debugging.

For version FOS 9.1.x through FOS 10.0.x, the root user is disabled and removed from functional access to mitigate malware, hijacking, and unauthorized kernel access.

Although the root account can appear in account listings, it is disabled and cannot be used for login.

Introduction of the maintenance account

To replace root for vendor service procedures, FOS introduced the maintenance account.

The default password for maintenance is set to password.

Unlike the old root account, logging into maintenance or invoking debug/kernel mode requires token-based authentication supervised by the service provider (Broadcom/Dell/HPE). You generate a challenge token via serviceshell --generate and receive a temporary response token from vendor support.

Mandatory default password changes forced at first login

In earlier FOS generations, default passwords (such as admin/password, user/password) could persist indefinitely if not manually updated.

For FOS 9.0+ & FOS 10.0 and later: First-time login to default accounts (admin, user, maintenance, etc.) forces an immediate password update.

Note: The new password cannot match the factory-default password.

Disabling and deprecating insecure default accounts

Default accounts: Unused or legacy service accounts (for example, default SNMP users and legacy factory diagnostic accounts) are disabled by default.

Factory default lockout: Switches shipped with FOS 9.2 or later adhere to Default Secure profiles out-of-the-box, enforcing local security policies right from initial setup.

Default account comparison

Default Account / FeatureFOS 9.0FOS 9.1 / 9.2FOS 10.0root AccountPresent / AccessibleDisabled (No privileges/access)Disabled / Removedmaintenance AccountIntroduced as defaultReplaces root (Requires token auth)Active (Requires vendor token auth)Mandatory Password ChangeEnforced at initial setupEnforced at initial setupEnforced at initial setupDefault Crypto / SecurityStandard settingsIntroduced Default Secure templatesDefault Secure enforced out-of-boxDefault SNMP UsersCan be disabledDisabled by defaultDisabled by default

Note: Recovering lost passwords might require significant effort and fabric downtime and assistance from Support resources.

User accounts

In addition to the default permissions that are assigned to the roles of admin, factory, and user, FOS supports up to 252 other user accounts on the chassis. These accounts expand the ability to track account access and audit administrative activities.

Each user account is associated with the following attributes:

• Virtual fabric list: Specifies the Virtual Fabric that a user account is allowed to log in to.
• Home virtual fabric: Specifies the Virtual Fabric that the user is logged in to, if available. The home Virtual Fabric must be a member of the user's Virtual Fabric list. If the fabric ID is not available, the next-lower valid fabric ID is used.
• LF permission list: Determines functional access levels within the bounds of the user's Virtual Fabrics.
• Chassis role: Similar to switch-level roles, but applies to a different subset of commands.

Fabric OS supports remote users through one of the following external Authentication, Authorization, and Accounting (AAA) services:

• Lightweight Directory Access Protocol (LDAP)
• RSA SecurID (RSA)
• Federated Authentication (FA)

Note: When the AAA server is configured as RSA, the communication between the server and the switch is through the REST API over HTTPS.

When configured for remote authentication and authorization, a switch becomes a LDAP, RSA client, or FA resource server. In any of these configurations, authentication records are stored in the authentication host server database. Account name, assigned permissions, and time-accounting records for each user are stored as per the following table.

Multi-factor authentication

Multi-factor authentication (MFA) is a multi-step account login process that requires users to enter more information than just a password. For example, in addition to a password, users might be asked to enter a code that is sent to their email, answer a secret question, or scan a fingerprint.

FOS supports MFA with the following services:

1. RSA with SecurID via REST API with HTTPS
2. FA

RSA SecurID provides the capability to verify the identity of users using MFA through the REST API over HTTPS. The users are provided with a time-based rotating numeric passcode. This passcode with the user PIN (PIN + OTP) is used for the user authentication. Fabric OS uses this mechanism to support the MFA user authentication for access to FOS.

Note: A one-time password (OTP), also known as a one-time PIN, one-time authorization code (OTAC) or dynamic password, is a password that is valid for only one login session or transaction, on a computer system or other digital device. In case of FA, the MFA can be enabled on the identity provider.

Federated authentication

FOS supports federated authentication (FA) performed by an Identity Provider (IDP). IDP manages the applications, user identities, credentials, and MFA configurations. The user or application attempts to log in to the switch using a valid access token that is issued by the IDP.

Note: The FOS switch can either fetch IDP public keys or the keys can be imported by the user to perform token validation.

Remote user configuration on the switch

At least one LDAP, RSA, or FA server must be configured before you can enable the AAA service. You can configure the AAA service even if it is disabled on the switch. You must be logged in as admin or securityAdmin to configure the remote authentication service.

LDAP, RSA, or FA configuration is chassis-based configuration data. On platforms that contain multiple switch instances, the configuration applies to all instances. The configuration is persistent across reboots and firmware downloads.

Security protocols

Security protocols provide endpoint authentication and communications privacy by using cryptography. Typically, the user is authenticated to the switch while the switch remains unauthenticated. This authentication means that you can be sure that you know with whom you are communicating.

The security protocols supported by FOS are listed in the following table.

ProtocolDescriptionHTTPSHTTPS is a Uniform Resource Identifier scheme that is used to indicate a secure HTTP connection. Web Tools supports the use of Hypertext Transfer Protocol over SSL (HTTPS). Quantum safe cryptography can be configured for HTTPS.LDAPLightweight Directory Access Protocol (LDAP) with Transport Layer Security (TLS) uses a certificate authority (CA). With the import of signed certificates, you can make LDAP traffic confidential and secure by using Secure Sockets Layer (SSL)/TLS technology with LDAP.RSARSA SecurID REST API-based authentication over HTTPS. The CA root certificate for the RSA server can be imported using the seccertmgmt command.FAFOS communicates to the IDP through the REST API over HTTPS protocol. If the signing authority does not exist in the FOS CA bundle, then the CA certificate that signed the IDP server certificate is required for import using the seccertmgmt command.SCPSecure Copy (SCP) is a means of securely transferring computer files between a local and a remote host or between two remote hosts, using the Secure Shell (SSH) protocol. Configuration upload and download support the use of SCP.Secure SyslogSecure syslog requires importing syslog CA certificates using the seccertmgmt command.SFTPSecure File Transfer Protocol (SFTP) is a network protocol for securely transferring files on a network. Configuration upload and download support the use of SFTP.SNMPV3Simple Network Management Protocol version 3 (SNMPv3) is used by network management systems to monitor and manage network-attached devices. SNMPv3 provides authentication, message integrity, and optional encryption to help secure management communications.SMTPSSecure SMTP (SMTPS) provides secure email delivery for MAPS notifications by using TLS encryption and authentication between the switch and the configured mail relay server.SSHSecure Shell (SSH) is a network protocol that allows data to be exchanged over a secure channel between two network devices. Encryption provides the confidentiality and integrity of data. SSH uses the public-key cryptography to authenticate the remote network device and to allow the remote network device to authenticate the user, if necessary. Quantum safe cryptography can be configured for SSH.SSLFabric OS uses Secure Socket Layer (SSL) to support LDAP, RSA, FA, SYSLOG, SMTPS, KAFKA, and HTTPS. A certificate must be generated and installed on each switch to enable the HTTPS server communication. This protocol supports 128-bit encryption by default. TLS v1.2 is recommended for a stronger encryption. HTTPS, SMTPS, and FA supports TLS v1.3.

Access control lists

Between Brocade Fabric OS (FOS) 9.0 and FOS 10.0, changes to Access Control Lists (ACLs), which encompass policies such as FCS (Fabric Configuration Server), DCC (Device Connection Control), SCC (Switch Connection Control), and IP Security Access Lists, fall into several key architectural, security, and hardware compatibility categories.

In FICON environments, ACLs help protect fabric integrity by controlling switch membership, device connectivity, and management access. Although FICON logical switches (FLSs) provide the logical separation required for mainframe workloads, ACL policies are configured and managed independently and should be implemented as part of the overall security architecture. The specific ACL requirements depend on the fabric topology, operational requirements, and security policies in effect.

The following list describes the primary changes:

• Improved policy management and consistency across physical and logical fabrics.
• Continued support for Fabric Configuration Server (FCS), Device Connection Control (DCC), and Switch Connection Control (SCC) policies to control fabric membership and device access.
• Improved support for modern hardware platforms, including Gen 8 directors and switches.
• Expanded support for IPv6 and unified IP filtering capabilities for management network access control.
• Better integration with virtual fabrics and FICON logical switch environments.

Hardware architecture and platform constraints

Gen 8 hardware integration: FOS 10.0 introduces support for Brocade Gen 8 platforms alongside Gen 7. ACL security policy processing natively extends across Gen 7 and Gen 8 fixed-switch, director, and extension platforms without requiring different ACL syntax or structural changes.

Gen 6 platform retirement: Gen 6 platforms reached their final supported software levels within the FOS 9.x family. Consequently, ACL policy deployment and management in FOS 10.0 are limited to supported Gen 7 and Gen 8 switches and directors.

In-band management security controls (FCS and DCC)

FOS utilizes specific built-in ACL policy types (such as Fabric Configuration Server / FCS and Device Connection Control / DCC) to govern in-band management and fabric access:

Extension Platform (FCIP) ACL support: While fixed-port switches and directors supported full ACL policies in FOS 9.0.0, complete ACL feature parity for Gen 7 Extension Switches such as the Brocade 7810/7850 matured in FOS 9.2.0 and carries forward into FOS 10.0.

Automation-friendly ACL management: In FOS 9.x, Broadcom introduced REST API support for security configurations, which expanded further into FOS 10.0. ACL management (activating, modifying, distributing FCS and DCC policies) shifted away from legacy Java-based interfaces toward structured REST payloads and SANnav orchestration.

FICON considerations: Within FICON logical switch (FLS) environments, ACL policies are configured independently of the logical switch definition. Organizations commonly use FCS, DCC, and SCC policies to control switch membership, restrict device connectivity, and maintain fabric integrity across single- and dual-director topologies.

WebTools and management interface ACLs

Removal of legacy WebTools: FOS 9.0 replaced the old Java-based WebTools interface with a Java-free HTML5 version. By FOS 10.0, legacy Java utilities and deprecated embedded tools like the legacy embedded SSH Client are removed entirely. ACL policy creation (DCC, FCS, SCC) is managed through the modern WebTools interface or CLI/REST API.

Tightened default security base

Although standard IP management ACL functionality (secpolicymanager / ipfilter) operates similarly between 9.x and 10.x, the base system surrounding network ACLs has been significantly tightened:

• Default secure policy profiles: FOS 10.0 defaults to stricter security profiles out of the box, requiring explicit ACL entries or TLS/crypto configurations for any out-of-band management traffic trying to traverse management interfaces.

• Deprecation of weak protocol rules: IP filter ACL rules permitting unencrypted legacy management protocols (HTTP, Telnet) are disabled by default in FOS 10.0 security baselines in favor of HTTPS and SSH.

ACL policies

Access control lists (ACLs) are used to provide network security through policy sets. FOS provides several ACL policies, including a Switch Connection Control (SCC) policy, a Device Connection Control (DCC) policy, a Fabric Configuration Server (FCS) policy, and an IP Filter.

SCC policy

Use the SCC policy to restrict FC switches that can join the fabric. Only switches that are specified in the policy can join the fabric. All other switches fail authentication if they attempt to connect to the fabric, which results in the respective E_Ports being segmented because of the security violation.

Use the SCC policy in environments where you need strict control of fabric switch members.

The SCC policy can prevent switches from participating in a fabric; therefore, it is important to regularly review and properly maintain the SCC policy.

DCC policy

Use the DCC policy to restrict devices that can attach to a single FC port. The policy specifies the FC port and one or more worldwide names (WWNs) that can connect to the port. The DCC policy comprises all of the DCC policies that are defined for individual FC ports.

Not every FC port must have a DCC policy, and only ports with a DCC policy in the active policy set enforce access controls. A port that is present in the active DCC policy allows only WWNs in its respective DCC policy to connect and join the fabric. All other devices fail authentication when they attempt to connect to the fabric, which results in the respective F_Ports being disabled because of the security violation.

Use the DCC policy in environments where you need strict control of fabric device members.

Because the DCC policy can prevent devices from participating in a fabric, it is important to regularly review and properly maintain the DCC policy.

FCS policy

Use the FCS policy to restrict the source of fabric-wide settings to a single FC switch. The policy contains the WWNs of one or more switches, and the first WWN (online) in the list is the primary FCS. If the FCS policy is active, only the primary FCS can make or propagate fabric-wide parameters. These parameters include zoning, security (ACL) policy databases, and other fabric settings.

Securing end points in SAN infrastructure

The SAN infrastructure consists of HBAs, switches, and storage devices. Each of these components offer security features that must be enabled to maximize security.

Several options are available regarding HBAs. You can use Single Initiator Zones to limit the number of LUNs that might be compromised if the server is compromised.

On the storage device, LUN masking must be implemented to ensure that only those LUNs zoned to the host bus adapter (HBA) are accessible through the associated storage port. DH-CHAP can also be enabled to authenticate devices when they join the fabric.

Additional security controls should be implemented to reduce the potential impact of a compromised device. Single-initiator zoning should be used in conjunction with LUN masking to limit device visibility and restrict access to only the required storage resources.

On FC switches, unused ports should be permanently disabled to reduce the attack surface. Active F_Ports should also be configured so that they cannot transition to E_Ports, preventing unauthorized interswitch links (ISLs) from being established and helping maintain fabric integrity.

Additional security controls are available for Fibre Channel switches. Unused switch ports can be permanently disabled. Administrators can also prevent active F_Ports from becoming E_Ports (ISLs) by configuring the ports to disallow E_Port operation.

By using a DCC policy, administrators can control which devices are allowed to log in to specific switch ports based on their WWNs. Similarly, an SCC policy can be used to control which switches are permitted to join the fabric based on switch WWNs. These controls are widely used in High Integrity Fabric (HIF) environments and are commonly implemented in FICON deployments to help maintain fabric integrity and restrict unauthorized access.

Between Brocade Fabric OS (FOS) 9.0 and FOS 10.0, Broadcom significantly modernized the security model for SAN endpoints (HBAs, servers, and storage target ports) and switch hardware. The focus shifted from optional security controls to zero-trust hardware enforcement, hardened endpoint authentication, and strict cryptographic standards.

Endpoints and HBAs (N_Port and F_Port security)

FC-SP-2 and modernized DH-CHAP authentication

FOS 9.0: Supported FC-SP (Fibre Channel Security Protocol) and DH-CHAP authentication for N_Ports (HBAs and storage arrays connecting to switch F_Ports). However, legacy cryptographic hashes like MD5 were still widely tolerated.

FOS 10.0: Enforces FC-SP-2 standards with SHA-256 / SHA-512 cryptographic hashing for DH-CHAP endpoint authentication. Legacy MD5 hashing is disabled or strongly deprecated, forcing HBAs and storage targets to authenticate using modern key exchange algorithms before logging into the fabric (FLOGI).

FC-NVMe endpoint security and isolation

Enhancements: As flash/NVMe storage adoption grew across the 9.x and 10.x release trains, FOS strengthened endpoint isolation for FC-NVMe workloads.

Impact: Tightened Fabric Zoning Lock mechanisms prevent dynamic FC-NVMe host/target discovery exploitation, ensuring HBAs cannot probe or map unauthorized NVMe namespaces or storage arrays on shared fabric switches.

Storage array and target device controls

Target rate limiting and flow guard security

FOS 9.0: Flow-based monitoring (Fabric Vision / MAPS) monitored oversubscription and congestion from storage arrays.

FOS 10.0: Deep integration between storage endpoint security and MAPS (Monitoring and Alerting Policy Suite) allows automatic quarantine or port-fencing of compromised, noisy, or misbehaving storage targets.

Restricted LUN and WWN masking and zoning integrity

4 MB zoning database: FOS 9.0 increased the maximum zoning database size to 4 MB, enabling support for larger and more complex SAN environments while maintaining centralized management and consistent enforcement of zoning policies across the fabric.

Transactional zoning locks: FOS 10.0 enforces transactional zoning locks that help prevent concurrent or unauthorized zoning modifications through management interfaces, including REST APIs. These controls help maintain zoning integrity and prevent unintended changes that could affect host-to-storage access.

Switch hardware and platform integrity

TruFOS certificates and counterfeit protection

FOS 9.0: Introduced digital license certificates and signature checks.

FOS 10.0 / Gen 8: Brocade TruFOS Certificates are strictly enforced. The switch verifies the cryptographic authenticity of the operating system, optics, and firmware updates. Unauthorized firmware or counterfeit hardware modules are blocked at boot time via hardware-rooted Secure Boot.

ISL encryption and switch-to-switch (E_Port) security

In-flight encryption: AES-256 encryption on Inter-Switch Links (ISLs) is updated to support modern cipher suites. In FOS 10.0, session key renegotiation for encrypted links between switches is hardened to protect against replay attacks.

Overall management and protocol baseline

FOS 9.2 introduced — and FOS 10.0 standardizes — out-of-the-box Default Secure configurations.

Protocol hardening: Legacy, unencrypted management protocols (Telnet, HTTP) and weak SNMP users are disabled by default. All REST API calls, WebTools sessions, and SSH connections require TLS 1.3 and elliptic curve Diffie-Hellman (ECDH) key exchanges.

ISL in-flight encryption and compression

IBM b-type Gen 8 FC platforms support in-flight compression and encryption at a port level for local and long-distance ISLs. In-flight data compression is a useful tool for saving money when bandwidth caps or bandwidth usage charges are in place for transferring data between fabrics. Similarly, in-flight encryption enables a further layer of security with no key management impact when transferring data between local and long-distance data centers besides the initial setup.

Between Brocade Fabric OS (FOS) 9.0 and FOS 10.0, changes to In-Flight Encryption (IFE) and In-Flight Compression (ICOMP) focus on scaling these features for 128Gb/s Gen 8 Fibre Channel architecture, enforcing modern cryptographic standards, and streamlining key exchange protocols.

Gen 8 hardware scaling and port density

Expanded ASIC throughput: In FOS 9.x (Gen 6/Gen 7 platforms), IFE and ICOMP were bound by 32G/64G ASIC buffer and port group limits. FOS 10.0 introduces native support for Gen 8 platforms (such as 128G switches/blades like the G820 and FC128-48).

Increased bandwidth capabilities: Under FOS 10.0, individual port groups support up to 256 Gb/s of combined encryption and compression bandwidth per ASIC port group, allowing up to 32 ports per group to run in-flight security/compression at native rates without needing auxiliary blades or external appliances.

Mixed-generation interoperability: FOS 10.0 natively supports encrypted/compressed Inter-Switch Links (ISLs and IFLs) operating between Gen 7 and Gen 8 switches running 10.x.

Cryptographic hardening and key exchange

Modern authentication protocols only: To establish an encrypted ISL (E_Port / EX_Port), the switches must authenticate prior to enabling encryption. While FOS 9.0 still tolerated legacy DH-CHAP hashing variants, FOS 10.0 strictly enforces modern, high-bit hashing algorithms (DH-CHAP with SHA-256 / SHA-512) and FCAP (FC-SP Certificate Authentication Protocol).

Removal of weak cipher suites: FOS 10.0 deprecates older 128-bit or legacy IPSec/AES key exchange modes on ISL encryption pipelines in favor of AES-256 GCM (Galois/Counter Mode), ensuring protection against modern replay attacks over long-distance links.

Auto-key rotation improvements: Session key renegotiation for in-flight encryption on long-haul ISLs operates with tighter background key rotation cycles in FOS 10.0, avoiding frame drops during session re-keying.

Enabling in-flight ISL encryption increases latency because frames must be processed by the ASIC before transmission. In-flight compression also requires additional processing, although the reduced volume of transmitted data may partially or fully offset the associated latency, depending on the workload.

Implementing DH-CHAP for ISL encryption

The following example shows how to implement DH-CHAP for ISL encryption:

1. Verify whether DH-CHAP secrets exist in the switch database:

switch:admin> secauthsecret --show Chap secret key database does not exist.

2. Run secauthsecret --set to set DH-CHAP authentication and create secrets on each switch:

switch:admin> secauthsecret --set This command is used to set up secret keys for the DH-CHAP authentication. The minimum length of a secret key is 8 characters and maximum 40 characters. Setting up secret keys does not initiate DH-CHAP authentication. If switch is configured to do DH-CHAP, it is performed whenever a port or a switch is enabled. Warning: Please use a secure channel for setting secrets. Using an insecure channel is not safe and may compromise secrets. Following inputs are specified for each entry. WWN for which secret is being set up. Peer secret: The secret of the peer that authenticates to peer. Local secret: The local secret that authenticates peer. Press Enter to start setting up shared secrets > Enter WWN, Domain, or switch name (Leave blank when done): 10:00:8j:94:7f:40:90:20 Enter peer secret: Reenter peer secret: Enter local secret: Reenter local secret: Warning: Keeping same peer and local secrets can compromise the security of your network. To change, reenter WWN and secrets. Enter peer WWN, Domain, or switch name (Leave blank when done): Are you done? (yes, y, no, n): [no] y Saving data to keystore... Done.

3. Validate that switch secrets are now stored in the switch database:

switch:admin> secauthsecret --show WWN DId Name 10:00:8j:94:7f:40:90:20 60 switchAname_DH-CHAP_example

4. Enable DH-CHAP as the authentication method:

switch:admin> authutil --set -a dhchap Authentication is set to dhchap.

5. Set the DH Group to 4:

switch:admin> authutil --set -g "4" switch:admin> authutil --show AUTH TYPE HASH TYPE GROUP TYPE fcap,dhchap sha256,sha1,md5 4

6. Activate the configuration:

switch:admin> authutil --policy -sw active Warning: Activating the authentication policy requires either DH-CHAP secrets or PKI certificates depending on the protocol selected. Otherwise, ISLs will be segmented during next E-port bring-up. ARE YOU SURE (yes, y, no, n): [no] yes Auth Policy is set to active.

7. Validate the authentication configuration:

switch:admin> authutil --show AUTH TYPE HASH TYPE GROUP TYPE fcap,dhchap sha256,sha1,md5 4 Switch Authentication Policy: ACTIVE Device Authentication Policy: OFF

8. Configure ports to use encryption for ISLs on local and remote switches:

switch:admin> portdisable 1/23 switch:admin> portcfgencrypt --enable 1/23 switch:admin> portenable 1/23

9. Validate the port's configuration:

switch:admin> portcfgshow 1/23 Area Number: 23 Octet Speed Combo: 1(32G|16G|8G|4G) Speed Level: 8G AL_PA Offset 13: OFF Trunk Port ON Long Distance OFF VC Link Init OFF Locked L_Port OFF Locked G_Port OFF Disabled E_Port OFF Locked E_Port OFF ISL R_RDY Mode OFF RSCN Suppressed OFF Persistent Disable OFF LOS TOV mode 0(OFF) NPIV capability ON QOS Port AE Port Auto Disable: OFF EX Port OFF Mirror Port OFF SIM Port OFF Credit Recovery ON F_Port Buffers OFF E_Port Credits OFF Fault Delay: 0(R_A_TOV) NPIV PP Limit: 126 NPIV FLOGI Logout: OFF CSCTL mode: OFF TDZ mode: OFF D-Port mode: OFF D-Port over DWDM: OFF Compression: OFF Encryption: ON 10G/16G FEC: ON 16G FEC via TTS: OFF

Implementing FCAP for ISL encryption

The following process shows an alternative way to enable FCAP for ISL encryption:

1. Generate switch CSR files:

   switch:admin> seccertmgmt generate -csr fcap

2. Export switch CSR files to CA for signing:

   switch:admin> seccertmgmt export -csr fcap

   Example with complete customer-supplied input:

   seccertmgmt export -csr fcap -protocol scp -ipaddr 10.1.1.1 -login hostsusername \ -password hostspassword -remotedir /home/fcap/fcap_files

3. Import CA certificate to each switch:

   switch:admin> seccertmgmt import -ca -client fcap

   Example with complete customer-supplied input:

   seccertmgmt import -ca -client fcap -protocol scp -ipaddr 10.1.1.1 \ -remotedir /home/fcap/fcap_files -certname ca.pem \ -login hostsusername -password hostspassword

4. On the host, verify switch CSRs:

   openssl req -text -noout -verify -in FcapSw.csr

5. On the host, CA signs switch CSRs:

   openssl ca -in FcapSw.csr -out FcapSw.pem

6. Verify CA signed switch CSRs:

   openssl x509 -in FcapSw.pem -text -noout

7. Validate filename permission on host:

   chmod 777 FcapSw.pem

8. Import CA signed switch CSRs:

   switch:admin> seccertmgmt import -cert fcap

   Example with complete customer-supplied input:

   seccertmgmt import -cert fcap -protocol scp -ipaddr 10.1.1.1 \ -remotedir /home/fcap/fcap_files -certname FcapSw.pem \ -login hostsusername -password hostspassword

9. Validate switch database:

   switch:admin> seccertmgmt show -all

10. Enable FCAP authentication:

    switch:admin> authutil --set -a fcap Authentication is set to fcap. switch:admin> authutil --set -g "4" DH Group was set to 4. switch:admin> authutil --set -h sha256 Hash is set to sha256.

11. Configure ports to use ISL encryption on local and remote switches:

    switch:admin> portdisable 1/23 switch:admin> portcfgencrypt --enable 1/23 switch:admin> portenable 1/23

12. Validate the port's configuration:

    switch:admin> portcfgshow 1/23 Area Number: 23 Octet Speed Combo: 1(32G|16G|8G|4G) Speed Level: 8G AL_PA Offset 13: OFF Trunk Port ON Long Distance OFF VC Link Init OFF Locked L_Port OFF Locked G_Port OFF Disabled E_Port OFF Locked E_Port OFF ISL R_RDY Mode OFF RSCN Suppressed OFF Persistent Disable OFF LOS TOV mode 0(OFF) NPIV capability ON QOS Port AE Port Auto Disable: OFF EX Port OFF Mirror Port OFF SIM Port OFF Credit Recovery ON F_Port Buffers OFF E_Port Credits OFF Fault Delay: 0(R_A_TOV) NPIV PP Limit: 126 NPIV FLOGI Logout: OFF CSCTL mode: OFF TDZ mode: OFF D-Port mode: OFF D-Port over DWDM: OFF Compression: OFF Encryption: ON 10G/16G FEC: ON 16G FEC via TTS: OFF

Consider the following points regarding in-flight encryption and compression:

• Encryption and compression are supported on E_Ports and EX_Ports.
• ISL ports must be set to long-distance (LD) mode when compression is used.
• Twice the number of buffers must be allocated if compression is enabled for long-distance links because frame sizes might be reduced by approximately half.
• If both compression and encryption are used, enable compression first.

Implementing ISL encryption across multiple ISLs between the same switch pair requires that either all ISLs be configured for encryption or none of them.

The supported number of encryption- and compression-enabled ports varies according to the platform generation, hardware architecture, and link speed. Earlier platforms imposed limits on a per-ASIC basis. See the platform-specific documentation for the applicable encryption and compression capacity limits.

Consider the following points regarding Virtual Fabric (encryption and compression):

• E_Ports in user-created logical switches, the base switch, and the default switch can support encryption and compression.

• Encryption and compression are supported on XISL (Extended Inter-Switch Link) ports but not on LISL (Logical Inter-Switch Link) ports. LISLs are internal links that connect logical switches through an XISL and are used for Virtual Fabrics communication.

• If encryption or compression is enabled on a port, it must be disabled before the port can be moved from one logical switch (LS) to another.

Policy database distribution

Security Policy Database Distribution provides a mechanism for controlling the distribution of each policy on a per-switch basis. Switches can individually configure policies to accept or reject a policy distribution from another switch in the fabric.

In addition, a fabric-wide distribution policy can be defined for the SCC and DCC policies with support for strict, tolerant, and absent modes. This setting can be used to enforce whether the SCC or DCC policy must be consistent throughout the fabric.

The Policy Database Distribution features the following modes:

Strict

All updated and new policies of the specified type (SCC, DCC, or both) must be distributed to all switches in the fabric, and all switches must accept the policy distribution.

Tolerant

All updated and new policies of the type specified (SCC, DCC, or both) are distributed to all switches (FOS V6.2.0 or later) in the fabric. However, the policy does not need to be accepted.

Absent

Updated and new policies of the type specified (SCC, DCC, or both) are not automatically distributed to other switches in the fabric. Policies can still be manually distributed.

Together, the policy distribution and fabric-wide consistency settings provide a range of control on the security policies from little or no control to strict control. Strict mode is required for FICON environments that require High Integrity Fabrics be enabled.

Cryptographic and security standards

Fabric OS firmware uses the Brocade Fabric OS FIPS Cryptographic Module 9.1.1 library to perform cryptographic functions. The module must be used in a Federal Information Processing Standards (FIPS) compliant operational environment along with the proper device configuration.

Fabric OS firmware uses the Brocade Fabric OS Common Criteria (CC) standards with Fabric OS 9.1.1 Network Device Collaborative Protection Profile (NDcPP) to perform cryptographic functions.

Fabric OS version 9.1.1b8 is in accordance with the BSI (Bundesamt für Sicherheit in der Informationstechnik) EAL2 (Evaluation Assurance Level 2) certified configuration.

For more information about other topics in this subject area that are out of the scope of this document, such as encrypting data that is at rest and in flight, see Brocade Fabric OS Administration Guide, 10.0x.