502-241-2600      shopping cart    Get SUPPORT

MCM Kramer Technology Solutions Blog

Ransomware: Incident Response

                Welcome back to our series on ransomware! In the last article we discussed ransomware prevention techniques, but what happens if our defenses fail to stop an infection? That’s where having a solid incident response plan comes into play. An incident response plan is an easy-to-follow document detailing the necessary steps to contain and remediate an infection or breach.

                The incident response process for ransomware is very much like any other incident response process, with the notable exception being the decision of whether it makes financial sense to pay the ransom. We generally do not recommend paying the ransom, for a multitude of reasons; but from a purely financial standpoint, it is often cheaper to pay to regain access to your data than to attempt recovery via other means. Paying the ransom can be troublesome, as the organization may open itself to prosecution for providing financial support for a known criminal enterprise, and may be marked by the criminal enterprise as a prime target willing to pay ransom. If you make the decision to pay the ransom, be aware that there are no guarantees that you will even get the decryption keys. For this reason, it is imperative you put the requisite controls in place to stop infections before they start, have a good backup procedure in place, and develop an incident response plan before being infected.

                Incident response is broken down into six phases that dictate steps taken prior to, during, and after an infection or breach. These six phases are as follows – this information is from the SANS Institute Incident Handlers Handbook:

  1. Preparation.
    1. Make all members of your team aware of the organization’s security policies.
    2. Make all members of your team aware of whom to contact in the event of an incident.
    3. Do all members of your incident response team have access to any tools necessary to perform incident response?
    4. Regularly perform incident response drills to practice and improve the incident response process.
  2. Identification.
    1. Where did the incident occur?
    2. Who reported or discovered the incident?
    3. How was the incident discovered?
    4. Are there any other areas that have been compromised by the incident?
    5. What is the scope of the impact?
    6. What is the business impact?
    7. Have the source(s) of the incident been located? If so, where, when, and what are they?
  3. Containment.
    1. Short-term containment
      1. Can the problem be isolated?
        1. If so, proceed to isolate the affected systems. (Remove infected machines from the network, ensure there are no avenues for the infection to spread).
        2. If not, work with the system owners and/or managers to determine what actions are necessary to contain the system.
        3. Are all affected systems isolated from non-affected systems?
          1. If so, continue to the next step.
          2. If not, continue to isolate affected systems until short-term containment has been accomplished to prevent the incident from escalating.
  4. System-backup.
    1. Have forensic copies of affected systems been created for further analysis?
    2. Have all commands and other documentation since the incident has occurred been kept up to date so far?
  5. Long-term containment.
    1. If the system can be taken offline, proceed to the Eradication phase.
    2. If the system must remain in production, proceed with long-term containment by removing all malware and other artifacts from affected systems, and harden the affected systems from further attacks until you can reimage the systems.
  6. Eradication.
    1. Can the system be reimaged and then hardened with patches and/or other countermeasures to prevent or reduce the risk of attacks?
      1. If not, why?
  7. Have all malware and other artifacts left behind been removed and the systems hardened against further attacks?
    1. If not, explain why?
  8. Recovery.
    1. Has the affected system(s) been patched and hardened against the recent attack, as well as possible future attacks?
    2. What day and time would be feasible to restore the affected systems back into production?
    3. What tools are you going to use to test, monitor, and verify that the systems being restored to production are not compromised by the same methods that caused the original incident?
    4. How long are you planning on monitoring the restored systems and what are you going to look for?
    5. Are there any prior benchmarks that can be used as a baseline to compare monitoring results of the restored systems against those of the baseline?
  9. Lessons Learned.
    1. Has all necessary documentation from the incident been written?
      1. If so, generate the incident response report for the lessons learned meeting.
      2. If not, have the documentation written as soon as possible before anything is forgotten and left out of the report.
  10. Does the incident response report document and answer the following questions of each phase of the incident response process: (Who? What? Where? When? Why? And How?)?
  11. Can a lessons learned meeting be scheduled within two weeks after the incident has been resolved?
  12. Lessons Learned Meeting.
    1. Review the incident response process of the incident that occurred with all incident response team members.
    2. Did the meeting discuss any mistake or areas where the response process could have been handled better?

In addition to the steps listed above, in the case of a ransomware infection, it is a good idea to keep an offline backup copy of any encrypted files in the event that the encryption scheme is ever broken or the decryption keys released.

That concludes this week’s installment of our series on ransomware! Join us next week, where we’ll be discussing mitigating factors – namely secure backup systems.

Craving more peace in 2017?
The Yahoo Hack, largest in cyber history

Mobile? Grab this Article!

QR-Code dieser Seite