Malware Analysis Quant: Metrics—Monitor for Reinfection
Yesterday’s Metrics for Remediation pointed out that looking for malware is not a one-time action. It must be done frequently – or even better, continuously. So any cost model needs to factor in this reality. We outlined the process of Monitoring for Reinfection, where the first step is to define how often you want to check and make sure you aren’t infected again by something you have already seen. Then run through the preceding steps in the Malware Proliferation subprocess. Scan your devices with testing tools, searching the logs and figuring out how to fix what you find.
Any serious estimate of malware costs must factor in this testing and retesting. So let’s see what it looks like:
Monitor for Reinfection
|Time to run testing tool periodically||More likely: time to load rule into tool, test effectiveness, and build testing schedule – automation and scheduling yield huge dividends.|
|Time to run search queries||More likely: time to load rules into a SIEM or Log Management product, test rules, and set appropriate alerting thresholds. Searching for malware is rarely the sole justification for buying a SIEM, but that is one way SIEM returns on its investment.|
|When receiving an alert, analyze results||Similar to the Find Infected Devices section – you need to figure out whether an alert represents an actual infection.|
|Document results of alert||Assemble information for other teams to use to remediate the infection.|
|Go back to remediation if new infections are found.||You found something – now fix it.|
And with that we have documented all the metrics involved in this Quant project. We are still fine tuning the process maps, so there will be some shifting around over the next few weeks as we finalize things. So there is still time to weigh in either on the Malware Analysis Quant survey or through comments on any of these Quant posts.