Select Two (Multi-Select) Questions

Create a new event type that tags the relevant fields.

Why it fails: Event types are used to categorize events and can be used for tagging, but they are not a required step for CIM compliance. The CIM relies on field aliases and tags applied via the data model, not event types. While event types can be helpful for search optimization, they are not mandatory for mapping data to the CIM.

Enable data model acceleration for all data models.

Why it fails: Data model acceleration improves search performance but is not required for CIM compliance. Acceleration is optional and depends on the use case and system resources. The CIM mapping itself is achieved through field aliases and tags, not acceleration. Enabling acceleration for all data models could be resource-intensive and is not a prerequisite for a new data source to be CIM-compliant.

Create a new index for the data source.

Why it fails: Creating a new index is not required for CIM compliance. Data can be ingested into existing indexes as long as the fields are properly aliased and tagged. Index selection is based on data retention and access policies, not CIM mapping. The CIM operates on the data regardless of the index, so a new index is unnecessary for this purpose.

License type.

Why it fails: License type is not an event attribute Splunk ES uses for notable event filtering; the Incident Review dashboard filters on fields such as urgency, status, owner, security domain and disposition. It is tempting because licence tier governs feature availability across Splunk deployments, making it a legitimate consideration when planning capability rollouts rather than triaging individual notables.

Index name.

Why it fails: Index name describes where raw data is stored, not a notable event attribute, so it cannot filter the Incident Review dashboard. It is tempting because indexes are the primary filter when searching raw events in Splunk, and would be the correct choice when narrowing a search across data sources rather than reviewing correlated notables.

Create a saved search that runs the correlation search and sends an email.

Why it fails: A saved search sending email does not integrate with the ticketing system via API. It also does not create a notable event in Splunk ES. The requirement is to create a notable and a ticket via API, which is achieved through the notable action and a custom alert action, not through email notifications.

Enable the risk analysis framework to assign a risk score to the user.

Why it fails: Risk analysis assigns risk scores to entities, which can be useful for prioritization, but it does not create notables or tickets. It is an additional enrichment step, not a requirement for the described actions. The scenario specifically requires notable creation and API-based ticket creation, which are handled by other configurations.

Set up a data model acceleration for the index containing the exfiltration data.

Why it fails: Data model acceleration improves search performance but is not required for creating notables or triggering alert actions. While it can be beneficial for large datasets, it is not a prerequisite for the desired outcome. The question focuses on actions, not search efficiency, so acceleration is not necessary here.

A single failed login attempt from an external IP address

Why it fails: A single failed login is common and not indicative of ransomware. Ransomware typically involves file encryption and lateral movement, not isolated authentication failures. This event lacks the specificity and severity to be prioritized as a ransomware indicator.

An increase in DNS queries for known cryptocurrency mining pools

Why it fails: Cryptocurrency mining is a different threat category (cryptojacking) and is not a direct indicator of ransomware. While both are malware, ransomware's primary behavior is file encryption and extortion, not mining. This indicator would be prioritized for a different use case.

A user reporting slower than usual workstation performance

Why it fails: Performance degradation is a vague symptom that could have many causes, including legitimate software updates or hardware issues. It is not a specific indicator of ransomware and would generate excessive false positives. Ransomware detection should focus on concrete file and network behaviors.

Phishing

Why it fails: Phishing is an initial access technique that tricks users into revealing credentials or executing malware. While it can lead to a foothold, it is not a lateral movement method. Lateral movement occurs after initial compromise, using techniques like Pass-the-Hash or RDP hijacking to move from host to host. Phishing is therefore not the correct choice here.

SQL injection

Why it fails: SQL injection is a web application attack that targets databases, not a lateral movement technique. It allows an attacker to execute arbitrary SQL queries, but it does not directly facilitate moving from one internal host to another. Monitoring for SQL injection is important for web security, but it is not a lateral movement method like Pass-the-Hash or RDP.

Cross-site scripting (XSS)

Why it fails: Cross-site scripting is a web vulnerability that allows attackers to inject client-side scripts into web pages viewed by other users. It is not used for lateral movement within a network. XSS typically targets web application users and can lead to session hijacking, but it does not involve moving between internal hosts like Pass-the-Hash or RDP hijacking.

The Splunk License usage report.

Why it fails: The licence usage report tracks daily indexing volume against entitlement, revealing nothing about correlation search logic, scheduling, or alert actions. It is tempting because exceeded licence limits can suppress searching, but that produces a global block, not a single malfunctioning correlation search.

The user's web browser cache.

Why it fails: A correlation search runs server-side in the Splunk search head, so browser cache contents cannot affect its execution or reveal why it failed. Browser cache is tempting because clearing it resolves stale dashboard rendering, which is a client-side display issue rather than a search logic or scheduling fault.

CPU core count

Why it fails: CPU core count is a host hardware metric, not a parameter of the Risk Analysis adaptive response action, which configures risk score thresholds, risk objects and risk message fields. It would be relevant when sizing search-head capacity for correlation searches, not when defining how risk is scored and attributed.

Network interface speed

Why it fails: Network interface speed is an infrastructure performance metric, not a configurable field within the Risk Analysis adaptive response action, which sets risk score, risk object and risk object type values. It would matter when diagnosing throughput bottlenecks on indexers, not when assigning risk to entities.

Anomalous number of failed logon attempts

Why it fails: Failed logon attempts are indicative of brute force or password guessing, not credential dumping. Credential dumping involves extracting credentials from a compromised system, which typically results in successful authentications. While failed logons may accompany an attack, they are not a specific indicator of credential dumping and would not be the best evidence to search for.

Creation of a new service with a random name

Why it fails: While attackers may create services for persistence, this is not a specific indicator of credential dumping. Credential dumping focuses on extracting credentials from memory or files, not on creating services. Service creation could be part of other malicious activities, but it lacks the direct link to credential theft that lsass access provides.

Unexpected modification of the hosts file

Why it fails: Modification of the hosts file is often used for redirecting traffic or persistence, but it is not directly related to credential dumping. Credential dumping targets credential stores like lsass memory or SAM database, not network name resolution. Therefore, hosts file changes are not a valid indicator for this specific attack.

Asset and identity correlation for context enrichment

Why it fails: Asset and identity correlation supports the Identify function by providing context about assets and users, which helps in understanding the environment. While this context is valuable during response, the primary CSF function it supports is Identify, as it involves inventorying and managing assets. It does not directly perform response actions.

Threat intelligence framework for ingesting indicators

Why it fails: The Threat Intelligence framework primarily supports the Detect function by enriching data with indicators of compromise to identify potential threats. While threat intelligence can inform response, its core purpose is detection and identification of malicious activity. Therefore, it is not the most direct support for the Respond function, which focuses on actions taken after detection.

Risk analysis dashboard for prioritizing vulnerabilities

Why it fails: The Risk Analysis dashboard helps in prioritizing risks based on asset criticality and threat intelligence, which is part of the Identify and Protect functions. It aids in understanding where to focus resources but does not directly execute response actions. Thus, it is not a primary capability for the Respond function.

Use the lookup command with a threat intelligence feed of known malicious IP addresses and drop every DNS event whose source is not in the feed.

Why it fails: Dropping events that are not in a threat feed assumes the attacker's infrastructure is already catalogued, which is exactly what a proactive hunt cannot rely on. Novel exfiltration domains will not appear in the feed, so this approach discards the very evidence being sought and biases the hunt toward known indicators only.

Use the dedup command on the query field to remove repeated queries and then count the remaining events per host to determine exfiltration volume.

Why it fails: Deduplicating on the query field collapses repeated identical lookups, but tunneling generates unique encoded queries that are rarely exact duplicates. This removal does not measure length or entropy and distorts volume counts, so it provides no reliable signal for identifying the abused destination domain or the anomalous encoding pattern.

Use the transaction command to group all DNS events from a single source IP over a 30-minute window into one event and inspect the raw payload.

Why it fails: The transaction command groups related events but does not compute length or entropy, and dumping raw grouped payloads does not scale to large DNS volumes. It also risks memory pressure and produces output that is hard to compare quantitatively, so it fails to directly quantify the abnormally long query names the hunt requires.

Events produced by the license master.

Why it fails: License master events are internal Splunk platform operational logs about licence usage and violations, not security detections from correlation searches. It is tempting because licence master events are genuinely monitored, and they would be the right concern where the requirement is platform health or licence compliance rather than notable event categorisation.

Every log event received by the indexer.

Why it fails: Notable events are produced by correlation searches, not by raw ingestion; indexing every event would make every log notable and destroy the signal. It is tempting because all events do flow through the indexer, and indexing would be the correct focus where the requirement concerns data onboarding or licence volume rather than notable event classification.

Browser history of a user.

Why it fails: Browser history is endpoint web activity, not a correlation-search result, so it never becomes a notable event unless a correlation search explicitly flags it. It is tempting because browser data can feed UEBA and threat-detection use cases, and it would be relevant where the requirement is to ingest web activity for risk scoring rather than to identify notable event types.

Encrypted packet captures

Why it fails: Encrypted packet captures carry no asset or identity metadata for the framework to correlate, since payloads are unreadable and no host or user context is exposed. Enrichment instead targets event and flow data such as authentication logs, DHCP, DNS and proxy records, where identity and asset fields can be joined.

Raw web server application logs

Why it fails: Raw web server application logs are event data, not identity or asset context, so the framework does not enrich them as assets or identities. It is tempting because logs feed SIEM analysis, but enrichment targets asset and identity records, not raw application log fields.

System performance statistics

Why it fails: System performance statistics are not enriched by the Asset and Identity framework, which merges asset and identity records with contextual fields such as owner, priority and category. Performance metrics belong to monitoring and capacity planning tooling, where CPU, memory and latency data would be the correct focus.

A permanent connection to the Internet.

Why it fails: Adaptive Response actions run inside the Splunk deployment between search heads, indexers and the external endpoint, so outbound Internet connectivity is irrelevant. A permanent Internet connection would matter only for cloud-service integrations or external threat-intelligence lookups reached directly over the web.

A user with 'Admin' role on all indexers.

Why it fails: Adaptive Response requires the capability to run the action and a configured alert action, not Admin role across every indexer. Broad Admin rights would be relevant when installing apps or managing indexer clusters, not for executing a response action.

License Master UI

Why it fails: The License Master UI governs ingestion volume and licensing, holding no risk framework configuration such as risk rules, risk index settings or risk factor definitions. It is tempting because administrators do visit it to manage Splunk ES licensing, which is the correct area when the task concerns licence usage rather than risk-based alerting.

Knowledge Object Manager

Why it fails: The Knowledge Object Manager lists saved searches, lookups and macros generally, but does not expose the risk framework settings that govern risk-based alerting. It is tempting because risk rules are knowledge objects, yet the correct areas are the Risk Analysis dashboard and the ES Configuration/Content Management interface.

Data Model Acceleration UI

Why it fails: Data Model Acceleration UI controls acceleration schedules and backfill for data models, not risk scoring or risk rule configuration. It is tempting because RBA depends on accelerated data models, so acceleration is genuinely relevant to performance, but the correct areas for configuring RBA are the Risk Analysis dashboard and ES configuration.

lookup file.csv --all

Why it fails: The lookup command has no --all flag; that syntax is invalid and the search errors. It is tempting because --all resembles a wildcard for returning every column, but lookup instead uses OUTPUT or OUTPUTNEW to specify which fields to return from the CSV.

lookup file.csv --join

Why it fails: The lookup command takes a lookup definition or CSV file as its first argument, followed by optional match fields; "--join" is not valid syntax and no such parameter exists. It is tempting because SQL-style joins suggest a join keyword, and lookup does enrich events by matching fields, but that is achieved with the lookup name and field list.

Disabling all network ports

Why it fails: Disabling all network ports is a host or network control, not a Splunk ES mitigation, and it would halt legitimate traffic. It is tempting as a blunt containment measure, but insider threat mitigation in ES means analytics such as risk scoring, UEBA and correlation searches.

Manually logging all user keystrokes

Why it fails: Keystroke logging is an endpoint surveillance control, not something Splunk ES performs, and it raises legal and privacy issues. It is tempting because monitoring user actions sounds relevant, but ES mitigates insider threat through risk-based analytics, not manual keystroke capture.

Deleting user accounts immediately

Why it fails: Deleting accounts immediately destroys the audit trail and evidence, and it is an identity-administration action rather than a Splunk ES capability. It is tempting as swift containment, but ES mitigates insider threat by detecting and scoring risky behaviour, not by removing identities.

Forwarder management

Why it fails: Forwarder management configures deployment clients and server classes, unrelated to threat intelligence ingestion, matching or scoring. It is tempting because it sits within Splunk Enterprise Security's configuration interface, and in scenarios requiring agent deployment or app distribution it would be the correct choice.

Dashboard customization

Why it fails: Dashboard customisation governs visualisation layout in Splunk ES, not threat intelligence ingestion, matching or threat-object enrichment. It tempts because ES ships editable dashboards, and tuning them is genuine administrative work — but that belongs to a reporting or SOC-display scenario, not to the Threat Intelligence framework's components.

Incident classification

Why it fails: Incident classification assigns urgency and status to notables inside Splunk ES Incident Review; it does not ingest, normalise or match threat indicators. It tempts because classification is central to triage workflows, and would be the right answer to a question about notable event handling rather than the Threat Intelligence framework.

The number of users in the organization

Why it fails: This is irrelevant to the risk scoring logic.

The total disk space of the index

Why it fails: Risk scores derive from risk object annotations — the risk score assigned to a risk rule or risk modifier and the object's priority — not from index storage capacity. Disk space would be the right concern when sizing indexers or planning retention, not when calculating an entity's risk score.

The operating system of the host

Why it fails: Splunk ES calculates risk from annotated risk rules, risk modifiers and the object's priority weighting, not from the host's operating system. OS type would be relevant when selecting universal forwarders or deployment apps, but it contributes nothing to the arithmetic behind a risk score.

The budget for the security department

Why it fails: Budget figures are administrative context, not a hunt component; they specify no data source, hypothesis or response step. It is tempting because resourcing does gate which hunts are feasible, but that decision sits in programme planning, whereas an actionable playbook needs concrete detection and triage elements.

A copy of the company's network topology map

Why it fails: A topology map describes infrastructure but supplies no detection logic, so it cannot make a hunt actionable. It is tempting because network context helps scope searches, yet an actionable playbook requires a hypothesis and the specific data sources, queries and thresholds that confirm or refute it.

A list of all employees in the company

Why it fails: Irrelevant to the hunt execution.

A separate Splunk instance for every sourcetype.

Why it fails: Splunk Enterprise Security correlates data across indexes and sourcetypes within a shared platform; per-sourcetype instances fragment correlation and break the common information model. It is tempting because isolated ingestion can simplify parsing, but ES requires consolidated data, not one instance per source.

A dedicated hardware appliance.

Why it fails: Splunk Enterprise Security is a software application deployed on supported infrastructure, cloud or on-premises; a dedicated hardware appliance is not a prerequisite. It is tempting because security workloads demand predictable performance, but ES requires data onboarding, the CIM and correlation searches, not specific physical hardware.