Investigation And Risk Management practice questions

signature

Why it fails: The signature field identifies the type of threat, not the object at risk.

src_ip

Why it fails: This is an optional enrichment field.

user_id

Why it fails: Splunk ES uses 'risk_object' rather than 'user_id' as the primary entity identifier.

correlation_search.log

Why it fails: While helpful, splunkd.log is the primary source for confirming the execution of the action.

notable_events.log

Why it fails: This is not a standard log file for troubleshooting action execution.

risk_index.log

Why it fails: This log does not exist in standard Splunk ES installations.

Asset and Identity Framework

Why it fails: This framework is for context enrichment, not for generating risk notables.

Correlation Search Editor

Why it fails: The Correlation Search Editor defines the search logic and scheduling that generate notable events, but it does not itself transform raw logs into risk notables; that transformation is performed by the risk framework's risk indexers populating the risk index. It is tempting because correlation searches are the usual starting point when building RBA content.

Notable Event Suppression

Why it fails: Notable Event Suppression only filters or hides existing notables matching suppression rules, so it cannot transform raw logs into risk notables. It is tempting because suppression is configured alongside RBA content, but it would be the correct choice when reducing duplicate notable noise, not when generating risk notables from raw events.

owner

Why it fails: This is an optional field for assignment.

incident_id

Why it fails: This field is generated after the incident is created.

risk_score

Why it fails: This is optional for general notables.

collect index=risk

Why it fails: Collect is for writing data, not reading it.

lookup asset_info

Why it fails: Lookups are for enrichment, not searching events.

search index=risk src_ip=...

Why it fails: While possible, it is less efficient than using tstats on the data model.

Manual approval for every alert

Why it fails: Manual approval for every alert introduces human latency and does not define risk scoring, thresholds or response actions, so it cannot make an alert risk-based. It is tempting because approval gates suit high-impact change control, where a person must authorise an action before it executes.

Hardware-level encryption

Why it fails: Hardware-level encryption protects data at rest on physical media and contributes nothing to defining alert risk, thresholds or response logic. It is tempting because encryption appears security-relevant, and it would be the right control when regulatory requirements demand protection of stored data against physical disk theft.

License Usage

Why it fails: License Usage reports ingestion volume against entitlement, giving no asset, identity or risk context for investigations. It is tempting because it is a genuine ES dashboard, and it would be correct when monitoring daily indexing consumption or planning licence capacity rather than investigating risk.

User Activity Monitoring

Why it fails: User Activity Monitoring is a genuine ES dashboard category, but risk-based investigation centres on risk, asset and identity views. It is tempting because user behaviour feeds risk scoring, and it would be correct when reviewing per-user session and access activity rather than aggregated risk posture.

Open the Incident Review dashboard and sort by risk score descending.

Why it fails: Sorting Incident Review by risk score shows other notables ranked by score, not the individual risk events behind this particular notable. It does not provide the per-risk-event attribution needed to understand which detections contributed, so it is not the correct pivot for this scenario.

Use the "Add to Case" action to attach the notable, then inspect the case's risk events.

Why it fails: Adding the notable to a case creates a case artifact but does not automatically populate the case with the underlying risk events. The case workflow is for tracking and collaboration, not for enumerating the risk events that rolled up into a notable, so this action does not achieve the analyst's goal.

Run a search on the risk index filtering by the notable's event ID.

Why it fails: Risk events in the risk index do not carry the notable's event ID; they are linked by risk object and threat object values, not by a shared event ID. Searching the risk index by the notable event ID returns no results, so this approach fails to surface the contributing risk events and wastes investigation time.

Set the risk rule's "Risk Score" to a negative value after a threshold.

Why it fails: Risk scores are additive and do not support negative values to simulate decay. Setting a negative score would incorrectly reduce risk from other detections and does not model time-based decay. This approach is not how Splunk ES handles risk expiration and would produce misleading risk profiles.

Create a correlation search that subtracts risk points on a schedule.

Why it fails: While you can create a correlation search that writes negative risk events, this is not a supported or recommended decay mechanism and can cause unpredictable scores. Splunk ES expects risk events to be positive contributions; subtracting points manually is error-prone and not how the platform implements risk aging.

Configure a risk score decay period in the risk rule's settings.

Why it fails: Splunk Enterprise Security does not provide a per-risk-rule decay period setting. Risk decay is managed globally via risk index retention and the risk score calculation window, not by individual rule configuration. Attempting to find such a setting leads to confusion, as it does not exist in the product.

| datamodel Risk.All_Risk_Events search | search risk_object="jdoe" | table _time, risk_score, risk_rule

Why it fails: The datamodel command can search a data model, but it is less efficient and more verbose than 'from risk'. It may also require additional syntax to extract fields correctly. While it could work, 'from risk' is the streamlined and recommended method for querying risk events directly from the risk index.

| tstats summariesonly=true count from datamodel=Risk.All_Risk_Events where Risk.All_Risk_Events.risk_object="jdoe" by _time, risk_score, risk_rule

Why it fails: While tstats can query the Risk data model, using summariesonly=true restricts results to accelerated data model summaries, which may not include all fields like risk_rule or individual event details. The 'from risk' command is more direct for retrieving raw risk events. This search may also miss events if acceleration is incomplete.

| search index=risk user=jdoe | stats sum(risk_score) by risk_rule

Why it fails: This search uses index=risk and filters on a 'user' field, but risk events store the entity in risk_object, not necessarily in a user field. It would likely return no results or incomplete data. Additionally, the stats command aggregates scores but does not list individual events with timestamps, which the analyst needs.

Export the notable event to a CSV file and email it to the teammate.

Why it fails: Exporting to CSV and emailing is an ad hoc, out-of-band process that does not preserve the event's context, link it to a case, or provide a shared workspace. It also bypasses Splunk ES audit and collaboration features. While it technically shares information, it does not satisfy the requirement to document investigative steps or attach evidence within Splunk ES, and it fragments the investigation record.

Configure a correlation search to automatically create a Jira ticket for every notable event.

Why it fails: Automatically creating a Jira ticket can help with tracking, but it is an external ticketing integration and does not provide the in-ES investigation workspace, evidence attachment, or collaborative notes described in the scenario. It also creates tickets for every notable event rather than letting the analyst decide when to open an investigation, so it does not meet the specific needs of documenting steps and collaborating inside Splunk ES.

Run a search using the | collect command to store the notable event in a custom index.

Why it fails: The collect command writes search results into an index for later retrieval, but it does not provide any collaboration, evidence attachment, or investigation documentation features. It is a data-persistence command, not an investigative workflow tool. Using it here would create an additional copy of the event but would not let the analyst record findings or work with a teammate, so it fails the scenario's requirements.

index=risk risk_object="jdoe" | timechart span=1d sum(risk_score)

Why it fails: This search correctly filters on risk_object but then timecharts the risk score, which shows a daily trend rather than a list of all risk events. The analyst wants to see all risk events, not a time-based aggregation. While useful for trend analysis, it does not provide the individual event details needed for investigation.

index=risk user="jdoe" | stats count by risk_rule

Why it fails: This uses the wrong field name; risk events store the risk object in risk_object, not user. While some risk events may have a user field, it is not the canonical field for risk attribution. This search would likely return incomplete or no results for the intended risk object.

index=notable user="jdoe" | table _time, rule_name, risk_score

Why it fails: This searches the notable index, not the risk index, and filters on a user field that may not exist in notables. Notables are aggregated alerts, not individual risk events. This search would miss the underlying risk events and does not provide the comprehensive risk event history the analyst needs.

Export the notable to a CSV file and import it into the Investigation Workbench using the "Import Entities" button on the workbench toolbar.

Why it fails: The Investigation Workbench does not provide an Import Entities button for CSV files. Entities are added through direct search, from notables via Add to Investigation, or by manual entry. Exporting and re-importing is not a supported path and would not automatically populate the workbench with the notable's IP and user fields.

Use the "Run Adaptive Response Action" menu on the notable and choose "Risk Analysis" to open the Investigation Workbench pre-filtered by the notable's entities.

Why it fails: The Risk Analysis adaptive response action enriches events with risk information; it does not open the Investigation Workbench. Choosing it will not pivot the analyst to the entity-centric investigation view described in the scenario. This option confuses an enrichment action with the investigation pivot mechanism.

Run `| from datamodel:"Risk.All_Risk" | search ip_address=* | table _time, risk_object, risk_score` to populate a custom investigation dashboard.

Why it fails: This search queries the Risk data model, not the Investigation Workbench. While it returns risk events for entities, it does not launch the prebuilt investigation dashboard the analyst wants, and it does not carry the notable's user and IP context into the workbench. It is a manual search approach, not the supported pivot action from a notable.

Run a search to update the case's event list using the case ID and the event's raw text.

Why it fails: There is no search command to update a case's event list directly. Cases are managed through the Case Management interface or via the 'Add to Case' action. Running a search to modify case data is not a supported procedure and would not achieve the goal.

Use the 'Send to Case' adaptive response action configured in the correlation search that generated the notable.

Why it fails: Adaptive response actions are configured on correlation searches to automatically add events to cases when the notable is created. However, the analyst is manually investigating and wants to add a specific event from search results, not rely on pre-configured automation. This option does not address the manual addition during investigation.

Export the event as a CSV and manually upload it to the case via the Case Management interface.

Why it fails: While exporting and uploading is possible, it is not the correct procedure for directly adding an event to a case. The 'Add to Case' action is built into the event menu for seamless integration. Manual upload is inefficient and may lose context, making it an incorrect approach.

Configure an adaptive response action that runs a search to update the notable with the risk score.

Why it fails: Adaptive response actions are triggered by correlation searches and can perform actions like sending email or running a script, but they do not dynamically update the notable's detail view with a risk score. Using an adaptive response to run a search would not automatically populate the notable's fields for display. This is not the intended mechanism for showing risk scores.

Enable the 'Risk Score' field in the notable's detail view by configuring the correlation search to include the risk score in the notable's fields.

Why it fails: Correlation searches can include additional fields in the notable, but the risk score is not a field that is directly passed from the risk rule to the notable. The risk score is computed by the Risk Analysis framework and associated with the risk object, not the notable. Including it as a notable field would not dynamically reflect the current risk score.

Add a custom field to the notable event that pulls the risk score from the risk index using a lookup.

Why it fails: Adding a custom field via lookup could display the risk score, but it requires building and maintaining a lookup that is refreshed regularly. This is a manual, indirect approach and not the built-in method. The risk score is already available through the Risk Analysis framework, so a custom lookup is unnecessary and prone to staleness.

Enable the "Notable" action to ensure the event appears in Incident Review.

Why it fails: Enabling the Notable action creates a notable event immediately, bypassing RBA. For a rule to contribute to RBA, it should generate risk events, not notables. The notable is generated later when the risk threshold is crossed. Adding a notable action would cause duplicate and premature alerts.

Add the risk rule to a correlation search that runs on a schedule.

Why it fails: While correlation searches can run on a schedule, this is not a mandatory configuration specific to risk rules. Risk rules can be part of real-time or scheduled searches. The essential requirements are the risk object and risk score; scheduling is a general search property, not a unique RBA requirement.

Configure a throttle to limit the number of risk events per risk object.

Why it fails: Throttling is used to suppress duplicate notables, not risk events. Risk events should generally not be throttled, as each detection contributes to the cumulative risk score. Throttling risk events would undercount risk and potentially prevent notables from firing when they should.

`index=risk user=jdoe | table _time, rule_name, risk_score, risk_object`

Why it fails: This search targets the risk index directly and filters on `user=jdoe`. While it returns risk events, the risk index stores events with fields like `risk_object` and `risk_object_type`, not necessarily a `user` field. Filtering on `user` may return nothing or miss events where the user is stored as the risk object, so it is unreliable for this scenario.

`| tstats summariesonly=t count from datamodel:"Risk.All_Risk" by _time, rule_name, risk_score`

Why it fails: This tstats query aggregates counts from the Risk data model but does not filter for the user jdoe and does not return individual risk events. It produces summarized counts grouped by time, rule name, and score, which is not the chronological list of events the analyst needs. It also omits the risk_object field entirely.

`index=notable user=jdoe | table _time, rule_name, risk_score, risk_object`

Why it fails: The notable index contains correlation search results, not risk events generated by risk rules. Risk scores are recorded in the risk index and the Risk data model. Searching the notable index for a user will return notable events, but not the individual risk contributions from each risk rule, so it does not satisfy the requirement.

Open the Risk Analysis dashboard and filter by the notable's risk object.

Why it fails: The Risk Analysis dashboard shows aggregated risk scores and risk events, but it does not directly display the raw event that triggered a specific notable. It is used for analyzing risk trends and top risk objects, not for drilling into individual notable source events. This approach would not efficiently show the raw event and may not even include it if the notable was not risk-based.

Click the 'Event Details' link and then the 'View raw event' button.

Why it fails: While the Event Details panel provides metadata, it does not always include a direct 'View raw event' button. The raw event is typically accessed through the 'Investigate' or 'Actions' menu, where you can drill down to the underlying event. The Event Details panel is more for notable metadata, not the raw source event.

Run a search on the notable index for the notable's event ID.

Why it fails: Searching the notable index returns the notable event itself, not the raw source event. The notable index stores notable events, which are summaries generated by correlation searches. To see the raw event, the analyst needs to access the original index where the event was stored. While searching the notable index can provide the notable's details, it does not directly show the raw event that triggered it.

A custom search using the 'tstats' command on the risk index, grouped by rule name.

Why it fails: While a custom tstats search on the risk index grouped by rule name could show contributions, it is not a built-in Splunk ES component. The analyst would have to construct the search manually. The question asks for a Splunk ES component, which implies a built-in dashboard or view. The Risk Rule view is the intended component.

The Incident Review dashboard's 'Risk Contributors' panel, which aggregates risk scores by rule.

Why it fails: The Incident Review dashboard does not have a 'Risk Contributors' panel. Incident Review is for managing notables and their statuses, not for breaking down risk scores by rule. The correct place to analyze risk rule contributions is the Risk Analysis dashboard, not Incident Review.

The Asset Investigator's 'Risk Rules' tab, which displays rules associated with the asset.

Why it fails: The Asset Investigator does not have a 'Risk Rules' tab. It provides asset details such as priority and category, but not a breakdown of risk rules that contributed to a score. Risk rule contributions are found in the Risk Analysis dashboard, not the Asset Investigator.

`index=risk earliest=-24h | stats sum(risk_score) as total_risk by risk_object | sort -total_risk | head 10`

Why it fails: This search reads the risk index directly and aggregates risk score by risk_object. While it returns top risk entities, it does not use the accelerated Risk data model, so it may be slower and does not leverage the data model's normalized fields. It also does not guarantee real-time updates unless the dashboard is configured with a real-time time range, which is less efficient.

`| from datamodel:"Risk.All_Risk" | stats sum(risk_score) as total_risk by risk_object | sort -total_risk | head 10`

Why it fails: This query uses the from command against the data model, which does not take advantage of the accelerated summaries the way tstats does. It will be slower on large datasets and is not the optimal choice for a real-time dashboard. It also lacks the summariesonly parameter that ensures efficient summary usage.

`index=notable earliest=-24h | stats sum(risk_score) as total_risk by risk_object | sort -total_risk | head 10`

Why it fails: Notable events may contain risk information, but they are not the authoritative source for cumulative risk scores. Risk scores are recorded in the risk index and the Risk data model. Aggregating from the notable index would miss risk events that did not generate notables and would produce an inaccurate top-10 list.