Cisco Secure Firewall - Blocked Connection
Description
The following analytic detects a blocked connection event by identifying a "Block" value in the action field. It leverages logs from Cisco Secure Firewall Threat Defense devices. This activity is significant as it can identify attempts from users or applications initiating network connection to explicitly or implicitly blocked range or zones. If confirmed malicious, attackers could be attempting to perform a forbidden action on the network such as data exfiltration, lateral movement, or network disruption.
Query · spl
`cisco_secure_firewall` EventType=ConnectionEvent action IN ("Block with reset", "Block", "blocked")
| stats count min(_time) as firstTime max(_time) as lastTime by src, dest, dest_port, transport, rule, url, EVE_Process, action
| `security_content_ctime(firstTime)`
| `security_content_ctime(lastTime)`
| `cisco_secure_firewall___blocked_connection_filter`
Implementation guide
This search requires Cisco Secure Firewall Threat Defense Logs, which
includes the ConnectionEvent EventType. This search uses an input macro named cisco_secure_firewall.
We strongly recommend that you specify your environment-specific configurations
(index, source, sourcetype, etc.) for Cisco Secure Firewall Threat Defense logs. Replace the macro definition
with configurations for your Splunk environment. The search also uses a post-filter
macro designed to filter out known false positives.
The logs are to be ingested using the Splunk Add-on for Cisco Security Cloud (https://splunkbase.splunk.com/app/7404).
The access policy must also enable logging.
Known false positives
- Blocked connection events are generated via an Access Control policy on the Firewall management console. Hence no false positives should be present.
Analyst notes
Known false positives: Blocked connection events are generated via an Access Control policy on the Firewall management console. Hence no false positives should be present.