Check Your Protocols

A short timeline of the Server Message Block protocol, a highly vulnerable vector, exploited in the WannaCry incident.

1996 : Microsoft Introduces CIFS

The Common Internet File System (CIFS), a proprietary, closed-source implementation of SMBv1, extends IBM's original SMB specification.

2006 : SMBv2 is Released

The second major revision debuts alongside Windows Vista and Windows Server 2008, remaining proprietary, though is now accompanied by a published specification.

2012 : NSA Develops EternalBlue Exploit

A volatile foreign intelligence gathering tool that exploits a buffer overflow vulnerability in SMBv1 that will later leak and combine with the DoublePulsar exploit, manifesting as WannaCry.

2013 : SMBv1 is Deprecated, Made Optional

The protocol is officially deprecated and made an optional component in Windows Server 2012 R2 and Windows 8.1, though remains enabled by default.

2014 : SMBv1 Exploit Compromises Sony Pictures

An EternalBlue trojan renders over 100 TB of data stolen, and 100 GB leaked, including multiple unreleased films; and private and confidential information.

2016 : DoublePulsar Exploit First Detected

The backdoor implant that with the 'EternalBlue' exploit manifests as WannaCry.

2017 : WannaCry Exploits SMBv1 Affecting the NHS

Machines running unpatched Windows 7 are locked demanding a ransom crypto payment. A minority of Windows XP machines are also affected.

2017 : SMBv1 Not Installed by Default

After 23 years, the protocol is not installed by default in Windows Server 2016 and Windows 10 versions 1709.

2021 : SMBv1 Still Prevalent

Despite the default non-installation of the protocol, a report by ExtraHop reveals that 67% of environments have 10 or more live devices running SMBv1, and even 31% with 100 or more exposed devices.

2022 : New Exploits Persist

The Common Vulnerability & Exposures (CVE) Database lists 470 entries regarding the SMB protocol, with 11 new to 2022 alone.

Consider Backup Hardware

The response to the incident primarily consisted of patching machines in person, as remote access was either non-existent or unfeasible. Infected devices were either replaced or 'rebuilt', and devices that were patched also 'refreshed' of their anti-virus.

There are many components to a successful disaster recovery plan, and retaining an inventory of hardware in the event of an incident might just be the element that saves the day. The turnaround would be much quicker, and a greater peace of mind regarding the digital 'cleanliness' of the machine.

Assess Third Parties

The NHS post-incident report details measures on internal, external, and independently conducted assessments on-site for all devices. More importantly, auditors themselves should be examined, and so should suppliers.

For support, the NHS requires that companies and professionals are accredited to Certified Information Systems Security Professional (CISSP) or Certified Information Security Manager (CISM) qualifications. Such highly regarded merits aren't without caveats, so ensure that certificates are up-to-date.

Consult the Community

Most of the best standards, frameworks, and practices are public and collectively sourced. For software and hardware, open-source offerings allow for greater transparency of the implementation, in particular function and security. Isolated organisations are ineffective.

In this context, the NHS provides a set of Good Practice Guides that can be accessed via the NHS Digital website. For health technologies in general, the government provide guidelines on digital platforms and data-driven processes.

Review Your Company

All staff should have a minimum level of knowledge around digital technologies, cyber security, and data processing. Where the role requires further knowledge, it should be met or exceeded. Through secure internal communications, up-to-date resources should be provided to ensure everyone stays informed.

In addition, hardware configurations should be appropriate, software versions current, and patches applied, with any details or discrepancies monitored and logged. Systems that are deprecated, end-of-life (EOL), or obsolete should be evaluated: keep if needed, update if possible, retire if appropriate. For extended projects, consider long term support (LTS) software versions and hardware maintenance.

Conclusion

Mitigating cyber security incidents requires policies that are not only comprehensive, but both top-down and flat in hierarchy. Management should be responsible, with cyber-security always a prioritised concern with actionable objectives.

Cyber security is a perpetual problem with incidents that are potentially long term and high impact. It is not if they will occur, but when.