Housing-authority engineers added a ransomware-hash intel table. The analyst must confirm lookups hit before any correlation search uses that table in production. How can they test it without querying live indexes?
Select an answer to reveal the explanation.
Short Explanation
Treat the new hash table like a spare key you try in the lock before issuing it to the night shift. makeresults plus eval of a known test hash, then lookup, proves the table hits — without poking housing-authority indexes.
Full Explanation
Before a housing-authority correlation search depends on a new ransomware-hash intel table, the analyst should prove lookups hit with a pipeline that never queries production indexes: makeresults to create a row, eval to set a known test hash, then lookup against the new table. That chain confirms key names, case normalization, and output fields in a controlled way and can be run during change review without touching live file-share or endpoint indexes. Waiting overnight on index= file_hash= hopes a real ransomware sample appears, which is neither safe nor a controlled validation of the table wiring. transaction on the housing file-share index forces live reads and does not validate lookup-table matching semantics. Verbose-mode rex on endpoint logs tests extraction behavior, not whether the intel CSV or KV join returns the expected match fields for a known hash. Exam caveat: a synthetic hash proves table wiring and search-time join behavior; production detections still need the real indicator feed to stay updated and normalized the same way as the test row. Operational check: eval both a hash present in the new table and one absent, confirm match fields only on the present hash, record the test SPL with the change ticket, and only then enable the correlation search that consumes the table.