Firepower 7.4 new features

on

 

1. TLS Server Identity Discovery

TLS 1.3 encrypts server certificate, so it breaks application and URL control. To resume full visibility, full decryption is required.
Note: in TLS 1.3 SNI is still cleartext, FTD still can use SNI solely to determine URL or application, but without server side certificate, the confidence and reliability is getting low.
SNI can be spoofed or empty,
New feature (from FTD 6.7) TLS Server Identity Discovery without requiring SSL decryption


Read: Network Security Efficacy in the Age of Pervasive TLS Encryption

https://blogs.cisco.com/security/network-security-efficacy-in-the-age-of-pervasive-tls-encryption?ccid=cc000155&dtid=oblgcdc000651&oid=pstsc023056

FTD intercepts a TLS 1.3 handshake message from a client to an unknown server and then opens a side connection to this server to discover its identity. FTD uses the same source IP address and TCP port as the client and mimics the ClientHello message as much as possible to get the server to present its true certificate. Once the server’s identity is established, FTD applies an appropriate application or URL policy to permit or deny access, or even engage full TLS decryption. It also caches the server’s identity to avoid repeated identify lookups for multiple clients that access the same resource. 


FMC 7.4

























 Encrypted Visibility Engine (EVE).


EVE works by fingerprinting the Client Hello packet in the TLS handshake. By identifying specific application fingerprints in TLS session establishment, the system can identify the client process and take appropriate action (allow/block).
By using fingerprints of known malicious processes, EVE technology can also be used to identify and stop malware.
Release 7.4 introduces the capability to block traffic based on EVE Threat Confidence Score


ACP Advanced Settings


























Read the following link regarding how to view events and enable the applications.
https://secure.cisco.com/secure-firewall/docs/encrypted-visibility-engine



Elephant Flow Detection

Elephant flow detection was introduced in release 7.1. Release 7.2 allows easier customization and the option to bypass or even throttle elephant flows. This capability replaces the Intelligent Application Bypass feature for Snort 3 devices running release 7.2 or later.

An elephant flow is a long-lived connection and is generally quite large in the number of bytes transferred.
Elephant flows are important because they can potentially consume an inordinate amount of CPU resources. This can impact other competing flows for detection resources and cause issues such as increased latency or packet drops

Users can configure three elephant flow detection outcomes:

  1. Alerting - by adding a note to the Reason field in a connection event.
  2. Flow bypass* - this can be select for all flows or just flows matching selected application criteria.
  3. Flow throttling* - flows can be throttled by adjusting TCP window sizes to reduce the flow's CPU usage and prevent consequences such as high latency or packet drops.

📘

Note

* Taking actions on an elephant flow is not supported on Firepower 2100 Series devices.



https://secure.cisco.com/secure-firewall/docs/elephant-flow-throttling 



Merge the Management and Diagnostic Interfaces

FTD 7.4 and later supports a merged Management and Diagnostic interface

After merge, the "management" interface is now shown in read-only mode on the Interfaces page.

You can add static routes for the Linux routing table at the CLI using the configure network static-routes command










Comments

Post a Comment