Cisco Security Cloud Add_on vs. Splunk Add-On for Cisco ASA

[kfsplunk]

Onboarding Cisco FTD firewalls presents the choice of which Add-On to use. Apparently Cisco FTD firewalls run both ASA core and FTD core which means they send different types of events. The ASA events are best handled with cisco:asa sourcetype whereas the FTD events are handled by cisco:ftd:syslog. However, all events in our environment use %FTD to tag their events, so this makes it harder to differentiate.

What Add-On is the preferred Add-On (I'd expect the Cisco Security Cloud, but it still has some flaws)? And how should we get these events in with the correct sourcetype.

My suggestion would be to send all events with cisco:asa sourcetype and include a transform which checks if the FTD code is in the 43k range, e.g. REGEX=%FTD-\d-43\d+.

[livehybrid]

Hi @kfsplunk 

What distinction do you need to make between the logs? You mention that they become hard to differentiate but I think you could probably create an eventtype or use a field extraction to determine if the FTD code is in the 43k range like you mentioned. 

I would avoid onboarding it as one sourcetype and then using props/transforms to overwrite the sourcetype because you risk breaking the built-in field extractions and CIM mappings you get from the app's configuration.

However, If you want to segregate into a separate index, or change the source to distinguish them apart then you could do this with props/transforms.

The Cisco Security Cloud app does look a lot richer in terms of functionality and dashboards (if that helps you) but also gets much more frequent updates than the ASA app, not that this should necessarily sway your decision but might help! 

🌟 Did this answer help you? If so, please consider:

• Adding karma to show it was useful
• Marking it as the solution if it resolved your issue
• Commenting if you need any clarification

Your feedback encourages the volunteers in this community to continue contributing

[kfsplunk]

Thanks for your reply. But if you look at some example log entries, it's fairly obvious that it's 2 different sourcetypes. The structure is completely different. I'd like to split these events at the source. The field extractions, aliases and CIM-ing of the data is just completely different for the ASA formatted logs and the FTD formatted logs. Hence, I'm wondering why this is not addressed in the Cisco Security Cloud Add-On. It has an out-of-the box "change sourcetype transform" for cisco:asa events to change to cisco:ftd:syslog when it has %FTD code and the for cisco:ftd:syslog events a transform to change to cisco:asa when it has a %ASA code.

However, all events arrive with %FTD code here, so the default behaviour doesn't work.

You can see from these 2 examples the big difference (FTD events with key value pairs separated by : ASA events more sentence like structure.

313004	<164>2025-07-02T11:13:26Z CF1 : %FTD-4-313004: Denied ICMP type=0, from laddr 172.143.19.36 on interface IT-1 to 10.40.72.24: no matching session	ASA
430004	<13>2025-07-02T11:29:03Z CF2 : %FTD-1-430004: DeviceUUID: 104cb27c-227a-11ee-b7ae-880bf955e0c1, InstanceID: 5, FirstPacketSecond: 2025-07-02T11:29:00Z, ConnectionID: 14812, SrcIP: 172.19.47.25, DstIP: 10.30.71.65, SrcPort: 64523, DstPort: 445, Protocol: tcp, FileDirection: Download, FileAction: Malware Cloud Lookup, FileSHA256: c885df893496d5c28ad16a1ecd12e259e191f54ad76428857742af843b846c53, SHA_Disposition: Unavailable, SperoDisposition: Spero detection not performed on file, FileName: DAC\BGinfo\Bginfo.exe, FileType: MSEXE, FileSize: 2198952, ApplicationProtocol: NetBIOS-ssn (SMB), Client: NetBIOS-ssn (SMB) client, WebApplication: SMBv3-unencrypted, FilePolicy: Malware Detect, FileStorageStatus: Not Stored (Disposition Was Pending), FileSandboxStatus: File Size Is Too Large, IngressVRF: Global, EgressVRF: Global	FTD