Common Criteria Supplemental User Guide for Cisco Firepower NGIPS/NGIPSv 6.4 with FMC/FMCv 6.4 Version 0.2 July 19, 2021

Transcription

1 1 Common Criteria Supplemental User Guide for Cisco Firepower NGIPS/NGIPSv 6.4 with FMC/FMCv 6.4 Version 0.2 July 19, 2021

2 2 Prepared by: Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA USA

3 3 Table of Contents 1 Introduction Common Criteria (CC) Evaluated Configuration References Operational Environment Operational Environment Components Environmental Assumptions Before Installation Assurance Activity Configuration Logging into the Appliance Login to Web Interface Login to CLI Remotely Login to CLI Locally Logout Auditable Events Audit Messages Generated by Firepower Services Audit Messages Generated by Firepower Management Center Restrict Access and Enable CC Mode Configure Secure Connection with Audit Server Configure Access Control Policy Access Control Policy Access Control Rule Configure Security Intelligence Managing Intrusion Policies Create Intrusion Policy Viewing Intrusion Rules in an Intrusion Policy Intrusion Rule States Adding and Modifying Intrusion Event Thresholds Intrusion Rules Editor Intrusion Rules Import Configure Dynamic Rule State Global Rule Threshold Stateful Session Behaviors Verify Enabled Preprocessors... 79

4 Configure Anomaly Detection Portscan Detection Rate-Based Attack Prevention Specific Attacks Checksum Verification Passive vs Inline Management Functions View Audit Log Management of Intrusion Events Device Registration Custom Web Server Certificate User and Role Management Change Password Configure Time Synchronization Configure Login Banner Inactivity Timeout Setting Product Upgrade Self-Tests

5 5 1 Introduction The Cisco Firepower Next-Generation Intrusion Prevention System (NGIPS) combines both SNORT open source and proprietary technology. The system is used to filter and monitor all incoming and outgoing network traffic for security events and violations. All packets on the monitored network are scanned, decoded, preprocessed and compared against a set of access control and intrusion rules to determine whether inappropriate traffic, such as system attacks, is being passed over the network. The system then notifies a designated administrator of these attempts and/or blocks the malicious traffic. The system generates these alerts when deviations of the expected network behavior are detected and when there is a match to a known attack pattern. In addition, the system also provides real-time contextual awareness, advanced malware protection, and security intelligence for blocking malicious URLs and IP addresses. The Cisco NGIPS System is an integrated suite of network security and traffic management products, deployed either on purpose-built platforms or as a software solution. In a typical deployment, multiple traffic-sensing managed devices (i.e., sensors) installed on network segments monitor traffic for analysis and report to a managing Firepower Management Center (FMC). Deployed inline, devices can affect the flow of traffic. The Firepower Management Center provides a centralized management console with web interface that you can use to perform administrative, management, analysis, and reporting tasks. The devices have a limited web interface 1 that you can use to perform initial setup and basic analysis and configuration tasks. You can also use a CLI on the devices to perform setup, basic analysis, and configuration tasks. This document is a supplement to the Cisco administrative guidance, which is comprised of the installation and administration documents identified in section 1.3. This document supplements those manuals by specifying how to install, configure and operate this product in the Common Criteria evaluated configuration. This document is referred to as the operational user guide in the Network Device collaborative Protection Profile (NDcPP) and meets all the required guidance assurance activities from the NDcPP. 1 The virtual device appliance (NGIPSv) does not have any web interface.

6 6 1.1 Common Criteria (CC) Evaluated Configuration The following sections describe the scope of evaluation, required configuration, assumptions, and operational environment that the system must be in to ensure a secure deployment. To ensure the system is in the CC evaluated configuration, the users must do the following: Configure all the required system settings and default policy as documented in this guide. Disable all the features that would violate the NDcPP and IPScEP requirements or would make the system vulnerable to attacks as documented in this guide. Ensure all the environmental assumptions in section 2 are met. Ensure that your operational environment is consistent with section 2. Follow the guidance in this document. Accessing the shell should be limited to authorized administrators for pre-operational setup (for example, Security Technical Implementation Guide (STIG) compliance testing), for troubleshooting, or regular maintenance. In addition, the PROTECTION license must be purchased and activated to use all the IPS features to meet the IPS Extended Package requirements. Optionally, to use the malware protection feature MALWARE license is required and to use URL filtering capability URL FILTERING license is required.

7 7 Scope of Evaluation The list below identifies features or protocols that are not evaluated and the rationale why. Note that this does not mean the features cannot be used in the evaluated configuration. It means that the features were not evaluated and/or validated by an independent third party and the functional correctness of the implementation is vendor assertion. The following features and protocols are not evaluated: VPN Gateway with IPsec This feature is not evaluated as part of the evaluation. The VPN Gateway Extended Package is not claimed in this evaluation. External Authentication Servers The NDcPP and IPScEP does not require external authentication servers. However, if they are used, the connection between the TOE and server must be protected by the approved security protocol. Shell Access The shell access is only allowed for pre-operational installation, configuration, and post-operational maintenance and trouble shooting. Timeout Exemption Option The use of the Exempt from Browser Session Timeout setting is not permitted. This allows a user to be exempted from the inactivity timeout feature. REST API This feature is not evaluated as part of the evaluation. REST API relies on HTTPS as the underlying communication protocol and can be used to build a management interface. This feature is not tested and is out of scope. Modbus and DNP3 SCADA preprocessors These features are not evaluated as part of the evaluation. These features are related to detection of traffic anomalies, but they are beyond the scope of testing defined in IPScEP. HTTP and Telnet for management purposes HTTP and Telnet pass credentials in clear text and are disabled in the evaluated system. SNMPv3 for management purposes SNMPv3 is supported but is not permitted for management only for sending SNMP traps for alerting. Any features not associated with SFRs in claimed NDcPP and and IPScEP NDcPP and IPScEP forbids adding additional requirements to the Security Target (ST). If additional functionalities are mentioned in the ST, it is for completeness only.

8 8 1.2 References TOE (Target of Evaluation) References Cisco NGIPS System 2 running Version 6.4 with FMC 6.4 Table 1: TOE Series and Models Firepower Management Center (FMC) FMC1000-K9 FMC2500-K9 FMC4500-K9 FMC1600-K9 FMC2600-K9 FMC4600-K9; and FMCv running on ESXi 6.0 or 6.5 on the Unified Computing System (UCS) UCSB-B200-M4, UCSC-C220-M4S, UCSC-C240-M4SX, UCSC- C240-M4L, UCSB-B200-M5, UCSC-C220-M5, UCSC-C240-M5, UCS-E160S-M3 and UCS- E180D-M3 Firepower IPS/IDS Sensor (NGIPS) Cisco Firepower 8000 Series Appliances Cisco Firepower 8350 Cisco Firepower 8360 Cisco Firepower 8370 Cisco Firepower 8390 Firepower IPS/IDS Sensor (NGIPS) Cisco Firepower AMP Appliances Cisco Firepower AMP 8350 Cisco Firepower AMP 8360 Cisco Firepower AMP 8370 Cisco Firepower AMP 8390 Cisco Firepower NGIPS for VMware 3 (NGIPSv) NGIPSv running on ESXi 6.0 or 6.5 on the Unified Computing System (UCS) UCSB-B200- M4, UCSC-C220-M4S, UCSC-C240-M4SX, UCSC-C240-M4L, UCSB-B200-M5, UCSC- C220-M5, UCSC-C240-M5, UCS-E160S-M3 and UCS-E180D-M3. 2 In the evaluated configuration, the TOE must comprise of at least one FMC and one or more devices all running version Hereinafter referred to as NGIPSv

9 9 Documentation References The Cisco Firepower System documentation set includes online help and PDF files. The following product guidance documents are provided online or by request: Cisco Firepower 7000 and 8000 Series Installation Guide, Version 6.x, updated: August 25, html Cisco Firepower Release Notes, Version , , , , , , , and , updated August 18, x.html Firepower Management Center Configuration Guide, Version 6.4, updated August 3, 2020 Cisco Firepower NGIPSv Quick Start Guide for VMware, updated August 16, Cisco Common Criteria Supplemental User Guide [This Document] Online help can be accessed in two ways: By selecting Product Support > Select a Product Search for the Product The most up-to-date versions of the documentation can be accessed on the Cisco Support web site (

10 10 2 Operational Environment This section describes the components in the environment and assumptions made about the environment. 2.1 Operational Environment Components The system can be configured to rely on and utilize a number of other components in its operational environment. Management Workstation (Required) The system supports Command Line Interface (CLI) and web access and as such an administrator would need a terminal emulator or SSH client (supporting SSHv2) or web browser (supporting HTTPS) to utilize those administrative interfaces. NOTE! The management network should be physically or logically separated (e.g., VLANs) from the monitored network. Audit server (Required) The system can be configured to deliver audit records to an external log server. NOTE! It is recommended that the audit server is physically or logically separated (e.g., VLANs) from the monitored network. It can be on the same trusted internal network as the management network. Authentication servers The system can be configured to utilize external authentication servers. WARNING! This use of external authentication server is not allowed in the evaluated configuration unless the channel is securely protected either logically (e.g., VLAN) or physically (e.g., dedicated connection). Certificate Authority (CA) server The system can be configured to import X.509v3 certificates from a CA, e.g., for TLS connection to syslog server. NTP server The system can be configured to obtain time from a trusted time source. DNS server The system supports domain name service in the network.

11 Environmental Assumptions The assumptions state the specific conditions that are expected to be met by the operational environment and administrators. Table 2: Operational Environment Security Measures Environment Security Objective OE.PHYSICAL OE.NO_GENERAL_PURPOSE OE.NO_THRU_TRAFFIC_P ROTECTION Operational Environment Security Objective Definition Physical security, commensurate with the value of the TOE and the data it contains, is provided by the environment. There are no general-purpose computing capabilities (e.g., compilers or user applications) available on the TOE, other than those services necessary for the operation, administration and support of the TOE. The TOE does not provide any protection of traffic that traverses it. It is assumed that protection of this traffic will be covered by other security and assurance measures in the operational environment. Administrator Responsibility Administrators must ensure the system is installed and maintained within a secure physical location. This can include a secured building with key card access or within the physical control of an authorized administrator in a mobile environment. Administrators must not add any generalpurpose computing capabilities (e.g., compilers or user applications) to the system. Administrators must configure the security devices in the Operation environment of the TOE to secure the network. OE.TRUSTED_ADMIN OE.UPDATES OE.ADMIN_CREDENTIALS_ SECURE TOE Administrators are trusted to follow and apply all guidance documentation in a trusted manner. The TOE firmware and software is updated by an administrator on a regular basis in response to the release of product updates due to known vulnerabilities. The administrator s credentials (private key) used to access the TOE must be protected on any other platform on which they reside. Administrators must be properly trained in the usage and proper operation of the system and all the enabled functionality. These administrators must follow the provided guidance. Administrators must regularly update the system to address any known vulnerabilities. Administrators must protect their access credentials where ever they may be.

12 12 Environment Security Objective OE.COMPONENTS_RUNN ING Operational Environment Security Objective Definition For distributed TOEs the Security Administrator ensures that the availability of every TOE component is checked as appropriate to reduce the risk of an undetected attack on (or failure of) one or more TOE components. The Security Administrator also ensures that it is checked as appropriate for every TOE component that the audit functionality is running properly. Administrator Responsibility For distributed TOEs it is assumed that the availability of all TOE components is checked as appropriate to reduce the risk of an undetected attack on (or failure of) one or more TOE components. It is also assumed that in addition to the availability of all components it is also checked as appropriate that the audit functionality is running properly on all TOE components. OE.RESIDUAL_INFORMA TION The Security Administrator ensures that there is no unauthorized access possible for sensitive residual information (e.g. cryptographic keys, keying material, PINs, passwords etc.) on networking equipment when the equipment is discarded or removed from its operational environment. For vnds, this applies when the physical platform on which the VM runs is removed from its operational environment. The Administrator must ensure that there is no unauthorized access possible for sensitive residual information (e.g. cryptographic keys, keying material, PINs, passwords etc.) on networking equipment when the equipment is discarded or removed from its operational environment.

13 13 Environment Security Objective OE.VM_CONFIGURATION OE.CONNECTIONS Operational Environment Security Objective Definition For vnds, the Security Administrator ensures that the VS and VMs are configured to reduce the attack surface of VMs as much as possible while supporting ND functionality (e.g., remove unnecessary virtual hardware, turn off unused inter- VM communications mechanisms), and correctly implement ND functionality (e.g., ensure virtual networking is properly configured to support network traffic, management channels, and audit reporting). The VS should be operated in a manner that reduces the likelihood that vnd operations are adversely affected by virtualization features such as cloning, save/restore, suspend/resume, and live migration. If possible, the VS should be configured to make use of features that leverage the VS s privileged position to provide additional security functionality. Such features could include malware detection through VM introspection, measured VM boot, or VM snapshot for forensic analysis. TOE is connected to distinct networks in a manner that ensures that the TOE security policies will be enforced on all applicable network traffic flowing among the attached networks. Administrator Responsibility The Administrator ensures that the attack surface of the VMs is reduced to its minimum. All the virtual networking, management channels and audit reporting that are not essential to the ND functionality are eliminated. It is assumed that the TOE is connected to distinct networks in a manner that ensures that the TOE security policies will be enforced on all applicable network traffic flowing among the attached networks. Note: The TOE contains SSD storage media in all hardware appliances and could also contain SSD storage on an NGIPSv and FMCv (the underlying Cisco UCS server hardware supports SSD storage options). SSD storage devices use wear-leveling that could result in blocks of residual data remaining when the SSD marks worn blocks as inactive. When these TOE components are being decommissioned, TOE administrators should follow their own organizational security policies and guidelines for destruction of sensitive data on wear-leveling SSD storage media.

14 14 3 Before Installation Before you install your appliance, Cisco highly recommends that the users must consider the following: Locate the Cisco Firepower System appliance in a lockable rack within a secure location that prevents access by unauthorized personnel. Allow only trained and qualified personnel to install, replace, administer, or service the Cisco appliance. Always connect the management interface to a secure internal management network that is protected from unauthorized access. This management interface is separate from the data interface described in the section Passive vs Inline. Identify the specific management workstation IP addresses that can be allowed to access appliances. Restrict access to the appliance to only those specific hosts using the Access Lists feature. To safeguard the FMC, user must deploy the FMC on a protected internal network. Although the FMC is configured to have only the necessary services and ports available, user must make sure that attacks cannot reach it from outside the access control. Connect the management interface of managed devices to the same protect internal network as the FMC. This allows the administrators to securely control the device from the FMC and aggregate the event data generated on the managed device s network segment. By default, several ports are open to allow the system to take advantage of additional features and functionality. The following table lists these ports. Note that DHCP on ports 67 and 68 is disabled by default. Ports Description Protoco Direction Open the port to l 22 SSH TCP Bidirectional Allow a secure remote connection to the appliance. 25 SMTP TCP Outbound Send notices and alerts from the appliance. 53 DNS TCP Outbound Use DNS. 67, 68 DHCP UDP Outbound Use DHCP. Disabled by default. 161, 162 SNMP UDP Bidirectional (161); Outbound (162) Provide access if you enabled SNMP polling (inbound) and SNMP traps (outbound). 443 HTTPS TCP Bidirectional Allow a secure remote connection to the appliance. Required Download software updates. 514 SYSLOG UDP Outbound Send alerts to a remote syslog server. The remote syslog server must allow port 6514 to be opened TLS TCP Bidirectional Allow for device management. Required

15 15 Audience This document is written for administrators configuring the Cisco Firepower system running software version 6.4. This document assumes you are familiar with networks and network terminology, that you are a trusted individual, and that you are trained to use the Internet and its associated terms and applications.

16 16 4 Assurance Activity Configuration This section has the required guidance and settings as specified in the NDcPP and IPScEP. 4.1 Logging into the Appliance Login to Web Interface The FMC has a web interface that administrators can use to perform administrative, management, and analysis tasks. The WebUI (GUI) is only available on FMC, NGIPS does not have its own GUI and is managed via FMC. Administrators can access the web interface by logging into the appliance using a web browser. The following table lists web browser compatibility. Browser Firefox 52.0 and later Google Chrome 57 and later Required Enabled Options and Settings JavaScript, cookies, Transport Layer Security (TLS) v1.1 and 1.2 JavaScript, cookies Note: The Chrome browser does not cache static content, such as images, CSS, or Javascript, with the system-provided self-signed certificate. This may cause the system to redownload static content when you refresh. To avoid this, add a self-signed certificate to the trust store of the browser/os or use another web browser. In addition, for managed devices only, a CLI is provided to manage the devices. This interface provides only a subset of the operations provided by the web interface. It is highly recommended that the users use the web interface over the CLI. All appliances, regardless of series or models, can access the shell bash (different from CLI) but this will remove the appliances from the evaluated configuration. If you are the first administrator to log into a Firepower appliance (physical or virtual) after it is installed, you must log in using the factory-default administrative (admin) account to complete the initial setup process, including changing the default password. The default password for Firepower Services and FMC is Admin123. By default, Firepower administrative sessions will automatically timeout after 60 minutes of inactivity. 1. Direct your web browser to where hostname corresponds to the host name of the appliance. You can also use the IP address of the appliance. The Login page appears.

17 17 NOTE! Observe the login banner under the Cisco Firepower logo. 2. In the Username and Password fields, type your username and password. NOTE! Observe the password is not displayed. 3. Click Log In. The default start page appears if the authentication is successful. If authentication fails, the following error message is displayed: Audit Record: Login to CLI Remotely 1. Direct an SSHv2 connection to the appliance at hostname, where hostname corresponds to the host name of the appliance. You can also use the IP address of the appliance. The login in: command prompt appears. 2. Type your username and press Enter. The login banner and Password: prompt appear.

18 18 3. Type your password and press Enter. NOTE! Observe the password is not displayed. The standard command prompt appears if the authentication is successful. If authentication fails, the following error message is displayed: Access denied Audit Record: Note: Search for sshd:session Login to CLI Locally 1. Use the serial or console connection to the appliance. The login banner and <hostname> login: prompt appear. 2. Type your username and press Enter. The Password: prompt appears. 3. Type your password and press Enter.

19 19 NOTE! Observe the password is not displayed. The standard command prompt appears if the authentication is successful. If authentication fails, the following error message is displayed: Login incorrect Audit Record: Note: Search for login:session Logout 1. For web session, from the drop-down list under your username, select Log Out. 2. Close the web browser. 3. For CLI, type the command exit. IMPORTANT! For security purpose, always logout as instructed above when you are finished using the management interface. Do NOT rely solely on the inactivity timeout feature. Audit Record:

20 Auditable Events The appliances that are part of the Cisco Firepower NGIPS System generate an audit record for each user interaction with the web interface, and also record system status messages in the system log. For the CLI, the appliance also generates an audit record for every command executed. Each appliance generates an audit event for each user interaction with the web interface and CLI command executed. Each event includes at least a timestamp, the user name of the user whose action generated the event, a source IP, and text describing the event. The common fields are described in the table below. The appliance includes an internal log database implementation that can be used to store and review audit records locally. However, the internal log only stores a default of 100,000 entries in the local database (to configure the size, go to System > Configuration > Database, and click on Audit Event Database ). When the audit log is full, the oldest audit records are overwritten by the newest audit records. In addition, the appliance also includes a local syslog storage in /var/log/messages. Similar to the audit log, when the syslog is full, the oldest syslogs messages are overwritten by the newest one. For audit log, the events are stored in partitioned event tables. The TOE will prune (i.e., delete) the oldest partition whenever the oldest partition can be pruned without dropping the number of events count below the configured event limit. Note this limit defaults to 10,000 if you set it any lower. For example, if you set the limit to 10,000 events, the events count may need to exceed 15,000 events before the oldest partition can be deleted. For syslog, the logs are stored in /var/log/messages and are rotated daily or when the log file size exceeds 25 MB. After the maximum number of backlog files is reached, the oldest is deleted and the numbers on the other backlogs file are incremented. Web UI Field Description Time Time and date that the appliance generated the audit record. User User name of the user that triggered the audit event. Subsystem Menu path the user followed to generate the audit record. For example, System > Monitoring > Audit is the menu path to view the audit log. Message In a few cases where a menu path is not relevant, the Subsystem field displays only the event type. For example, Login classifies user login attempts or Command Line classifies a command executed. Action the user performed. For example, Page View signifies that the user simply viewed the page indicated in the Subsystem, while Save means that the user clicked the Save button on the page. If the Subsystem field is Command Line, the Message field will show the command executed. Source IP Changes made to the Cisco 3D System appear with a compare icon ( click to see a summary of the changes. IP address of the host used by the user. ) that you can CLI

21 21 Field Time Event Type Subsystem Actor Message Result Source IP Destination IP Description Time and date that the appliance generated the audit record. The type of action. Command Line User name of the user that executed the command. The command that was executed. Success or Failure IP address of the host used by the user. IP address of the appliance. Syslog

22 22 Field Date Time Subsystem Message Description Date that the appliance generated the audit record. Time that the appliance generated the audit record. This identifies the subsystem, process, or daemon that generates the audit record. This information is sometime included as part of the Message field. Identify the event type, user name (if applicable), outcome (if applicable), and IP address (if applicable). For example, [SSH session establishment and termination] Mar :49:30 FMCv sshd[20605]: pam_unix(sshd:session): session opened for user admin by (uid=0) Mar :10:04 FMCv sshd[7456]: Accepted keyboard-interactive/pam for admin from port ssh2 Mar :49:42 FMCv sshd[20605]: pam_unix(sshd:session): session closed for user admin [Trying to connect with SSHv1 only (SSH failure)] Mar :26:19 FMCv sshd[15102]: Did not receive identification string from [Trying to connect with diffie-hellman-group1-sha1 only (SSH failure)] May :15:49 FMCv sshd[2775]: fatal: Unable to negotiate with : no matching key exchange method found. Their offer: diffie-hellmangroup1-sha1 [preauth] [SSH rekey event audit] Jul 28 17:34:55 NGIPSv sshd[31989]: Outbound-ReKey for :50244 NOTE: Filter system in the syslog. [TLS session establishment and termination] Jul 26 00:20:20 FMC syslog-ng[18245]: Syslog connection established; fd='15', server='af_inet( :6514)', local='af_inet( :0)' NOTE: Filter syslog-ng in the syslog. [Trying to connect with mismatched ciphersuites (TLS failure)] Jul 25 23:13:20 NGIPS syslog-ng[22691]: SSL error while reading stream; tls_error='ssl routines:ssl3_get_client_hello:no shared cipher' [Unable to determine revocation status (X509 failure)] Feb 22 18:42:00 amp7150 syslog-ng[21468]: X509 Certificate Validation; depth='0', ok='0', errnum='3', error='unable to get certificate CRL' [System shutdown] Jul :49:10 FMCv shutdown[18868]: shutting down for system reboot [System startup] Jul :49:10 FMCv pmmon Crypto Self Tests Succeed (0) Jul :49:11 FMCv pmmon Starting the Process Manager...

23 23 Message [Handshake failure] Jul 3 15:22:50 fs750 syslog-ng[9535]: SSL error while writing stream; tls_error='ssl routines:ssl23_get_server_hello:sslv3 alert handshake failure' [Decryption filed or bad record MAC] Jul 3 15:32:50 fs750 syslog-ng[12688]: SSL error while writing stream; tls_error='ssl routines:ssl3_get_record:decryption failed or bad record mac' [Digest check failed] Jul 3 15:32:03 fs750 syslog-ng[12439]: SSL error while writing stream; tls_error='ssl routines:ssl3_get_finished:digest check failed' [Wrong SSL version] Jul 3 15:29:16 fs750 syslog-ng[11102]: SSL error while writing stream; tls_error='ssl routines:ssl3_get_server_hello:wrong ssl version' [Unknown cipher returned] Jul 3 15:28:38 fs750 syslog-ng[10210]: SSL error while writing stream; tls_error='ssl routines:ssl3_get_server_hello:unknown cipher returned' [bad signature] Jul 3 15:29:53 fs750 syslog-ng[11362]: SSL error while writing stream; tls_error='rsa routines:rsa_private_encrypt:bad signature' [decrypt error] Jul 3 15:34:51 fs750 syslog-ng[13251]: SSL error while writing stream; tls_error='ssl routines:ssl3_read_bytes:tlsv1 alert decrypt error' [Certificate Subject mismatch] [Certificate Expired] Jul 3 16:42:38 fs750 syslog-ng[29762]: Certificate validation failed; subject= address=server-rsa-rsa-expired@example.com, CN=test.example.com, O=Cisco, L=RTP, ST=NC, C=US, issuer= address=subsubca-rsarsa@example.com, CN=Example RSA Sub Sub CA, O=Cisco, L=RTP, ST=NC, C=US, error= certificate has expired, depth= 0 [Certificate Revoked] Jun 29 21:45:03 fs750 syslog-ng[23414]: Certificate validation failed; subject=' address=subca-rsa-rsa@example.com, CN=Example RSA Sub CA, O=Cisco, L=RTP, ST=NC, C=US, issuer='cn=example RSA Root CA, address=rootca-rsa@example.com, O=Cisco, L=RTP, ST=NC, C=US, error='certificate revoked', depth='2' [CRL is not yet valid] Jun 29 21:44:03 fs750 syslog-ng[23414]: Certificate validation failed; subject=' address=server-rsa-rsa@example.com, CN=test.example.com, O=Cisco, L=RTP, ST=NC, C=US, issuer=' address=subsubca-rsarsa@example.com, CN=Example RSA Sub Sub CA, O=Cisco, L=RTP, ST=NC, C=US, error='crl is not yet valid', depth='0'

24 24 Message [Establishing a Syslog Connection] Jan 26 00:21:41 fs750 syslog-ng[31597]: Syslog connection established; fd='15', server='af_inet( :6514)', local='af_inet( :0)' [Terminating a Syslog Connection] Jan 26 00:20:41 fs750 syslog-ng[31597]: Syslog connection broken; fd='15', server='af_inet( :6514)', time_reopen='60' [Failures of a Syslog Connection] Jan 26 00:20:41 fs750 syslog-ng[31597]: Syslog connection broken; fd='15', server='af_inet( :6514)', time_reopen='60' Examples of audit log events for web interface and CLI:

25 25 Samples of audit messages viewable via the FMC WebUI are shown in screenshots throughout this document in sections describing configuration actions relevant to the auditable actions. Samples textbased audit messages, as would be seen on a syslog server, are listed in a table at the end of this section. The FMC WebUI audit log screenshots are presented in this document in the format shown here: Audit Record: Actual audit record screenshot Audit Record Syntax: <date><time><user><message/action><result of action><source IP> CLI Audit Log Syntax: <date><time><type><subsystem><user><message><result><source IP><destination IP> The connection and intrusion events (hereafter, referred to as events) are generated by the log operation in the rule. The events are default to 100,000 entries size each (200,000 total). However, the internal database stores a maximum of 10,000,000 entries (depending on FMC models) and a minimum of 10,000 entries in the local database (to configure the size, go to System > Configuration > Database, and click on

26 26 Intrusion Event Database or Connection Database ). When the events log is full, the oldest events are overwritten by the newest events. The following information is associated with each event in Table View mode: Events Field Date Access Control Rule Action Initiator IP Responder IP Source Port/ ICMP Type Destination Port/ ICMP Code Protocol Ingress Interface Egress Interface Description Time and date that the appliance generated the event record. The access control rule that triggered the event. The configured action of the rule. The source IP address of the packet that triggered the event. The destination IP address of the packet that triggered the event. The source port (for TCP and UDP) or ICMP type for IP of the packet that triggered the event. The destination port (for TCP and UDP) or ICMP code for IP of the packet that triggered the event. The protocol of the packet that triggered the event. The incoming interface of the packet. The outgoing interface of the packet. Examples of events for access control rules: Examples of connection events: Examples of intrusion events:

27 Audit Messages Generated by Firepower Services SFR Auditable Event Audit Messages Generated by Firepower Services FAU_GEN.1 FCO_CPC_EXT.1 FCS_HTTPS_EXT.1 FCS_SSHS_EXT.1 FCS_TLSC_EXT.2 FCS_TLSS_EXT.1 FIA_AFL.1 Start up and shutdown of audit functions Enabling communications between a pair of components. Disabling communications between a pair of components. Failure to establish an HTTPS session. Failure to establish an SSH session Successful SSH rekey Failure to establish an TLS Session Failure to establish an TLS Session Unsuccessful login attempts limit is met or exceeded. Start Up {date-time} {hostname} SF-IMS[9917]: [9917] init script:system [INFO] pmmon Starting the Process Manager... Shutdown {date-time} {hostname} shutdown[20717]: shutting down for system reboot Enabling {date-time} {hostname} SF-IMS[10512]: [7308] sftunneld:sf_ssl [INFO] Peer {ip-address} registration is complete remotely Disabling {date-time} {hostname} SF-IMS[10470]: [10511] sftunneld:sf_connections [INFO] <<<<<<<<<<<<<<<<<<<<<< ShutDownPeer fmcv >>>>>>>>>>>>>>>>>>>>>>>> {date-time} {hostname} sshd[16626]: error: PAM: Authentication failure for {username} from {hostname} {date-time} {hostname} sshd[27611]: Unable to negotiate with {ip-address} port 58748: no matching key exchange method found. Their offer: {key-exchange-method},ext-info-c [preauth] {date-time} {hostname} sshd[27736]: Outbound-ReKey for {ip-address}:37100 Syslog FIA_PMG_EXT.1 Resetting Password time: {date-time} {date-time} {hostname} syslog-ng[20192]: SSL error while writing stream; tls_error='ssl routines:ssl23_get_server_hello:sslv3 alert handshake failure' Distributed TOE Communication {date-time} {hostname} SF-IMS[6423]: [10802] sftunneld:sf_ssl [ERROR] Connect:SSL handshake failed Distributed TOE Communication {date-time} {hostname} SF-IMS[6423]: [11592] sftunneld:sf_ssl [ERROR] Accept:SSL handshake failed {date-time} {hostname} sshd[28533]: pam_tally(sshd:auth): user {username} (1000) tally 4, deny 3 {date-time} {hostname} sshd[28533]: Failed password for {username} from {ip-address} port ssh2 event_type: Default Action

28 28 SFR Auditable Event Audit Messages Generated by Firepower Services FIA_UIA_EXT.1 FIA_UAU_EXT.2 FIA_X509_EXT.1/ITT FIA_X509_EXT.1/Rev All use of the identification and authentication mechanism. All use of the identification and authentication mechanism. Unsuccessful attempt to validate a certificate subsystem: Command Line actor: {username} message: Password Update successful result: Success action_source_ip: {ip-address} action_destination_ip: Default Target IP SSH {date-time} {hostname} sshd[27641]: Accepted keyboardinteractive/pam for {username} from {ip-address} port ssh2 {date-time} {hostname} sshd[16626]: error: PAM: Authentication failure for {username} from {hostname} Console {date-time} {hostname} login[1501]: pam_unix(login:session): session opened for user {username} by LOGIN(uid=0) {date-time} {hostname} login[4410]: pam_unix(login:auth): authentication failure; logname=login uid=0 euid=0 tty=/dev/ttys1 ruser= rhost= user={username} See FIA_UIA_EXT.1 {date-time} {hostname} syslog-ng[17117]: Certificate validation failed; subject='title={uuid}, address={ addr}, CN={CN}, O={organization}, L={location}, ST={state}, C={country}', issuer='o={organization}\, Inc, CN={uuid} + OU=Intrusion Management System + title=internalca', error='subject issuer mismatch', depth='0' Trust Anchor Addition: <date> <time> <host> % SF-IMS [111008]: User 'enable_1' executed the 'crypto ca trustpoint rootca-rsa-no-revocation' command. <date> <time> <host> % SF-IMS [111010]: User 'enable_1', running 'N/A' from IP , executed 'crypto ca trustpoint rootca-rsa-no-revocation' <date> <time> <host> % SF-IMS [111008]: User 'enable_1' executed the 'crypto ca authenticate rootca-rsa-no-revocation nointeractive' command. <date> <time> <host> % SF-IMS [111010]: User 'enable_1', running 'N/A' from IP , executed 'crypto ca authenticate rootca-rsa-no-revocation nointeractive'

29 29 SFR Auditable Event Audit Messages Generated by Firepower Services FMT_MOF.1/ ManualUpdate FMT_SMF.1 Any attempt to initiate a manual update All management activities of TSF data. <date> <time> <host> % SF-IMS [111008]: User 'enable_1' executed the 'crypto ca enroll rootca-rsa-no-revocation noconfirm' command. Trust Anchor Deletion: <date> <time> <host> % SF-IMS [111008]: User 'enable_1' executed the 'no crypto ca trustpoint rootca-rsa-no-revocation noconfirm' command. <date> <time> <host> % SF-IMS [111010]: User 'enable_1', running 'N/A' from IP , executed 'no crypto ca trustpoint rootca-rsa-no-revocation noconfirm' {date-time} {hostname} SF-IMS[31925]: [31925] Sourcefire_3D_Device_S3_Patch :000_start/100_start_messages.sh [INFO] Upgrade starting {date-time} {hostname} SF-IMS[6447]: [6447] Sourcefire_3D_Device_S3_Patch :999_finish/999_z_complete_upgrade_message.sh [INFO] Upgrade complete Import Cert and Private Key time: {date-time} event_type: Default Action subsystem: Command Line actor: {username} message: Executed root-view- configure audit_cert import result: Success action_source_ip: {ip-address} action_destination_ip : Default Target IP Delete Cert and Private Key time: {date-time} event_type: Default Action subsystem: Command Line actor: {username} message: Executed root-view- configure audit_cert delete result: Success action_source_ip: {ip-address} action_destination_ip: Default Target IP Add User time: {date-time} event_type: Default Action subsystem: Command Line

30 30 SFR Auditable Event Audit Messages Generated by Firepower Services FPT_TUD_EXT.1 FPT_STM_EXT.1 Initiation of update; result of the update attempt (success or failure) Discontinuous changes to time - either Administrator actuated or changed via an automated process. (Note that no continuous changes to actor: {username} message: Executed root-view- configure user add audit config result: Success action_source_ip: {ip-address} action_destination_ip: Default Target IP Edit User/Role time: {date-time} event_type: Default Action subsystem: Command Line actor: {username} message: Executed configure- user {username} result: Success action_source_ip: {ip-address} action_destination_ip: Default Target IP Configure Login Banner {date-time} {username} Devices > Platform Settings > Login Banner > Modified: {login-banner-text} Save {ip-address} Configure Remote/Local Timeout time: {date-time} event_type: Browser/Shell timeout changed subsystem: Shell Timeout actor: Default User message: Browser/Shell timeout changed result: Success action_source_ip: {ip-address} action_destination_ip: Default Target IP {date-time} {hostname} SF-IMS[31925]: [31925] Sourcefire_3D_Device_S3_Patch :000_start/100_start_messages.sh [INFO] Upgrade starting {date-time} {hostname} SF-IMS[6447]: [6447] Sourcefire_3D_Device_S3_Patch :999_finish/999_z_complete_upgrade_message.sh [INFO] Upgrade complete {date-time} {hostname} SF-IMS[18755]: ntpd:cmos [INFO] Updated hardware clock to '{date-time-year} {offset} seconds {date-time} {hostname} ntpd[19557]: ntpd 4.2.8p11@ o {date-time} (1): Starting

31 31 SFR Auditable Event Audit Messages Generated by Firepower Services FTA_SSL_EXT.1 FTA_SSL.3 FTA_SSL.4 FTP_ITC.1 time need to be logged. See also application note on FPT_STM_EXT.1) The termination of a local session by the session locking mechanism. The termination of a remote session by the session locking mechanism. The termination of an interactive session. Initiation of the trusted channel. Termination of the trusted channel. {date-time} {hostname} ntpd[19557]: Command line: /usr/bin/ntpd -n -p /var/run/ntpd.pid -c /etc/ntp.conf -I lo -I eth0 eth0 {date-time} {hostname} ntpd[19557]: proto: precision = usec (-24) {date-time} {hostname} ntpd[19557]: switching logging to file /var/log/ntp.log Console time: ({date-time}) event_type: Session terminated on ttys0 due to inactivity ({username}) subsystem: Session Expiration actor: {username} message: Session terminated on ttys0 due to inactivity ({username}) result: Success action_source_ip: local action_destination_ip: {ip-address} SSH time: ({date-time}) event_type: Session terminated on pts/0 due to inactivity ({username}) subsystem: Session Expiration actor: {username} message: Session terminated on pts/0 due to inactivity ({username}) result: Success action_source_ip: {ip-address} action_destination_ip: {ip-address} SSH {date-time} {hostname} sshd[27641]: pam_unix(sshd:session): session closed for user {username} Console {date-time} {hostname} login[9903]: pam_unix(login:session): session closed for user {username} Established {date-time} {hostname} syslog-ng[20192]: Syslog connection established; fd='52', server='af_inet({ip-address}:6514)', local='af_inet( :0)'

32 32 SFR Auditable Event Audit Messages Generated by Firepower Services FTP_TRP.1/Admin FPT_ITT.1 Failure of the trusted channel functions. Initiation of the trusted channel. Termination of the trusted channel. Failures of the trusted path functions. Initiation of the trusted channel. Termination of the trusted channel. Failure of the trusted channel functions. Terminated {date-time} {hostname} syslog-ng[20192]: Syslog connection broken; fd='16', server='af_inet({ip-address}:6514)', time_reopen='60' Failure {date-time} {hostname} syslog-ng[20192]: SSL error while writing stream; tls_error='ssl routines:ssl23_get_server_hello:sslv3 alert handshake failure' Initiation See FIA_UIA_EXT.1 Termination See FTA_SSL.4 Failure See FCS_HTTPS_EXT.1 and FCS_SSHS_EXT.1. Initiation {date-time} {hostname} SF-IMS[6425]: [6432] sfmbservice:sfmb_service [INFO] Established connection to peer {ip-address} Termination {date-time} {hostname} SF-IMS[6425]: [11606] sfmbservice:sfmb_service [INFO] Connection closed to host {ip-address} Failure {date-time} {hostname} SF-IMS[6423]: [10802] sftunneld:sf_ssl [ERROR] Connect:SSL handshake failed Audit Messages Generated by Firepower Management Center SFR Auditable Event Audit Messages Generated by FMC FAU_GEN.1 FCO_CPC_EXT.1 Start up and shutdown of audit functions Enabling communications between a pair of components. Disabling Start Up {date-time} {hostname} SF-IMS[11637]: [11637] init script:system [INFO] pmmon Starting the Process Manager... Shutdown {date-time} {hostname} shutdown[1992]: shutting down for system reboot Enabling (Audit log Web GUI) {date-time} {username} Devices > Device Management Add Device - {ip-address} {ip-address}

33 33 SFR Auditable Event Audit Messages Generated by FMC FCS_HTTPS_EXT.1 FCS_SSHS_EXT.1 FCS_TLSC_EXT.2 FCS_TLSS_EXT.1 FIA_AFL.1 communications between a pair of components. Failure to establish an HTTPS session. Failure to establish an SSH session Successful SSH rekey Failure to establish an TLS Session Failure to establish an TLS Session Unsuccessful login attempts limit is met or exceeded. Disabling (Audit log Web GUI) {date-time} {username} Devices > Device Management Delete Device {hostname} {ipaddress} {date-time} {username} Login Login Failed {ipaddress} {date-time} {hostname} sshd[34096]: Unable to negotiate with {ip-address} port 43275: no matching key exchange method found. Their offer: {keyexchange-method},ext-info-c [preauth] {date-time} {hostname} sshd[27951]: Outbound- ReKey for {ip-address}:36598 Syslog {date-time} {hostname} syslog-ng[2812]: SSL error while writing stream; tls_error='ssl routines:ssl23_get_server_hello:sslv3 alert handshake failure' Distributed TOE Communication {date-time} {hostname} SF-IMS[9173]: [9545] sftunneld:sf_ssl [ERROR] Connect:SSL handshake failed HTTPS {date-time} {hostname} {date-time} [ssl:info] [pid 10651] [client {ip-address}:58082] AH02008: SSL library error 1 in handshake (server {ip-address}:443) Distributed TOE Communication FIA_PMG_EXT.1 Resetting Password Audit log Web GUI FIA_UIA_EXT.1 All use of the identification and authentication mechanism. {date-time} {hostname} SF-IMS[5264]: [15867] SFDataCorrelator:IdentityChannel [WARN] Handshake did not complete, not connect to peer {uuid}, Not connected {date-time} {username} Login Account Locked {ipaddress} {date-time} {username} javascript:void(0) > User Preferences > Change Password Change {ip-address} SSH {date-time} {hostname} sshd[8484]: Accepted keyboard-interactive/pam for {username} from {ipaddress} port ssh2

34 34 SFR Auditable Event Audit Messages Generated by FMC FIA_UAU_EXT.2 FIA_X509_EXT.1/ITT FIA_X509_EXT.1/Rev FMT_MOF.1/ ManualUpdate FMT_SMF.1 All use of the identification and authentication mechanism. Unsuccessful attempt to validate a certificate Any attempt to initiate a manual update All management activities of TSF data. {date-time} {hostname} sshd[15885]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost={hostname} user={username} HTTPS (audit log Web GUI) {date-time} {username} Login Login Success {ipaddress} {date-time} {username} Login Login Failed {ipaddress} Console {date-time} {hostname} login[25663]: pam_unix(login:session): session opened for user {username} by LOGIN(uid=0) {date-time} {hostname} login[23995]: pam_unix(login:auth): authentication failure; logname=login uid=0 euid=0 tty=/dev/ttys0 ruser= rhost= user={username} See FIA_UIA_EXT.1 {date-time} {hostname} syslog-ng[2812]: Certificate validation failed; subject=' address={ addr}, CN={CN}, O={organization}, L={location}, ST={state}, C={country}', issuer='cn={cn}, address={ -addr}, O={organization}, L={location}, ST={state}, C={country}', error='subject issuer mismatch', depth='0' Audit log Web GUI {date-time} {username} System > Updates > Product Updates Update Install {ip-address} Import Certificate and Private Key (Audit log Web GUI) {date-time} {username} System > Configuration > Configuration > /admin/audit_cert.cgi Import {ipaddress} Delete Certificate and Private Key (Audit log Web GUI) {date-time} {username} System > Configuration > Configuration > /admin/audit_cert.cgi Delete {ipaddress}

35 35 SFR Auditable Event Audit Messages Generated by FMC FPT_TUD_EXT.1 FPT_STM_EXT.1 FTA_SSL_EXT.1 Initiation of update; result of the update attempt (success or failure) Discontinuous changes to time - either Administrator actuated or changed via an automated process. (Note that no continuous changes to time need to be logged. See also application note on FPT_STM_EXT.1) The termination of a local session by the session locking mechanism. Add User {date-time} {username} System > Local > User Management > Users Added user {username}:1725 {ip-address} Edit User/Role {date-time} {username} System > Local > User Management > Users Edited user {username}:1729 {ip-address} Configure Login Banner {date-time} {username} Devices > Platform Settings > Login Banner > Modified: Custom Login Banner Gossamer Testing Banner. Created to demonstrate TOE Banner features. > Gossamer Testing Banner. Created to demonstrate TOE Banner features. TestSave {ip-address} Configure Local Timeout {date-time} {username} Devices > Platform Settings > User Interface > Modified: cli_setting_session_timeout 1440 > 100 Save {ipaddress} Configure Remote Timeout {date-time} {username} Devices > Platform Settings > User Interface > Modified: Shell Timeout (Minutes) 1440 > 100 Save {ip-address} Audit log Web GUI {date-time} {username} System > Updates > Product Updates Update Install {ip-address} {date-time} {username} Updated time to {date-timetimezone} from {date-time-timezone} Save {ipaddress} Console (audit log on Web GUI)

36 36 SFR Auditable Event Audit Messages Generated by FMC FTA_SSL.3 FTA_SSL.4 FTP_ITC.1 FTP_TRP.1/Admin The termination of a remote session by the session locking mechanism. The termination of an interactive session. Initiation of the trusted channel. Termination of the trusted channel. Failure of the trusted channel functions. Initiation of the trusted channel. Termination of the trusted channel. Failures of the trusted path functions. {date-time} {username} Session Expiration Session terminated on ttys0 due to inactivity ({username}) local SSH (audit log on Web GUI) {date-time} {username} Session Expiration Session terminated on pts/0 due to inactivity ({username}) {ipaddress} HTTPS (audit log on Web GUI) {date-time} {username} Session Expiration Session expired due to inactivity ({username}) {ip-address} HTTPS (audit log on Web GUI) {date-time} {username} Logout Logout Success {ipaddress} SSH {date-time} {hostname} sshd[27835]: pam_unix(sshd:session): session closed for user {username} Console {date-time} {hostname} login[2965]: pam_unix(login:session): session closed for user {username} Initiation {date-time} {hostname} syslog-ng[2812]: Syslog connection established; fd='19', server='af_inet({ipaddress}:6514)', local='af_inet( :0)'' Termination {date-time} {hostname} syslog-ng[2812]: Syslog connection broken; fd='16', server='af_inet({ipaddress}:6514)', time_reopen='60' Failure {date-time} {hostname} syslog-ng[2812]: SSL error while writing stream; tls_error='ssl routines:ssl23_get_server_hello:sslv3 alert handshake failure' Initiation See FIA_UIA_EXT.1 Termination See FTA_SSL.4

37 37 SFR Auditable Event Audit Messages Generated by FMC FPT_ITT.1 Initiation of the trusted channel. Termination of the trusted channel. Failure of the trusted channel functions. Failure See FCS_HTTPS_EXT.1 and FCS_SSHS_EXT.1. Initiation {date-time} {hostname} SF-IMS[9756]: [9781] sfmbservice:sfmb_service [INFO] Established connection to peer {ip-address} Termination {date-time} {hostname} SF-IMS[9756]: [9781] sfmbservice:sfmb_service [INFO] Connection closed to host {ip-address} Failure 4.3 Restrict Access and Enable CC Mode {date-time} {hostname} SF-IMS[9173]: [9545] sftunneld:sf_ssl [ERROR] Connect:SSL handshake failed The system by default only supports SSH and HTTPS security protocols for management. Telnet and HTTP are not supported for management and cannot be enabled. SNMPv3 is supported but is not permitted for management only for sending SNMP traps for alerting. The system is required to support only the cipher suites, version, and protocols claimed in the Security Target. HTTPS, TLS, and SSH connection settings are configured automatically when CC mode is enabled. While not required by the NDcPP, the administrator should configure access list to control which computers can access the appliances on specific ports. IMPORTANT! By default, access to the appliance is not restricted. To operate the appliance in a more secure environment, consider adding access to the appliance for specific IP addresses and then deleting the default any option. By default, port 443 (HTTPS), which is used to access the web interface, and port 22 (SSH), which is used to access the command line, are enabled for any IP address. The access list is part of the system policy. Administrator can specify the access list either by creating a new system policy or by editing an existing system policy. In either case, the access list does not take effect until the system policy is applied. 1. Login with Administrator Role. 2. Depending on whether you are configuring audit log streaming for a Firepower Management Center or a Classic managed device: Management Center Choose System > Configuration. Managed device Choose Devices > Platform Settings and create or edit a Firepower policy. 3. Click Access List.

38 38 The Access List page appears. 4. Click Add Rules. The Add IP Address page appears. 5. In the IP Address field, you have the following options, depending on the IP addresses you want to add: An exact IP address (for example, ) An IP address range using CIDR (for example, /16) Any IP address using any term 6. Select SSH or HTTPS or both of these options to specify which ports you want to enable for these IP addresses. WARNING! SNMP management must not be enabled in the evaluated configuration. SNMP cannot be used for management. However, encrypted SNMPv3 traps are allowed for alerting only. 7. Click Add. 8. Click the delete icon ( ) to remove the permissive rules. IMPORTANT! If you delete access for the IP address that you are currently using to connect to the appliance interface, and there is no entry for IP=any port=443, you will lose access to the system when you save (for FMC) or deploy (for device) the setting. 9. Click Save. 10. Click Deploy if you are configuring these settings for the managed devices. Select the device(s) you want to deploy the setting to and click Deploy again. Audit Record: Note: The Source IP field in the audit event above is cut off.

39 39

40 40 Enable CC Compliance (also known as CC Mode) Enabling CC mode will restrict the SSH algorithms, SSH rekey, TLS versions and TLS cipher suites (including elliptical curves) to the Approved ones claimed in the Security Target. There are additional features such as enabling the power-up integrity HMAC-SHA-512 self-test, enabling FIPS mode, and other TLS required checks such as the ones specified in section 6 of RFC To be in the evaluated configuration, you must enable CC Mode. IMPORTANT! After you enable this setting, you cannot disable it. If you need to do so, contact Support for assistance. IMPORTANT! The FMC will not receive data from a managed device unless both are operating in CC mode. Therefore, you must enable CC mode on the FMC first, then its managed devices. 1. Login with Administrator Role. 2. Depending on whether you are configuring audit log streaming for a Firepower Management Center or a Classic managed device: Management Center Choose System > Configuration. Managed device Choose Devices > Platform Settings and create or edit a Firepower policy. 3. Click UCAPL/CC Compliance. 4. Choose CC from the drop-down list. 5. Click Save. 6. Click Deploy if you are configuring these settings for the managed devices. Select the device(s) you want to deploy the setting to and click Deploy again. Remember, you need to enable CC Mode first on the FMC! NOTE! System automatically reboots when you enable CC compliance. The FMC reboots when you save the system configuration; managed devices reboot when you deploy the configuration. Audit Record: Configure SSH Public-Key Authentication Perform the following steps on a remote workstation: 1. Log into the remote machine as root. 2. Regenerate the SSH keypair and follow instructions below ssh-keygen -t rsa

41 41 Generating public/private rsa key pair. Enter file in which to save the key (/root/.ssh/id_rsa): /root/.ssh/id_rsa already exists. Overwrite (y/n)? y Enter passphrase (empty for no passphrase): [leave it blank] Enter same passphrase again: Your identification has been saved in /root/.ssh/id_rsa. Your public key has been saved in /root/.ssh/id_rsa.pub. The key fingerprint is: 1e:54:c7:09:14:29:f5:32:b8:81:c4:99:e2:a8:5d:b8 root@cc-auto 3. Copy the public key to the system. IMPORTANT! Use step 3 for configuring FMC only. cat ~/.ssh/id_rsa.pub ssh admin@<ip address of System> "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys" 4. Copy the public key to the system. IMPORTANT! Use step 4 for configuring Device only. # After generating the RSA keys, login to Device and type expert mkdir p ~/.ssh touch ~/.ssh/authorized_keys scp <username>@<ip address of remote machine>:~/.ssh/id_rsa.pub. mv id_rsa.pub ~/.ssh/authorized_keys exit exit [Enter the admin password to authorized the copy of public keys to system authorized keys] 5. Log into the system without providing a password Audit Record: May :33:27 FMCv sshd[14076]: Accepted publickey for admin from port ssh2: RSA SHA256:PLdSQVED/mXpzRl59rHp4+dL5lbSktFiEfmAUBoTLMs Configure SSH ReKey Configuration (Optional) When CC mode is enabled, the SSH rekeying will occur approximately at 1 hour of time or after 1 GB of data has been transmitted, whichever occurs first. To change these values to be smaller, the administrator can configure these during the pre-operational state ONLY using the local management connection:

42 42 1. Login locally to shell with the default admin account using the password created during the initial setup process. NOTE! If you are on a sensor, the > will be displayed. Type the command expert to access the shell from the CLI. 2. The shell prompt <username>@<hostname>:~$ is displayed. 3. Type command sudo -i to gain root access. A warning message is displayed about root privilege (first time only). 4. Enter the same password as in step The shell prompt <username>@<hostname>:~# is displayed. 6. Type the command vi /etc/ssh/sshd_config to modify the SSH daemon configuration file. 7. Modify RekeyLimit 1G 1h to the desired values. For example, RekeyLimit 1G 30m WARNING! Do not set the time to be greater than one hour or the volume to be greater than 1 GB. 8. Type /etc/rc.d/init.d/sshd restart to restart the SSH server. Generate Certificate Request and RSA Keypair (***NGIPSv ONLY***) 1. Login locally to shell with the default admin account using the password created during the initial setup process. 2. Type command expert to gain expert mode. 3. The shell prompt <username>@<hostname>:~$ is displayed. 4. Type command sudo -i to gain root access. A warning message is displayed about root privilege (first time only). 5. Enter the same password as in step The shell prompt <username>@<hostname>:~# is displayed. 7. Change to ssl dir using command cd /etc/ssl. 8. Type the command openssl genrsa out audit.key 2048 to generate the RSA key. 9. Type the command chmod 700 audit.key 10. Type the command openssl req new key audit.key subj /C=<Country>/ST=<State>/L=<City>/O=<Company>/<OU>=<Unit>/CN=<CommonName> out CSR.pem Replace <Country> with US (for example, /C=US/ST=NC/L=RTP/O= ) 11. Send the CSR.pem to the external CA to sign and generate certificate.

43 43 IMPORTANT! The audit client certificate is expected to have the ca flag set to FALSE and critical. Other expected fields include: TLS Web Client Authentication (for X509v3 Extended Key Usage) and Digital Signature, Non Repudiation, Key Encipherment (for X509v3 Key Usage). 12. Exit expert mode. 13. Use the command configure audit_cert import to import the certificate, private key (i.e., audit.key), and CA or CA chain.

44 Configure Secure Connection with Audit Server Administrator can configure the system so it can transmit audit and syslog records securely to an external audit server (Suggestion: syslog-ng, version 3.7 or later) while storing the audit and syslog records locally. The audit server must be functional and accessible before the appliance can send the audit records. The system does not send the audit records until you save the setting. If you stream the logs to an audit server, you can use Transport Layer Security (TLS) to secure the channel between the system and the syslog-ng server. To securely send the logs to a trusted audit server, there are two requirements: Import a signed audit client certificate for the system. You can generate a certificate request based on your system information and the identification information you supply. Send the resulting request to a certificate authority to request a client certificate. After you have a signed certificate from a certificate authority (CA), you can import it. Configure the communication channel with the audit server (i.e., syslog-ng) to use TLS. To verify the certificate status, configure the system to load one of more certificate revocation lists (CRLs). The system compares the server certificate against those listed in the CRLs. If a server offers a certificate that is listed in a CRL as a revoked certificate, the connection fails. NOTE! If you choose to verify certificates using CRLs, the system uses the same CRLs to validate both the audit client and audit server certificates. Audit log connection fails if the audit server certificate that does not meet either one of the following criteria: The certificate is not signed by the CA with ca flag set to TRUE. The certificate is not signed by a trusted CA in the certificate chain. The certificate Common Name (CN) or Subject Alternative Name (SAN) does not match the expected hostname (i.e., reference identifier). The certificate has been revoked or modified. To view the client audit certificate: 1. Login with Administrator Role. 2. Depending on whether you are configuring audit log streaming for a Firepower Management Center or a Classic managed device: Management Center Choose System > Configuration. Managed device Choose Devices > Platform Settings and create or edit a Firepower policy. 3. Select Audit Log Certificate.

45 45 Audit Record: To generate a Certificate Signing Request (CSR): 1. Login with Administrator Role. 2. Depending on whether you are configuring audit log streaming for a Firepower Management Center or a Classic managed device: Management Center Choose System > Configuration. Managed device Choose Devices > Platform Settings and create or edit a Firepower policy. 3. Select Audit Log Certificate. 4. Click Generate New CSR. 5. Enter a country code in the Country Name (two-letter code) field. 6. Enter a state or province postal abbreviation in the State or Province field. 7. Enter a Locality or City. 8. Enter an Organization name. 9. Enter an Organization Unit (Department) name. 10. Enter the fully qualified domain name for which you want to request a certificate in the Common Name field.

46 46 NOTE! If the SAN and DNS hostname do not match, or if the SAN is not present and the CN and the DNS hostname do not match, the secure audit log connection will fail. 11. Click Generate. 12. Open a new blank file with a text editor. 13. Copy the entire block of text in the certificate request, including the BEGIN CERTIFICATE REQUEST and END CERTIFICATE REQUEST lines, and paste it into a blank text file. 14. Save the file with extensions.csr. 15. Click Close. IMPORTANT! This method will automatically generate a RSA 2048-bits key pair and embed the public key in the CSR. In this case, you do not need to import the private key. However, if you generate the RSA key pair externally, then you will need to import the private RSA key. To import the audit client certificate (On the NGIPSv, use the command configure audit_cert import.) 1. Login with Administrator Role. 2. Depending on whether you are configuring audit log streaming for a Firepower Management Center or a Classic managed device: Management Center Choose System > Configuration. Managed device Choose Devices > Platform Settings and create or edit a Firepower policy. 3. Select Audit Log Certificate. 4. Click Import Audit Client Certificate. 5. Open the client certificate in a text editor, copy the entire block of text, including the BEGIN CERTIFICATE and END CERTIFICATE lines. Paste this text into the Client Certificate field. IMPORTANT! The audit client certificate is expected to have the ca flag set to FALSE and critical. Other expected fields include: TLS Web Client Authentication (for X509v3 Extended Key Usage) and Digital Signature, Non Repudiation, Key Encipherment (for X509v3 Key Usage). 6. To import a private RSA key, open the private key file and copy the entire block of text, including the BEGIN <KEY TPYE> PRIVATE KEY and END <KEY TYPE> PRIVATE KEY lines. Paste this text into the Private Key field. If the key pair is generated internally, this field is not required. 7. Open each intermediate CA certificate and the root CA certificate, and copy the entire block of text for each, and paste it into the Certificate Chain field (concatenate as needed). The audit server certificate is signed by one of these CA in the chain.

47 47 IMPORTANT! The CA certificate must have the ca flag set to TRUE and critical. WARNING! The audit client certificate is validated against the CA or CA certificates in the chain. The import will fail if the validation fails. 8. Click Save. 9. Click Deploy if you are configuring these settings for the managed devices. Select the device(s) you want to deploy the setting to and click Deploy again. The system supports validating audit server certificates using imported CRLs in Distinguished Encoding Rules (DER) format. If you choose to use CRLs, to ensure that the list of revoked certificates stays current, you can create a scheduled task to update the CRLs. The system displays the most recent refresh of the CRLs. If you choose CRLs, the system uses the same CRLs to validate both audit client certificates and HTTPS certificate to secure the HTTPS connection between the system and a web browser. Enable TLS and mutual authentication with the audit server (i.e., syslog-ng): 1. Login with Administrator Role. 2. Depending on whether you are configuring audit log streaming for a Firepower Management Center or a Classic managed device: Management Center Choose System > Configuration. Managed device Choose Devices > Platform Settings and create or edit a Firepower policy. 3. Select Audit Log Certificate. 4. Choose Enable TLS to use Transport Layer Security to send the audit and syslog log to an external audit server. WARNING! This setting is required in the evaluated configuration. 5. Choose Enable Mutual Authentication. WARNING! This setting is required in the evaluated configuration. NOTE! If you enable mutual authentication without importing a valid audit client certificate, the secure audit log connection will fail. 6. You have two options: To verify server certificate using one or more CRLs, select Enable Fetching of CRL and continue with Step 6. This setting is required in the evaluated configuration. To accept server certificate without revocation check, skip to Step 9.

48 48 7. Enter a valid URL to an existing CRL file and click Add CRL. Repeat to up to 25 CRLs. NOTE! Do not copy and paste the URL. Enter the URL manually. 8. Click Refresh CRL to load the current CRL or CRLs from the specified URL or URLs. Enabling fetching of the CRL creates a scheduled task to regularly update the CRL or CRLs. Edit the task to set the frequency of the update. 9. Click Save. 10. Click Deploy if you are configuring these settings for the managed devices. Select the device(s) you want to deploy the setting to and click Deploy again. Specify the external audit server: 1. Login with Administrator Role. 2. Depending on whether you are configuring audit log streaming for a Firepower Management Center or a Classic managed device: Management Center Choose System > Configuration. Managed device Choose Devices > Platform Settings and create or edit a Firepower policy. 3. Select Audit Log. 4. Select Enabled from the Send Audit Log to Syslog drop-down menu. 5. Specify the destination host for the audit information by using the IP address or the fully qualified name (reference identifier, e.g., syslog.cisco.com) of the syslog server in the Host field. The default port (514) is used but if TLS is enabled, port 6514 will be used. For NGIPS and FMC the reference identifier used for the syslog-over-tls connection to the remote syslog server is the syslog server s hostname or IP address as entered by the Firepower administrator when adding the syslog host to the configuration. 6. Click Save. 7. Click Deploy if you are configuring these settings for the managed devices. Select the device(s) you want to deploy the setting to and click Deploy again. Audit Record: Configure the external audit server (i.e., syslog-ng daemon): 1. Login as authorized administrator. 2. Install syslog-ng with version or later. 3. Edit the syslog-ng configuration file by adding the following section below. 4 Another option is rsyslog with stunnel but this configuration is not described in this document.

49 49 vi /etc/syslog-ng/syslog-ng.conf # It maybe a different path depending on OS. Or you can search for it. find / -name syslog-ng.conf source s_network_tls { tcp( port(6514) tls( key-file( /etc/ssl/server.key.pem ) # Private key of audit server certificate cert-file( /etc/ssl/server.cert.pem ) # Audit server certificate ca-dir( /etc/ssl ) # Location of the CA certificates and symbolic links. See below ### openssl x509 -noout -hash -in rootca.pem ### ln -s rootca.pem 2e ### This is the CA that signed the audit client certificate and other CA(s) in the chain. ### All CA certs must have basic constraints CA flag set to TRUE and critical cipher-suite(aes128-sha) # e.g., TLS Ciphersuite to be supported by the server ssl-options(no-sslv2, no-sslv3, no-tlsv1) # no-sslv2, no-sslv3, no-tlsv1, no-tlsv11, no-tlsv12 peer-verify(required-trusted) # required-trusted for mutual auth, optional-trusted for no auth ) ); }; destination d_local { }; file("/var/log/remote_messages"); # The remote syslog file location can be configured here log { }; source(s_network_tls); destination(d_local); NOTE! When CC mode is enabled, the TLS version and cipher suites will be limited to the ones claimed in the Security Target. The audit server setting must include those versions and cipher suites, or the secure audit log connection will fail. 4. Restart the syslog-ng server and make sure there is no error message. /etc/rc.d/init.d/syslog-ng restart # Command may be different depending on the OS. 5. Use netstat to make sure the syslog-ng is listening. netstat -an grep Make sure port 6514 is opened by the firewall to allow the connection.

50 50 The administrator is responsible for maintaining the connection between the system and audit server. If the connection is unintentionally broken, the administrator should perform the following steps to diagnose and fix the problem: Check the physical network cables. Check that the audit server is still running. Reconfigure the audit log settings. If all else fail, reboot the system and audit server.

51 Configure Access Control Policy An access control policy determines how the system handles traffic on the monitored network. Administrators can configure one or more access control policies, which they can then apply to one or more managed devices. Each device can have only one applied policy though. Access control rules can be added to a policy to provide granular control how traffic is handled and logged. To associate the access control policy and all rules under the policy to an interface, you first need to create the interface sets for the device using Configure Inline Interface and Configure Inline Set sections from the general System User Guide. Then you can target the policy to a certain device using the target tab. For each rule, administrator can specify a rule action, that is, whether to trust, block, or inspect matching traffic with an intrusion policy. Each rule contains a set of conditions that identify the specific traffic you want to control. Rules can be simple or complex, matching traffic by any combination of security zone, IP address, application, protocols, ports, etc. The system matches traffic to access control rules in order; the first matched rule handles the traffic Access Control Policy On the Access Control Policy page (Policies > Access Control) administrator can view all the current access control policies by name and optional description and the following status information: When a policy is up to date on targeted devices, in green text. When a policy is out of date on targeted devices, in red text. The default access control policy blocks all traffic from entering your network. Creating Access Control Policy When you create a new access control policy you must, at minimum, give it a unique name and specify a default action. Although you are not required to identify the policy targets at policy creation time, you must perform this step before you can apply the policy. 1. Login with Administrator Role or Access Admin. 2. Select Policies > Access Control.

52 52 3. Click New Policy. 4. In the Name: field, type a unique name for the new policy. Optionally, type a description in the Description: field. 5. Specify the default action. WARNING! Leave the default Block all traffic in the evaluated configuration. 6. Select the devices where you want to apply the policy. Click on the managed Device(s) you want the policy to applied to. Then click on Add to Policy button. 7. Specify the initial Default Action: 8. Click Save. Block all traffic creates a policy with the Access Control: Block All Traffic default action. Intrusion Prevention creates a policy with the Intrusion Prevention: Balanced Security and Connectivity default action, associated with the default intrusion variable set. 9. Click Deploy and select the device(s) you want to deploy the setting to and click Deploy again. Audit Record: Editing Access Control Policy 1. Login with Administrator Role. 2. Select Policies > Access Control. 3. Click the edit icon ( ) next to the access control policy you want to configure.

53 53 The Policy Edit page appears. 4. Make changes to the policy and click Save. 5. Click Deploy and select the device(s) you want to deploy the setting to and click Deploy again. Audit Record: Delete Access Control Policy 1. Login with Administrator Role. 2. Select Policies > Access Control. 3. Click the delete icon ( ) next to the policy you want to delete. 4. Click OK to confirm. Audit Record:

54 Access Control Rule A set of access control rules is a key component of an access control policy. Access control rules allow administrator to manage, in a granular fashion, which traffic can enter the network, exit it, or cross from within without leaving it. Within an access control policy, the system matches traffic to rules in top-down order by rule number. Firepower access-control rules can be reordered via the FMC GUI by clicking dragging any rule up or down within its access-control rule listing. In addition to its rule order and some other basic attributes, each rule has the following major components: A set of rule conditions that identifies the specific traffic you want to control. A rule action, which determines how the system handles traffic that meets the rule s conditions. Intrusion inspection option, which allow you to examine allowed traffic with intrusion policy. The logging option, which allow you to keep a record (event log) of the matching traffic. The access control policy s default action defines the default action (for example, block all traffic) for the policy. Creating and Editing Access Control Rules 1. Login with Administrator Role or Access Admin. 2. Select Policies > Access Control. 3. Click the edit icon ( ) next to the access control policy you want to configure. 4. Add a new rule or edit an existing rule: To add a new rule, click Add Rule. To edit an existing rule, click the edit icon ( ) next to the rule you want to edit. Either the Add Rule or Editing Rule page appears. 5. Configure the following rule components: You must provide a unique rule Name.

55 55 Specify whether the rule is Enabled. Specify the rule position. Select a rule Action 5. Configure the rule s conditions 6. Configure the rule s Inspection option. Specify Logging option. Add Comments. 6. Click Add or Save. Your changes are saved. You must apply the access control policy for your changes to take effect. Audit Record: Click on the compare ( ) icon to see what rule(s) were added, removed, or modified and how. For example, the following AC rule cc rule has been added to AC policy test by admin. For example, the following AC rule cc rule has the new action set to block, from allow. 5 The evaluated actions are Allow and Block. 6 The evaluated conditions are Zones, Networks, Applications, and Ports. The other conditions are presented for completeness only.

56 56 Understanding Rule Conditions Administrator can set an access control rule to match traffic meeting any of the conditions described in the following table: Condition Zones Networks VLAN Tags Users Applications Ports URLs Description A configuration of one or more interfaces where you can apply policies. Zones provide a mechanism for classifying traffic on source and destination interfaces, and you can add source and destination zone conditions to rules. Any combination of individual IPv4 and IPv6 addresses, CIDR blocks, and/or networks (by default, any). The system also supports Network Objects as described in Section 4, page 148 in the Cisco 3D System User Guide. A number from 0 to 4094 that identifies traffic on your network by VLAN. Individual LDAP users and user groups retrieved from a Microsoft Active Directory Server. Applications provided by Cisco, user-defined applications, and application filters you create using the object manager. Source and Destination ports. ICMPv4 and ICMPv6 type and code. Transport protocol ports, including individual and group port objects you create based on transport protocols 7. The system supports Port Objects as described in Section 4, page 170 in the Cisco 3D System User Guide. Cisco-provided URLs grouped by category and reputation, literal URLs, and any individual and group URL objects you create using the object manager. 7 We support all the protocol-specific attributes required in the FWPP.

57 57 IMPORTANT! Note that to use the Application tab for the access control rules, CONTROL license is required which requires PROTECTION license. This is needed to detect FTP and FTP data connections for dynamic rule. The CONTROL license is only supported for series 3 appliances. To support the dynamic session establishment capability for FTP, you first need to create an access control rule that allows both FTP and FTP data. You can also configure the logging for this rule. This will enable the FTP application detector which has understanding of the application-level protocol so that FTP data connection will be allowed without additional rule. Deleting Access Control Rules 1. Login with Administrator Role. 2. Select Policies > Access Control. 3. Click the edit icon ( ) next to the access control policy you want to configure. 4. Click the delete icon ( ) next to the access control rule you want to delete. 5. Click OK to confirm. 6. Click Save. Audit Record: Click on the compare ( ) icon to see what rule was added, deleted, or modified and how. For example, the following AC rule cc rule has been deleted in AC policy test by admin.

58 58 The following example demonstrates how to block all Ping (ICMP echo request) from the external network to internal network and log the connection attempt. 1. Login with Administrator Role. 2. Select Policies > Access Control. 3. Click the edit icon ( ) next to the access control policy you want to configure. 4. Click Add Rule. 5. Type a name for the rule. 6. Leave the Enabled checkbox selected. 7. Let the rule get inserted into standard rules. 8. Select Block from drop-down list for the rule action. 9. On the Zones tab, select the External zone as the source zone and the Internal zone as the destination zone. You can click and drag or use the buttons.

59 On the Networks tab, select any as the source network and any as the destination network. For granular control, you can enter IP address or range of IP addresses for source and destination networks. The system also supports IPv6 addresses as well. 11. On the Ports tab, in the second Protocol fields, select ICMP(1). The Select ICMP type and code pop-up window appears. 12. In the Type: field, select 8 (Echo Request). 13. Click Add. 14. On the Logging tab, check Log at Beginning of Connection. 15. In the Send Connection Events to: field, check the FMC. 16. Click Add.

60 Click Save. The Intrusion and Network Analysis Policy (NAP) policies are associated with the Access Control (AC) policy which is then assigned to one or more sensors. However, only one AC policy can be assigned to any one sensor at a time (for example, if admin assigns AC policy XYZ to a sensor with another policy assigned, the old AC policy will be unassigned automatically). Finally, when an AC policy is assigned to a sensor, that policy will be active on all the enabled interfaces on the sensor. Modification of which Intrusion Policy is Active on Device s Interfaces Create an IPS Policy and associate it with an AC Policy 1. Login with Administrator Role. 2. Select Policies > Access Control > Intrusion. 3. Click Create Policy and create the Intrusion policy. 4. Select Policies > Access Control. 5. Assign a device (i.e., sensor) to the AC policy. Select the device and click on Add to Policy. 6. Click Save. 7. Associate the Intrusion policy with the AC policy either through the default action or AC rule. 8. Click Save. Audit Record: Click on the compare ( ) icon to see what change.

61 61 Assign a Different AC Policy to the Device 1. Login with Administrator Role. 2. Select Policies > Access Control. 3. Edit a different AC policy. 4. Click on Policy Assignments. 5. Assign a device to the AC policy. Select the device and click on Add to Policy. Click OK and confirm. 6. Click Save. Audit Record: Click on the compare ( ) icon to see what change. Associate AC Policy with Different Intrusion Policy 1. Login with Administrator Role. 2. Select Policies > Access Control. 3. Edit a AC policy. 4. Associate a different Intrusion policy either through the default action or AC rule. 5. Click Save. Audit Record:

62 62 Click on the compare ( ) icon to see what change. Enabling/Disabling a Device Interface with Intrusion Policy Applied 1. Login with Administrator Role. 2. Select Device > Device Management. 3. Edit an interface (e.g., eth1). 4. To disable an interface, change the interface from Inline to None. 5. Click Save. Audit Record: Click on the compare ( ) icon to see what change. Modification of which Mode(s) is/are Active on Device Interface 1. Login with Administrator Role. 2. Select Device > Device Management. 3. Edit an interface (e.g., eth1).

63 63 4. To change an interface mode, change the interface from Inline to Passive. 5. Click Save. Audit Record: Click on the compare ( ) icon to see what change. Note: eth1 and eth2 used to be inline and now eth1 is passive and eth2 is not active (i.e., disabled). 6. Change eth1 and eth2 back to inline mode. Doing this also enables eth2. Audit Record: Click on the compare ( ) icon to see what change.

64 Configure Security Intelligence If you want to whitelist, blacklist, or monitor specific IP addresses, URLs, or domain names, you must configure custom objects, lists, or feeds. For your convenience, Cisco provides feeds containing IP addresses, domain names, and URLs with poor reputation, as determined by Talos: The Intelligence Feed, which comprises several regularly updated collections of IP addresses. The DNS and URL Intelligence Feed, which comprises several regularly updated collection of domain names and URLs. You can also customize the feature to suit the unique needs of your organization, for example: Global blacklist and custom blacklists the system allows you to manually blacklist specific IP addresses, URLs, or domain names in many ways depending on your needs. Whitelisting to eliminate false positives when a blacklist is too broad in scope, or incorrectly blocks traffic that you want allow (for example, to vital resources), you can override a blacklist with a custom whitelist. Monitoring instead of blacklisting especially useful in passive deployments and for testing feeds before you implemented them; you can merely monitor and log the violating sessions instead of blocking them. By default, Security Intelligence filtering is not constrained by zone, that is, Security Intelligence objects have an associated zone of Any. You can constrain by only one zone. To enforce Security Intelligence filtering for an object on multiple zones, you must add the object to the whitelist or black list separately for each zone. Also, the default whitelist or blacklist cannot be constrained by zone. 1. Login with Administrator Role or Access Admin. NOTE: You must be admin or access admin role to configure this. 2. Select Policies > Access Control. 3. Click the edit icon ( ) next to the access control policy you want to configure.

65 65 4. Click on the Security Intelligence tab. 5. You have the following options: Click the Networks tab to add network objects. Click the URLs tab to add URL objects. 6. Find the Available Objects you want to add to the whitelist or blacklist. 7. Select one or more Available Objects to add. 8. Optionally, constrain the selected objects by zone by selecting an Available Zone. NOTE: You cannot constrain system-provided Security Intelligence lists by zone. 9. Click Add to Whitelist or Add to Blacklist, or click and drag the selected objects to either list. 10. Optionally, set blacklisted objects to monitor-only by right-clicking the object under Blacklist, then selecting Monitor-only (do not black). 11. Choose a DNS policy from the DNS Policy drop-down list. 12. Click Save. The policy hierarchy order is not configurable and follows this order: Security Intelligence (whitelist takes precedence over blacklist), anomaly-based rules, then signature-based rules. 4.7 Managing Intrusion Policies Intrusion policies are defined sets of intrusion detection and prevention configurations that inspect traffic for security violations and, in inline deployments, can block or alter malicious traffic. Intrusion policies are invoked by your access control policy and are the system s last line of defense before traffic is allowed to its destination. At the heart of each intrusion policy are the intrusion rules. An enabled rule causes the system to generate intrusion events for (and optionally block) traffic matching the rule. Disabling a rule stops processing of the rule. The Firepower System delivers several base intrusion policies, which enable you to take advantage of the experience of the Cisco Talos Security Intelligence and Research Group (Talos). For these policies, Talos sets intrusion and preprocessor rule states (enabled or disabled), as well as provides the initial configurations for other advanced settings. For intrusion rules to affect traffic, you must correctly configure drop rules and rules that replace content, as well as well as correctly deploy managed devices inline, that is, with inline interface sets. Finally, you must enable the intrusion policy s drop behavior, or Drop when Inline setting Create Intrusion Policy When you create a new intrusion policy you must give it a unique name, specify a base policy, and specify drop behavior. 1. Login with Administrator Role or Intrusion Admin. 2. Select Policies > Access Control > Intrusion. 3. Click Create Policy. 4. Enter a unique Name and, optionally, a Description. 5. Specify the initial Base Policy.

66 66 You can use either a system-provided or another custom policy as your base policy. 6. Set the policy s drop behavior: Check the Drop when Inline check box to allow intrusion rules to affect traffic and generate events. Clear the Drop when Inline check box to prevent intrusion rules from affecting traffic while still generating events. 7. Create the policy: Click Create Policy to create the new policy and return to the Intrusion Policy page. The new policy has the same settings as its base policy. Click Create and Edit Policy to create the policy and open it for editing in the advanced intrusion policy editor. Audit Record: Viewing Intrusion Rules in an Intrusion Policy You can adjust how rules are displayed in the intrusion policy, and can sort rules by several criteria. You can also display the details for a specific rule to see rule settings, rule documentation, and other rule specifics. 1. Login with Administrator Role or Intrusion Admin. 2. Select Policies > Access Control > Intrusion. 3. Click the edit icon ( ) next to the intrusion policy. 4. Click Rules under Policy Information in the navigation panel. 5. Check the rule whose rule details you want to view. 6. Click Show details button Intrusion Rule States Intrusion rule states allow you to enable or disable the rule within an individual intrusion policy, as well as specify which action the system takes if monitored conditions trigger the rule. In an intrusion policy, you can set a rule s state to the following values: Generate Events You want the system to detect a specific intrusion attempt and generate an intrusion event when it finds matching traffic. When a malicious packet crosses your network and triggers the rule, the packet is sent to its destination and the system generates an intrusion event. The malicious packet reaches its target, but you are notified via the event logging. Drop and Generate Events

67 67 Disable You want the system to detect a specific intrusion attempt, drop the packet containing the attack, and generate an intrusion event when it finds matching traffic. The malicious packet never reaches its target, and you are notified via the event logging. Note that rules set to this rule state generate events but do not drop packets in a passive deployment, including deployments where a 7000 or 8000 Series device inline interface set is in tap mode. For the system to drop packets, you must also enable the Drop when Inline in your intrusion policy and deploy your device inline. You do not want the system to evaluate matching traffic. NOTE: Choosing either the Generate Events or Drop and Generate Events options enables the rule. Choosing Disable disables the rule. 1. Login with Administrator Role or Intrusion Admin. 2. Select Policies > Access Control > Intrusion. 3. Click the edit icon ( ) next to the intrusion policy. 4. Click Rules under Policy Information in the navigation panel. 5. Choose the rule or rules where you want to set the rule state. 6. Choose one of the following: Rule State > Generate Events Rule State > Drop and Generate Events Rule State > Disable 7. To save changes you made in this policy since the last policy commit, click Policy Information in the navigation panel, then click Commit Changes. If you leave the policy without committing changes, changes since the last commit are discarded if you edit a different policy. Audit Record: Adding and Modifying Intrusion Event Thresholds You can set a threshold for one or more specific rules in an intrusion policy. You can also separately or simultaneously modify existing threshold settings. You can set a single threshold for each. Adding a threshold overwrites any existing threshold for the rule. You can also modify the global threshold that applies by default to all rules and preprocessor-generated events associated with the intrusion policy. Please see the Global Rule Threshold section for more details.

68 68 1. Login with Administrator Role or Intrusion Admin. 2. Select Policies > Access Control > Intrusion. 3. Click the edit icon ( ) next to the intrusion policy. 4. Click Rules under Policy Information in the navigation panel. 5. Choose the rule or rules where you want to set a threshold. 6. Choose Event Filtering > Threshold. To remove the threshold, choose Event Filtering > Remove Thresholds. 7. Choose a threshold type from the Type drop-down list. 8. From the Track By drop-down list, choose whether you want the event instances tracked by Source or Destination IP address. 9. Enter a value in the Count field. 10. Enter a value in the Seconds field. 11. Click OK. 12. To save changes you made in this policy since the last policy commit, click Policy Information in the navigation panel, then click Commit Changes. If you leave the policy without committing changes, changes since the last commit are discarded if you edit a different policy. Audit Record: Intrusion Rules Editor An intrusion rule is a set of keywords and arguments that the system uses to detect attempts to exploit vulnerabilities on your network. As the system analyzes network traffic, it compares packets against the conditions specified in each rule. If the packet data matches all the conditions specified in a rule, the rule triggers. If a rule is an alert rule, it generates an intrusion event. If it is a pass rule, it ignores the traffic. For a drop rule in an inline deployment, the system drops the packet and generates an event. You can view and evaluate intrusion events from the Firepower Management Center web interface. All rules contain two logical sections: the rule header and the rule options. The rule header contains: the rule's action or type the protocol the source and destination IP addresses and netmasks direction indicators showing the flow of traffic from source to destination the source and destination ports The rule options section contains:

69 69 For example, event messages keywords and their parameters and arguments patterns that a packet s payload must match to trigger the rule specifications of which parts of the packet the rules engine should inspect The following diagram illustrates the parts of a rule: Intrusion Rule Header Every rule has a rule header containing parameters and arguments. The following illustrates parts of a rule header: Action (alert) Generates an intrusion event when triggered. Other actions include pass or drop. Protocol (tcp) Tests TCP traffic only. ICMP, IP, TCP, and UDP protocols are also supported. Source IP ($EXTERNAL_NET) Tests traffic coming from any host that is not on your internal network. Source Port (any) Tests traffic coming from any port on the originating host. Operate (->) Tests external traffic destined for the web servers on your network. Destination IP ($HTTP_SERVERS) - Tests traffic to be delivered to any host specified as a web server on your internal network. Both IP and IPv6 addresses and ranges are supported. Destination Port ($HTTP_PORTS) - Tests traffic delivered to an HTTP port on your internal network. Intrusion Rule Options and Keywords Rule options follow the rule header and are enclosed inside a pair of parentheses. There may be one option or many and the options are separated with a semicolon. If you use multiple options, these options form a logical AND. The action in the rule header is invoked only when all criteria in the options are true. In general, an option may have two parts: a keyword and an argument. The message keyword: Specify meaningful text that appears as a message when the rule triggers. The ack keyword: Specify the acknowledgement value. For example, (flags: A; ack: 0; msg: "TCP ping detected";)means receive a TCP packet with the A flag set and the acknowledgement contains a value of 0.

70 70 The content keyword: Specify data pattern inside a packet. The pattern may be presented in the form of an ASCII string or as binary data in the form of hexadecimal characters. The offset keyword: Specify a certain offset from the start of the data part of the packet to search. The dsize keyword: Specify the length of the data part of a packet. The flags keyword: Find out which flag bits are set inside the TCP header of a packet. The fragbits keyword: Find out which three frag bits (Reserved, Don t Frag, More Frag) in the IP headers. The fragoffset keyword: Tests the offset of a fragmented packet. The itype keyword: Specify the ICMP type. The icode keyword: Specify the ICMP code. The icmp_id keyword: Specify the ICMP identification number. The icmp_seq keyword: Specify the ICMP sequence number. The ipopts keyword: Specify the IP Options. Record Route, Loose Source Routing, Strict Source Routing. The ip_proto keyword: Specify the IP protocol number. The id keyword: Specify the IP header fragment identification field The nocase keyword: Its only purpose is to make a case insensitive search of a pattern within the data part of a packet. It is used in conjunction with the content keyword. The seq keyword: Specify the sequence number of a TCP packet. The window keyword: Specify the TCP window size. The flow keyword: Apply a rule on TCP sessions to packets flowing in a particular direction. The tos keyword: Detect a specific value in the Type of Service (TOS) field of the IP header. The ttl keyword: Detect Time to Live value in the IP header of the packet. Required Header Field Inspection IPv4: Version Intrusion Rule Keyword or Rule alert ( msg:"decode_not_ipv4_dgram"; sid:1; gid:116; rev:1; metadata:rule-type decode; classtype:protocol-commanddecode;)

71 71 Header Length Packet Length ID IP Flags Fragment Offset Time to Live (TTL) Protocol Header Checksum Source Address Destination Address IP Options. IPv6: Version payload length next header alert ( msg:"decode_ipv4_invalid_header_len"; sid:2; gid:116; rev:1; metadata:rule-type decode; classtype:protocol-command-decode; ) alert ( msg:"decode_ipv4_dgram_lt_iphdr"; sid:3; gid:116; rev:1; metadata:rule-type decode; classtype:protocolcommand-decode; ) alert ( msg:"decode_ipv4_dgram_gt_caplen"; sid:6; gid:116; rev:1; metadata:rule-type decode; classtype:protocolcommand-decode; ) id fragbits fragoffset ttl ip_proto Inspected by Checksum Verification preprocessor. Source IP OR alert (msg:"decode_ip4_src_multicast"; sid:410; gid:116; rev:1; metadata:rule-type decode; classtype:miscactivity; ) Destination IP OR alert (msg:"decode_ip4_dst_reserved"; sid:412; gid:116; rev:1; metadata:rule-type decode; classtype:miscactivity; ) ipopts alert ( msg:"decode_ipv6_is_not"; sid:271; gid:116; rev:1; metadata:rule-type decode; classtype: protocol-commanddecode; ) dsize OR alert ( msg:"decode_ipv6_truncated_ext"; sid:272; gid:116; rev:1; metadata:rule-type decode; classtype:badunknown; ) alert ( msg:"decode_ipv6_bad_next_header"; sid:281; gid:116; rev:1; metadata:rule-type decode; classtype:protocol-command-decode; )

72 72 hop limit source address destination address alert ( msg:"decode_ipv6_min_ttl"; sid:270; gid:116; rev:1; metadata:rule-type decode; classtype:protocol-commanddecode; ) Source IP OR alert ( msg:"decode_ipv6_src_multicast"; sid:277; gid:116; rev:1; metadata:rule-type decode; classtype:protocolcommand-decode; ) Destination IP OR alert ( msg:"decode_ipv6_dst_reserved_multicast"; sid:278; gid:116; rev:1; metadata:rule-type decode; classtype:protocol-command-decode; ) routing header ICMP: Type Code Header Checksum Rest of Header(varies based on the ICMP type and code) ICMPv6: Type Code Header Checksum TCP: source port destination port sequence number alert ( msg:"decode_ipv6_dst_zero"; sid:276; gid:116; rev:1; metadata:rule-type decode; classtype:protocolcommand-decode; ) alert ( msg:"decode_ipv6_route_and_hopbyhop"; sid:282; gid:116; rev:1; metadata:rule-type decode; classtype:protocol-command-decode; ) alert ( msg:"decode_ipv6_two_route_headers"; sid:283; gid:116; rev:1; metadata:rule-type decode; classtype:protocol-command-decode; ) itype icode Inspected by Checksum Verification preprocessor. icmp_id, icmp_seq itype icode Inspected by Checksum Verification preprocessor. Source Port Destination Port seq

73 73 acknowledgement number offset reserved TCP flags window checksum urgent pointer TCP options UDP: Source port destination port length; UDP checksum ack alert ( msg:"decode_tcp_invalid_offset"; sid:46; gid:116; rev:1; metadata:rule-type decode; reference:cve, ; classtype:bad-unknown; ) Inspected and normalized by preprocessor, if configured. flags window Inspected by Checksum Verification preprocessor. alert ( msg:"decode_tcp_bad_urp"; sid:419; gid:116; rev:1; metadata:rule-type decode; classtype: misc-activity; ) OR Inspected and normalized by preprocessor, if configured. alert ( msg:"decode_tcpopt_truncated"; sid:55; gid:116; rev:1; metadata:rule-type decode; classtype:protocolcommand-decode; ) Source Port Destination Port alert ( msg:"decode_udp_dgram_invalid_length"; sid:96; gid:116; rev:1; metadata:rule-type decode; classtype:protocol-command-decode; ) Inspected by Checksum Verification preprocessor. Writing New Rules 1. Login with Administrator Role or Intrusion Admin. 2. Access the intrusion rules using either of the following methods: Choose Policies > Access Control > Intrusion then click Intrusion Rules. Choose Objects > Intrusion Rules. 3. Click Create Rule. 4. Enter a value in the Message field. 5. Choose a value from each of the following drop-down lists: Classification Action Protocol Direction

74 74 6. Enter values in the following fields: Source IPs Destination IPs Source Port Destination Port NOTE: The system uses the value any if you do not specify a value for these fields. 7. Click Add Option. 8. Enter any arguments for the keyword you added. 9. Optionally, repeat steps 6 to If you added multiple keywords, you can: Reorder keywords Click the up or down arrow next to the keyword you want to move. Delete a keyword Click the X next to that keyword. 11. Click Save As New. Audit Record: Intrusion Rules Import As new vulnerabilities become known, the Cisco Talos Security Intelligence and Research Group (Talos) releases intrusion rule updates that you can import onto your Firepower Management Center, and then implement by deploying the changed configuration to your managed devices. These updates affect intrusion rules, preprocessor rules, and the policies that use the rules. Intrusion rule updates are cumulative, and Cisco recommends you always import the latest update. For changes made by an intrusion rule update to take effect, you must redeploy configurations. When importing a rule update, you can configure the system to automatically redeploy to affected devices. This approach is especially useful if you allow the intrusion rule update to modify system-provided base intrusion policies. 1. Manually download the update from the Cisco Support Site ( 2. Login with Administrator Role. 3. Choose System > Updates, then click the Rule Updates tab. 4. If you want to move all user-defined rules that you have created or imported to the deleted folder, you must click Delete All Local Rules in the toolbar, then click OK. 5. Choose Rule Update or text rule file to upload and install and click Browse to navigate to and choose the rule update file. 6. If you want to automatically re-deploy policies to your managed devices after the update completes, choose Reapply all policies after the rule update import completes.

75 75 7. Click Import. The system installs the rule update and displays the Rule Update Log detailed view. NOTE: Contact Support if you receive an error message while installing the rule update Configure Dynamic Rule State The administrator can configure traffic bandwidth control at the policy level to stop excessive traffic from a specific source or network, to a specific destination or network, or all detected traffic. 1. Login with Administrator Role or Intrusion Admin. 2. Select Policies > Access Control > Intrusion. 3. Click the edit icon ( ) next to the policy you want to configure. 4. Click Rules under Policy Information in the navigation panel. 5. Select the rule or rules where you want to add a dynamic rule state. You have the following options: To select a specific rule, select the check box next to the rule. To select all the rules, select the check box at the top of the column. 6. Select Dynamic State > Add Rate-Based Rule State. The Add Rate-Based Rule State dialog box appears. 7. Select the appropriate Track By option to indicate how you want the rule matches tracked: Select Source to track the number of hits for that rule from a specific source or set of sources. Select Destination to track the number of hits for that rule to a specific destination or set of destinations.

76 76 Select Rule to track all matches for that rule. 8. When you set Track By to Source or Destination, enter the address of each host you want to track in the Network field. You can specify a single IP address, address block, variable, or a comma-separated list comprised of any combination of these. 9. Indicate the number of rule matches per time period to set the attack rate: In the Count field, using an integer between 1 and , specify the number of rule matches you want to use as your threshold. In the Seconds field, using an integer between 1 and , specify the number of seconds that make up the time period for which attacks are tracked. 10. Select a New State radio button to specify the action to be taken when the conditions are met: Select Drop and Generate Events to generate an event and drop the packet that triggered the event in inline deployments or generate an event in passive deployments. 11. In the Timeout field, type the number of seconds you want the action to remain in effect. After the timeout occurs, the rule reverts to its original state. Specify 0 or leave the field blank to prevent the action from timing out. 12. Click OK. 13. Select Commit Changes. 14. Deploy the policy. Audit Record: Global Rule Threshold The global rule threshold sets limits for event logging by an intrusion policy. You can set a global rule threshold across all traffic to limit how often the policy logs events from a specific source or destination and displays those events per specified time period. You can also set thresholds per rule, or preprocessor rule in the policy. When you set a global threshold, that threshold applies for each rule in the policy that does not have an overriding specific threshold. Thresholds can prevent you from being overwhelmed with a large number of events. Every intrusion policy contains a default global rule threshold that applies by default to all intrusion rules and preprocessor rules. This default threshold limits the number of events on traffic going to a destination to one event per 60 seconds. You can: Change the global threshold. Disable the global threshold.

77 77 Override the global threshold by setting individual thresholds for specific rules. For example, you might set a global limit threshold of five events every 60 seconds, but then set a specific threshold of ten events for every 60 seconds for SID1315. All other rules generate no more than five events in each 60-second period, but the system generates up to ten events for each 60-second period for SID Login with Administrator Role or Intrusion Admin. 2. Select Policies > Access Control > Intrusion. 3. Click the edit icon ( ) next to the policy you want to configure. 4. Click Advanced Setting in the navigation panel. 5. If Global Rule Thresholding under Intrusion Rule Thresholds is disabled, click Enabled. 6. Click the edit icon ( ) next to Global Rule Thresholding. 7. Using the Type radio buttons, specify the type of threshold that will apply over the time you specify in the Seconds field. Limit Logs and displays events for the specified number of packets (specified by the count argument) that trigger the rule during the specified time period. For example, if you set the type to Limit, the Count to 10, and the Seconds to 60, and 14 packets trigger the rule, the system stops logging events for the rule after displaying the first 10 that occur within the same minute. Threshold Logs and displays a single event when the specified number of packets (specified by the count argument) trigger the rule during the specified time period. Note that the counter for the time restarts after you hit the threshold count of events and the system logs that event. For example, you set the type to Threshold, Count to 10, and Seconds to 60, and the rule triggers 10 times by second 33. The system generates one event, then resets the Seconds and Count counters to 0. Both Logs and displays an event once per specified time period, after the specified number (count) of packets trigger the rule. For example, if you set the type to Both, Count to 2, and Seconds to 10, the following event counts result: If the rule is triggered once in 10 seconds, the system does not generate any events (the threshold is not met). If the rule is triggered twice in 10 seconds, the system generates on eevent (the threshold is met when the rule triggers the second time). If the rule is triggered four times in 10 seconds, the system generates one event (the threshold is met when the rule triggered the second time and following events are ignored).

78 78 8. Using the Track By radio buttons, specify the tracking method. This determines whether the event in stance count is calculated per source or destination IP address. 9. Enter a value in the Count field. 10. Enter a value in the Seconds field. 11. To save changes you made in this policy since the last policy commit, click Policy Information, then click Commit Changes. Audit Record: 4.8 Stateful Session Behaviors The system implements packet decoders and preprocessors to detect anomalous traffic that might signal an intrusion attempt and, when the appropriate enabled accompanying decoder and preprocessor rules, report on detected anomalies. Next, intrusion rules examine the decoded packets for attacks based on patterns. Used together, intrusion rules and preprocessors provide broader and deeper packet inspection than a signature-based system and help to identify intrusions more effectively. Before packets can be inspected, the packets must be captured from the network. As the system captures packets, it sends them to the packet decoder. The packet decoder converts the packet headers and payloads into a format that can be easily used by the preprocessors and the rules engine. Each layer of the TCP/IP stack is decoded in turn, beginning with the data link layer and continuing through the network and transport layers, as described in the following table. TCP/IP Layer Data Link Network Transport Decoded Packets Ethernet Virtual local area network (VLAN) Internet Protocol version 4 (IPv4) Internet Protocol version 6 (IPv6) Internet Control Message Protocol version 4 (ICMPv4) Internet Control Message Protocol version 6 (ICMPv6) Transmission Control Protocol (TCP) User Datagram Protocol (UDP) After the packets are decoded through the first three TCP/IP layers, they are sent to preprocessors, which normalize traffic at the application layer and detect protocol anomalies. The following three preprocessors must be enabled and configured in the evaluated configuration (be default, all three preprocessors are enabled): TCP Streaming Preprocessor - Administrators can configure the system so that the preprocessor detects any TCP traffic that cannot be identified as part of an established TCP session. Stateful inspection allows administrators to ignore these packets because they are not part of an established TCP session and do not provide meaningful information. UDP Streaming Preprocessor - UDP data streams are not typically thought of in terms of sessions. However, the stream preprocessor uses the source and destination IP address fields in the encapsulating IP datagram header and the port fields in the UDP header to determine the direction of flow and identify a session.

79 79 IP Defragmentation Preprocessor - When an IP datagram is broken into two or more smaller IP datagrams because it is larger than the maximum transmission unit (MTU), it is fragmented. A single IP datagram fragment may not contain enough information to identify a hidden attack. Attackers may attempt to evade detection by transmitting attack data in fragmented packets or attempt to crash the system when reassembling the fragmented packets. The IP defragmentation preprocessor reassembles fragmented IP datagrams, and if fragmented datagrams cannot be reassembled, it will be rejected (i.e., dropped) and logged with certain intrusion rules enabled Verify Enabled Preprocessors 1. Login with Administrator Role or Intrusion Admin. 2. Select Policies > Access Control > Intrusion. 3. Click Create Policy. 4. In the Name field, enter a unique name and optionally a description. 5. Click Create and Edit Policy. 6. Click Advanced Settings. 7. Verify that IP Defragmentation, TCP Stream and UDP Stream are enabled.

80 80 8. Click on Policy Information and Commit Changes. 9. Optionally, enter a comment and click OK. 10. Associate the intrusion policy with the access control policy. NOTE! You cannot apply the intrusion policy until it is associated with an access control policy or rule. Audit Record: Configure Anomaly Detection Preprocessors prepare traffic to be further inspected by normalizing traffic and identifying protocol anomalies. Preprocessors can generate preprocessor events when packets trigger preprocessor options that you configure. The base policy for your network analysis policy determines which preprocessors are enabled by default and the default configuration for each. The FTP/Telnet decoder analyzes FTP and telnet data streams, normalizing FTP and telnet commands before processing by the rules engine. You can enable rule126:3 to generate an event when this anomaly is detected in Telnet traffic, and rule125:9 when it is detected on the FTP command channel. The inline normalization preprocessor normalizes traffic to minimize the chances of attackers evading detection in inline deployments. You can specify normalization of any combination of IPv4, IPv6, ICMPv4, ICMPv6, and TCP traffic. When the packet decoding Detect Protocol Header Anomalies option is enabled, you can enable the following rules in the decoder rule category to generate events for this option: You can enable rule 116:428 to generate an event when the system detects an IPv4 packet with a TTL less than the specified minimum. You can enable rule 116:270 to generate an event when the system detects an IPv6 packet with a hop limit that is less than the specified minimum. The system can detect, drop, and log anomaly fragmented packets if the IP Defragmentation Preprocessor is enabled and certain intrusion rules are enabled. 1. Login with Administrator Role or Intrusion Admin.

81 81 2. Select Policies > Access Control > Intrusion. 3. Click Create Policy. 4. In the Name field, enter a unique name and optionally a description. 5. Click Create and Edit Policy. 6. Click Manage Rules.

82 82 7. Click Rule Content and select GID. The Enter the GID filter pop-up window appears. 8. Enter 123 and click OK. 9. Select all the rules. Hint: Click the top checkbox. 10. In the Rule State field, click and select Drop and Generate Events.

83 For more details on each rule, click on a rule and select Show details. 11. Click on Policy Information and Commit Changes. 12. Optionally, enter a comment and click OK. 13. Associate the intrusion policy with the access control policy. NOTE! You cannot apply the intrusion policy until it is associated with an access control policy or rule. Audit Record:

84 Portscan Detection A portscan is a form of network reconnaissance that is often used by attackers as a prelude to an attack. In a portscan, an attacker sends specially crafted packets to a targeted host. By examining the packets that the host responds with, the attacker can often determine which ports are open on the host and, either directly or by inference, which application protocols are running on these ports. By itself, a portscan is not evidence of an attack. In fact, some of the port scanning techniques used by attackers can also be employed by legitimate users on your network. Cisco s portscan detector is designed to help you determine which portscans might be malicious by detecting patterns of activity. Protocol TCP UDP ICMP IP Description Protocol Types Detects TCP probes such as SYN scans, ACK scans, TCP connect() scans, and scans with unusual flag combinations such as Xmas tree, FIN, and NULL. Detects UDP probes such as zero-byte UDP packet. Detects ICMP echo requests (pings). Detects IP protocol scans. These scans differ from TCP and UDP scans because the attacker, instead of looking for open ports, is trying to discover which IP protocols are supported on a target host. When portscan detection is enabled, you must enable rules with GeneratorID (GID)122 and a SnortID (SID) from among SIDs 1 through 27 to generate events for each enabled portscan type. Portscan Event Packet View When you enable the a accompanying preprocessor rules, the portscan detector generates intrusion events that you can view just as you would any other intrusion event. However, the information presented on the packet view is different from the other types of intrusion events. Begin by using the intrusion event views to drill down to the packet view for a ports can event. Note that you cannot download a portscan packet because single port scan events are based on multiple packets; however, the portscan packet view provides all usable packet information. For any IP address, you can click the address to view the context menu and select whois to perform a lookup on the IP address or View Host Profile to view the host profile for that host. Information Device Time Message Source IP Destination IP Description Portscan Packet View The device that detected the event. The time when the event occurred. The event message generated by the preprocessor. The IP address of the scanning host. The IP address of the scanned host.

85 85 Port/Proto Count Port/Proto Range Open Ports For TCP and UDP portscans, the number of times that the port being scanned changes. For example, if the first port scanned is 80, the second port scanned is 8080, and the third port scanned is again 80, then the port count is 3. For IP protocol portscans, the number of times that the protocol being used to connect to the scanned host changes. For TCP and UDP portscans, the range of the ports that were scanned. For IP protocol portscans, the range of IP protocol numbers that were used to attempt to connect to the scanned host. The TCP ports that were open on the scanned host. This field appears only when the portscan detects one or more open ports. 1 Login with Administrator Role or Intrusion Admin. 2 Select Policies > Access Control > Intrusion then click on Network Analysis Policy. 3 Click the edit icon ( ) next to the policy you want to edit. 4 Click Settings. 5 If Portscan Detection under Specific Threat Detection is disabled, click Enabled. 6 Click the edit icon ( ) next to Portscan Detection. 7 In the Protocol field, specify protocols to enable. NOTE! You must ensure TCP stream processing is enabled to detect scans over TCP, and that UDP stream processing is enabled to detect scans over UDP. Also make sure you do not enable Packet Size Performance Boost and Packet Type Performance Boost. 8 In the Scan Type field, specify portscan types you want to detect. 9 Choose a level from the Sensitivity Level list. NOTE! If you are encountering inconsistent detection (especially on the virtual Sensor), try disabling the Latency-based performance setting. 10 To save changes you made in this policy since the last policy commit, click Policy Information, then click Commit Changes. Audit Record:

86 Rate-Based Attack Prevention Rate-based attacks (i.e., flooding attacks) are attacks that depend on frequency of connection or repeated attempts to perpetrate the attack. You can use rate-based detection criteria to detect a rate-based attack as it occurs and respond to it when it happens, then return to normal detection settings after it stops. You can configure your network analysis policy to include rate-based filters that detect excessive activity directed at hosts on your network. You can use this feature on managed devices deployed in inline mode to block rate-based attacks for a specified time, then revert to only generating events and not drop traffic. The SYN attack prevention option helps you protect your network hosts against SYN floods. You can protect individual hosts or whole networks based on the number of packets seen over a period of time. If your device is deployed passively, you can generate events. If your device is placed inline, you can also drop the malicious packets. After the timeout period elapses, if the rate condition has stopped, the event generation and packet dropping stops. For example, you could configure a setting to allow a maximum of 10 SYN packets from anyone IP address, and block further connections from that IP address for 60 seconds. You can also limit TCP/IP connections to or from hosts on your network to prevent denial of service (DoS) attacks or excessive activity by users. When the system detects the configured number of successful connections to or from a specified IP address or range of addresses, it generates events on additional connections. The rate-based event generation continues until the timeout period elapses without the rate condition occurring. In an inline deployment you can choose to drop packets until the rate condition times out. For example, you could configure a setting to allow a maximum of 10 successful simultaneous connections from anyone IP address, and block further connections from that IP address for 60 seconds. Rate-based attack prevention identifies abnormal traffic patterns and attempts to minimize the impact of that traffic on legitimate requests. Rate-based attacks usually have one of the following characteristics: Any traffic containing excessive incomplete connections to hosts on the network, indicating a SYN flood attack Any traffic containing excessive complete connections to hosts on the network, indicating a TCP/IP connection flood attack Excessive rule matches in traffic going to a particular destination IP address or addresses or coming from a particular source IP address or addresses. Excessive matches for a particular rule across all traffic. In a network analysis policy, you can either configure SYN flood or TCP/IP connection flood detection for the entire policy; in an intrusion policy, you can set rate-based filters for individual intrusion or preprocessor rules. Note that you cannot manually add a rate-based filter to GID135 rules or modify their rule state. Rules with GID135 use the client as the source value and the server as the destination value. The detection_filter keyword prevents a rule from triggering until a threshold number of rule matches occur within a specified time. When a rule includes the detection_filter keyword, the system tracks the number of incoming packets matching the pattern in the rule per timeout period. The system can count hits for that rule from particular source or destination IP addresses. After the rate exceeds the rate in the rule, event notification for that rule begins. You can configure rate-based attack prevention at the policy level to stop SYN flood attacks. You can also stop excessive connections from a specific source or to a specific destination.

87 87 1 Login with Administrator Role or Intrusion Admin. 2 Select Policies > Access Control > Intrusion then click on Network Analysis Policy. 3 Click the edit icon ( ) next to the policy you want to edit. 4 Click Settings. 5 If Rate-Based Attack Prevention under Specific Threat Detection is disabled, click Enabled. 6 Click the edit icon ( ) next to Rate-Based Attack Prevention. 7 You have two choices: To prevent incomplete connections intended to flood a host, click Add under SYN Attack Prevention. To prevent excessive numbers of connections, click Add under Control Simultaneous Connections. 8 Specify how you want to track traffic: To track all traffic from a specific source or range of sources, choose Source from the Track By drop-down list, and enter a single IP address or address block in the Network field. To track all traffic to a specific destination or range of destinations, choose Destination from the Track By drop-down list, and enter an IP address or address block in the Network field. NOTE! To load-balance the traffic for maximum performance, the source and destination address and port are used to determine which Snort Instance the traffic is sent to. 9 Specify the triggering rate for the rate tracking setting: For SYN attack configuration, enter the number of SYN packets per number of seconds in the Rate fields. For simultaneous connection configuration, enter the number of connections in the Count field. NOTE! The recommended setting is between 600-6,000 TCP SYN/connection requests per minute per IP address. However, the exact number will vary and will depend on the host(s) and/or network configuration. 10 To drop packets matching the rate-based attack prevention settings, check the Drop check box. 11 In the Timeout field, enter the time period after which to stop generating events (and if applicable, dropping) for traffic with the matching pattern of SYNs or simultaneous connections. 12 Click OK. 13 To save changes you made in this policy since the last policy commit, click Policy Information, then click Commit Changes. Audit Record:

88 Specific Attacks To detect these specific attacks, enable each of the rules listed in the table below: Attack Attack Category Rule Teardrop IP Attack Rule 123:2 FRAG2_TEARDROP Bonk IP Attack Rule 123:4 FRAG3_ANOMALY_OVERSIZE Boink IP Attack Rule 123:4 FRAG3_ANOMALY_OVERSIZE Land IP Attack Rule 116:151 DECODE_BAD_TRAFFIC_SAME_SRCDST Nuke ICMP Attack alert tcp $EXTERNAL_NET any -> $HOME_NET 135:139 (msg:"server-other Winnuke attack"; flow:stateless; flags:u+; metadata:ruleset community; reference:bugtraq,2010; reference:cve, ; classtype:attempted-dos; sid: ; rev:15; gid:1001; ) Ping of Death ICMP Attack Rule 123:7 FRAG3_ANOMALY_BADSIZE_LG Null flags TCP Attack alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"null TCP attack"; flags:0; classtype:attempteddos; sid:269; rev:3;) SYN+FIN flags TCP Attack Rule 116:420 DECODE_TCP_SYN_FIN FIN only flags TCP Attack alert tcp any any -> any any (sid: ; gid:1; flags:f*; msg:"fin only"; classtype:attempted-dos; rev:3; ) SYN+RST flags TCP Attack Rule 116:421 DECODE_TCP_SYN_RST Bomb UDP Attack Rule 116:98 DECODE_UDP_DGRAM_LONG_PACKET Chargen DoS UDP Attack Rule 1:271 SERVER-OTHER echo+chargen bomb The default behavior for each rule is determined by which Base Policy is used to create a customdefined Intrusion Policy that s deployed to a Firepower device. The available pre-configured Base Policies are: No Rules Active; Connectivity Over Security; Balanced Security and Connectivity; Security Over Connectivity; and Maximum Detection. Regardless of which Base Policy is used to create the Intrusion Policy that s deployed to the Firepower device, each Base Policy contains the same set of default rules and the behavior of each rule can be modified as desired by editing any Intrusion Policy. Attack Default Rule Behavior (Rule State) in each type of Base Policy No Rules Active Connectivity Over Security Balanced Security and Connectivity Security Over Connectivity Maximum Detection Teardrop Disabled Disabled Disabled Disabled Drop and Generate Events Bonk Disabled Disabled Disabled Disabled Drop and Generate Events Boink Disabled Disabled Disabled Disabled Drop and Generate Events

89 89 Land Disabled Disabled Disabled Disabled Drop and Generate Events Nuke Undefined Undefined Undefined Undefined Undefined Ping of Death Disabled Disabled Disabled Disabled Drop and Generate Events Null flags Undefined Undefined Undefined Undefined Undefined SYN+FIN flags FIN only flags SYN+RST flags Disabled Disabled Disabled Disabled Drop and Generate Events Undefined Undefined Undefined Undefined Undefined Disabled Disabled Disabled Disabled Drop and Generate Events Bomb Disabled Disabled Disabled Disabled Drop and Generate Events Chargen DoS Disabled Disabled Disabled Disabled Disabled The FTP/Telnet decoder analyzes FTP and telnet data streams, normalizing FTP and telnet commands before processing by the rules engine. You can set options for decoding on multiple FTP servers. Each server profile you create contains the server IP address and the ports on the server where traffic should be monitored. You can specify which FTP commands to validate and which to ignore for a particular server, and set maximum parameter lengths for commands. You can also set the specific command syntax the decoder should validate against for particular commands and set alternate maximum command parameter lengths. Networks Use this option to specify one or more IP addresses of FTP servers. Ports Use this option to specify the ports on the FTP server where the managed device should monitor traffic. In the interface, list multiple ports separated by commas. Port21 is the well-known port for FTP traffic. File Get Commands Use this option to define the FTP commands used to transfer files from server to client. Do not change these values unless directed to do so by Support. File Put Commands Use this option to define the FTP commands used to transfer files from client to server. Do not change these values unless directed to do so by Support. Additional FTP Commands Use this line to specify the additional commands that the decoder should detect. Separate additional commands by spaces. The HTTP Inspect preprocessor is responsible for: Decoding and normalizing HTTP requests sent to and HTTP responses received from web servers on your network.

90 90 Networks Separating messages sent to web servers into URI, non-cookie header, cookie header, method, and message body components to improve performance of HTTP-related intrusion rules. Use this option to specify the IP address of one or more servers. You can specify a single IP address or address block, or a comma-separated list comprised of either or both. Ports The ports whose HTTP traffic the preprocessor engine normalizes. Separate multiple port numbers with commas. HTTP Methods Specifies HTTP request methods in addition to GET and POST that you expect the system to encounter in traffic. Use a comma to separate multiple values. Intrusion rules use the content or protected_content keyword with the HTTP Method argument to search for content in HTTP methods. You can enable rule 119:31 to generate events when a method other than GET, POST, or a method configured forth is option is encountered in traffic. The SMTP preprocessor instructs the rules engine to normalize SMTP commands. The preprocessor can also extract and decode attachments in client-to-server traffic and, depending on the software version, extract filenames, addresses, and header data to provide context when displaying intrusion events triggered by SMTP traffic. Ports Specifies the ports whose SMTP traffic you want to normalize. You can specify a value greater than or equal to 0. Separate multiple ports with commas. Stateful Inspection When selected, causes SMTP decoder to save state and provide session context for individual packets and only inspects reassembled sessions. When cleared, analyze seach individual packet without session context. Custom Commands When Normalize is set to Cmds, normalizes the listed commands. Detect Unknown Commands Detects unknown commands in SMTP traffic. You can enable rules124:5 to generate events for this option Checksum Verification The system can verify all protocol-level checksums to ensure that complete IP, TCP, UDP, and ICMP transmissions are received and that, at a basic level, packets have not been tampered with or accidentally altered in transit. A checksum uses an algorithm to verify the integrity of a protocol in the packet. The packet is considered to be unchanged if the system computes the same value that is written in the packet by the end host.

91 91 Disabling checksum verification may leave your network susceptible to insertion attacks. Note that the system does not generate checksum verification events. In an inline deployment, you can configure the system to drop packets with invalid checksums. NOTE! Do not disable checksum verification in the evaluated configuration. Portscan Event Packet View You can set any of the following options to Enabled or Disabled in a passive or inline deployment, or to Drop in an inline deployment: ICMP Checksums IP Checksums TCP Checksums UDP Checksums To drop offending packets, in addition to setting an option to Drop you must also enable Inline Mode in the associated network analysis policy and ensure that the device is deployed inline. Setting these options to Drop in a passive deployment, or in an inline deployment in tap mode, is the same as setting them to Enabled. The default for all checksum verification options is Enabled. 1 Login with Administrator Role or Intrusion Admin. 2 Select Policies > Access Control > Intrusion then click on Network Analysis Policy. 3 Click the edit icon ( ) next to the policy you want to edit. 4 Click Settings. 5 If Checksum Verification under Transport/Network Layer Preprocessors is disabled, click Enabled. 6 Click the edit icon ( ) next to Checksum Verification. 7 For each protocol, click Drop. 8 To save changes you made in this policy since the last policy commit, click Policy Information, then click Commit Changes. Audit Record:

92 Passive vs Inline You can configure your device in either a passive or inline IPS deployment. In a passive deployment, you deploy the system out of band from the flow of network traffic. In an inline deployment, you configure the system transparently on a network segment by binding two ports together. Passive Deployment In a passive IPS deployment, the Firepower System monitors traffic flowing across a network using a switch SPAN or mirror port. The SPAN or mirror port allows for traffic to be copied from other ports on the switch. This provides the system visibility within the network without being in the flow of network traffic. When configured in a passive deployment, the system cannot take certain actions such as blocking or shaping traffic. Passive interfaces receive all traffic unconditionally, and no traffic received on these interfaces is retransmitted. You can configure one or more physical ports on a managed device as passive interfaces. IMPORTANT! When you disable a passive interface, users can no longer access it for security purposes. 1. Login with Administrator Role. 2. Select Device > Device Management. 3. Next to the device where you want to configure the passive interface, click the edit icon ( ). 4. Next to the interface where you want to configure it as a passive interface, click the edit icon ( ). 5. Click Passive. 6. Associate a security zone with the passive interface 7. Check the Enabled check box. 8. Click Save. Audit Record: Inline Deployment In an inline IPS deployment, you configure the Firepower System transparently on a network segment by binding two ports together. This allows the system to be installed in any network environment without the configuration of adjacent network devices. Inline interfaces receive all traffic unconditionally, but all traffic received on these interfaces is retransmitted out of an inline set unless explicitly dropped. You can configure one or more physical ports on a managed device as inline interfaces. You must assign a pair of inline interfaces to an inline set before they can handle traffic in an inline deployment. 1. Login with Administrator Role. 2. Select Device > Device Management. 3. Next to the device where you want to configure the inline interface, click the edit icon ( ).

93 93 4. Next to the interface where you want to configure it as an inline interface, click the edit icon ( ). 5. Click Inline. 6. Associate a security zone with the inline interface 7. Check the Enabled check box. 8. Click Save. 9. Select Device > Device Management. 10. Next to the device where you want to add the inline set, click the edit icon ( ). 11. Click the Inline Sets tab. 12. Click Add Inline Set. 13. Enter a Name. 14. Next to Interfaces, choose one or more inline interface pairs, then click the add selected icon ( ). 15. If you want to specify that traffic is allowed to bypass detection and continue through the device, choose Failopen (default). If you want Failsafe, please click on the FailSafe check box. IMPORTANT! Failsafe option will prevent traffic from flowing through the appliance if a failure occurs for inline deployment. This can potentially cause a Denial of Service (DoS) attack on the monitored network. 16. Click OK. Audit Record:

94 Management Functions View Audit Log FMCs and managed devices log read-only auditing information for user activity. Audit logs are presented in a standard event view that allows administrator to view, sort, and filter audit log messages based on any item in the audit view. Administrator can delete and report on audit information and can view detailed reports of the changes that users make. The audit log stores a maximum of 100,000 entries. When the number of audit log entries greatly exceeds 100,000, the appliance overwrites the oldest records from the database to reduce the number to 100,000. NOTE! To change the maximum number of entries, go to System > Configuration > Database > Audit Event Database > Maximum Audit Events The syslog is not stored in the same database as the audit logs. The number of syslog entries is based on the disk space so it varies based on the model. However, when the syslog storage space is full, it will overwrite the oldest logs with the newest logs via logrotate implementation. NOTE! To prevent losing audit records, set up an audit server to send a copy of the audit and syslog records to. View Audit Log and Syslog via GUI 1. Login with Administrator Role. 2. Select System > Monitoring > Audit. 3. The System log (syslog) page provides administrator with system log information for the appliance. The system log displays each message generated by the system. The following items are listed in order: Date that the message was generated. Time that the message was generated. Host that generated the message.

95 95 The message itself Select System > Monitoring > Syslog. Audit Record: View Audit Log and Syslog via CLI The command show audit-log and show syslog [filter] [number of lines]displays the audit log in reverse chronological order; the most recent audit log events are listed first. Access Syntax Example Basic show audit-log show audit-log 8 The message includes the user or source IP only if applicable. In most cases, the system generated the system log not the user and most of the time, the source IP address is the IP address of the appliance (i.e., system process resides on the system).

96 96 Audit Record: Management of Intrusion Events When the system identifies a possible intrusion, it generates an intrusion event, which is a record of the date, time, the type of exploit, and contextual information about the source of the attack and its target. For packet-based events, a copy of the packet or packets that triggered the event is also recorded. Managed devices transmit their events to the Firepower Management Center where you can view the aggregated data and gain a greater understanding of the attacks against your network assets. You can also deploy a managed device as an inline, switched, or routed intrusion system, which allows you to configure the device to drop or replace packets that you know to be harmful. The only accounts able to view intrusion events are accounts that have been assigned the Administrator or Intrusion Admin roles, and intrusion events can only be viewed via the FMC GUI, they cannot be viewed via CLI on either NGIPS or FMC. The initial intrusion events view differs depending on the workflow you use to access the page. You can use one of the predefined workflows, which includes one or more drill-down pages, at able view of intrusion events, and a terminating packet view, or you can create your own workflow. You can also view workflows based on custom tables, which may include intrusion events. Viewing Intrusion Events 1. Login with Administrator Role or Security Analyst. 2. Select Analysis > Intrusions > Events. Audit Record: The list below describes the intrusion event information that can be viewed, searched, filtered, and sorted by the system. In addition, basic contents such as date, time, and type can also be used to filter and sort. Note only Administrators and Intrusion Admins have access to the intrusion events.

97 97 NOTE! Some fields in the table view of intrusion events are disabled by default. To enable a field for the duration of your session, expand the search constraints, then click the column name under Disabled Columns. Samples of Intrusion Event (split into 3 parts) Access Control Policy The access control policy associated with the intrusion policy where the intrusion, preprocessor, or decoder rule that generated the event is enabled. Access Control Rule The access control rule that invoked the intrusion policy that generated the event. Default Action indicates that the intrusion policy where the rule is enabled is not associated with a specific access control rule but, instead, is configured as the default action of the access control policy. This field is blank if intrusion inspection was associated with neither an access control rule nor the default action, for example, if the packet was examined by the default intrusion policy. Application Protocol The application protocol, if available, which represents communications between hosts detected in the traffic that triggered the intrusion event. Application Risk The risk associated with detected applications in the traffic that triggered the intrusion event: Very High, High, Medium, Low, and Very Low. Each type of application detected in a connection has an associated risk; this field displays the highest risk of those. Count The number of events that match the information that appears in each row. Note that the Count field appears only after you apply a constraint that creates two or more identical rows. This field is not searchable.

98 98 Destination Continent The continent of the receiving host involved in the intrusion event. Destination Country The country of the receiving host involved in the intrusion event. Destination IP The IP address used by the receiving host involved in the intrusion event. Destination Port / ICMP Code The port number for the host receiving the traffic. For ICMP traffic, where there is no port number, this field displays the ICMP code. Destination User The User ID for any known user logged in to the destination host. Device The managed Sensor where the access control policy was deployed. Domain The domain of the Sensor that detected the intrusion. This field is only present if you have ever configured the Firepower Management Center for multitenancy. Egress Interface The egress interface of the packet that triggered the event. This interface column is not populated for a passive interface. Egress Security Zone The egress security zone of the packet that triggered the event. This security zone field is not populated in a passive deployment. Attachments The MIME attachment filename that was extracted from the MIME Content-Disposition header. To display attachment file names, you must enable the SMTP preprocessor Log MIME Attachment Names option. Multiple attachment filenames are supported. Headers (search only) The data that was extracted from the header. To associate headers with intrusion events for SMTP traffic, you must enable the SMTP preprocessor Log Headers option. Generator The component that generated the event. HTTP Hostname The hostname, if present, that was extracted from the HTTP request Host header. Note that request packets do not always include the hostname. To associate hostnames with intrusion events for HTTP client traffic, you must enable the HTTP Inspect preprocessor Log Hostname option.

99 99 In table views, this column displays the first fifty characters of the extracted host name. You can hover your pointer over the displayed portion of an abbreviated host name to display the complete name, up to 256 bytes. You can also display the complete host name, up to 256 bytes, in the packet view. HTTP Response Code The HTTP status code sent in response to a client's HTTP request over the connection that triggered the event. HTTP URI The raw URI, if present, associated with the HTTP request packet that triggered the intrusion event. Note that request packets do not always include a URI. To associate URIs with intrusion events for HTTP traffic, you must enable the HTTP Inspect preprocessor Log URI option. To see the associated HTTP URI in intrusion events triggered by HTTPresponses, you should configure HTTP server ports in the Perform Stream Reassembly on Both Ports option; note, however, that this increases resource demands for traffic reassembly. This column displays the first fifty characters of the extracted URI. You can hover your pointer over the displayed portion of an abbreviated URI to display the complete URI, up to 2048bytes. You can also display the complete URI, up to 2048 bytes, in the packet view. Ingress Interface The ingress interface of the packet that triggered the event. Only this interface column is populated for a passive interface. Ingress Security Zone The ingress security zone of the packet that triggered the event. Only this security zone field is populated in a passive deployment. Inline Result Actions Intrusion Policy The intrusion policy where the intrusion, preprocessor, or decoder rule that generated the event was enabled. Message The explanatory text for the event. For rule-based intrusion events, the event message is pulled from the rule. Priority The event priority as determined by the Cisco Talos Security Intelligence and Research Group (Talos). The priority corresponds to either the value of the priority keyword or the value for the classtype keyword. For other intrusion events, the priority is determined by the decoder or preprocessor. Valid values are high, medium, and low. Protocol (search only) The name or number of the transport protocol used in the connection. Snort ID (search only)

100 100 Specify the Snort ID (SID) of the rule that generated the event or, optionally, specify the combination Generator ID (GID) and SID of the rule, where the GID and SID are separated with a colon (:) in the format GID:SID. Source Continent The continent of the sending host involved in the intrusion event. Source Country The country of the sending host involved in the intrusion event. Source IP The IP address used by the sending host involved in the intrusion event. Source Port / ICMP Type The port number on the sending host. For ICMP traffic, where there is no port number, this field displays the ICMP type. Source User The User ID for any known user logged in to the source host. The intrusion events cannot be modified but they can be deleted by the Administrators or Intrusion Admins who have restricted access. When the intrusion events storage is full, the newest data will overwrite the oldest data. The intrusion event database stores a maximum of 100,000 entries. When the number of intrusion event entries greatly exceeds 100,000, the appliance overwrites the oldest records from the database to reduce the number to 100,000. NOTE! To change the maximum number of entries, go to System > Configuration > Database > Intrusion Event Database > Maximum Intrusion Events Searching Intrusion Events 1. Login with Administrator Role. 2. Select Analysis > Intrusions > Events. 3. Click on the Edit Search link.

101 Enter the value you want to search for then click Search. Sorting and filtering Intrusion Events 1. Login with Administrator Role. 2. Select Analysis > Intrusions > Events. 3. Click on the column name to sort the intrusion events based on that column. 4. To configure (i.e., filter) different column names, create a workflow via Analysis > Custom > Custom Workflows. 5. Click Create Custom Workflow. 6. Give your workflow a descriptive name. In the Table drop-down, select Intrusion Events. 7. Click Add Page. 8. Set the Sort Priority and Field for each column. There are five columns to configure. 9. Click Save. 10. Go back to intrusion events via Analysis > Intrusions > Events.

102 102 Click on the switch workflow link and choose the workflow you created Device Registration Before you manage a device with a Firepower Management Center, you must make sure that the network settings are configured correctly on the device. This is usually completed as part of the installation process. In addition, the management network should be an internal, trusted network separated physically or logically from the monitored network. Note that if you registered a Firepower Management Center and a device using IPv4 and want to convert them to IPv6, you must delete and re-register the device. The registration process requires: a) manually setting a registration key on the device to be registered, and setting the hostname or IP address of the FMC that will be managing the device; and b) manually setting the same registration key on the FMC, as well as the hostname or IP address of the device being registered. When the key and FMC IP address are set on the device, the device will periodically attempt to establish a TLS connection with the FMC, and will listen for TLS connections from the FMC. Likewise, when the registration key and device hostname or IP address are set on the FMC, the FMC will attempt to initiate a TLS connection to the device and will listen for a TLS connection from that device. When the initial TLS connection is established the device and FMC will authenticate each other using the registration key, and will each generate and exchange new X.509v3 certificates. Those certificates will be used for authentication of all subsequent TLS connections between the device and the FMC. The FMC and NGIPS generate unique certificates with distinct UUIDs at install and as part of the registration process. Those certificates are only used for communications between NGIPS and FMC, are not configurable, and do not provide interoperability with non-firepower devices. During device registration if there s an interruption to the TLS connection between the FMC and the device being registered the registration will fail, and will be automatically reattempted when connectivity is resumed. Follow the procedures below to proceed with device registration. On NGIPS AMP appliances: 1. Login with Administrator Role. 2. Select Configuration > ASA Firepower Configuration > Integration > Remote Management. 3. Click the Remote Management tab, if it is not already displaying. 4. Click Add Manager. 5. In the Management Host field, enter one of the following for the Firepower Management Center that you want to use to manage this appliance: a. The IP address b. The fully qualified domain name or the name that resolves through the local DNS to a valid IP address (that is, the hostname) 6. In the Registration Key field, enter the registration key that you want to use to setup communications between appliances. 7. Click Save.

103 103 On NGIPSv or NGIPS AMP appliances: 1. Login to the CLI with Administrator Role. 2. Use the configure manager add command. The syntax is shown below. configure manager add {hostname IPv4_address IPv6_address} [registration key] where {hostname IPv4_address IPv6_address} specifies the DNS hostname or IP address (IPv4 or IPv6) of the Firepower Management Center that manages this device. 3. To de-register a manager, just enter configure manager delete command. Please sure you delete the Device from the FMC first. On FMC 1. Login with Administrator Role. 2. Select Device > Device Management. 3. From the Add drop-down menu, choose Add Device. NOTE! To de-register a Device, just click on the trash can icon next to the Device you want to remove. 4. In the Host field, enter the IP address or the hostname of the device you want to add. 5. In the Display Name field, enter a name for the device as you want it to display in the Firepower Management Center. 6. In the Registration Key field, enter the same registration key that you used when you configured the device to be managed by the Firepower Management Center. 7. Choose licenses to apply to the device. 8. Click Register to add the device to the Firepower Management Center Custom Web Server Certificate Transport Layer Security (TLS) certificates enable Firepower Management Centers and 7000 and 8000 Series devices to establish an encrypted channel between the system and a web browser. A default certificate is included with all Firepower devices, but it is not generated by a certificate authority (CA) trusted by any globally known CA. For this reason, consider replacing it with a custom certificate signed by a globally known or internally trusted CA. You can generate a certificate request based on your system information and the identification information you supply. You can use it to self-sign a certificate if you have an internal certificate authority(ca) installed that is trusted by your browser. You can also send the resulting request to a certificate authority to request a server certificate. After you have a signed certificate from a certificate authority (CA), you can import it. Generating an HTTPS Server Certificate Signing Request When you generate a certificate request through the local configuration HTTPS Certificate page using this procedure, you can only generate a certificate for a single system. If you install a certificate that is not signed by a globally known or internally trusted CA, you receive a security warning when you connect to the system.

104 Login with Administrator Role. 2. Select System > Configuration. 3. Click HTTPS Certificate. 4. Click Generate New CSR. 5. Enter a country code in the Country Name (two-letter code) field. 6. Enter a state or province postal abbreviation in the State or Province field. 7. Enter a Locality or City. 8. Enter an Organization name. 9. Enter an Organization Unit (Department) name. 10. Enter the fully qualified domain name of the server for which you want to request a certificate in the Common Name field. NOTE! Enter the fully qualified domain name of the server exactly as it should appear in the certificate in the Common Name field. If the common name and the DNS hostname do not match, you receive a warning when connecting to the appliance. 11. Click Generate. 12. Open a text editor. 13. Copy the entire block of text in the certificate request, including the BEGIN CERTIFICATE REQUEST and END CERTIFICATE REQUEST lines, and paste it into a blank text file. 14. Save the file as servername.csr, where servername is the name of the server where you plan to use the certificate. 15. Click Close. Importing HTTPS Server Certificate If the signing authority that generated the certificate requires you to trust an intermediate CA, you must also supply a certificate chain (or certificate path). Please note only PEM format is supported. 1. Login with Administrator Role. 2. Select System > Configuration. 3. Click HTTPS Certificate. 4. Click Import HTTPS Certificate. 5. Open the server certificate in a text editor, copy the entire block of text, including the BEGIN CERTIFICATE and END CERTIFICATE lines. Paste this text into the Server Certificate field. 6. If you want to upload a private key, open the private key file and copy the entire block of text, including the BEGIN RSA PRIVATE KEY and END RSA PRIVATE KEY lines. Paste this text into the Private Key field. 7. Open any required intermediate certificates, copy the entire block of text for each, and paste it into the Certificate Chain field. 8. Click Save.

105 User and Role Management If you have Administrator Role, you can use the web interface to view and manage user accounts on a FMC or a managed device, including adding, modifying, and deleting accounts. User accounts without Administrator Role are restricted from accessing user management functions. The CLI has show users and configure users commands but they are only available for the virtual appliances. Management of the user and role is performed via web interface only. Note that all users created are TOE administrators. Viewing User Accounts From the User Management page, you can view, edit, and delete existing accounts. 1. Login with Administrator Role. 2. Select System > Users The User Management page appears, showing each user, with options to activate, deactivate, edit, or delete the user account. Audit Record: Adding New User Accounts When you set up a new user account, you can control which parts of the system the account can access. You can set password expiration and strength settings for the user account during creation. For a local account on an 8000 Series device, you can also configure the level of command line access the user will have. On the NGIPSv, use the command configure user add <username> [basic configure]. To get more CLI options, use the command configure user?. 1. Login with Administrator Role. 2. Select System > Users. 3. Click Create User.

106 In the User Name field, type a name for the new user. New user names must contain alphanumeric or hyphen characters with no spaces, and must be no more than 32 characters. 5. Do NOT check the Use External Authentication Method checkbox. 6. In the Password and Confirm Password fields, type a password (up to 32 alphanumeric characters). Strong Password Composition: The password must be at least eight alphanumeric characters of mixed case and must include at least one numeric character and one special character. It cannot be a word that appears in a dictionary or include consecutive repeating characters. 7. Set the Maximum number of Failed Logins to 3 to 7 (recommended). The default setting is 5. When the maximum number of failed login attempts is reached for any account, that account will be locked. Accounts can be unlocked by another account with the Administrator role by resetting the account activation switch ( ), and optionally editing the account properties to check the Force Password Reset on Login checkbox (see screenshot above at step 3). If all accounts with the Administrator role become locked the default admin account can be unlocked using password recovery procedures available here: technote-firesight-00.html

107 Configure the user account password options. For example, set the Minimum Password Length to 15. The default setting is 8 and the maximum allowable is If you are creating a local user through the web interface of an 8000 Series device, you can assign the level of Command-Line Interface Access for the user: Select None to disable access to the command line for the user. Select Basic to allow the user to log into the shell and to access a specific subset of commands. Select Configuration to allow the user to log into the shell and use any command line option, including expert mode if that is allowed on the appliance. 10. Check the Check Password Strength checkbox. By default, this is not selected. WARNING! This is a recommended evaluated configuration setting. 11. Do NOT click on the Exempt from GUI Session Timeout checkbox. 12. Select the access roles to grant the user. NOTE! The screenshot above shows multiple roles that exist by default. The only role evaluated under Common Criteria (CC) for administration of the entire set of CC-certified functionality is the Administrator role, while the other default roles listed below are relevant only to the CC-certified IPS functionality. IPS Administrator (or Administrator): Have all privileges and access. IPS Analyst (or Intrusion Admin): Have all access to intrusion policies and network analysis privileges but cannot deploy policies Access Admin: Have all access to access control policies but cannot deploy policies Discovery Admin: Have all access to network discovery, application detection, and correlation features but cannot deploy policies Security Analyst: Have all access to security event analysis feature 13. Click Save. Audit Record: time : (Wed Mar 1 01:27: ) event_type : Default Action subsystem : Command Line actor : admin message : Executed root-view- configure user add tester1 config result : Success action_source_ip : action_destination_ip : Default Target IP

108 108 Modifying and Deleting User Accounts Administrator can modify or delete user accounts from the system at any time, with the exception of the admin account, which cannot be deleted. On the NGIPSv, use the command configure user delete <username>. To get more CLI options, use the command configure user?. 1. Login with Administrator Role. 2. Select System > Users. 3. Click the edit icon ( ) next to the user you want to modify. 4. Modify the settings you choose and click Save. 5. To delete a user account, click the delete icon ( ) next to the user you want to delete. 6. Click OK to confirm. 7. The user account is deleted. Audit Record: time : (Wed Mar 1 01:27: ) event_type : Default Action subsystem : Command Line actor : admin message : Executed root-view- configure user delete tester1 result : Success action_source_ip : action_destination_ip : Default Target IP Change Password All user accounts are protected with a password. You can change your password 9 at any time, and depending on the settings for your user account, you may have to change your password periodically due to password expiration. You can use either the web page or the CLI 10 to change your password. Note that if password strength checking is enabled, passwords must be at least eight alphanumeric characters of mixed case and must include at least one number and one special character. When creating or changing passwords, the passwords must be composed of upper and lower case letters, numbers and special characters including blank space and!@#$%^&*() (double or single quote/apostrophe), + (plus), 9 Only user with Administrator Role can change other user password. 10 Available on Series-3 managed devices only.

109 109 - (minus), = (equal),, (comma),. (period), / (forward-slash), \ (back-slash), (vertical-bar or pipe), : (colon), ; (semi-colon), < > (less-than, greater-than inequality signs), [ ] (square-brackets), { } (braces or curly-brackets ),? (question-mark), (underscore), and ~ (tilde). Passwords cannot be a word that appears in a dictionary or include consecutive repeating characters. 1. From the drop-down list under your username, select User Preferences. 2. In the Current Password field, type your current password. 3. In the New Password and Confirm fields, type your new password. 4. Click Change. 5. The Success message appears. Audit Record: Configure Password via CLI The command configure password allows the current user to change their password. After issuing the command, the CLI prompts the user for their current password, then prompts the user to enter the new password twice. Access Basic Syntax configure password Example configure password Enter current password: Enter new password: Confirm new password:

110 110 Audit Record: Configure Time Synchronization Administrator can manage time synchronization on the managed appliance (NGIPS/NGIPSv or AMP) using the Time Synchronization page. To adhere to the Common Criteria requirements, the clock on the FMC must be set manually, but the managed device can synchronize its clock with the FMC (the connection between the managed device and FMC will use NTP over TLS). Time settings are part of the system policy. Administrator can specify the time settings either by creating a new system policy or by editing an existing policy. In either case, the time setting is not used until you apply the system policy. Note that time settings are displayed on most pages on the appliance in local time using the time zone you set on the Time Zone page (America/New York by default), but are stored on the appliance itself using UTC time. In addition, the current time appears in UTC at the top of the Time Synchronization page (local time is displayed in the Manual clock setting option, if enabled). To configure the FMC system clock, and configure how the managed device s clock will be set: 1. Login with Administrator Role. 2. Depending on whether you are configuring audit log streaming for a Firepower Management Center or a Classic managed device: Management Center Choose System > Configuration. Managed device Choose Devices > Platform Settings and create or edit a Firepower policy. 3. Click Time Synchronization on the left side of the page. 4. On the FMC: Set the time manually by selecting Manually in Local Configuration. For more details see the Setting the Time Manually section below.

111 111 Optional and recommended: If you want to serve time from the FMC to your managed devices, in the Serve Time via NTP drop-down list, select Enabled. 5. For the managed device: Click Time Synchronization on the left side of the page (under Devices > Platform Settings), then set the Set My Clock option to Via NTP from Management Center. 6. Click Save. 7. Click Deploy if you are configuring these settings for the managed devices. Select the device(s) you want to deploy the setting to and click Deploy again. Audit Record: Setting the Time Manually 1. Login with Administrator Role. 2. Select System > Configuration. 3. Click Time. 4. Select the following from the Set Time drop-down lists: Year Month Day Hour Minute

112 Click Apply. 6. The Success message appears. Audit Record: Configure Login Banner Administrator can create a custom login banner that appears when users log into the appliance using SSH and on the login page of the web interface. Banners can contain any printable characters except the lessthan symbol (<) and the greater-than symbol (>). 1. Login with Administrator Role. 2. Depending on whether you are configuring audit log streaming for a Firepower Management Center or a Classic managed device: Management Center Choose System > Configuration. Managed device Choose Devices > Platform Settings and create or edit a Firepower policy. 3. Click Login Banner. 4. In the Custom Login Banner field, enter the login banner you want to use with this system policy. 5. Click Save. 6. Click Deploy if you are configuring these settings for the managed devices. Select the device(s) you want to deploy the setting to and click Deploy again. Audit Record:

113 Inactivity Timeout Setting By default, all user sessions (web-based and CLI) automatically log out after 60 minutes (1 hour) of inactivity, unless you are otherwise configured to be exempt from session timeout. Users with Administrator Role can change the inactivity timeout value in the system policy to meet their security needs. 1. Login with Administrator Role. 2. Depending on whether you are configuring audit log streaming for a Firepower Management Center or a Classic managed device: Management Center Choose System > Configuration. Managed device Choose Devices > Platform Settings and create or edit a Firepower policy. 3. Click Shell Timeout. 4. In the Browser Session Timeout (Minutes) and Shell Timeout (Minutes) fields, enter a value from (24 hours) max. The value of 0 will disable this feature. Note that FMC checks multiple times per minute for idle sessions and terminates those sessions when they re detected, so sessions may not be terminated until seconds after the configured inactivity limit has been reached. WARNING! This is a required evaluated configuration setting and must NOT be disabled. 6. Click Save. 7. Click Deploy if you are configuring these settings for the managed devices. Select the device(s) you want to deploy the setting to and click Deploy again. Audit Record: Session Timeout Record The system will record in the audit log when a user is logged out due to inactivity. Audit Record:

114 Product Upgrade Cisco electronically distributes several different types of updates, including major and minor updates to the system software itself, as well as intrusion rule updates and VDB updates. Administrator must update the FMC before you can update the devices they manage. Cisco recommends that you use the FMC s web interface to update not only itself, but also the devices it manages. As upgrade files are uploaded to FMC, FMC will automatically verify the integrity of the files using digital signature to ensure they have not been modified since they were created by Cisco, and that they were properly signed by Cisco. If any upgrade file fails the automatic integrity verification the file will be automatically deleted and will not be available to install to the FMC or any managed device. Any upgrade file listed on FMC s Product Updates page has been verified and can be installed by an authorized administrator. The Product Updates page (System > Updates) shows the version of each update, as well as the date and time it was generated. It also indicates whether a reboot is required as part of the update. When administrator install or uninstall updates from a managed device, the following capabilities may be affected: Traffic inspection and connection logging Traffic flow including switching, routing, and related functionality