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.

FIPS 140-2 specifies that a cryptographic module should be a set of hardware, software, firmware, or some combination that implements cryptographic functions or processes, including cryptographic algorithms and, optionally, key generation, and is contained within a defined cryptographic boundary. FIPS specifies certain crypto algorithms as secure, and it also identifies which algorithm should be used if a cryptographic module is to be called FIPS compliant. For more information on FIPS, see http:/​/​csrc.nist.gov/​.

About Roles and Services

Note	There are four levels of increased security defined in FIPS 140-2.

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.

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.

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.

The Common Criteria (CC) is a testing standard to verify that a product provides security functions that is 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 on CC, see Common Criterial Portal and CC evaluation and validation scheme.

To configure the controller into CC mode of operation, refer the Admin Guidance Document published under the Certified Product page of the Common Criterial Portal website .

After providing CC for the controller, the controller series name is listed in the Common Criterial Portal. Click the Security Documents tab to view the list of documented available for the controller.

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.

Cisco TrustSec enables organizations to secure their networks and services through identity-based access control to anyone, anywhere, anytime. The solution also offers data integrity and confidentiality services, policy-based governance, and centralized monitoring, troubleshooting, and reporting services. Cisco TrustSec can be combined with personalized, professional service offerings to simplify solution deployment and management, and is a foundational security component to Cisco Borderless Networks.

The Cisco TrustSec security architecture helps build secure networks by establishing domains of trusted network devices. Each device in the domain is authenticated by its peers. Communication on the links between the devices in the domain is secured with a combination of encryption, message integrity check, and data path replay protection mechanisms. Cisco TrustSec uses a device and user credentials acquired during authentication for classifying the packets by security groups (SGs), as they enter the network. This packet classification is maintained by tagging packets on ingress to the Cisco TrustSec network so that they can be correctly identified to apply security and other policy criteria along the data path. The tag, called the security group tag (SGT), allows the network to enforce the access control policy by enabling the end-point device to act upon the SGT to filter traffic. Note that the Cisco TrustSec security group tag is applied only when you enable AAA override on a WLAN.

One of the components of Cisco TrustSec architecture is the security group-based access control. In the security group-based access control component, access policies in the Cisco TrustSec domain are topology-independent, based on the roles (as indicated by the security group number) of source and destination devices rather than on network addresses. Individual packets are tagged with the security group number of the source.

The Cisco TrustSec solution is implemented across the following three distinct phases:

• Client classification at ingress by a centralized policy database (Cisco ISE) and assigning unique SGT to clients based on client identity attributes such as the role and so on.

• Propagation of IP-to-SGT binding to neighboring devices using the SGT Exchange Protocol (SXP) or inline tagging methods or both.

• Security Group Access Control List (SGACL) policy enforcement. Cisco AP is the enforcement point for central or local switching (central authentication).

• Enable Cisco TrustSec on Cisco WLC by entering this command:

  config cts enable

  Note	If you enable Cisco TrustSec, the SGACL is also enabled in the Cisco WLC. Also, you will need to manually enable inline tagging.

• Enable or disable the SXP on the controller by entering this command:

  config cts sxp {enable | disable}

• Configure the default password for MD5 authentication of SXP messages by entering this command:

  config cts sxp default password password

• Configure the IP address of the next-hop switch with which the controller is connected by entering this command:

  config cts sxp connection peer ip-address

• Configure the interval between connection attempts by entering this command:

  config cts sxp retry period time-in-seconds

• Remove an SXP connection by entering this command:

  config cts sxp connection delete ip-address

• See a summary of the SXP configuration by entering this command:

  show cts sxp summary

  The following is a sample output of this command:

  
  SXP State........................................ Enable
  SXP Mode......................................... Speaker
  Default Password................................. ****
  Default Source IP................................ 209.165.200.224
  Connection retry open period .................... 120
  

• See the list of SXP connections that are configured by entering this command:

  show cts sxp connections

  The following is a sample output of this command:

  
  Total num of SXP Connections..................... 1
  SXP State........................................ Enable
  Peer IP            Source IP           Connection Status
  ---------------    ---------------     -----------------
  209.165.200.229   209.165.200.224              On
  

• Establish connection between the controller and a Cisco Nexus 7000 Series switch by following either of these steps:

  • Enter the following commands:

    1. config cts sxp version sxp version 1 or 2 1

    2. config cts sxp disable

    3. config cts sxp enable

  • If SXP version 2 is used on the controller and version 1 is used on the Cisco Nexus 7000 Series switch, an amount of retry period is required to establish the connection. We recommend that you initially have less interval between connection attempts. The default is 120 seconds.