Threat Intelligence Management practice questions

Settings > Object Fields > Indicators

Why it fails: Object fields define schema attributes, not scoring priorities.

Settings > Integrations > Instances

Why it fails: Instance settings manage connection parameters, not cross-source scoring logic.

Settings > Advanced > Indicator Types

Why it fails: This manages indicator type definitions, not source precedence.

indicator.type == 'IP' & rep == 3

Why it fails: XSOAR indicator search uses key-value syntax like type:IP and reputation:Bad.

find ip where status = bad and campaign = CampaignX

Why it fails: This syntax is invalid for the Threat Intel query bar.

ip = malicious AND tag == CampaignX

Why it fails: This is not valid XQL syntax for the Threat Intel workspace.

Automation > Scripts > Expiration Script

Why it fails: Expiration is handled natively by the engine based on type settings, not custom scripts.

Threat Intel > Indicator Queries > Expiration

Why it fails: There is no expiration menu under Threat Intel queries.

Settings > About > Server Configuration

Why it fails: Server configuration handles global system flags, not indicator lifecycle rules.

Create a scheduled job in Settings > Advanced > Jobs.

Why it fails: Jobs run scheduled scripts or playbooks, not ad-hoc bulk tag edits on a query selection; the tag action belongs in the indicator bulk-actions menu or a playbook. It tempts because jobs automate recurring maintenance, which would suit periodic tag synchronisation rather than a one-off update of 500 selected indicators.

Export indicators to CSV, modify the tags in Excel, and re-import as incidents.

Why it fails: CSV export and re-import creates new incidents rather than modifying the existing 500 indicators, so tags are not updated in place. Bulk indicator editing is tempting because it appears to offer a scriptable bulk path, and would be correct for migrating indicator data between systems, not for in-place tag changes.

Run a Python script using demisto.executeCommand() for each indicator ID individually.

Why it fails: While possible via script, bulk actions are natively supported via the UI without writing custom code.

Threat Intel > Feeds > Status Dashboard

Why it fails: There is no dedicated Feeds Status Dashboard menu path; status is checked per instance.

Incidents > Audit > Feeds

Why it fails: Feeds are not audited under the Incidents audit tab.

Automation > Playbooks > Execution History

Why it fails: Playbook execution history does not track feed fetch intervals.

Settings > Integrations > Instances > Enrichment Settings

Why it fails: Enrichment behavior is controlled via indicator types and associated playbooks, not instance settings.

Incidents > Classification & Mapping > Indicator Rules

Why it fails: Classification and mapping apply to incident ingestion, not indicator pipelines.

Threat Intel > Feeds > Automation Rules

Why it fails: There is no 'Automation Rules' menu under Threat Intel.

By adding the attribute to the incident layout editor.

Why it fails: Incident layouts control how incident fields display in the XSOAR console, not how indicator attributes are mapped into outbound TAXII/STIX bundles. It tempts administrators who equate custom attribute visibility with export configuration, but the correct mechanism is editing the indicator type's STIX mapping or the TAXII feed's field mapping.

By modifying the server configuration key 'vim.export.custom.fields'.

Why it fails: No such server configuration key exists in Cortex XSOAR, so setting it changes nothing about indicator serialisation. Server configuration keys govern platform behaviour such as authentication or retention, not the field mapping applied when building TAXII/STIX bundles.

By writing a post-processing automation script that directly injects XML tags into the firewall API.

Why it fails: Injecting XML tags into a firewall API bypasses the TAXII/STIX export entirely, so the custom attribute never enters the bundle other consumers receive. Direct API manipulation suits bespoke enforcement-point formatting, not enriching the shared indicator payload.

Threat Intel > Feeds > Impact Settings

Why it fails: There is no impact settings menu under Threat Intel feeds.

Incidents > Types > Severity Rules

Why it fails: Incident types define base severities, but indicator impact is managed via TIM scoring.

Automation > Scripts > SeverityCalculator

Why it fails: Severity calculation is handled natively by platform rules rather than standalone scripts.

Automation > Playground > Test Hash

Why it fails: Playground is for testing scripts and commands.

Settings > Integrations > Global Search

Why it fails: There is no global search under settings.

Incidents > Filter > Hash Lookup

Why it fails: Incidents filter queries incidents, not threat intel indicators directly.

Dashboards > Widgets > Export PDF

Why it fails: Dashboard widget export produces a one-off PDF snapshot of a widget's current data, with no indicator filtering by tag or recurrence. It is tempting because dashboards visualise indicators, and this would be correct for manually sharing a static view of an existing widget rather than scheduling a recurring filtered report.

Threat Intel > Reports > New Report

Why it fails: Threat Intel reports summarise indicator feeds and threat actors, but cannot query ingested indicators by tag across a time window with scheduling. It is tempting because it is the dedicated indicator-reporting area, and would be correct for producing a curated threat-intel digest rather than a filtered indicator export.

Settings > Advanced > Scheduled Reports

Why it fails: Settings > Advanced holds platform configuration, not report authoring; no scheduled-report builder exists there. It is tempting because scheduled reporting sounds like an administrative feature, and this path would be correct for configuring system-wide settings or integrations rather than generating an indicator report from ingested data.

Fetch interval frequency

Why it fails: Fetch interval sets how often the integration polls, not how long a single fetch may run. It is tempting because it is a scheduling parameter tied to feed retrieval, and would be correct for reducing polling frequency to ease API rate limits, not for accommodating large payloads.

Indicator expiration threshold

Why it fails: Indicator expiration controls how long indicators remain valid, not fetch timeout behaviour. It is tempting because it is an integration parameter administrators routinely tune, and would be correct when stale indicators must be purged sooner, not when large payloads exceed the fetch timeout.

Server configuration key 'http.lethal.timeout'

Why it fails: 'http.lethal.timeout' is a server configuration key, not an integration parameter, and governs request termination rather than payload size. It is tempting because it references timeouts, and would be correct for tuning platform-wide HTTP behaviour, not for extending a specific feed integration's fetch limits.

demisto.incidents().create()

Why it fails: This creates incidents, not threat indicators.

demisto.executeCommand('add-indicator', args)

Why it fails: While CLI commands exist, Python integrations use demisto.createIndicators() for bulk indicator ingestion.

demisto.setIndicatorReputation(values)

Why it fails: This sets reputation but does not create or ingest raw feed entries.

Active Directory SSL certificate

Why it fails: AD certificates are unrelated to indicator type definitions.

Syslog facility level

Why it fails: Syslog facilities are irrelevant to indicator type schemas.

Incident SLA escalation timer

Why it fails: SLAs apply to incidents, not indicator type definitions.

The integration must be configured with a TAXII collection URL so the platform can pull indicators directly.

Why it fails: TAXII collection URLs apply only to TAXII-based feed integrations, not to custom generic feed integrations. This integration already fetches indicators through its own command, so adding a TAXII URL is irrelevant and would not cause the fetched objects to be ingested. The missing piece is the ingestion call, not a transport protocol change.

The indicator types returned by the feed must first be registered in the Indicators Types settings page before they can be stored.

Why it fails: Cortex XSOAR supports common indicator types out of the box and allows custom types, but registration is not a prerequisite for ingestion of standard types. Indicators returned without the createIndicators call are not stored regardless of type registration, so this step alone would not fix the problem. The fetch command must explicitly push indicators into the database.

The integration instance's indicator reputation settings must map each indicator type to a reputation level.

Why it fails: Reputation settings control how indicator scores are calculated from feed data, but they do not govern whether fetched indicators are persisted to the Threat Intel database. Even with correct reputation mapping, indicators returned without the proper ingestion flag are discarded by the fetch pipeline before storage, so this step would not resolve the missing indicators.

Set the Feed Reputation parameter to Benign and use the feed's indicator type mapping to filter out high-confidence indicators.

Why it fails: The Feed Reputation parameter applies one fixed reputation to every indicator the feed ingests; it cannot vary reputation per indicator based on a confidence field. Indicator type mapping controls how vendor-specific types translate to XSOAR types, not reputation, so this combination would mark all indicators Benign regardless of confidence.

Create a post-processing script that runs on a scheduled job to downgrade the reputation of any indicator whose confidence attribute is below 40.

Why it fails: A scheduled post-processing job adds latency and complexity: indicators would briefly carry their original reputation before being downgraded, and the job must repeatedly scan the database. Mapper or pre-processing logic applies the correct reputation at ingestion time, which is simpler and avoids the window where a low-confidence indicator shows as malicious.

Configure the feed's fetch query to exclude indicators with confidence below 40 so they are never ingested into the Threat Intel database.

Why it fails: Excluding low-confidence indicators contradicts the stated requirement that they be ingested but marked Benign. Filtering them out at fetch time means they never enter the database, so analysts lose the visibility the security team explicitly wants to retain, and the behavior differs from the specified outcome.

Adjust the 'Reputation' weight of the external feed in the feed's integration settings to be higher than the honeypot feed.

Why it fails: Cortex XSOAR does not provide a per-feed reputation weight parameter in integration settings. Reputation calculation is based on the highest score among contributing sources, not weighted averages. While feed reliability can be set, it does not function as a numerical weight. This option misrepresents how XSOAR aggregates indicator scores from multiple feeds.

Create a playbook that triggers on indicator updates and uses the 'setIndicator' command to force the score to malicious.

Why it fails: While a playbook can automate actions, using 'setIndicator' to force a score is a manual override that bypasses the feed reliability mechanism. It would need constant maintenance and does not leverage built-in conflict resolution. This approach is overly complex and not the intended method for prioritizing feeds. It also fails to respect the dynamic nature of feed updates.

Set the indicator's manual score to 'Malicious' in the Indicator Details page.

Why it fails: Manually setting the score overrides all feed inputs but does not automate conflict resolution for future updates. It is a one-time action and will not persist when feeds refresh. The analyst needs a systematic way to prioritize one feed over another, not a manual override. This approach also fails to address the root cause of conflicting reputations from multiple sources.

The integration's *.yml file, adding a new command block under the 'commands' section.

Why it fails: The .yml file is the integration's metadata and configuration schema; it defines parameters, the display name, and the supported command names but not the per-argument CLI parsing and DBotScore output contract for a new reputation command. Adding only a command block there without the corresponding argument definitions and outputs in the integration definition leaves the command undiscoverable in the CLI. The engineer must edit the file that declares command arguments, outputs, and reputation handling.

The integration's *.py file, adding a new function decorated with @reputation_command.

Why it fails: Writing a Python function in the integration code is necessary to implement the logic, but the function alone does not register the command name, argument list, or output schema with the platform. Cortex XSOAR discovers commands from the integration definition file, so a bare Python function with a decorator will not appear in the CLI or be usable in playbook tasks. The engineer must also declare the command in the definition file.

The integration's *.json file, adding a new entry to the 'commands' array.

Why it fails: Cortex XSOAR integrations are defined by YAML and Python files, not a JSON manifest for commands. A JSON file is used for some configuration or test data, but it is not the mechanism that registers CLI commands, their arguments, or their reputation outputs. Creating a JSON entry would have no effect on command discovery, so analysts would still not see the new DeviceID command in the CLI or in playbook task pickers.

A Cortex XSOAR list named 'overlap_indicators' populated by a custom script that compares feeds on a cron job.

Why it fails: Lists store static or scripted data but do not themselves create incidents or evaluate indicator relationships. Building a custom comparison script duplicates functionality that threat intel management rules already provide natively. While a script could theoretically detect overlaps, it would not automatically create the review incident the team wants, so this is an unnecessarily complex and incomplete solution.

A playbook trigger configured on the 'Indicator' incident type that runs whenever any indicator is updated.

Why it fails: Indicator updates do not automatically spawn indicator incidents unless a rule or integration explicitly creates one. Playbook triggers act on incidents that already exist, so there would be no incident for the trigger to fire on. Without a threat intel management rule to generate the incident, this approach cannot detect cross-feed overlap, making it incorrect for the scenario.

A threat intel feed's 'Fetch indicators' schedule, set to run every minute so overlaps are detected quickly.

Why it fails: The fetch schedule only controls how often the integration pulls data; it does not evaluate overlaps between feeds or create incidents. Increasing frequency may surface indicators sooner but never triggers an incident on its own. The requirement is event-driven incident creation on overlap, which scheduling alone cannot deliver, so this setting is the wrong control.

Set the feed's 'Fetch indicators' parameter to true and increase the fetch interval.

Why it fails: The 'Fetch indicators' parameter determines whether the integration retrieves data from the TAXII collection on schedule, but retrieval alone does not cause indicators to be written to the Threat Intel database. Increasing the interval only changes timing. An engineer relying on this setting would see fetch activity in logs yet no indicators in the database, because the create/persist behavior is controlled separately.

Enable 'Trust any certificate (not secure)' in the integration instance settings.

Why it fails: The certificate trust toggle only affects TLS validation when connecting to the TAXII server; it has no bearing on whether fetched indicators are stored in the Threat Intel database. Disabling certificate verification is a security downgrade and does not create indicators. An engineer enabling this would still find no indicators persisted, because the persistence behavior is governed by a different parameter entirely.

Set the feed's 'Reputation' parameter to 'Good' so the indicators are trusted by default.

Why it fails: Setting reputation to Good does not control whether indicators are persisted to the Threat Intel database; it only influences the score assigned to matched indicators. Feed ingestion still requires the appropriate indicator-creation toggle. Reputation alone cannot cause indicators to be written automatically, so the engineer's goal of database population without manual review would not be met by changing this value.

Enabling the TLP:RED sharing designation on the trusted feed so its indicators override all other sources in the database.

Why it fails: TLP markings govern how intelligence may be shared with external parties; they are not a mechanism for arbitrating reputation conflicts inside the database. Setting TLP:RED on a feed restricts redistribution of its data and does not cause its scores to override those from other feeds during aggregation.

Using the Sources section on the indicator and adjusting the score manually for each conflicting indicator as analysts encounter them.

Why it fails: Manual score adjustment is a per-indicator, reactive action and does not scale to the volume of overlapping feed data described. It also does not establish an automated policy for how trusted versus untrusted feeds are weighted, so it fails to deliver the systematic noise reduction the engineer was asked to implement.

Configuring indicator expiration rules per feed so stale indicators from lower-fidelity sources age out faster than those from trusted sources.

Why it fails: Expiration rules remove indicators after a period without sightings, which reduces clutter over time but does not resolve simultaneous conflicting reputations between an active trusted feed and an active untrusted feed. The requirement is about which score prevails while both feeds are reporting, not about how long indicators persist.