Questions to ask before the next WannaCry

If your inbox or social media feed is anything like my own you'll have probably been inundated with a stream of marketing material following the WannaCry(pt) outbreak last week. Amongst all the vendor bragging, claims and offers of free trials and assessments I've seen a lot of good advice from security professionals. The message is clear enough to sum up in one sentence for technical staff - patch, manage your network, do the basics. For security practitioners, this advice is a message they've repeated enough to become mantra.

I thought then it might be useful to look at this recent event through a different lens and provide a pocket guide for Business Managers looking to assess the situation and provide Business Owners with an understanding of their exposure. This can be used then to identify what help (if any) your technical teams need.  Clearly, a disconnect still exists in many organisations between risk owners and technical staff.  Below is a series of questions which can be sent to the relevant people within your organisation along with some guidance for interpreting their responses. There are no trick questions and any negative of incomplete responses should raise a red flag. 

These are by no means represent a definitive assessment (nor is it intended to be). Rather, it should highlight the key risks which those organisations effected by WannaCry failed to address in time.

Vulnerability Management 

This can be a daunting topic, especially for the less-technical - but it doesn't have to be. Equipped with these questions and you can identify the weaknesses that might have led to your organisation succumbing to this incident and set about addressing them. 

Ask yourself these questions:

• Are we installing software updates from Microsoft (and other vendors) in 14 days or less? 
• Are we capable of installing updates remotely and automatically?
• Does someone have to log on to systems (as an administrator) to install updates? 
• Can we reboot ALL systems after installing updates? 
• Are we capable of testing that these updates are received and installed on ALL systems?
• Are we capable of identifying ALL systems that AREN'T getting updates?
• Have we taken steps to isolate ALL these systems? 
• Do we have a process to roll these same updates into our build processes so that new systems are up to date when they are built?
• Do we have (and use) documented standards for building, configuring and maintaining systems?
• Has ALL of the above been independently verified? 
• Have we asked / checked ALL OF THE ABOVE with ANY 3rd parties which have access to ANY of our systems or our network? 

Guidance: Systems typically fail to receive security updates when the processes for doing this fail or the systems themselves are deployed in such a way that any downtime or interruption will result in an outage the business may deem unacceptable. 
Business lines should be robust enough to withstand outages and managers should look to support technical teams with pre-approved outage windows and you should promote the development of healthy 'roll-back' procedures rather than insisting on lengthy testing for security patches. The process of applying updates should be a scientific one, and technical teams should verify that patches have been successfully applied through reporting and the use of vulnerability scanning tools. Tooling should be employed to patch systems en masse wherever possible as patching systems one by one, by hand, is unsustainable. All systems should receive all patches within days because threat actors can weaponise vulnerabilities to those timescales. 

Source: Microsoft

Cyber Defences 

This can be a complicated area, especially for the non-technical. Typically referred to as 'controls', organisations have available to them families of countermeasures designed to detect or prevent security incidents progressing in the event that Technical Hygiene fails. Some of these will be known to you, like anti-virus, firewalls and web filters. Others might be unfamiliar to you, like Intrusion Detections Systems (IDS), Anti-exploit protection and Sandboxes. There is no silver bullet, despite what many vendors claim.

Source: Sophos

At the very minimum you should ask these questions:

• Do all systems, irrespective of Operating System or manufacturer have anti-virus installed?
• Do all these systems receive updates and do you have visibility of this?
• Can you identify systems on your network that DON'T have antivirus installed?
• Can you identify systems that have antivirus installed which aren't receiving updates?
• Do all of these systems log antivirus alerts / events centrally or to a cloud service?
• Is someone actively reviewing antivirus alerts / events?
• Do you ever test if the antivirus product is working correctly?
• Do we restrict access TO and FROM our network to the internet?
• Is our network divided so that systems that don't need to access others, can't? 
• Do we have any services exposed to the entire Internet?
• Do we perform regular Vulnerability Scans of these exposed services? 
• Have we ever performed a Penetration test with these services in-scope? 

Guidance: Aligning your organisation to a security controls framework is the most effective way of identifying realistic and practical options as well as the best way to navigate the complex world of security marketing. The Centre for Internet Security (CIS) now maintain the Critical Security Controls (CSC), which used to be called the SANS 20. This no-nonsense framework should provide sufficient structure and detail for orchestrating your cyber defences. 

Perform a gap analysis against the standard as-is then use the control objectives as the minimum requirements when defining your desired to-be state. If you lack expertise in-house, engage professional services but be clear with your requirements. Most will offer managed services which you should consider if you truly lack expertise in-house. The security industry is 1.7M professionals short of current demand - you should have realistic expectations when looking to address your gaps in head count.  

Incident Readiness

As important to controls is knowing what to do when they alert you to an Incident. Incident Readiness or Incident Response is the ability to effectively react to the detection of an issue or intrusion. This takes preparation and practice.

Ask yourself these questions:

• Do we have defined security incident plans? 
• Do we rehearse and test these plans through simulations or 'tabletops'?
• Are we confident that our preparation can accommodate for 'real-world' incident scenarios? 
• Can we perform root-cause analysis against incidents and identify weaknesses?
• Are we confident that our plans have been adapted and improved following incidents?
• Do we have arrangements in place to utilise 3rd party IR resources if needed? 

Guidance: If your controls are lacking then it's reasonable to assume you IR capabilities are in a similar state. Don't confuse incident response with business continuity or DR - having plans to inform your customers of service outages and restore things quickly is important​ but it's not the same as being able to identify and respond to an intrusion or malware

propagating through your network. Treat these adversarial situations as exactly that. Understand your capabilities for going toe-to-toe with the bad guys and train for that eventuality. You can't start down that path once you're in the ring. Use war games and table tops to begin with before upscaling to simulations and even full red-team assessments. I wrote a post recently about Simulating Incidents.