Splunk App
9 min
the flare splunk app brings your flare events into splunk enterprise https //www splunk com/en us/products/splunk enterprise html after you connect the app to flare and select the tenants you want, flare events are ingested into a splunk index on a schedule you set, so you can view, search, and build automations on that data alongside the rest of your data in splunk access full event details go beyond alert summaries and directly dive into detailed event information in splunk enhance security workflows use flare data to perform correlations, enrich investigations, and automate responses within splunk, all tailored to their environment customize and control meet compliance and operational requirements with an on premises app designed to fit enterprise needs, allowing for high control over data access and usage installing the splunk app follow these steps from the splunk platform to install flare's splunk app from your splunk instance, go to apps > find more apps search the store for flare, and click install to install the app once installed, the flare app appears in the left sidebar under apps configuration follow these steps to complete the configuration of the flare splunk app select the flare app from the left navigation, and go to the configuration tab choose the index the app will ingest data into an index is a splunk data store, similar to a log database, that the app writes events into you can select an index that already exists in your splunk instance or create a new one for flare if you create a custom index, go to advanced search » search macros » flare index in splunk and update the macro to point to your new index if you create a custom index, go to advanced search > search macros > flare index in splunk and update the macro to point to your new index enter the api key the app will use to connect to flare for information on how to create an api key, see generate an api token https //api docs flare io/api reference/tokens/endpoints/generate once your api key is entered, the tenants available to your organization are loaded select one or more tenants to synchronize into splunk the app pulls the events from each selected tenant into your chosen index, based on the filters you set below use the severity filter to select which severity levels to include use the categories filter to select which event categories to ingest expand a category to select its subcategories the categories correspond to your flare data sources, such as illicit networks, open web, leaked credentials, and look alike domains the initial backfill range setting sets how many days of past events the app ingests on its first run, up to a maximum of 180 days the ingestion interval setting sets how often the app pulls new data after that, in minutes the value must be between 1 and 2880 (2 days) for example, 60 runs the app once an hour and 1440 runs it once a day choose an interval based on how current you need the data to be, how much data you expect to ingest, and the load on your splunk instance the ingest full event data setting controls how much detail is stored for each event when it is selected, the app ingests the complete event schema https //api docs flare io/api reference/v4/endpoints/get event , including detail such as a matched look alike domain or the host information found in a stealer log choose this if you want full event data in splunk for correlation, automation, or alerting on specific fields when it is cleared, the app ingests only the core fields for each event https //api docs flare io/api reference/v4/endpoints/current tenant feed , such as the event uid, key highlights, and the tenant and identifiers the event matched this keeps storage use lower and suits teams that mainly want to know when an event appears log level sets the verbosity of the app's own application logs, which are used for troubleshooting the default is info if you are diagnosing an issue, set it to debug to capture more detail, then return it to your usual level once the issue is resolved a higher verbosity uses more storage because the app logs more, but it does not change how events are ingested if your splunk instance reaches the internet through a proxy, turn on the enable proxy toggle and enter the proxy server address and its authentication details this allows the app to ingest data on hosts that do not have direct internet access enable ssl verification to validate the https certificates of the connections the app makes while it is on, ingestion fails if a certificate cannot be validated, which helps protect the connection against interception when all configurations are done, select save configuration to clear all values, select remove configuration values migrating from the legacy splunk app if you are migrating from the legacy splunk app docid\ towzpv4 v10x8jl7qpz 1 , follow these steps to ensure a smooth transition record your current settings from the legacy app’s configuration page api key, tenants, severity and category filters, backfill days, index, and whether full event data was enabled you will re enter these when you configure the new app disable the legacy app’s scripted input (under \<font color="#2166ae">settings\</font> » \<font color="#2166ae">data\</font> \<font color="#2166ae">inputs\</font> » \<font color="#2166ae">scripts\</font> ) so the same events are not ingested twice install and configure the new app ingestion starts only once you save a valid configuration expect a backfill on its first run, the new app re ingests its backfill window (30 days be default), so events from that period are stored twice, once under each schema deduplicating across the two is not practical, because the structure and the \<font color="#2166ae">` time`\</font> value differ update your alerts and reports to use the new app’s fields the legacy saved searches ( \<font color="#2166ae">`flare search`\</font> and \<font color="#2166ae">`severity`\</font> ) are replaced by the new app’s reports, which are prefixed \<font color="#2166ae">`flare `\</font> once the new app is successfully configured, remove the legacy app and delete its stored credentials (under \<font color="#2166ae">settings\</font> » \<font color="#2166ae">passwords\</font> , the realm \<font color="#2166ae">`flare integration realm`\</font> ) the legacy api key remains in splunk until you delete it post migration considerations running both apps at once duplicates events it is recommended to remove the legacy splunk app if they run together, the same events can get ingested by both and result in duplicate events point the search macro at your index dashboards and saved searches read through a search macro named \<font color="#2166ae">`flare index`\</font> , not the index directly if you ingest into an index other than the app’s default, update this macro to match under \<font color="#2166ae">settings\</font> » \<font color="#2166ae">advanced\</font> \<font color="#2166ae">search\</font> » \<font color="#2166ae">search macros\</font> , or every dashboard and saved search returns empty this is the same macro covered in configuration legacy events stay in the index uninstalling the legacy app does not remove the events it already ingested; they remain in whichever index it wrote to they fall out of the new app’s own dashboards and searches but can inflate totals in loosely filtered custom searches, so use a separate index for the new app or time bound your searches to the cutover date splunk sees the new app as a separate install the version resets (the legacy app ended at 1 3 4, the new app starts at 1 0 0) and the app id changes to \<font color="#2166ae">`flare splunk app`\</font> , so splunk treats it as a fresh install rather than an upgrade if you use a deployment server, add \<font color="#2166ae">`flare splunk app`\</font> to the relevant server classes for your search heads and indexers changing the index or backfill window re ingests the whole window the new app collects only new events using a checkpoint; changing either setting clears that checkpoint, so the next run re ingests the entire backfill window expect duplicate events and a temporary spike in license usage, which splunk counts by daily volume ingested time means something different in each app \<font color="#2166ae">` time`\</font> is the timestamp an event is stored under and drives all time ranges and time based dashboards the legacy app set it to the ingestion time; the new app uses the event’s own timestamp from flare, taking full effect once the legacy app is uninstalled, so the same event can shift on the timeline after the cutover the flare dashboard in splunk the flare dashboard tab in splunk mirrors the dashboard in the flare platform https //app flare io and gives an overview of the ingested events use the time range and identifiers filters at the top to scope what the dashboard shows use edit and export in the top right to customize or export the dashboard search the search tab lets you explore your ingested flare events using the time range, severity, event type, and tenant filters at the top to narrow the results saved searches are prebuilt searches for common queries, including all unique events, critical & high severity, leaked credentials, daily volume trend, severity distribution, ingestion health, and ingestion errors the flare events table lists the matching events, with sortable columns for time, category, severity, tenant, and flare url each flare url links to the event in the flare application use edit and export in the top right to customize or export the view application logs the application logs tab shows the app's activity, including when a sync started, whether it succeeded or failed, and any errors tied to a specific activity