We are working on a release for Cloud. Stay tuned, thanks! ... View more

Those two specifically are NOT designed to avoid the ingest of similar data over time. They were designed as a "pull all each time" to account for finding "missing" or other similar types of searches that require the entire data set of agents each time.  I have entered an issue into the project to investigate what can be done at those scales for the applications endpoint. I'm not sure we can do anything without S1 changing endpoint supports, but we will take a look and try. You should be able to up the bulk_import_limit to 2,000,000 and see if that helps pull in the data and get it all. Additionally, it is multi-threaded. If you have a sufficiently beefy HF, find the bin/s1_client.py file in the app root.  Update line line 186 per below p = mp.Pool(10) CHANGE IT TO p = mp.Pool(50) This will increase the amount of available threads to the paginator, and you should see an increase in ingest.  Keep increasing it as you see fit, and document it was changed. On an app upgrade, it will be overwritten. We cannot make that configurable, as it might violate Splunk Cloud requirements. ... View more

So  the Agents and Applications are non-timestamp aware data ingest, by design. Agents might be running more than 1 hour, causing a backup, but should not run for days. Adjust your interval to 86400 for both agents and applications and see if it calms down and doesn't duplicate the data. Applications API doesn't support time: https://usea1-partners.sentinelone.net/api-doc/api-details?category=agents&api=applications Agents can support time, but the design was not to. This allows for lookup building for other data, even if the agents have been created or updated past the checkpoint time. https://usea1-partners.sentinelone.net/api-doc/api-details?category=agents&api=get-agents Threats should be time-aware, and "respect" the checkpoint. ... View more

Good afternoon @guarisma ! Unfortunately, the "rank" field is deprecated in version 2.1 of the SentinelOne API. v5.1.X of the Splunk Integration uses v2.1 of the API, hence the discrepancy. Please direct further questions to SentinelOne support for follow up. Thank you! ... View more

@nickmdps  Apologies for the delay. That app (DA-ESS-cbresponse) is deprecated. Please use https://splunkbase.splunk.com/app/5624/ . Thanks! ... View more

@robayersApologies for the delay, but that should be fixed in the latest release. Thanks! ... View more

Yes, it is. We are currently in the process of upgrading for Python 3 and Splunk 8. No exact timeframe yet . Thanks! ... View more

Each application (authentication, network traffic, etc...) has a README.md that contains the documentation for the application. ... View more

Thank you for the suggestion. I can add it as an improvement. ... View more

Version 3.0.5 is not available for download via Cloud. The apps have since been upgraded to v3.0.9 and are allowed for Splunk Cloud. Thanks! ... View more

@andreibanaru v1.1.1 was released to fix that bug. Thanks. ... View more

Please try v1.1.x. The excessive memory usage can occur when pulling very large datasets on a first run. It's a race condition, ie can't pull all the events, so can't write out the checkpoint because it fails. Then trys to pull all the events again... and so we go. v1.1.x addresses this. Curious: Do you have the Netskope for Web product? ... View more

This bug is also present in v1.1.0, so it will be fixed in v1.1.1. ... View more

v1.1.0 and v1.0.5 do contain this bug. The macro behind the dropdown was reconfigured, but this dropdown was missed. Look for a new maintenance release to fix this. The app will also change from "Host Input" to something more clear, as it was intended to be the source Netskope tenant. The macro should be changed to: [netskope_configured_inputs] definition = tstats count where sourcetype=netskope:* by host | fields host Thanks! ... View more

@andreibanaru What is the version you are using? ... View more

The credentials are automatically handled when the modular input is configured. The username and password are stored in the credential store. If you refresh the page, you'll see the credential on the tab (see note below). It uses a guid to associate the credential with the input. You shouldn't have to manually work with credentials. EDIT After further review and a check of the code, the IA-Code42ForSplunk app does indeed query only within it's own namespace and not an ALL call to the endpoint. Check the developer panel of the browser that is in use. The other credentials on your system appear to have been shared globally, which is then included within the namespace IA-Code42ForSplunk . I checked on a dev instance, and a search/local created app only export credential DID NOT SHOW in the Credential Tab. I modified the credential metadata to system and there it was, exactly as working within the namespace would predict. This can be corrected with JavaScript filtering, but there is no "native" solution to pull only an app's config, it's related to namespace and permissions. /services/storage/passwords is also not a valid endpoint, since the call is filtered to include all of the credentials the user has access to. The limit of 30 is a default configuration for the REST endpoint call. http://localhost:8027/en-US/splunkd/__raw/servicesNS/nobody/IA-Code42ForSplunk/storage/passwords?output_mode=json&_=1548376886291 From what I can tell, and after code review, everything is lining up exactly as native Splunk is intended to work. I'll enter an ER for the filtering option client side. https://docs.splunk.com/Documentation/Splunk/7.2.3/RESTUM/RESTusing#Namespace ... View more