Configure TISC add-on in Splunk

  • Release version: Australia
  • Updated March 12, 2026
  • 6 minutes to read

    • Configure the TISC add-on in Splunk to connect your account, define data inputs, and pull observable records into the KV store for search and analysis.

    Before you begin

    Role required: Splunk admin

    About this task

    The TISC add-on connects your ServiceNow account to Splunk and pulls observable records into the KV store.

    Procedure

    1. Search for Threat Intelligence Security Center for Splunk app from the left navigation.
    2. Select Set up under the Actions column.
      The Configuration page is displayed, and you can set up your ServiceNow TISC account.
    3. Select Add.
    4. On the form, fill in the fields.
      Field Description
      Add Accounts
      Name A unique name for the account.
      User Name The ServiceNow account user name. You can use the same user name created during role creation [sn_sec_tisc.api_obs_read_access] in the preceding step.
      Password The ServiceNow account password.
      Instance URL The ServiceNow instance URL.
    5. Select Add.
      The ServiceNow instance account is added to the Splunk.
    6. Navigate to the Inputs page to manage your data inputs for your ServiceNow account.
    7. Select Create Input.
      The Add Input dialogue box is displayed for you to add the inputs to your ServiceNow account. After the input set is defined, the application sends the information to the TISC instance to retrieve a specific number of observables that meet the criteria.
    8. Fill in the input details, as appropriate.
      Field Description
      Name A unique name for your input. For example, malicious IP list.
      Account The ServiceNow account user name. You can use the same user name created with the role sn_sec_tisc.api_obs_read_access in the preceding step.
      Interval Set time interval in seconds to retrieve the incremental data from TISC to the Splunk instance.
      Offset (in seconds) Number of seconds to subtract from the last execution time when building the incremental fetch filter. For example, if the last fetch ran at 10:00:00 and Offset is set to 5, the next fetch requests records updated since 09:59:55, creating a 5-second overlap window. The offset ensures that records updated in TISC at the same time as the data being retrieved from Splunk, are included in sequential runs and not overlooked.

      Valid values: 1 to 30. Default: 5. Empty: no offset.

      Note:
      A higher offset value reduces the chance of missed records, but may fetch duplicate records.
      Never Expire Choose this option if you don't want to expire the records ingested.
      Expiration Type Controls how the records expire from the Splunk KV store:
      • Splunk-side expiry — Records expire after the number of days configured in Expiry Period (in days), calculated from the time of ingestion into Splunk.
      • Map TISC expiration — Records expire when the expiration_time configured for the TISC observable is reached.
      Expiry Period (in days) Option to set the expiry period in days — displayed when you select Splunk-side expiry.
      Note:
      The sample expiration is set to 30 days. For example, when data is pulled on a specific date, a set of 10,000 records may be retrieved. These records are stored in the KV (Key-Value) store within Splunk. Starting from the ingested date, the records are retained for 30 days. On the 31st day, they are automatically deleted from the KV store.
      Enable Historical Fetch Select this option to fetch records from a date and time you specify, instead of only the delta since the last fetch. The fetch runs once on the next interval and then the option is disabled automatically. To run another historical fetch, re-enable the option and set a new start date.
      Additional Attributes Additional attributes from the list of recommended options to include in the KV store. Attributes must be separated by commas.

      A list of allowed attributes is provided in the table following the mandatory attributes table.
      Filters Conditions that determine which data is imported and filtered.

      To set the filter conditions, you can define the criteria based on the fields such as threat score, confidence level, and type.

      Use this option for simple, single-level conditions joined by AND operators. For complex conditions or nested groups, select JSON Filters.

      • Allowed tokens: threat_score, confidence, reputation, type, value.
      • The allowed integer operators are:

        "=", "!=", ">", "<", ">=", "<="

      • The allowed string operators are:

        "=", "!=", "IN"

      Simple filter example:

      reputation IN ("clean","suspicious","malicious") AND threat_score > 90 AND confidence > 90 AND type = "ip_v4_address"
      JSON Filters JSON-format filters for more complex conditions, including grouped boolean logic. Filters support up to 2 levels of nesting. The top-level can use AND or OR as the boolean operator, with individual filter conditions or one level of nested boolean groups beneath it. Filters with nesting deeper than 2 levels are rejected.
      Note:
      When using a top-level OR filter, the latest version of TISC must be installed.
      Sample JSON filter:
      {"boolean_operator":"AND","filters":[{"field_name":"reputation","operator":"IN","field_value":"clean,suspicious,malicious"},{"field_name":"threat_score","operator":">","field_value":"90"},{"field_name":"confidence","operator":">","field_value":"90"},{"field_name":"type","operator":"=","field_value":"ip_v4_address"}]}
      Note:
      Accounts are active by default, but inputs are inactive by default. Activate inputs to start importing data. For possible filters refer to Observable_filters section in Adds observable source records to the Threat Intelligence Security Center (TISC) application.
    9. Select Add to save the inputs.
    10. Select Clone to copy and create an account based on the existing account.
      Deactivate the input before copying to avoid creating duplicate entries when importing data using the same criteria.
    11. Review the information retrieved and stored in the KV store within Splunk along with the records pulled from TISC.
      Field Description
      confidence Indicates the confidence level associated with the accuracy of the threat score.
      instance_url Indicates the ServiceNow instance URL.
      kvlookup_created_time Indicates the record creation time in the key value store.
      kvlookup_days_till_expiry Indicates the number of days before the record is deleted from the KV store.
      kvlookup_expiration_time Expiration time of the record in Splunk.
      kvlookup_updated_time Indicates the timestamp when the record was last updated in the key value store.
      last_updated_by_input_name Name of the input that most recently created or updated this record.
      reputation Indicates the reputation of the entity involved.
      source_reported_score The reported source score from TISC.
      sys_id Sys ID of the record from TISC.
      threat_level Indicates the severity level of the threat.
      threat_score The score indicating the level of threat associated with a record.
      threat_severity Indicates the threat severity of the observable.
      type Indicates the observables type.
      updated_by The user who last updated the record.
      value Value of the record. For example, IP address, hash, and similar values.
      Table 1. Additional Attributes
      Field Description
      additional_context Any additional context for the observable.
      attack_phases Indicates attack phases in a kill chain such as LM, MITRE ATT&CK.
      author Name of the author.
      comments Any additional comments for the observable.
      created Indicates when the observable was created.
      description Description of the observable.
      expiration_time Specifies the expiration time of the observable record in TISC.
      extensions Indicates the extensions of an observable.
      first_observed The first time when the data was observed.
      first_seen The first time this record was seen performing malicious activities.
      historically_significant Indicates if the observable is considered historically significant. This TISC system flag is used to exclude the observable from archival.
      id Unique identifier assigned to the observable by the TISC system.
      is_defanged Flag indicating whether the observable value has been defanged.
      is_false_positive Boolean flag that indicates if an observable is identified as false positive.
      language Indicates the language of the text content in this object.
      last_observed The last time when the data was observed.
      last_seen The time that this object was last seen performing malicious activities.
      notes Any additional notes for the observable record.
      number System-generated number assigned to the observable by TISC.
      security_type Specifies whether the observable belongs to the Allowlist or Denylist.
      no_of_sources Represents the number of unique sources that have contributed to the observable.
      sources Specifies the threat source from which this record is created.
      status Status of the observable: active or inactive.
      tisc_tags The TISC tags associated with the observable.
      taxonomies The taxonomy associated with the observable.
      tlp Unique value that indicates the Data sensitivity setting per TLP.
      updated Indicates when the observable record was last updated
      usage_categories Categories that the observable falls under, such as botnet or phishing.
      watch_list Flag specifying if the observable is included in the watch list.

      These fields along with any others defined by your criteria will be available in Splunk and can be viewed, searched, and analyzed through the search tab.