A correlation search for wastewater firewall denies is flooding notables because one noisy historian produces hundreds of matching rows. What should be configured on the search so adaptive responses do not fire on every row?
Select an answer to reveal the explanation.
Short Explanation
One chatty historian can look like a war if every deny becomes a notable. Trigger conditions are the gate: fire the action after N results or unique dests, not on row one. That is how ES searches stay house-trained.
Full Explanation
In Splunk Enterprise Security for a municipal SOC, correlation searches support trigger conditions—such as a minimum result count or a count of unique dest values—that decide when adaptive responses actually fire. For wastewater firewall denies dominated by one noisy historian, those bounds stop notables or risk events from firing on every single matching row and keep civic on-call load proportional to real bursts. Removing the historian from Asset and Identity so Enterprise Security can no longer see the host fails by concept because blinding asset context does not fix trigger logic and weakens enrichment for genuine incidents. Replacing the correlation search with an ad-hoc makeresults query that never schedules fails by concept because makeresults is not continuous monitoring and invents rows instead of detecting denies. Suppressing the entire Analyst Queue during the night shift when the historian is noisiest fails by concept because hiding all notables during peak civic operations is operational blindness, not search tuning. Exam caveat: SPLK-5001 expects analysts to request trigger conditions on ES searches when noisy civic hosts would otherwise flood adaptive responses. Operational check: edit or request the wastewater deny correlation search’s trigger conditions, set a sensible minimum results or unique dest bound, replay or wait for a noisy historian window, and verify adaptive responses fire only when the bound is met while the search still schedules and indexes evidence.