SRA EX9000 Security Policy Document Version 2.1 SonicWALL, Inc. February 20, 2013 Copyright SonicWALL, Inc. 2012. May be reproduced only in its original entirety [without revision]. SonicWALL, Inc. SRA EX9000 Security Policy Version 2.1 Revision Date February 20, 2013 TABLE OF CONTENTS 1. MODULE OVERVIEW .........................................................................................................................................3  2. SECURITY LEVEL ................................................................................................................................................4  3. APPROVED MODE OF OPERATION ................................................................................................................4  REQUIREMENTS FOR FIPS 140-2 ...............................................................................................................................5  ENABLING FIPS .........................................................................................................................................................6  MANAGING FIPS COMPLIANT CERTIFICATES ............................................................................................................7  EXPORTING AND IMPORTING CERTIFICATES ..............................................................................................................7  ZEROIZATION.............................................................................................................................................................8  4. NON-APPROVED MODE OF OPERATION ......................................................................................................8  DISABLING FIPS ........................................................................................................................................................8  5. PORTS AND INTERFACES .................................................................................................................................9  6. IDENTIFICATION AND AUTHENTICATION POLICY ..............................................................................10  7. ACCESS CONTROL POLICY ............................................................................................................................12  ROLES AND SERVICES ..............................................................................................................................................12  DEFINITION OF CRITICAL SECURITY PARAMETERS (CSPS) ......................................................................................13  DEFINITION OF CSPS MODES OF ACCESS ................................................................................................................15  DEFINITION OF PUBLIC KEYS ...................................................................................................................................16  8. OPERATIONAL ENVIRONMENT....................................................................................................................17  9. SECURITY RULES ..............................................................................................................................................18  10. PHYSICAL SECURITY POLICY ....................................................................................................................20  PHYSICAL SECURITY MECHANISMS .........................................................................................................................20  OPERATOR REQUIRED ACTIONS ..............................................................................................................................21  11. MITIGATION OF OTHER ATTACKS POLICY ...........................................................................................21  12. REFERENCES ....................................................................................................................................................22  13. DEFINITIONS AND ACRONYMS...................................................................................................................22  Page 2 SonicWALL, Inc. SRA EX9000 Security Policy Version 2.1 Revision Date February 20, 2013 1. Module Overview The SonicWALL SRA EX9000 (HW P/N 101-500352-50 Rev A, FW Version SRA 10.6.1) is a multi-chip standalone cryptographic module enclosed in a hard, opaque, commercial grade metal case. The primary purpose of the module is to provide secure remote access to internal resources via the Internet Protocol (IP). The module provides network interfaces for data input and output. Figure 1 – Images of the Cryptographic Module SonicWALL SRA EX9000 Page 3 SonicWALL, Inc. SRA EX9000 Security Policy Version 2.1 Revision Date February 20, 2013 2. Security Level The cryptographic module meets the overall requirements applicable to Level 2 security of FIPS 140-2. Table 1 - Module Security Level Specification Security Requirements Section Level Cryptographic Module Specification 2 Module Ports and Interfaces 2 Roles, Services and Authentication 2 Finite State Model 2 Physical Security 2 Operational Environment N/A Cryptographic Key Management 2 EMI/EMC 2 Self-Tests 2 Design Assurance 3 Mitigation of Other Attacks N/A The cryptographic module supports both an Approved and Non-Approved mode of operation. 3. Approved Mode of Operation The cryptographic module supports the following FIPS Approved algorithms and security functions:  RNG - ANSI X9.31  AES 128 and 256 bit in CBC mode  AES 128 and 256 bit in ECB mode  RSA 1024, 1536 and 2048 bit  Triple-DES CBC 3-key  SHA-1  SHA-256  HMAC-SHA-1 Page 4 SonicWALL, Inc. SRA EX9000 Security Policy Version 2.1 Revision Date February 20, 2013 The cryptographic module supports the following allowed algorithms and protocols in the Approved mode:  MD5 (Limited use within TLS)  RSA key wrapping (key establishment methodology provides 80 or 112 bits of strength)  PKCS #12 Password based obfuscation does not provide security. The security strength is provided by TLS for CSPs being pushed off box to other cryptographic models participating in a replication relationship.  SNMP v3 – No security claimed  Non-Approved NDRNG – Generation of seed values for the Approved RNG Requirements for FIPS 140-2 The following items are required to properly configure the Approved mode for full compliance:  An SRA EX9000 appliance. CAUTION: For a SonicWALL SRA EX9000 appliance with 140-2 Level 2 FIPS validation, the tamper evident seals affixed to it must remain in place.  A license to run FIPS Approved mode. FIPS mode is not automatically enabled after a license is imported.  A secure connection to the authentication server  A strong administrator password, which should be at least 8 to 14 characters long and contain punctuation characters, numbers, and a combination of uppercase and lowercase letters. In addition, an authentication server must be specified when a realm is configured; "null auth" is not allowed. The following required configuration and steps must be performed to operate in the Approved mode:  Do not use unsecured connections with authentication servers  Do not use RADIUS authentication servers  Do not use LDAP authentication servers without using TLS connections employing only FIPS Approved ciphers  Do not use Active Directory single domain authentication servers without using TLS connections employing only FIPS Approved ciphers  Do not use RSA Authentication Manager authentication servers without using TLS connections employing only FIPS Approved ciphers  Do not use RSA Authentication Manager authentication servers without strong passwords as shared secrets  Do not use USB devices for any purpose Page 5 SonicWALL, Inc. SRA EX9000 Security Policy Version 2.1 Revision Date February 20, 2013  Do not use clustering (High Availability). Clustering (HA) is not supported in FIPS mode.  Do not use with SonicWALL GMS or Viewpoint servers  Do not Load or unload any kernel modules via the shell command line  Do not Install third party software via the shell command line  Do not attempt Firmware upgrades via the shell command line  Do not use Debug 1, Debug 2, Debug 3 or plaintext logging  Do not use certificates with private/public key-pairs generated by a non-FIPS validated system  The FIPS Approved mode must be enabled as described in “Enabling FIPS”. Enabling FIPS Before enabling FIPS Approved mode, a strong password, secure connection to the authentication server, and valid license are required. To be FIPS-compliant, the password must be at least 8 characters long, but it is recommended that it be at least 14 characters. Although this recommendation is not enforced by the software, having a weak administrator password is a potential vulnerability. A strong password includes a mix of letters, numbers and symbols. Think of this as a phrase, not just a password. For instance, “I never saw a purple cow, I never hope 2C1.” has a combination of all three types of characters. Only administrators with System rights can change the mode of operation. When in FIPS Approved mode, you will not be able to select non-compliant algorithms for session security. To Enable the FIPS Approved mode: 1. In the main navigation menu, click General Settings, then click FIPS Security. 2. Click Edit. 3. If the license is imported, select the Enable FIPS mode check box. Note: Existing certificates will be removed from the system in the next step. To preserve the FIPS-compliant certificates, ensure that they have been exported. 4. Click Save and then apply the Pending changes. ! The appliance will be rebooted to apply these changes. Any connections will be terminated. ! Once in FIPS Approved mode, hand editing via the shell of any configuration files is not allowed and if done will cause the appliance to immediately reboot and be placed into single user mode for remediation by the primary administrator. If the appliance configuration is known to not be FIPS compliant, FIPS compliance warning will be provided. Click on the link for more information on how to bring the appliance configuration into FIPS compliance. Page 6 SonicWALL, Inc. SRA EX9000 Security Policy Version 2.1 Revision Date February 20, 2013 Caution: The lack of this alert does not mean the environment is FIPS compliant. It is the operator’s responsibility to ensure all of the FIPS prerequisites are met in order to be FIPS compliant. Managing FIPS Compliant Certificates Any keys generated on an SRA EX9000 appliance running in FIPS Approved mode will be FIPS compliant. If certificates are imported (and their associated public and private keys) to the appliance, it is the Crypto-Officer’s or User’s responsibility to make sure that they are also FIPS compliant. Certificates must be exported and then re-imported when switching FIPS mode on or off. For the export and import procedure, see “Exporting and Importing Certificates”. The best way to ensure that the certificates used are FIPS compliant is to generate all CSRs (certificate signing requests) on a FIPS-enabled appliance. Exporting and Importing Certificates If existing Certificate keys were generated on a FIPS-compliant system and are to be used after FIPS is enabled, they must be exported from the FIPS-compliant system and then imported after FIPS is enabled. To export Certificates before the FIPS-mode transition: 1. In AMC, navigate to SSL Setting > SSL Certificates. 2. For each certificate to export, do the following: a. On the Certificates table, select a certificate and click the Export button. b. Enter a password for the exported .p12 file. c. Click the Save button To import certificates after the FIPS-mode transition: 1. In AMC, navigate to SSL Settings > SSL Certificates. 2. For each certificate to import, do the following: a. On the Certificates table, select New > Import certificate.... b. Select the certificate file to import. c. Enter the password for the .p12 file. d. Click the Import button Page 7 SonicWALL, Inc. SRA EX9000 Security Policy Version 2.1 Revision Date February 20, 2013 Zeroization Zeroization is the practice of permanently destroying all critical security parameters. This is accomplished by overwriting the entire disk with zeros. Zeroization makes it very hard to retrieve sensitive data from the appliance. It is used before recycling hardware, or in other cases where data security is more important than retaining the data. Once this operation is completed, the appliance can no longer be used at the site and must be returned to SonicWALL for replacement hardware to restore service. To Zeroize the appliance: 1. Connect to the appliance using a serial connection, and log in as the Crypto Officer. 2. Type factory_reset_tool --zeroize. 3. Stay physically present with the appliance until the appliance halts. ! The appliance can take up to an hour to complete the zeroization process. 4. Non-Approved Mode of Operation The cryptographic module provides non-FIPS Approved algorithms as follows:  MD5 with TLS and ESP  RC4 with TLS These algorithms are not usable in the Approved mode of operation and are available only when the system is not configured in FIPS mode. Disabling FIPS Turning off FIPS disables the FIPS feature and removes all of the constraints imposed by the FIPS mode prerequisites. To disable FIPS: 1. From the main navigation menu, click General Settings, then click FIPS Security. 2. Click Edit. 3. Clear the box next to Enable FIPS mode. Note: Existing certificates will be deleted from the system in the next step. To preserve the existing certificates, ensure that they have been exported. 4. Click Save and then apply the Pending changes. ! The appliance will be rebooted to apply these changes. Any connections will be terminated. ! Warning: To be fully FIPS compliant, no FIPS critical security parameters shall be used outside of the FIPS Approved mode of operation. Zeroization must be performed prior to transitioning out of the Approved mode of Operation. Page 8 SonicWALL, Inc. SRA EX9000 Security Policy Version 2.1 Revision Date February 20, 2013 5. Ports and Interfaces The cryptographic module provides the following physical ports and logical interfaces: Ports Type The X0 Ethernet interface provides Data In, Data Out, Ethernet Status Out and Control In. It is not enabled when the X8 The cryptographic module provides Ethernet interfaces. is enabled. Ethernet interface X0 thru X7 are [10/100/1000] auto- The X1 Ethernet interface provides Data In and Data sensing with an RJ- 45 connector. Ethernet interfaces Out. It is not enabled when X9 is enabled. X8-X11 are 10000 SFP+ cavities and support a variety of transceivers including but not limited to SC, LC and The X2 Ethernet interface provides Data In and Data 10GBase-CX-4 physical mediums. Each Ethernet Out. It is not supported in the Approved mode of interface includes LINK and ACT LEDs. operation. The X3 Ethernet interface, when enabled provides Status Out and Control In. The X4-X7 Ethernet interfaces are not enabled and are reserved for future use. The X8 Ethernet 10G interface provides Data In, Data Out, Status Out and Control In. It is not enabled when the X0 interface is enabled. The X9 Ethernet 10G interface provides Data In and Data Out. It is not enabled when the X1 interface is enabled. The X10 Ethernet 10G interface provides Data In and Data Out. It is not supported in the Approved mode of operation. The X11 Ethernet 10G interface is not enabled and is reserved for future use. The DIAG interface is used during the manufacturing DIAG process and is disabled. The cryptographic module provides a diagnostic interface. This interface is an Ethernet [10/100/1000] RJ45 and includes LINK and ACT LEDs. Each USB interface shall not be used in the Approved USB mode of operation. The cryptographic module provides USB interfaces. Neither is supported in the Approved mode of operation. The console interface provides Data In, Data Out, Status Console Out and Control In. The cryptographic module provides a console interface. The console interface is a DB-9/RJ-45 serial connector. The serial port provides a serial console. The serial console can be used for basic administration functions. The LED interface provides Status Out. LED The cryptographic module provides Status LEDs. The Power LED indicates the module is receiving power. The Test LED indicates the module is initializing and performing self-tests. The Alarm LED indicates an Page 9 SonicWALL, Inc. SRA EX9000 Security Policy Version 2.1 Revision Date February 20, 2013 Ports Type alarm condition. The LCD interface provides Status Out. LCD Screen The cryptographic module provides a LCD screen interface. The LCD screen is used to display basic setup information. The 4-button panel interface provides Control In. 4-Button Panel The cryptographic module provides a 4-button panel interface. The 4-button panel is used to control the LCD screen display. Inputting of setup information is not supported in the Approved mode of operation. The power port provides Power In. Power The cryptographic module provides power interfaces. 6. Identification and Authentication Policy Assumption of roles The cryptographic module supports administrator roles and the VPN End User role. Administrators, Cryptographic Officer and User, must authenticate with the AMC GUI console via the GUI Administration Interface and a HTML forms-based username and password method. The username and password are validated with an internal database. Once validated, the username is mapped into either the User or Cryptographic Officer role. Cryptographic Officers may also utilize a command line shell for basic administration purpose by authenticating using the password over either the SSH Administration Interface or the Console Interface. The VPN End User accesses the routing and data handling of the VPN device. Authentication is provided by username and password or by an authenticated external AAA server. Table 2 - Roles and Required Identification and Authentication Role Type of Authentication Authentication Data User Identity-based operator authentication Username and Password Cryptographic- Identity-based and Role-based operator Username or Role and Password Officer authentication VPN End User Identity-based authentication. Username and Password or Transitive trust with authentication of the external AAA server utilizing either X.509 certificates or shared secrets. Page 10 SonicWALL, Inc. SRA EX9000 Security Policy Version 2.1 Revision Date February 20, 2013 Table 3 – Strengths of Authentication Mechanisms Authentication Mechanism Strength of Mechanism Username and Password The Cryptographic Officer and User passwords must be at least eight characters long each, and the password character set is ASCII characters 32-127, which is 96 ASCII characters. This makes the probability, 1 in 96^8, which is less than one in 1,000,000 that a random attempt will succeed or a false acceptance will occur for each attempt. After three successive unsuccessful password verification tries, the cryptographic module pauses for one second before additional password entry attempts can be reinitiated. This makes the probability approximately, 180/96^8, which is less than one in 100,000 that a random attempt will succeed or a false acceptance will occur in a one- minute period. Transitive AAA with shared secret When shared secrets are employed with external AAA servers, strong passwords must be used. These strong passwords have the same strength properties as the Username and Password previously described. Transitive AAA with X.509 When X.509 certificates are employed with external AAA servers, the AAA server is authenticated via its TLS presented certificate with key sizes of 1024 to 2048 bits The probability is between 1 in 2^80, and 1 in 2^112 which is less than one in 1,000,000 that a random attempt will succeed or a false acceptance will occur for each attempt. The probability is between 1 in 600/2^80 and 1 in 600/2^112, which is less than one in 100,000 that a random attempt will succeed or a false acceptance will occur in a one-minute period. Page 11 SonicWALL, Inc. SRA EX9000 Security Policy Version 2.1 Revision Date February 20, 2013 7. Access Control Policy Roles and Services Table 4 – Services Authorized for Roles Role Authorized Services Cryptographic-Officer Security Administration – Administrator access to pages for access control rules, resources, users and groups, web portal services and client end point control. System Configuration – Administrator access to pages for network settings, general appliance settings, SSL settings, access and network services, and authentication. System Maintenance – Administrator permission to shut down or restart the appliance, update or roll back the system software, and import or export configuration data. System Monitoring – Read access permits the administrator to view system logs and graphs, view active users and run troubleshooting tools. Write access permits termination of VPN End Users and to change logging levels. Remote Assistance – Read access permits viewing of the service configuration and the trouble ticket queue. Write access permits modify the service configuration and reorder the trouble ticket queue. System Zeroize – Zeroizes the hard disk and firmware portion of flash by writing zeros to these areas. User Security Administration – Rights are delegated by the Crypto-Officer and can be none, read only or read/write. System Configuration – Rights are delegated by the Crypto-Officer and can be none, read only or read/write. System Maintenance – Rights are delegated by the Crypto-Officer and can be none, read only or read/write. System Monitoring – Rights are delegated by the Crypto-Officer and can be none, read only or read/write. Remote Assistance – Rights are delegated by the Crypto-Officer and can be none, read only or read/write. System Zeroize – Rights are delegated by the Crypto-Officer and can be none or allowed to zeroize the hard disk and firmware portion of flash by writing zeros to these areas. VPN End User Send and receive network traffic – route traffic via the VPN TLS and VPN ESP interfaces. Cryptographic Encryption, Decryption and all CSP state management is outside the control of the VPN End User and is maintained by the cryptographic module according to the security policies of the Cryptographic Officer. Page 12 SonicWALL, Inc. SRA EX9000 Security Policy Version 2.1 Revision Date February 20, 2013 Unauthenticated Services: The cryptographic module supports the following unauthenticated services, none of which disclose, modify or substitute CSP, use approved security functions, or otherwise affect the security of the cryptographic module:  Show Status: This service provides the current status of the cryptographic module on the LED and LCD interfaces.  Self-tests: This service executes the suite of self-tests required by FIPS 140-2. Performed by power-cycling the module. Definition of Critical Security Parameters (CSPs) Key / CSP Description/Usage Generated / Storage Entry/Output Destruction Derived AMC TLS RSA 1024, 1536 or Externally or Plaintext Encrypted via TLS System private key 2048 bit private key Internally session Zeroization used in the TLS negotiation for web administration GUI. WorkPlace Site RSA 1024, 1536 or Externally or Plaintext Encrypted via TLS System TLS private 2048 bit key used in Internally session Zeroization key(s) TLS handshakes for VPN sessions. There is one key for each WorkPlace site VPN TLS interface. SSH private key RSA private key is Internally Plaintext Not Applicable System used in Zeroization Administration shell SSH negotiation. Key length is 2048. SAML private RSA private key Generated Plaintext Imported / Exported in Deleted from key (certs) are used for internally PKCS12, format key store digital signing of using ANSI when the Or AAA SAML requests. X9.31 Self-Signed or 3rd Party Key length is 1024, Appendix Passphrase entered via 1536 or 2048. A.2.4 Certificate is web Administration removed, or GUI when disk is wiped. SNMPv3 Symmetric HMAC- Generated Plaintext Passphrase entered via Deleted Shared Secret SHA-1 160bit shared internally web Administration when the secret is used to verify using ANSI GUI keys are the authenticity of X9.31 removed SNMP messages Appendix from key being sent and A.2.4 store or when received. disk is wiped Page 13 SonicWALL, Inc. SRA EX9000 Security Policy Version 2.1 Revision Date February 20, 2013 Key / CSP Description/Usage Generated / Storage Entry/Output Destruction Derived Firmware Symmetric HMAC- Externally Plaintext Loaded during System Integrity shared SHA-1 160 bit shared manufacturing Zeroization secret secret is used to verify firmware integrity. Keystore Symmetric TDES 192 Externally Plaintext Loaded during System Password bit shared secret is manufacturing Zeroization Encryption used to encrypt shared secret passwords. ESP Session Symmetric HMAC- Internally Plaintext Not Applicable ESP session Authentication SHA-1 160 bit shared ends and Keys secret for ESP System session. Used to Zeroization. authenticate an ESP session. ESP Session Symmetric AES 128, Internally Plaintext Not Applicable ESP session Encryption 256 bit shared secret ends and Keys for ESP session. Used System to encrypt an ESP Zeroization. session. TLS Session Symmetric HMAC- Internally Plaintext Not Applicable TLS session Authentication SHA-1 160 bit shared ends and Keys secret for TLS System session. Used to Zeroization. authenticate a TLS session. TLS Session Symmetric AES 128, Internally Plaintext Not Applicable TLS session Encryption 256 bit or TDES 192 ends and Keys bit shared secret for System TLS session. Used to Zeroization encrypt a TLS session. TLS Shared Shared secret for TLS Externally or Plaintext Encrypted via TLS Process Secret session. Used to Internally handshake completion establish a TLS and System session. Zeroization Passwords Authentication N/A Hashed and Entered in plaintext System Passwords plaintext in Zeroization RAM Internal RNG Stored information Internally Plaintext Not Applicable System state and RNG regarding the RNG Zeroization seeding material instantiation and seed material used to initialize the Approved RNG Page 14 SonicWALL, Inc. SRA EX9000 Security Policy Version 2.1 Revision Date February 20, 2013 Definition of CSPs Modes of Access Table 6 defines the relationship between access to CSPs and the different module services. The modes of access shown in the table are defined as follows:  Generate: This operation generates keys using the FIPS Approved RNG  Read: Export the CSP  Write: Enter/establish and store a CSP  Destroy: Overwrite the CSP  Execute: Employ the CSP Table 6 – CSP Access Rights within Roles & Services Roles Cryptographic Keys and Services CO User VPN CSPs Access Operation User System Maintenance Firmware Integrity Shared Secret (Execute) Passwords (Read/Write) AMC Private Key (Read/Write) X1 X Work Place Site Private Keys (Read/Write) SAML Private Key (Read/Write) SNMPv3 (Read/Write) Security Passwords (Read/Write) X1 X Administration X1 X System Monitoring N/A System Configuration Passwords (Read/Write) AMC Private Key (Generate/Read/Write/Execute) Work Place Site Private Keys (Generate/Read/Write) X1 X SSH Private Key (Generate/Execute) SAML Private Key (Generate/Read/Write) SNMPv3 Shared Secret (Generate/Read/Write) X1 X Remote Assistance Work Place Site Private Keys (Execute) Zeroization Passwords(Destroy) AMC Private Key (Destroy) X Work Place Site Private Keys (Destroy) SSH Private Key (Destroy) SAML Private Key (Destroy) Page 15 SonicWALL, Inc. SRA EX9000 Security Policy Version 2.1 Revision Date February 20, 2013 Roles Cryptographic Keys and Services CSPs Access Operation SNMPv3 Shared Secret (Destroy) Firmware Integrity Shared Secret (Destroy) Keystore Password Encryption Shared Secret (Destroy) TLS Shared Secret (Destroy) TLS Session Encryption Keys (Destroy) TLS Session Authentication Keys (Destroy) ESP Session Encryption Keys (Destroy) ESP Session Authentication Keys (Destroy) RNG Seed Material (Destroy) Send and receive Passwords (Read/Write) network traffic AMC Private Key (Execute) Work Place Site Private Keys (Execute) SSH Private Key (Execute) X TLS Shared Secret (Write/Execute) TLS Session Encryption Keys (Write/Execute) TLS Session Authentication Keys (Write/Execute) ESP Session Encryption Keys (Write/Execute) ESP Session Authentication Keys (Write/Execute) 1 Rights must be explicitly delegated by the Crypto-Officer to the User. These rights may be restricted to read only or full rights at the discretion of the Crypto-Officer. 2 User cannot generate their own password nor can they generate the Crypto-Officer password. Definition of Public Keys Public Keys Description/Usage Storage License Verification RSA public key used to verify product Stored in fixed disk as plaintext public key license and authenticity. Key length is 1024. AMC TLS public key RSA public key is used for Administration Stored in fixed disk as plaintext GUI TLS negotiation. Key length is 1024, 1536 or 2048. WorkPlace Site TLS RSA public keys are used for VPN TLS Stored in fixed disk as plaintext public key(s) negotiation. Key length is 1024, 1536 or 2048. SSH public key RSA public key is used in Administration Stored in fixed disk as plaintext shell SSH negotiation. Key length is 2048 Page 16 SonicWALL, Inc. SRA EX9000 Security Policy Version 2.1 Revision Date February 20, 2013 Public Keys Description/Usage Storage Destination Web Server RSA public keys are used by cryptographic Stored in fixed disk as plaintext public keys module VPN web proxy service to establish VPN TLS sessions with HTTPS web server resources. Key length is 1024 or 2048. AAA Server public keys RSA public keys are used by cryptographic Stored in fixed disk as plaintext module policy service to establish VPN TLS sessions with LDAPS AAA servers, and for verifying digital signatures from SAML and OCSP AAA servers. Key length is 1024, 1536 or 2048. Trusted CA public keys RSA public keys are used by cryptographic Stored in fixed disk as plaintext module to validate X.509 certificate chains from VPN client devices. Key length is 1024, 1536 or 2048. 8. Operational Environment The FIPS 140-2 Operational Environment requirements are not applicable because the module only allows the loading of firmware through the firmware load test, which ensures the image is appropriately HMAC authenticated by SonicWALL. Page 17 SonicWALL, Inc. SRA EX9000 Security Policy Version 2.1 Revision Date February 20, 2013 9. Security Rules The cryptographic module’s design corresponds to the cryptographic module’s security rules. This section documents the security rules enforced by the cryptographic module to implement the security requirements of this FIPS 140-2 Level 2 module. 1. The cryptographic module shall provide distinct operator roles. These are the User role and the Cryptographic Officer role. Additionally, the module supports a VPN End User role. 2. The cryptographic module shall provide identity-based and role-based authentication. 3. When the module is not placed in a valid role, the operator shall not have access to any cryptographic services. 4. The cryptographic module shall encrypt message traffic using the AES or TDES algorithms. 5. The cryptographic module shall perform the following tests: A. Power up Self-Tests:  TDES Known Answer Test  AES 128 CBC Known Answer Test  AES 256 CBC Known Answer Test  AES 128 ECB Known Answer Test  RNG Known Answer Test  SHA-1 Known Answer Test  SHA-256 Known Answer Test  HMAC-SHA-1 Known Answer Test  RSA Known Answer Test B. Firmware Integrity Test  Firmware integrity test of CSPs and CSP processing components using 160 bit HMAC-SHA-1 and 16 bit CRC are performed on each power up cycle. C. Critical Functions Tests  CSP integrity is performed at each system configuration invocation and configuration update D. Conditional Self-Tests:  Continuous Random Number Generator (RNG) test – performed on Non- Approved RNG and Approved RNG  RSA pairwise consistency test for generation of asymmetric keys a. For signature generation and verification b. For encryption and decryption Page 18 SonicWALL, Inc. SRA EX9000 Security Policy Version 2.1 Revision Date February 20, 2013  Firmware Load Test: When a new firmware image or patch is loaded, the cryptographic module verifies the 160 bit HMAC-SHA-1 of the image. If this verification fails, the firmware image loading is aborted and the module reboots. 6. At any time the cryptographic module is in an idle state, the operator shall be capable of commanding the module to perform the power up self-test. This is accomplished by rebooting the appliance. 7. Prior to each use, the internal RNG shall be tested using the conditional test specified in FIPS 140-2 §4.9.2. 8. Data output shall be inhibited during power up self-tests and error states. 9. Status information shall not contain CSPs or sensitive data that if misused could lead to a compromise of the module. 10. The module supports concurrent use by VPN End Users and the system’s Crypto-Officer or User. 11. If any of the self-tests fail, the cryptographic module enters the error state. No VPN services are provided in the error state. This effectively inhibits the data output interfaces. Upon successful completion of the Diagnostic Phase, the cryptographic module enters the VPN Services State. 12. PKCS #12 Password based cryptography shall not be relied upon to provide security. 13. The following components are excluded from the FIPS 140-2 requirements:  Power supplies, connector board components and wiring  Non-critical firmware files 14. Zeroization overwrites all CSPs. Performance of the zeroization process will prevent the module from successfully booting, effectively disabling the module. The operator is required to be physically present while the module completes this process. The process may take up to one hour to complete. 15. The module shall not share CSPs between the Approved mode of operation and the non- Approved mode of operation. This section summarizes the security rules imposed by the vendor: 1. Before enabling FIPS mode, a strong password, secure connection to the authentication server, and valid license are required. 2. If any of the Power up Self-Test, CSP Firmware Integrity Tests or Conditional Self-Tests fail, the cryptographic module enters an error state. No VPN services are provided in the error state. Upon successful completion of the Diagnostic Phase, the cryptographic module enters the VPN Services State. This effectively inhibits the data output interfaces. 3. When all tests are completed successfully, an LED indicator shall be provided and status shall be available via logs and/or console access. Page 19 SonicWALL, Inc. SRA EX9000 Security Policy Version 2.1 Revision Date February 20, 2013 10. Physical Security Policy Physical Security Mechanisms The cryptographic module includes the following physical security mechanisms:  Production-grade components and production-grade opaque enclosure  Tamper evident material and seals  Protected vents The module has seven (7) tamper evident seals initially applied by the manufacturer. Figures 2 - 5 show the locations of the tamper evident seals. The tamper evident seals shall be installed for the module to operate in a FIPS Approved mode of operation. Figure 2 - Right Side Tamper Seal (qty. 1) Figure 3 - Underside Tamper Seals (qty. 3) (also protect front expansion bays) Figure 4 – Rear Fan Bay Tamper Seal (qty. 1) Page 20 SonicWALL, Inc. SRA EX9000 Security Policy Version 2.1 Revision Date February 20, 2013 Figure 5 – Front Tamper Seals (qty. 2) Operator Required Actions Some module components (e.g., hard drives) are field replaceable. If a replacement component is installed in the field, new tamper seals are sent with the replacement component, along with instructions on how to properly prepare the module surface and apply the new seals. Tamper seals may not be ordered separately. The Crypto-Officer is responsible for the following:  Directly controlling and monitoring module reconfigurations where the tamper evident seals are removed and re-installed, to ensure that the security of the module is maintained during component replacement and that the module is returned to a FIPS Approved state.  Securing and controlling any unused tamper seals. The operator is required to periodically inspect tamper evident seals. Table 7 – Inspection/Testing of Physical Security Mechanisms Physical Security Recommended Frequency of Inspection/Test Guidance Details Mechanisms Inspection/Test Tamper Evident Seals Inspect tamper evident seals monthly. See the SonicWALL Aventail Secure Remote Access Installation and Administration Guide Version 10.6 for procedure. 11. Mitigation of Other Attacks Policy The module has not been designed to mitigate attacks outside the scope of FIPS 140-2. Page 21 SonicWALL, Inc. SRA EX9000 Security Policy Version 2.1 Revision Date February 20, 2013 12. References [ESP] Kent, S., “IP Encapsulating Security Payload (ESP)”, RFC 4303, Internet Engineering Task Force, December 2005. [LDAP] Semersheim, J., Ed., “Lightweight Directory Access Protocol (LDAP): The Protocol”, RFC 4511, Internet Engineering Task Force, June 2006. [RADIUS] Rigney, C., Rubens, A., Simpson, W. and S. Willens, “Remote Authentication Dial In User Service (RADIUS), RFC 2865, Internet Engineering Task Force, June 2000. [SSH] Ylonen, T. and C. Lonvick, “The Secure Shell (SSH) Connection Protocol”, RFC 4254, Internet Engineering Task Force, January 2006. [TLS] Dierks, T., and E. Rescoria, “The Transport Layer Security (TLS) Protocol Version 1.2”. RFC 5246, Internet Engineering Task Force, August 2008. 13. Definitions and Acronyms AES Advanced Encryption Standard AMC Administrator Management Console CA Certificate Authority CBC Cipher Block Chaining CSP Critical Security Parameter DES Data Encryption Standard RNG Random Number Generator EMC Electromagnetic Compatibility EMI Electromagnetic Interference ESP Encapsulated Security Payload FIPS Federal Information Processing Standard GMS Global Management System GUI Graphical User Interface HMAC Hashed Message Authentication Code LAN Local Area Network LDAP Lightweight Directory Access Protocol OCSP Online Certificate Status Protocol PKCS #12 Public-Key Cryptography Standards RADIUS Remote Authentication Dial-In Service RSA Rivest, Shamir, Adleman asymmetric algorithm SAML Security Assertion Markup Language SNMP Simple Network Management Protocol SHA Secure Hash Algorithm SSH Secure Shell TDES Triple Data Encryption Standard VPN Virtual Private Network Page 22