About mreynov_splunk

mreynov_splunk · ‎11-08-2018

FIELDALIAS behavior change in 7.2: FIELDALIAS for a specific field overwrites the field value, regardless of whether it is NULL or not. In earlier versions, FIELDALIAS did NOT overwrite the value in case of NULL. Solution to this is to use COALESCE: FIELDALIAS-s_computername = s_computername as host should be something like EVAL-host=coalesce(s_computername, host)

mreynov_splunk · ‎10-30-2018

This is a known issue in the addon which stems from Checkpoint OPSEC SDK only working with 32-bit OS flavors: http://docs.splunk.com/Documentation/AddOns/released/OPSEC-LEA/Releasenotes OPSEC SDK is no longer maintained and Checkpoint recommends Log Exporter instead (which is based on syslog integration and thus avoids OPSEC all together): https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk122323

mreynov_splunk · ‎09-26-2018

Yes! Stand by - its going to be a little while, but we are working on it right now.

mreynov_splunk · ‎08-31-2018

This is not a best practice per ce, more a list of backward-compatibility risk assessment considerations: does the add-on have any custom modular inputs? (check the bin folder in the app directory) does the add-on have custom UI? If the answer is "yes" the risk of installing on newer Splunk is higher and more rigorous testing is warranted. Many addons, however, such as Juniper have only Splunk configurations (.conf files) and these features stay quite stable as we move from version to version of Splunk enterprise. **This may change in the future. If above is too generic, it's always a good practice to install the add-on on a staging environment before attempting a production upgrade and many add-ons should just work. As for the specific add-ons in this question: - Juniper is very close to a certified release - Infoblox is on the list of items to be worked on in the next 2 months - Recommended and supported solution for OKTA ingestion is now developed by OKTA and available here: https://splunkbase.splunk.com/app/3682/

mreynov_splunk · ‎05-16-2018

Integration works as follows: when incident data hits SNOW, it is first entered into an interstitial table "Splunk Incident". Therefore to make this work you will need to adjust that table definition on the SNOW side. (This is part of the "Splunk Integration" SNOW app. Then you will need to change a few files, depending on the type of action you want to use (alert has custom UI, for example). With the above said, let me ask you this: - can you include this data in the description field? - can you set these fields using custom workflow on the SNOW side?

mreynov_splunk · ‎02-06-2018

This is not a supported scenario and will cause intermittent authorization errors and data loss.

mreynov_splunk · ‎11-16-2017

I believe it should, the key is to include "kms:Decrypt" in the permission policy: http://docs.splunk.com/Documentation/AddOns/released/AWS/ConfigureAWSpermissions

mreynov_splunk · ‎09-04-2017

Your props look all mangled. Here is my copy: [snow:em_event] EXTRACT-snow_em_event_alert = alert="(?P<snow_em_event_alert>[^\s"]*)" # For display_value = all, uncomment the following. #FIELDALIAS-severity_name = dv_severity AS severity_name # For display_value = all, comment the following. LOOKUP-severity_name = severity_lookup severity AS severity OUTPUTNEW severity_name AS severity_name I would suggest reinstalling the addon.

mreynov_splunk · ‎05-23-2017

Incremental S3 does not yet support KMS ootb

mreynov_splunk · ‎04-06-2017

ALB is not yet supported, but it is coming in a future version Incremental currently supports only 4 different types of data, so setting the sourcetype to something unsupported will not help, unless you create the props/transforms by yourself

mreynov_splunk · ‎03-06-2017

yes, it is on the roadmap for the next version.

mreynov_splunk · ‎02-10-2017

there are a couple of things to consider - having a rising column will actually add "order by" clause to your query, so not sure why you were experiencing this - for catching up on historical data, you can do a batch input to ingest everything and then create a new rising column input to stay up to date - timestamps are not recommended for rising columns: https://answers.splunk.com/answers/400221/why-is-using-a-timestamp-column-for-the-rising-col.html

mreynov_splunk · ‎01-05-2017

dynamic key names will slow things down even more. Why not indexed_extractions = JSON instead?

mreynov_splunk · ‎01-04-2017

that's great, but there is still a bug in the addon, or rather a behavior we want to support - would be good to get that sample anyway, even if there is a customization that serves as a workaround. Also, hopefully you added this in local/props.conf, because if this is in /default/props, it WILL get overwritten on upgrade.

mreynov_splunk · ‎01-03-2017

CIM validator is stricter, I guess.

mreynov_splunk · ‎01-03-2017

This may be permissions issue... When you say "search used by the data model" - are you using the pivot feature?

mreynov_splunk · ‎01-03-2017

timestamp extraction is not handled through input, but rather native Splunk behavior or props/transforms override. For vpcflow logs it's the former. The props for this sourcetype extract in the following format: [aws:cloudwatchlogs:vpcflow] EXTRACT-all=^\s*(?P[^\s]+)\s+(?P[^\s]+)\s+(?P[^\s]+)\s+(?P[^\s]+)\s+(?P[^\s]+)\s+(?P[^\s]+)\s+(?P[^\s]+)\s+(?P[^\s]+)\s+(?P[^\s]+)\s+(?P[^\s]+)\s+(?P[^\s]+)\s+(?P[^\s]+)\s+(?P[^\s]+)\s+(?P[^\s]+) This is the format it expects: 2 000000000000 eni-00000000 #ipv4-1# #ipv4-2# #port-1# #port-2# #protocol# #packets# #bytes# #timestamp# #timestamp# #action# OK It seems Splunk is getting confused about the timestamp in your vpcflow events: instead of grabbing the start_time, it finds the account which also looks like a timestamp. This does seem like a bug, could you share a sample event for me to try?

mreynov_splunk · ‎01-03-2017

Did you configure through UI or conf files? Basically, please share the config.

mreynov_splunk · ‎01-03-2017

it should be cloudwatchlogs, I think its getting confused about the format.

mreynov_splunk · ‎01-03-2017

"The "deployment-apps" directory is a link to the "apps" directory." ---> this is why: apps are updated with local metadata and other local settings. deployment-apps are for distributing. These should not be shared.

Posts	141
Solutions	12
Karma Given	63
Karma Received	69
Member Since	‎01-07-2015

Online Status	Offline
Date Last Visited	‎06-05-2020 02:04 AM

Re: Splunk 7.2.0 - Field Aliases incorrect behavio...

Re: Splunk Check Point LEA OPSEC error : Fatal err...

Re: Support for BRO IDS in splunk 7

Re: Best practice for Splunk Upgrade 6.x to 7.x wh...

Re: Splunk Add-on for ServiceNow: How to populate...

Re: How do I get scan data from Tenable.io to Splu...

Re: Splunk Add-on for AWS: Does this add-on suppor...

Re: Splunk App for ServiceNow: Error - "Could not ...

Re: Splunk Add-on for Amazon Web Services: How to ...

Re: Splunk Add-on for Amazon Web Services: Why are...

Re: Splunk Add-on for Microsoft Azure: Azure Secur...

Re: Splunk DB Connect 2: DB Input does not collect...

Re: How to parse json which makes up part of the e...

Re: Splunk Add-on for Amazon Web Services: How to ...

Re: How to troubleshoot why SA-cim_validator is sh...

Re: How to troubleshoot why SA-cim_validator is sh...

Re: Splunk Add-on for Amazon Web Services: How to ...

Re: Splunk Add-on for Amazon Web Services: How to ...

Re: Splunk Add-on for Amazon Web Services: How to ...

Re: Why am I getting error "Failed to tarAndChksum...