We are running the Cisco Security Cloud app in the Splunk Cloud.
It does not seem to parse events of the `[cisco:ftd:syslog]` sourcetype -- The app does have that stanza in its `props.conf` file.
Any one has the same issue?
2025-08-20 Edit: I installed the CiscoSecurityCloud app on a test instance, uploaded some FTD logs, with timestamp in rfc3339 format, the app fails to parse those logs -- I tried uploading one file with sourcetype set to [cisco:ftd:syslog] and another one set to [cisco:asa]. Both data sets ended up in Splunk with `sourcetype=cisco:ftd:syslog` without the fields.
It seems the CiscoSecurityCloud app isn’t correctly parsing fields from your Cisco FTD syslog data—likely due to a misconfiguration in props/transforms or a format mismatch. A good starting point is to check the syslog.conf or your app's props.conf and transforms.conf files to ensure the correct TIME_FORMAT, field extractions, and source types are in place.
If you're working with a Windows/macOS GUI, you might also consider using an APK file editor (like APKTool, JADX, or APK Editor Pro)—not for Splunk specifically, but as a familiar toolset to browse configurations or reverse-engineer similar structured files and gain insight into file layout or logic flow.
Hi @ww9rivers
Can you confirm that you are running your search in Smart or Verbose mode and not Fast mode please?
What do you see in the interested fields on the left?
🌟 Did this answer help you? If so, please consider:
Your feedback encourages the volunteers in this community to continue contributing
I have test smart mode and verbose mode. Does not change the results.
The other funny thing is, under the standard list of fields shown on the left side, there is "84 more fields".
I click that, and get these strange stuff👇
This suggests that timestamp extraction and parsing is not working. Just search for index and sourcetype and give first 10 logs and that should be enough for defining the parsers if the source log format does not change. If there are multiple sources and different formats of the logs, will need logs for each of the pattern.
Also, it is suggestible to have only one single log format for one source. So, check if the logs are following a unified pattern throughout.
Thanks,
Tejas.
Thank you.
I exported 5 events from the FTD device:
Aug 15 10:56:42 <FTD-IP-redacted> : Aug 15 14:56:41 UTC: %FTD-session-6-302015: Built inbound UDP connection 2853365636 for int-inside:<INSIDE-IP>/54408 (<PUBLIC-IP>/54408) to ext-outside:<OUTSIDE-IP>/443 (<OUTSIDE-IP>/443)
Aug 15 10:56:42 <FTD-IP-redacted> : Aug 15 14:56:41 UTC: %FTD-session-4-106023: Deny udp src int-inside:<INSIDE-IP>/53542 dst ext-outside:<OUTSIDE-IP>/53 by access-group "CSM_FW_ACL_" [0xbb8ba4cf, 0x53f0f2f7]
Aug 15 10:56:42 <FTD-IP-redacted> : Aug 15 14:56:41 UTC: %FTD-session-6-302013: Built inbound TCP connection 2853365631 for int-inside:<INSIDE-IP>/55126 (<PUBLIC-IP>/39066) to ext-outside:<OUTSIDE-IP>/443 (<OUTSIDE-IP>/443)
Aug 15 10:56:42 <FTD-IP-redacted> : Aug 15 14:56:41 UTC: %FTD-session-6-302015: Built inbound UDP connection 2853365629 for int-inside:<INSIDE-IP>/51617 (<PUBLIC-IP>/51617) to ext-outside:<OUTSIDE-IP>/443 (<OUTSIDE-IP>/443)
Aug 15 10:56:42 <FTD-IP-redacted> : Aug 15 14:56:41 UTC: %FTD-session-4-106023: Deny udp src int-inside:<INSIDE-IP>/62133 dst ext-outside:<OUTSIDE-IP>/53 by access-group "CSM_FW_ACL_" [0xbb8ba4cf, 0x53f0f2f7]
I think I may need to change the message logging format to remove the rsyslog server timestamp and other added elements.
The timestamp fields you see in the interested fields are likely caused by the syslog_auto_kv transform which is applied:
[syslog_auto_kv]
REGEX = (\s(?<_KEY_1>[^,%]+):\s(?<_VAL_1>[^,]+))
REPEAT_MATCH = true
It looks like the "Aug 15 10:56:42 <FTD-IP-redacted> : Aug 15 14:56:41 UTC: " is being added by something else - your rsyslog server? Is it possible to prevent this being added? As far as I know the FTD log should look something like this:
%FTD-session-2-106016: Deny IP spoof from (10.103.55.11) to 192.168.25.12 on interface INSIDE
Ultimately, the props/transforms extracting the fields will not behave correctly if the log is prefixed with something like this.
🌟 Did this answer help you? If so, please consider:
Your feedback encourages the volunteers in this community to continue contributing
Hey @ww9rivers,
Can you share a couple of logs that you receive with masking sensitive information? If the TA parsing doesn't work, we can always customize the parsing parameters as per the log pattern we receive. I'm not sure if the issue is being faced by multiple customers, but if you can provide the logs, we can define the necessary parameters for parsing the data efficiently.
Thanks,
Tejas.
"A couple of logs"? Like what? This is running in the Splunk Cloud, maybe you could give me a search to show what logs are of interest?