Author: Brian Davenport

If you are ever out to dinner with friends talking about which network devices have the strangest exports, the Cisco ASA will certainly be near the top of the list. The ASA is truly unlike any other firewall in what it can export in its NetFlow Secure Event Logging (NSEL) format. When gathering ASA flows, you will get most of what you are used to with standard version 5 or 9 of NetFlow (minus DSCP Marking and TCP Flags). The interesting bit is its unique elements:

Elements Unique to Cisco ASA NSEL Data

• Firewall Event:
  • ID 1 –  Flow Created: Flow added to cache (conversation starts)
  • ID 2 –  Flow Deleted: Flow deleted from cache (conversation ends)
  • ID 3 –  Flow Denied: (conversation was blocked)
  • ID 5 –  Flow Updated: In the cache as an active flow (conversation is ongoing)
• Firewall Extended Events:
  • Flow Denied:
    • ID 1001: Flow was denied by an ingress ACL
    • ID 1002: Flow was denied by an egress ACL
    • ID 1003: Typically, ICMP to the ASA being denied, but could be other reasons.
    • ID 1004: The first packet on the TCP connection wasn’t a SYN packet
  • Flow Deleted: These IDs will be somewhere in the 2000s
• Ingress Access List: What ingress ACL was in play during a flow
• Egress Access list: What egress ACL was in play during a flow
• Username: Interestingly, the Cisco ASA includes VPN Username in the flow records. So if your ASA is a VPN appliance, you can gain some valuable insight into what users are doing during VPN sessions. I have worked with customers to set up custom alerts to let them know if VPN connections are being established from outside of the USA or other approved regions.
• NAT Information: ASA keeps track of and exports information regarding how IPs and ports are translated by the firewall. Useful for gaining visibility into internal users when investigating traffic entering the firewall.

As you can see, there is a wide variety of elements that are specific to the ASA. By harnessing these data elements, you can get historical reports on all of the ACL activity the firewall has seen.

For example, let’s say there is an overly permissive policy that allows any host to communicate to a disaster recovery provider off prem. A firewall admin may want to lock this policy down to the IP addresses he believes should be making this communication. But prior to making this change on the firewall, we could look back over a couple months of data and make sure we aren’t going to be inadvertently blocking any IP addresses we didn’t think of. Furthermore, we could check to see if any hosts are communicating with the disaster recovery site that we wouldn’t expect.

Taking a look at an example from Scrutinizer, we can see some peculiar activity from our marketing team. As a firewall administrator, I could investigate who from marketing was attempting to connect to the AWS Backup Servers and what time of day it’s occurring. Then I can determine if this communication should be allowed or investigated further.

These type of reports nicely complement companies’ compliance initiatives. Being able to prove that ACLs are doing their job over extended periods of time tells a great story during an audit. That said, when considering where to store this NSEL data, if compliance is a priority, make sure the solution you choose has customizable data retention settings to ensure the data is there when you need it.

When it comes to reporting on ACLs within a flow collection system, powerful filtering mechanics will be crucial to this endeavor. To get started collecting these, you can either use ASDM or the CLI to configure the Cisco ASA. Once the data is flowing into Scrutinizer, you would simply be running reports specific to those events.

Contact our support team if you want to learn more about these integrations, or need help with configurations.