SRA EX6000 and SRA EX7000 Security Policy Document Version 1.2 SonicWALL, Inc. September 2, 2010 Copyright SonicWALL, Inc. 2010. May be reproduced only in its original entirety [without revision]. SonicWALL, Inc. SRA EX6000 and SRA EX7000 Security Policy Version 1.2 Revision Date September 2, 2010 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 ................................................................................................................14  DEFINITION OF PUBLIC KEYS ...................................................................................................................................16  8. OPERATIONAL ENVIRONMENT....................................................................................................................16  9. SECURITY RULES ..............................................................................................................................................17  10. PHYSICAL SECURITY POLICY ....................................................................................................................19  PHYSICAL SECURITY MECHANISMS .........................................................................................................................19  OPERATOR REQUIRED ACTIONS ..............................................................................................................................19  11. MITIGATION OF OTHER ATTACKS POLICY ...........................................................................................20  12. REFERENCES ....................................................................................................................................................21  13. DEFINITIONS AND ACRONYMS...................................................................................................................21  Page 2 SonicWALL, Inc. SRA EX6000 and SRA EX7000 Security Policy Version 1.2 Revision Date September 2, 2010 1. Module Overview The SonicWALL SRA EX6000 (HW P/N 101-500210-58 Rev A, FW Version SRA 10.5.0) and SRA EX7000 (HW P/N 101-500188-58 Rev A, FW Version SRA 10.5.0) are multi-chip standalone cryptographic modules enclosed in a hard, opaque, commercial grade metal case. The primary purpose of these modules is to provide secure remote access to internal resources via the Internet Protocol (IP). The modules provide network interfaces for data input and output. Figure 1 – Images of the Cryptographic Modules SonicWALL SRA EX6000 SonicWALL SRA EX7000 Page 3 SonicWALL, Inc. SRA EX6000 and SRA EX7000 Security Policy Version 1.2 Revision Date September 2, 2010 2. Security Level The cryptographic modules meet 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 modules support both an Approved and Non-Approved mode of operation. 3. Approved Mode of Operation The cryptographic modules support the following FIPS Approved algorithms and security functions: • RNG - ANSI X9.31 • AES 128 and 256 bit in CBC mode • AES 128 bit in ECB mode • RSA 1024, 1536 and 2048 bit • Triple-DES CBC 3-key • SHA-1 • HMAC-SHA-1 Page 4 SonicWALL, Inc. SRA EX6000 and SRA EX7000 Security Policy Version 1.2 Revision Date September 2, 2010 The cryptographic modules support the following allowed algorithms in the Approved mode: • MD5 (Limited use) • 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. • Non-Approved RNG – 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 EX6000 or SRA EX7000 appliance. CAUTION: For a SonicWALL E-Class SRA EX6000 or SRA EX7000 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 are 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 ClearTrust 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 • Do not use clustering (High Availability). Clustering (HA) is not supported in FIPS mode. Page 5 SonicWALL, Inc. SRA EX6000 and SRA EX7000 Security Policy Version 1.2 Revision Date September 2, 2010 • 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 EX6000 and SRA EX7000 Security Policy Version 1.2 Revision Date September 2, 2010 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 SRA EX6000 and SRA EX7000 appliances 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 EX6000 and SRA EX7000 Security Policy Version 1.2 Revision Date September 2, 2010 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 modules provide 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. Page 8 SonicWALL, Inc. SRA EX6000 and SRA EX7000 Security Policy Version 1.2 Revision Date September 2, 2010 ! 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. 5. Ports and Interfaces The cryptographic modules provide the following physical ports and logical interfaces: Ports Type The X0 Ethernet interface provides Data In, Data Out, Ethernet Status Out and Control In. The cryptographic modules provide Ethernet interfaces. The X1 Ethernet interface provides Data In and Data Each Ethernet interface is [10/100/1000] auto-sensing Out. with an RJ- 45 connector. Each Ethernet interface includes LINK and ACT LEDs. The X2 Ethernet interface provides Data In and Data Out. It is not supported in the Approved mode of operation. The X3 Ethernet interface is not enabled and is reserved for future use. The X4-X5 (SRA EX7000 only) Ethernet interface is not enabled and is reserved for future use. Each USB interface shall not be used in the Approved USB mode of operation. The cryptographic modules provide 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 modules provide 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 modules provide 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 alarm condition. The LCD interface provides Status Out. LCD Screen The cryptographic modules provide 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 modules provide 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. Page 9 SonicWALL, Inc. SRA EX6000 and SRA EX7000 Security Policy Version 1.2 Revision Date September 2, 2010 Ports Type The power port provides Power In. Power The cryptographic modules provide power interfaces. 6. Identification and Authentication Policy Assumption of roles The cryptographic modules support 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 EX6000 and SRA EX7000 Security Policy Version 1.2 Revision Date September 2, 2010 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, 1 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 EX6000 and SRA EX7000 Security Policy Version 1.2 Revision Date September 2, 2010 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. 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 EX6000 and SRA EX7000 Security Policy Version 1.2 Revision Date September 2, 2010 Unauthenticated Services: The cryptographic modules support the following unauthenticated services, none of which disclose, modify or substitute CSP, use approved security functions, or otherwise affect the security of the cryptographic modules: • 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 or 2048 bit Externally or Plaintext Encrypted via TLS System private key private key used in the Internally session Zeroization TLS negotiation for web administration GUI. WorkPlace Site RSA 1024 or 2048 bit Externally or Plaintext Encrypted via TLS System TLS private key used in TLS Internally session Zeroization key(s) 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 1024. 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. Page 13 SonicWALL, Inc. SRA EX6000 and SRA EX7000 Security Policy Version 1.2 Revision Date September 2, 2010 Key / CSP Description/Usage Generated / Storage Entry/Output Destruction Derived 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 Encrypted Encrypted, except via System Passwords console Zeroization RNG seeding Seeding the Approved Internally Plaintext Not Applicable System material RNG Zeroization 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 Page 14 SonicWALL, Inc. SRA EX6000 and SRA EX7000 Security Policy Version 1.2 Revision Date September 2, 2010 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) X1 X AMC Private Key (Read/Write) Work Place Site Private Keys (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) X1 X Work Place Site Private Keys (Generate/Read/Write/Execute) SSH Private Key (Generate/Execute) X1 X Remote Assistance Work Place Site Private Keys (Execute) Zeroization Passwords(Destroy) AMC Private Key (Destroy) Work Place Site Private Keys (Destroy) SSH Private Key (Destroy) Firmware Integrity Shared Secret (Destroy) Keystore Password Encryption Shared Secret (Destroy) X 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) X SSH Private Key (Execute) TLS Shared Secret (Write/Execute) TLS Session Encryption Keys (Write/Execute) Page 15 SonicWALL, Inc. SRA EX6000 and SRA EX7000 Security Policy Version 1.2 Revision Date September 2, 2010 Roles Cryptographic Keys and Services CSPs Access Operation 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 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 or 2048. SSH public key RSA public key is used in Administration Stored in fixed disk as plaintext shell SSH negotiation. Key length is 1024. 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. Key length is 1024 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 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 16 SonicWALL, Inc. SRA EX6000 and SRA EX7000 Security Policy Version 1.2 Revision Date September 2, 2010 9. Security Rules The cryptographic modules’ design corresponds to the cryptographic modules’ security rules. This section documents the security rules enforced by the cryptographic modules to implement the security requirements of these FIPS 140-2 Level 2 modules. 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 • 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 Page 17 SonicWALL, Inc. SRA EX6000 and SRA EX7000 Security Policy Version 1.2 Revision Date September 2, 2010 b. For encryption and decryption • 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 and wiring (SRA EX7000 only) • Fan units, connectors and wiring • Non-Critical 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 Page 18 SonicWALL, Inc. SRA EX6000 and SRA EX7000 Security Policy Version 1.2 Revision Date September 2, 2010 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. 4. SNMPv2 is understood and shall be treated as clear text communication. Access to CSPs is not provided via this interface. 10. Physical Security Policy Physical Security Mechanisms The cryptographic modules include the following physical security mechanisms: • Production-grade components and production-grade opaque enclosure • Tamper evident material and seals • Protected vents Each module has three (3) tamper evident seals applied by the manufacturer. Figures 2 - 4 show the locations of the tamper evident seals. Operator Required Actions 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 See the SonicWALL Aventail Secure Tamper Evident Inspect tamper evident seals Remote Access Installation and Seals monthly. Administration Guide Version 10.5 for procedure. Figure 2: Tamper Seal #1 – Left Side Page 19 SonicWALL, Inc. SRA EX6000 and SRA EX7000 Security Policy Version 1.2 Revision Date September 2, 2010 Figure 3: Tamper Seal #2 - Bottom Cover Figure 4: Tamper Seal #3 - Expansion Bay 11. Mitigation of Other Attacks Policy The modules have not been designed to mitigate attacks outside the scope of FIPS 140-2. Page 20 SonicWALL, Inc. SRA EX6000 and SRA EX7000 Security Policy Version 1.2 Revision Date September 2, 2010 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 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 PKCS #12 Public-Key Cryptography Standards RADIUS Remote Authentication Dial-In Service RSA Rivest, Shamir, Adleman asymmetric algorithm SHA Secure Hash Algorithm SSH Secure Shell TDES Triple Data Encryption Standard VPN Virtual Private Network Page 21