FIPS, CC, and UCAPL
This section contains the following subsections:
FIPS
Federal Information Processing Standard (FIPS) 140-2 is a security standard used to validate cryptographic modules. The cryptographic modules are produced by the private sector for use by the U.S. government and other regulated industries (such as financial and healthcare institutions) that collect, store, transfer, share and disseminate sensitive but unclassified (SBU) information.
Note |
Cisco TrustSec (CTS) is not supported when the controller is in FIPS mode. |
For more information about FIPS, see
https://www.cisco.com/c/en/us/solutions/industries/government/global-government-certifications/fips-140.html.FIPS Self-Tests
A cryptographic module must perform power-up self-tests and conditional self-tests to ensure that it is functional.
Power-up self-tests run automatically after the device powers up. A device goes into FIPS mode only after all self-tests are successfully completed. If any self-test fails, the device logs a system message and moves into an error state. Also, if the power-up self test fails, the device fails to boot.
Using a known-answer test (KAT), a cryptographic algorithm is run on data for which the correct output is already known, and then the calculated output is compared to the previously generated output. If the calculated output does not equal the known answer, the known-answer test fails.
Power-up self-tests include the following:
-
Software integrity
-
Algorithm tests
Conditional self-tests must be run when an applicable security function or operation is invoked. Unlike the power-up self-tests, conditional self-tests are executed each time their associated function is accessed.
The device uses a cryptographic algorithm known-answer test (KAT) to test FIPS mode for each FIPS 140-2-approved cryptographic function (encryption, decryption, authentication, and random number generation) implemented on the device. The device applies the algorithm to data for which the correct output is already known. It then compares the calculated output to the previously generated output. If the calculated output does not equal the known answer, the KAT fails.
Conditional self-tests run automatically when an applicable security function or operation is invoked. Unlike the power-up self-tests, conditional self-tests are executed each time their associated function is accessed.
Conditional self-tests include the following:
-
Pair-wise consistency test—This test is run when a public or private key-pair is generated.
-
Continuous random number generator test—This test is run when a random number is generated.
-
Bypass
-
Software load
Information About CC
Common Criteria (CC) is a testing standard to verify that a product provides security functions that are claimed by its developer. CC evaluation is against a created protection profile (PP) or security target (ST).
The four security levels in FIPS 140–2 do not map directly to specific CC EALs or CC functional requirements. For more information about CC, see Common Criteria Portal and CC evaluation and validation scheme.
To configure the controller into CC mode of operation, refer the Admin Guidance Document published on the Certified Product page of the Common Criteria Portal website.
After providing CC for the controller, the controller series name is listed in the Common Criteria Portal. Click the Security Documents tab to view the list of documented available for the controller.
Information About UCAPL
The US Department of Defense (DoD) Unified Capabilities Approved Product List (APL) certification process is the responsibility of the Defense Information Systems Agency (DISA) Unified Capabilities Certification Office (UCCO). Certifications are performed by approved distributed testing centers including the Joint Interoperability Test Command (JITC).
DoD customers can only purchase unified capabilities related equipment, both hardware and software, that has been certified. Certified equipment is listed on the DoD UC APL. UC APL certifications verify the system complies with and is configured consistent with the DISA Field Security Office (FSO) Security Technical Implementation Guides (STIG).
For more information about the UC APL process, see Defense Information System Agency.
Guidelines on UCAPL
-
In UCAPL web authentication login, multifactor authentication, which includes client (browser) certificate validation and user authentication, is performed; Certificate validation prior to user authentication is mandatory. Certificate validation is part of DTLS handshake, which is performed only once for a session till its lifetime (default session lifetime is 5 minutes). When a user tries to login again, certificate validation is not performed because the old session is not yet flushed and user authentication is not performed without certificate validation. For more information, see https://tools.ietf.org/html/rfc5246.
-
UCAPL certification requires a maximum of three unsuccessful login attempts to SSH. With some SSH clients, fourth attempts are also observed; however, controller does not accept the fourth attempt even if the credentials are correct.
Configuring FIPS (CLI)
Procedure
Step 1 |
Configure FIPS on the controller by entering this command: |
Step 2 |
View the FIPS configuration by entering this command:
|
Configuring CC (CLI)
Before you begin
FIPS must be enabled on the controller.
Procedure
Step 1 |
Configure FIPS on the controller by entering this command: |
Step 2 |
View the FIPS configuration by entering this command:
|
Configuring UCAPL (CLI)
Before you begin
FIPS and WLAN CC must be enabled on the controller.
Procedure
Step 1 |
Configure UCAPL on the controller by entering this command: |
Step 2 |
View the FIPS configuration by entering this command:
|