Ransomware: The race you don’t want to lose

September 9, 2016

In the race to detect and contain ransomware on their networks, many organizations fail before they are out of the gate.  The reason has very little to do with technology, and more so a great deal to do with process.

“But we bought all the good tools!”, such organizations protest. Good security technologies implemented and optimized properly are certainly one piece of the puzzle, however organizations, with large or small budgets, can use good processes and procedures to narrow their attack surfaces.

As discussed in a blog written by Sean Mason of Cisco Security, organizations can be rated on their overall Threat Management Maturity by what level of capabilities they have in the categories of People, Process and Technology.  Without documented processes and procedures, IT departments frequently rely on tribal knowledge and react to incidents in an ad-hoc fashion. Time to remediation is longer due to lack of assigned roles and responsibilities, and little or no pre-written and rehearsed action plans.  In the case of ransomware, the time to remediation for some organizations can be the difference between being in business and going under.

The question then is, how best to prepare for ransomware infections that are becoming a daily occurrence for a majority of organizations? The answer is a Runbook, which is focused specifically on detecting, containing and remediating ransomware. At its simplest, a runbook is a series of steps to undertake when a specific incident occurs. This is considerably less complicated than developing a full Incident Response Plan (which doesn’t necessarily tackle the heart of the incident) and there are a number of good resources on the Internet to assist with the development of one.

To be effective, a ransomware runbook should address the following:


The ways in which a ransomware incursion could be identified on a network. For less mature organizations, this is usually an end-user notifying the helpdesk or local IT support person.  It may also include IT team members recognizing an abnormal condition on a system they are responsible for. As organizations mature, this may also include alerts produced via security technologies, or via centralized monitoring platforms (e.g.: SIEM).


Ransomware comes in a wide variety of types these days. To effectively contain a ransomware threat, it is imperative that it be identified properly. Actions in this section of the runbook would address the attributes of the suspected infection (e.g.: file extension, infection vector, files created, file owner). While time is of the essence during a hunt for patient zero in a ransomware investigation, improper identification can lead to incorrect containment steps.


This is commonly referred to as “stopping the bleeding” and involves making sure the active infection is contained or terminated so damage to network systems is halted. In the case of ransomware, ensuring the executable responsible for encrypting files is no longer able to run or communicate out are common containment steps. The runbook should consider both host-based and network containment steps.

Analysis & Remediation

The inclusion and level of analysis in a runbook will largely depend on the level of capability an organization has. While full forensic analysis on a host is possible for some organizations, many do not have the skill set or time to engage in this level of investigation. Once containment has been validated, analysis may be as simple as running additional anti-virus or anti-malware scans on a host. Indeed, analysis may not even occur and the remediation step may simply be a re-image of the affected host.  A runbook should also include host and network remediation steps that address the initial infection vector, as well as how the malware was able to run on the host in the first place.

A ransomware runbook, like any other runbook written to address a specific and known threat, should be written with the organization’s actual capabilities in mind. It should also be reviewed frequently and updated based on new tactics, techniques and procedures that attacker may use as ransomware continues to evolve. A runbook will not stop all ransomware attacks, however it will enhance an organization’s ability to respond and remediate faster and more efficiently.

The following is a list of prevention, mitigation and safeguards that organizations can take to reduce their impact to Ransomware based threats and incorporate into existing process, procedures and architecture.

Ransomware Prevention, Mitigation and Safeguards

  • LAYERED HOST AND NETWORK-BASED SECURITY DEFENSES – Each system should be protected with DNS layer protections to prevent devices from connecting to sites hosting ransomware and endpoint protection for detecting and preventing the latest ransomware variants. At an organizational level, strong email and web threat protections in addition to network security (Intrusion Prevention Systems and Next-Generation Firewalls) should be utilized in also detecting and preventing the latest ransomware variants.
  • PATCHING LIFE CYCLE– A patching level cycle should be utilize to deploy updates to all systems for known Common Vulnerabilities and Exposures (CVE) in commonly used software such as but not limited to: Adobe Flash, Adobe Acrobat, Microsoft Silverlight, Oracle Java, Microsoft Internet Explorer, and Microsoft Office; where exploits can take advantage of programmatic errors and unsecure code.
  • REMEDIATION/UPGRADE PLAN FOR UNSUPPORTED OS (Operating Systems)- Develop a remediation/upgrade plan for unsupported and unpatched OS, such as: Windows XP, Windows 2000 and 2003 systems or consider the use of application white listing.
  • BACKUPS/CONTINGENCY PLANNING- A backup policy/contingency plan, procedure, and technology for systems should be developed and utilized in the event that the loss of data on a system occurs


This blog post was originally written for the Cisco Security Blog and was co-authored by Aaron Varrone.

I’m a project manager?

February 2, 2016

I recently passed the GCPM (GIAC Certified Project Manager) exam. It’s part of the core curriculum for the SANS Technology Institute’s MSISE program of which I am a second year student. Now, I want to point out that I don’t intend to be a project manager. That said, as an incident responder who frequently has a few people working with me, every client issue we respond to is, at its base, a project by definition. It is temporary (has a beginning and an end), goes through dedicated phases (including planning, execution, monitoring and closing), and requires a detailed plan if you have any hopes of being successful.

Magically, without even meaning to be, I’m a project manager. Huh…

Delegation 101

January 14, 2016

I was promoted last quarter to Manager. This was exciting and daunting all at the same time as part of me felt I was ready, and part of me suffers from Imposter Syndrome. One thing that has become patently clear since my promotion is that I have a lot more on my plate from the perspective of planning, teaching, organizing and leading. This is in addition to all the actual “doing” of client work. I am lucky that I work with very smart and dedicated people who are as passionate about what we do as I am. We are very busy, and frequently have to call on each other to assist when new work or additional tasks occur. That leads me to my dilemma. I am a terrible, horrible, no-good, very bad delegator. Not because I am smarter than everyone else is, and not because my team can’t do it (they are amazing…), but because I am bad at saying no and asking for help.

While this will be a continuing journey for me, I thought I would share some new things I’m learning about the benefits of delegation in hopes they may ring true for someone in a similar situation.

Firstly, delegating a task to someone else means I have more time to do other things. This is probably the most intuitive of my observations, (You’re all saying, “Thanks Captain Obvious!” right about now.) but if it was that easy, I’d have done it long ago. Delegation means a loss of immediate control over that piece of work. It could mean the work may be done by someone less experienced, or by someone who has a different method. Both of which could lead to different results. Right about there, my brain starts to shudder a bit and I think, “It won’t be done exactly the way I want it!” Immediately after this thought, I tell myself to get over myself, and realize, as the old saying goes, “There is more than one way to skin a cat”**

This leads me to the second benefit of delegating, making my team better. When I delegate a task to a less experienced team member, I more than likely will need to spend time with them the first time this happens teaching them my methodology, and then QA’ing their deliverable. Upfront, this means more work for me, but at the end of the day, three miraculous things happens:

1) I am now better at this task because if I can teach it, I must really understand it;

2) Someone else on my team now knows how to do what I can do. Next time, delegation will be less work and time saved for me;

3) The person who now knows how to do what I can do may then figure out a way to do that task better. Now, I am a leader of innovators!

The third benefit gained by delegating is that as a result of delegating to someone else on my team, I may learn something new. A new set of eyes on a task can bring new methods, new ideas, and new, possibly better, results.

Lastly, the net benefit of having more time for other things, leading innovators with deep skillsets, and learning new ways of completing tasks from experienced colleagues is that I may end up becoming the confident, experienced leader and manager I know I can. Delegation feels like losing control, but at the end of the day, I have learned to trust myself more to lead by example, teach to inspire innovation, and let go a little to continue to learn.

** Creepy fact from my days as a Biology major: There is, in fact, only one good way to skin a cat.

SANS DFIR Summit 2014 Slides

June 12, 2014

Here is a pdf of the deck I presented at the SANS DFIR Summit 2014 in Austin last week.

Check out all the great presentations from the Summit here.

Open Source tools I use at work

May 22, 2014

No catchy title here today. I recently did a webcast for SANS called the “7 Deadly Sins of Security Operations” and during the talk, I mentioned that sometimes, even with the choice or ability to use a more expensive commercial tool, my team will still choose to use something open source. The breadth of tools that members of the security community have created over the years and continue to innovate and improve upon is truly astounding but my list will only cover what we use on a regular basis. So for what you don’t find on my list, please make sure you look for others that can help you, and if you don’t find what you need, roll your own… and then tell me so I can use it!

Open Source Tools

SIFT Workstation
Volatility Framework
PDF Tools

And not to be forgotten, there are some great tools out there that are not open source but are free to use:


FTK Imager
Mandiant Redline

If we choose to script something ourselves, we tend to go with a coding language that best fits the job. I recently used perl to parse a particularly horrible log format into something more readable, but we also frequently use python or powershell depending on the task.

Again, this list is by NO means exhaustive. There are MANY tools out there I haven’t mentioned as the purpose of this post was just to list what we have found useful in our practice. If you have any tools that are must-have in your day to day, I would appreciate you reaching out and sharing it with me.