Incorrect rewrite of cisco:asa logs to cisco:ftd

[inspired]

Was the issue replicated by support?
N/A

What is the sc4s version ?
3.36.0

Which operating system (including its version) are you using for hosting SC4S?
Linux

Which runtime (Docker, Podman, Docker Swarm, BYOE, MicroK8s) are you using for SC4S?
Podman

Is there a pcap available? If so, would you prefer to attach it to this issue or send it to Splunk support?
N/A

Is the issue related to the environment of the customer or Software related issue?
Software

Is it related to Data loss, please explain ?
NO

Last chance index/Fallback index?
N/A

Is the issue related to local customization?
NO

Do we have all the default indexes created?
YES

Describe the bug
SC4S incorrectly assigns fields that should be sourcetyped as cisco:asa as cisco:ftd due to a simple logic looking for the presence of the pattern "%FTD". This breaks field extractions etc for data in this format. A better way would be to look for the presence of both %FTD and DeviceUUID: because these events should be rewritten as cisco:ftd:syslog to work with the Cisco Security Cloud app: https://splunkbase.splunk.com/app/7404

A workaround is to create /opt/sc4s/local/config/filters/app-dest-cisco-ftd_selective-postfilter.conf

block parser app-dest-cisco-ftd_selective-postfilter() {
    channel {
        rewrite {
            r_set_splunk_dest_update_v2(
                sourcetype('cisco:ftd:syslog')
            );
        };
    };
};

application app-dest-cisco-ftd_selective-postfilter[sc4s-postfilter] {
    filter {
        message('%FTD') and message('DeviceUUID:')
    };
    parser { app-dest-cisco-ftd_selective-postfilter(); };
};

In addition the Cisco Security Cloud app needs a local modification in local/transforms.conf for Splunk Enterprise or in a separate private app AAA_CiscoSecurityCloud/default/transforms.conf for Splunk Cloud:

[set_ftd_sourcetype]
REGEX = %FTD.*?DeviceUUID:

This should be added to the docs.

To Reproduce

1. Ingest Cisco ASA/FTD logs.
2. Logs will come in with both this type of format:
   %FTD-6-302020: Built inbound ICMP connection for faddr 1.1.1.1/398 gaddr 2.2.2.2/0 laddr 3.3.3.3/0 type 8 code 0
3. And this type of format:
   %FTD-1-430004: DeviceUUID: 57553658-e8c3-11e9-b00e-8c3c2efaf16d, InstanceID: 44, FirstPacketSecond: 2025-05-23T10:49:20Z, ConnectionID: 32922, SrcIP: 2.2.2.2, DstIP: 1.1.1.1, SrcPort: 52401, DstPort: 80, Protocol: tcp, FileDirection: Download, FileAction: Malware Cloud Lookup, FileSHA256: b5fc166ecb732bbe47db5a721b43ae62ea58a3abd020401d1393de9e1b1591d1, SHA_Disposition: Unknown, SperoDisposition: Spero detection not performed on file, FileName: 15892776_8aa6c91ec10569163a15156de8aa43b33a3a48b2.cab, FileType: MSCAB, FileSize: 8323, ApplicationProtocol: HTTP, Client: Windows Update, WebApplication: Microsoft Update, FilePolicy: DSV Internal File Policy, ArchiveSHA256: b5fc166ecb732bbe47db5a721b43ae62ea58a3abd020401d1393de9e1b1591d1, ArchiveFileName: 15892776_8aa6c91ec10569163a15156de8aa43b33a3a48b2.cab, ArchiveFileStatus: Extracted, URI: /c/msdownload/update/others/2014/12/15892776_8aa6c91ec10569163a15156de8aa43b33a3a48b2.cab
4. With the current behaviour the former log sample will be rewritten as cisco:ftd and will not have any field extractions because cisco:ftd (or cisco:ftd:syslog) only has extractions for the latter sample

[sbylica-splunk]

Looks like this bug may be caused by new message types introduced by FTD:
https://www.cisco.com/c/en/us/td/docs/security/firepower/Syslogs/b_fptd_syslog_guide/syslogs4.html#id_87690

It will probably require changes to app-cisco-cisco_asa.conf and app-cisco-cisco_ftd.conf, we'll discuss this and get back to you.

[sbylica-splunk]

Just FYI we have implemented changes that address this issue, they should be a part of the next release