The proper way to get Cisco AnyConnect NVM data into Splunk (documentation unclear/unconventional)?

[woodcock]

I have been working from the documentation here:
https://www.cisco.com/c/en/us/support/docs/security/anyconnect-secure-mobility-client/200600-Install...
And, to a lesser degree, this blog:
https://www.splunk.com/blog/2018/09/27/a-cisco-splunk-security-integration-everyone-should-be-using....

My understanding is that the way that it works, is that the acnvm service needs to listen for incoming UDP NVM data netflow feed on port 2055 (default/arbitrary). As data comes in, acnvm processes and separates the data and sends it back out on UDP ports 20519 (for flowdata) and 20520 (for sysdata). This part is clear and fine.

We all know that it is a poor practice to use Splunk (even IHF) to directly receive network inputs, even though it is capable of doing so. Therefore, I have planned to setup acnvm on my syslog server and use syslog to receive the 20519/20520 feeds. This is where things get strange. The Cisco apps both contain an inputs.conf file with this:

[udp://20519]
connection_host = ip
source = cisconvmflowdata
sourcetype = syslog

[udp://20520]
connection_host = ip
source = cisconvmsysdata
sourcetype = syslog

[udp://20521]
connection_host = ip
source = cisconvmifdata
sourcetype = syslog

Even worse, the TA-Cisco-NVM/default/eventtypes.conf file contains this:

[cisco_nvm_data]
search = source=cisconvmflowdata sourcetype=syslog
#tags = network,communicate

And the TA-Cisco-NVM/default/props.conf file contains this:

[source::cisconvmflowdata]
FIELDALIAS-dp-for-nvm = dp as dest_port
...

These make clear that the authors of the app expect that the source and sourcetype values to remain unchanged with these very unsatisfactory and unconventional values.

Short of a VERY good explanation of why I should not, I am planning to make the following changes:
Deploy the apps with this local/inputs.conf:

[udp://20519]
disabled = true

[udp://20520]
disabled = true

[udp://20521]
disabled = true

Instead, I am going to configure syslog-ng to receive this information. Obviously this means that the source value will change. In addition, I plan on using these sourcetypes: { cisco:nvm:flowdata, cisco:nvm:sysdata, cisco:nvm:ifdata }

This also means that I must make analogous accommodating changes to props.conf, eventtypes.conf, and *.xml dashboard files. Hopefully the authors of this app will consider doing the same. What do you say, readers? Also, @nvzFlow, why was it not done/documented this way in the first place?

[nvzFlow]

This will be addressed shortly in version 2.0 which has a number of new and exciting enhancements.

[woodcock]

Be sure to post a followup announcement here when it drops!

[nvzFlow]

Let us know what you think of the new 2.x version

[woodcock]

I will followup here. Thank you for considering my suggestions.

[Besmir]

Dear Colleagues,

Any improvement in this case ! I see the same situation with Cisco NVM Addons Version 2.0.187 .

Thank you .

[nvzFlow]

Hi, versions 2 and later have the mappings in the TA (https://splunkbase.splunk.com/app/4221/) as described in this thread. Is there some other issue you are seeing?