Best Practices Guide for Threat Intelligence Security Center (TISC)<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Importing data via Import Intelligence: It’s recommended to keep the file size to a low value for quick processing of imported file without much delay in the review screen. For the large files, the user can check the import record link at any point of time to know the status of the import.“Import from raw text” option has character limit of 10k characters. If there is huge chunk of raw text that needs to be processed and imported as observables, then instead of using this option, create a file and place the raw text in the file and upload this file using the “Import from file (unstructured)” option. This option supports upto 5 MB as supported file size.When importing using structured files, Ensure that mandatory fields are populated for observables or indicator structured files Mandatory fields for Observables – Value and TypeMandatory fields for Indicators – Pattern, Pattern Type and Valid From The fields with date values are followed as per the format: YYYY-MM-DDThh:mm:ssZ. STIX 2.x JSON option only supports importing observables and indicators. Ingesting from Threat Intelligence Feed Data Sources: It is recommended to keep the number of data sources on automated ingestion to an optimum level by prioritizing quality instead of quantity. Any sources that are not providing quality and timely intelligence could be turned off. Too many Threat Intelligence feeds should not be scheduled to execute at the same time, so that system does not get overloaded with data to be processed at the same time.Threat intelligence feeds should be scheduled according to the refresh times from provider. For example, if feed provider refreshes data once in every 30 days, it would be redundant to fetch data every hour, Instead the data can be scheduled to be ingested once every day so that in worst case, maximum delay between data getting refreshed at provider and data ingested in to the system would be a day (24 hrs).For CrowdStrike Feed, lot of records will be modified on CrowdStrike server every day, Scheduling frequency must be as low as possible for data refresh from CrowdStrike (eg: every 1hr OR every 2hrs etc.) so that system does not try to fetch too many records in a single execution. Threat score provided by feed source can be mapped to "Source Reported Score" field in observable source table which would eventually be aggregated to the aggregate record "Source Reported Score" field. Make sure the value being mapped to "Source Reported Score" field is within the range of 0 to 100. Filtering unwanted data during ingestion: It is recommended to filter unwanted data during ingestion using the capabilities available in TISC to reduce the noise being processed and eventually stored in the system. Filtering Rules: Filtering rules can be used to filter data based on conditional logic or by referring to a security control list such as ‘Allow-list’. Additional Settings on CrowdStrike feed Ingestion By setting required additional settings in Crowdstrike Feed configuration page, you can fetch only specific type of indicators or indicators with specific malicious confidence values from crowdstrike. Migrating Threat Feeds and Enrichment Integration Configurations across different instances using update sets: When migrating threat feeds / integrations configured from lower environment(sub-prod) to higher environment(prod) using update sets, Customers are required to enter the authentication details required for the feed/integration again in the higher environment(prod) so that the authentication details are encrypted with the KMF key of higher environment instead of KMF key of lower environment API: For the Fetch Observables API which is used to fetch the observables from TISC application, ensure that the page size parameter value doesn’t exceed value of 1000 - which is the maximum page size that’s set in the instance and is controlled by a system property 'sn_sec_tisc.api_maximum_page_size_limit'. It is generally not recommended to increase the maximum page size as it could increase the API response time and API might even result in timeout for a larger page size value. For the Add Observables API which is used to add the observables into TISC application, maximum number of observables that can be added via API is controlled by a system property 'sn_sec_tisc.add_obs_api_max_records' and is set to 100 and ensure that this property is not changed to very high value as it could increase the API response time. Threat Score Calculator: While configuring the threat score calculator rule, ensure that scoring criteria configured on related records such as threat actors, vulnerabilities etc. are limited. The more scoring criteria on related records the more the processing time for scoring each observable as these are conditions evaluated on records on different related tables to the observable.As there is only one threat score calculator rule shipped. The re-apply feature basically recalculates for the entire set of observables in the system. As the feature internally uses parallel processing, it is recommended to run the re-apply on days where system load is minimal to ensure that other processes are not impacted.Recommendation is to use advanced conditions with care. Though customers are given the flexibility of building their own logic for scoring, the complexity of the script should be taken into consideration as this would run for every observable change in the system. Webhooks: While creation of webhook trigger , it is highly recommended to specify the filter conditions in the triggers to reduce the number of matched records thereby reduces the load on the system. Manage system properties for better UI performance: If list loading times out after 30 seconds due to 30 second transaction limit, set the below glide system property. glide.ui.list.batching.exclusion.list with a comma separated value of table names. If list count query is causing the table to load slowly, set the below glide system properties. Omit the total record count for certain tables. Set this Glide System Property: glide.ui.list.seismic.omit.count with a comma separated value of table names which should not have a total record count. Want to fetch the total record count after the list data comes back? This will affect seismic based lists across the entire platform.Set the Glide System Property glide.ui.fetch.list.record.count.asynchronously to a value of true. Life Cycle Management of Observables It is recommended to keep only the most recent and active observables in the system to optimize performance. This can be achieved by using expiration policies and data archival policies. Custom data ingestion flows When using any custom flows for creating data in the system other than OOB provided ways of ingestion (Import / Threat Feed ingestion), any new records should be created only in source tables (Observable Source(sn_sec_tisc_observable_source), Indicator Source(sn_sec_tisc_indicator_source), Attack Pattern Source(sn_sec_tisc_attack_pattern_source) etc.), so that system aggregates data from similar records and creates only a single aggregated record Create Case records using Inbound Emails Inbound Email Flow Trigger: https://docs.servicenow.com/bundle/washingtondc-build-workflows/page/administer/flow-designer/task/create-inbound-email-flow.html Sample OOB flows using Inbound Email Trigger: Inbound Email Flow Example: logging a problem Inbound Email Flow Example: handling email replies Ingest from Inbound Email Flow: Refer this link on how to process inbound emails.