Malware Incident Response

Are you in the process of establishing your malware incident response plan? This page is dedicated to helping teams assemble the key components when reacting to and investigating malware. Hopefully you are not reacting to an immediate incident as a proper program generally requires good planning. 

In the “Planning for Failure” study performed by John Kindervag and Rick Holland a number of interesting statistics a brought to light. Twenty five percent of companies have experienced a breach during the past 12 months, seven percent don’t know, 21% won’t say and 45% reported no breaches. Some suspect that the number of companies breached is actually much higher than 25%.  Also in the study, it is reported that 30% of companies breached changed nothing after realizing their security was compromised.  Simply amazing. 

john kindervag

John Kindervag
Vice President & Principal Analyst
at Forrester Research

Rick Holland

Rick Holland
Principal Analyst at Forrester Research

If you only do two things as part of your malware incident response preparation, consider the following:

  1. Prepare: Formally document the malware incident response process.  If you don’t have a clearly laid out strategy for dealing with a compromising situation, you will end up with people going off and working on different areas with no unified effort.  Clearly define the people necessary to react to a situation and what their responsibilities are. Play books that outline how to respond to specific incidences is also a good proactive measure. Make sure you documentation explains how the issue will be brought to the attention of the employees, the customers and the board members.  It should all be detailed.  The documentation should also identify the electronic assets that put your company at risk. Where do these assets reside and how is it accessed?  How are they protected and what steps need to occur in order to breach the defenses? When the breach is discovered and as the details come in, the security team needs to make the investigation and prosecution decision as soon as possible.  In other words, does your company want to simply investigate and remove the malware or do they want to collect as much detail as possible in order to take legal steps against the perpetrator? Although investigation often results in allowing the malware to run for a period of time in order to identify other compromised hosts, prosecution requires a considerable amount of additional work and requires expertise in the rules of evidence that must be followed in order to take position in a court of law.
  2. Test: Run a fire drill and test the “investigating malware” plans and documentation that the security team has put in place.  Are people comfortable and can they delegate properly? How well are people communicating and being kept in the loop? Are people clear on what their role is and do they stick to their responsibilities? Are the hand offs taking place at appropriate times. Make sure the transparency is tested; in other words, how much visibility do the existing log systems provide? How is the reporting? To learn on this, the company must budget for testing and training because, if your team is not testing, they are not prepared.  Finally, review and update your plan after each incident.  This is how many of the short falls are identified and fixed.  Remember, be flexible, but stick to the plan.  It’s OK to engage different resources depending on the issue at hand but, everyone needs to be clear on the overall effort toward the final objective.


In summary, prevention, detection and response are all very different issues and require different efforts. Preventing a robbery is the lock on the door.  Detection is the alarm system that gets triggered.  Response is the call to the police and hopefully a timely response.  Your cyber attack incident response plan is the timely response.  Learn more about our incident response system.