The TOE is comprised of both software and hardware. The model is comprised of the following: FP 4110, 4120, 4140, and 4150 and 9300. The software is comprised of the Adaptive Security Appliance software image Release 9.6.2, with ASDM 7.6, running on the security module and FXOS 2.0.1 running on Supervisor blade.
\r\nThe models that comprise the TOE have common hardware characteristics (for example, the same FXOS image runs on all the models 4100 series and 9300, and the same ASA image runs on the security module regardless of the platforms). These differing characteristics affect only non-TSF relevant functionality (such as throughput, processing speed, number and type of network connections supported, number of concurrent connections supported, and amount of storage) and therefore support security equivalency of the TOE in terms of hardware.
","evaluation_configuration":"\r\n\r\nThe Cisco Firepower 4100 and 9300 security appliances (TOE) are purpose-built, scalable platforms with firewall and VPN capabilities.
\r\nThe evaluated configuration consists of the following devices:
\r\n| \r\n TOE Configuration \r\n | \r\n\r\n Hardware Configuration \r\n | \r\n\r\n Software Version \r\n | \r\n
| \r\n FP 4110 \r\nFP 4120 \r\nFP 4140 \r\nFP 4150 \r\n\r\n | \r\n\r\n The Firepower 4100 chassis contains the following components: \r\n· Network module 1 with eight fixed SFP+ ports (1G and 10G connectivity), the management port, RJ-45 console port, Type A USB port, PID and S/N card, locator indicator, and power switch \r\n· Two network modules slots (network module 2 and network module 3) \r\n· Two (1+1) redundant power supply module slots \r\n· Six fan module slots \r\n· Two SSD bays \r\n | \r\n\r\n FXOS release 2.0.1 and ASA release 9.6.2 \r\n | \r\n
| \r\n FP 9300 \r\n\r\n | \r\n\r\n The Firepower 9300 chassis contains the following components: \r\n· Firepower 9300 Supervisor—Chassis supervisor module \r\n? Management port \r\n? RJ-45 console port \r\n? Type A USB port \r\n? Eight ports for 1 or 10 Gigabit Ethernet SFPs (fiber and copper) \r\n· Firepower 9300 Security Module—Up to three security modules \r\n? 800 GB of solid state storage per security blade (2 x 800 GB solid state drives running RAID1) \r\n· Firepower Network Module—Two single-wide network modules or one double-wide network module \r\n· Two power supply modules (AC or DC) \r\n· Four fan modules \r\n | \r\n\r\n FXOS release 2.0.1 and ASA release 9.6.2 \r\n | \r\n
| \r\n ASDM \r\n | \r\n\r\n Included on all ASA 9.6.2 \r\n | \r\n\r\n Release 7.6 \r\n | \r\n
The evaluation was carried out in accordance to the Common Criteria Evaluation and Validation Scheme (CCEVS) requirements and guidance. The evaluation demonstrated that the TOE meets the security requirements contained in the Security Target. The criteria against which the TOE was judged are described in the Common Criteria for Information Technology Security Evaluation, Version 3.1, Revision 4, September 2012. The evaluation methodology used by the evaluation team to conduct the evaluation is the Common Methodology for Information Technology Security Evaluation, Evaluation Methodology, Version 3.1, Revision 4, July 2012. The product, when delivered and configured as identified in the Cisco Preparative Procedures & Operational User Guide for Firepower 4100 and 9300, Version 1.0, June 27, 2017 and Cisco Adaptive Security Appliance (ASA) 9.6 Preparative Procedures & Operational User Guide for the Common Criteria Certified configuration, 1.0, June 27, 2017 documents, satisfies all of the security functional requirements stated in the Cisco Firepower 4100 and 9300 Security Appliances Security Target, Version 1.0, September 11, 2017. The project underwent CCEVS Validator review. The evaluation was completed in September 2017. Results of the evaluation can be found in the Common Criteria Evaluation and Validation Scheme Validation Report (report number CCEVS-VR-VID10775-2017) prepared by CCEVS.
","environmental_strengths":"\r\n\r\nThe logical boundaries of the Cisco Firepower 4100 and 9300 Security Appliances are realized in the security functions that it implements. Each of these security functions is summarized below.
\r\n\r\nThe TOE provides extensive auditing capabilities. The TOE can audit events related to cryptographic functionality, identification and authentication, and administrative actions. The TOE generates an audit record for each auditable event. The administrator configures auditable events, performs back-up operations, and manages audit data storage. The TOE provides the administrator with a circular audit trail or a configurable audit trail threshold to track the storage capacity of the audit trail. Audit logs are backed up over an encrypted channel to an external audit server.
\r\nCryptographic support:
\r\nThe TOE provides cryptography in support of other TOE security functionality. The TOE provides cryptography in support of secure connections using IPsec and TLS, and remote administrative management via SSHv2 (for ASA, SSH over IPsec), and TLS/HTTPS. The cryptographic random bit generators (RBGs) are seeded by an entropy noise source.
\r\nFull residual information protection:
\r\nThe TOE ensures that all information flows from the TOE do not contain residual information from previous traffic. Packets are padded with zeros. Residual data is never transmitted from the TOE.
\r\nIdentification and authentication:
\r\nThe TOE performs two types of authentication: device-level authentication of the remote device (VPN peers) and user authentication for the authorized administrator of the TOE. Device-level authentication allows the TOE to establish a secure channel with a trusted peer. The secure channel is established only after each device authenticates the other. Device-level authentication is performed via IKE/IPsec X509v3 certificate based authentication or pre-shared key methods.
\r\nThe TOE provides authentication services for administrative users wishing to connect to the TOEs secure CLI and GUI administrator interfaces. The TOE requires authorized administrators to authenticate prior to being granted access to any of the management functionality. The TOE can be configured to require a minimum password length of 15 characters as well as mandatory password complexity rules. The TOE also implements a lockout mechanism if the number of configured unsuccessful threshold has been exceeded.
\r\nThe TOE provides administrator authentication against a local user database. Password-based authentication can be performed on the serial console or SSH and HTTPS interfaces. The SSHv2 interface also supports authentication using SSH keys. The TOE optionally supports use of any RADIUS AAA server (part of the IT Environment) for authentication of administrative users attempting to connect to the TOE.
\r\nSecurity management:
\r\nThe TOE provides secure administrative services for management of general TOE configuration and the security functionality provided by the TOE. All TOE administration occurs either through a secure SSHv2 (for ASA, SSH over IPsec) or TLS/HTTPS session, or via a local console connection. The TOE provides the ability to securely manage all TOE administrative users; all identification and authentication; all audit functionality of the TOE; all TOE cryptographic functionality; the timestamps maintained by the TOE; TOE configuration file storage and retrieval, and the information flow control policies enforced by the TOE including encryption/decryption of information flows for VPNs. The TOE supports an “authorized administrator” role, which equates to any account authenticated to an administrative interface (CLI or GUI, but not VPN), and possessing sufficient privileges to perform security-relevant administrative actions.
\r\nWhen an administrative session is initially established, the TOE displays an administrator- configurable warning banner. This is used to provide any information deemed necessary by the administrator. After a configurable period of inactivity, administrative sessions will be terminated, requiring administrators to re-authenticate.
\r\nProtection of the TSF:
\r\nThe TOE protects against interference and tampering by untrusted subjects by implementing identification, authentication, and access controls to limit configuration to authorized administrators. The TOE prevents reading of cryptographic keys and passwords.
\r\nAdditionally the TOE is not a general-purpose operating system and access to the TOE memory space is restricted to only TOE functions.
\r\nThe TOE internally maintains the date and time. This date and time is used as the timestamp that is applied to audit records generated by the TOE. Administrators can update the TOE’s clock manually, or can configure the TOE to use NTP to synchronize the TOE’s clock with an external time source. Additionally, the TOE performs testing to verify correct operation of the appliance itself and that of the cryptographic module. Whenever any system failures occur within the TOE the TOE will cease operation.
\r\n\r\nWhen an administrative session is initially established, the TOE displays an administrator- configurable warning banner. This is used to provide any information deemed necessary by the administrator. After a configurable period of inactivity, administrator and VPN client sessions will be terminated, requiring re-authentication. The TOE also supports direct connections from VPN clients, and protects against threats related to those client connections. The TOE disconnects sessions that have been idle too long, and can be configured to deny sessions based on IP, time, and day, and to NAT external IPs of connecting VPN clients to internal network addresses.
\r\nTrusted path/channels:
\r\nThe TOE supports establishing trusted paths between itself and remote administrators using SSHv2 for CLI access (for ASA, SSH over IPsec), and TLS/HTTPS for GUI/ASDM access. The TOE supports use of TLS and/or IPsec for connections with remote syslog servers. The TOE can use IPsec to encrypt connections with remote authentication servers (e.g. RADIUS). The TOE can establish trusted paths of peer-to-peer VPN tunnels using IPsec, and VPN client tunnels using IPsec or TLS. Note that the VPN client is in the operational environment.
\r\n\r\nThe TOE provides stateful traffic firewall functionality including IP address-based filtering (for IPv4 and IPv6) to address the issues associated with unauthorized disclosure of information, inappropriate access to services, misuse of services, disruption or denial of services, and network-based reconnaissance. Address filtering can be configured to restrict the flow of network traffic between protected networks and other attached networks based on source and/or destination IP addresses. Port filtering can be configured to restrict the flow of network traffic between protected networks and other attached networks based on the originating (source) and/or receiving (destination) port (service). Stateful packet inspection is used to aid in the performance of packet flow through the TOE and to ensure that only packets are only forwarded when they’re part of a properly established session. The TOE supports protocols that can spawn additional sessions in accordance with the protocol RFCs where a new connection will be implicitly permitted when properly initiated by an explicitly permitted session. The File Transfer Protocol is an example of such a protocol, where a data connection is created as needed in response to an explicitly allowed command connection. System monitoring functionality includes the ability to generate audit messages for any explicitly defined (permitted or denied) traffic flow. TOE administrators have the ability to configure permitted and denied traffic flows, including adjusting the sequence in which flow control rules will be applied, and to apply rules to any network interface of the TOE.
\r\nThe TOE also provides packet filtering and secure IPsec tunneling. The tunnels can be established between two trusted VPN peers as well as between remote VPN clients and the TOE. More accurately, these tunnels are sets of security associations (SAs). The SAs define the protocols and algorithms to be applied to sensitive packets and specify the keying material to be used. SAs are unidirectional and are established per the ESP security protocol. An authorized administrator can define the traffic that needs to be protected via IPsec by configuring access lists (permit, deny, log) and applying these access lists to interfaces using crypto map set.
","features":[]}