Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TA naming scheme #11

Open
brandonganem opened this issue May 25, 2016 · 4 comments
Open

TA naming scheme #11

brandonganem opened this issue May 25, 2016 · 4 comments

Comments

@brandonganem
Copy link

Just a quick note - Splunk Enterprise Security has an import filter for TAs:
app_regex = (search)|([ST]A-.)|(Splunk[ST]A_.)|(DA-ESS-.)|(Splunk_DA-ESS_._)

This means when the TA is named "TA_" it will not import into ESS. It would be great if the name was updated to use "TA-" for auto import in ESS.

@doksu
Copy link
Owner

doksu commented May 30, 2016

Hi Brandon,

Thanks very much for opening this issue.

The Linux Auditd app for Splunk was originally developed for the vendor's first "Apptitude" competition. One of the rules in the competition was that this document (http://challenges.s3.amazonaws.com/splunk/Best%20Practices%20App%20building.pdf) was to be followed exactly. On page 4 it specified the convention 'TA_vendor-product' so I used that even though at the time I thought it was at odds with the more widely accepted 'TA-' convention. It seemed the vendor was moving in the 'TA_' convention direction, similar to the sourcetype naming convention change they made from _ to :.

I considered renaming the app to resolve the issue you've raised, but that too could be problematic and so I raised an RFE with support to add '|(TA_.)' to the app_regex. In the interim, my suggestion would be to create a local app_regex with 'TA_'; I should add this to the documentation :).

Thanks,
Doksu

@brandonganem
Copy link
Author

Thanks doksu. It isn't entirely surprising that their best practices for some things are out of alignment with their communication for other best practices.

For example, their new addon builder utilizes the "TA_" naming scheme: http://docs.splunk.com/Documentation/AddonBuilder/latest/UserGuide/NameProject

Ultimately it isn't a huge deal either way. The work around you suggested is fine, but not entirely upgrade safe for ES (what if they change the whitelist? The whole key gets overridden in local so your changes are immortal). That's not really this app's fault, it's more of a design fault with ES. The other work around is to rename the TA which is what i've done. Not a big deal.

Thanks!

@doksu
Copy link
Owner

doksu commented Jun 27, 2016

Just putting a note here with a link to an issue someone else was having with the TA's naming convention and ES: https://answers.splunk.com/answers/418287/cim-is-not-getting-validated-after-splunk-upgrade.html#answer-419124

@doksu
Copy link
Owner

doksu commented Jun 27, 2016

I've asked Jack Coates (PM for the add-on builder app) about this issue and he informed me that use of the 'TA_' convention has been "fixed" as a bug: http://docs.splunk.com/Documentation/AddonBuilder/1.0.1/UserGuide/Fixedissues

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants