Philip Barton

UK & Europe

Philip is a senior security consultant at Atkins. His background is in industrial control systems (ICS), having spent over 25 years working in a variety of markets including steel, oil and gas, pharmaceuticals and aerospace. Philip is currently part of the Cyber Security team consulting on ICS security across critical national infrastructure and UK Government.

Please complete the form below to contact Philip Barton.



Having had time to digest the major themes in this report, I think that the Government at the time seemed determined to establish the Cyber Essentials scheme as key parts of UK SMEs cyber tool kits, and to leverage the insurance industry to secure that goal.

The message was that Cyber Essentials or Cyber Essentials Plus compliance would deserve a reduced premium, as well as enabling greater cyber-risk awareness among SMEs. The report indicated that cyber insurance firms were likely to offer support in becoming Cyber Essentials certified as part of the insurance process. This patently did not happen as planned, and the UK National Cyber Security Centre (NCSC) are yet to pick up the reins sufficiently to consider cyber insurance guidance.

The report was aimed squarely at SME cyber risk in the IT space, with brief mention that Cyber Essentials may not be appropriate, or rigorous enough, for many manufacturing industries. Regulated industries and critical infrastructure will have their own regimes to follow, so what for the SME manufacturing industries? The NIST cyber security framework or the SANS 20 controls are an excellent starting point, not to mention the many standards that exist such as ISO/IEC27001, ISA/IEC62443 etc.

An obvious barrier to widespread adoption of worthwhile, insurance-backed, cyber security in the industrial arena is having sufficiently good cyber forensic capability in place to be able to back up any claim. In the event of an incident, the bias for most manufacturing organisations is naturally toward production and not to preserving evidence; it may not even be obvious that a cyber event has occurred until later.

Bringing the insurance arena up to date, a recent (March 2017) report from Swiss Re: , a leading global re-insurer, explores the cyber insurance industry today and its recent evolution. This report, like many others, misses the point that the potential costs of a cyber breach are not rising – they always have been huge. What is changing fast is the democratisation of adversary capability, the ever-lowering of the bar to entry for ransomware and other malware. The report does correctly highlight the lack of mainstream cyber risk management practices, both pre and post-event, the still-immature market, and the dearth of understanding surrounding cyber events emanating from the culture of silence. All of these must be overcome collaboratively between insurers and the insured to enable proper transfer of residual risk.

A final ‘red flag’ from the Swiss Re: research is that of uninsurable risk. This is closely linked to critical infrastructure (utilities, major industry) where catastrophic loss could lead to Government intervention. Here, the low number of events to base assumptions on, coupled with the magnitude of consequential and accumulated losses naturally tends to limit the willingness of insurers to become involved. This surely must act as a spur for industry to enable insurers to evaluate the underwriting risks better by supplying better information about cyber events.

UK & Europe,

Although I would always advocate having every feasible layer of security in place to protect an organisation’s industrial control systems (ICS), what I’d like to share now are my thoughts on how good system design techniques can augment those other layers. Doing so is a capability that is often overlooked, which is surprising considering that this is often the last line of defence after all other layers of security have been compromised.

‘Out of the box’ settings

To fully appreciate what can, and should, be achieved through rigorous design, configuration and management, one first needs to understand the condition in which ICS components are often delivered. Vendors are motivated to make their equipment easy to configure, easy to integrate, and least likely to generate technical support workload or service returns. All of this helps to create a positive first impression with their customers. To this end, devices tend to have the simplest, most accessible configuration:

  • common addresses are used (192.168.y.x)
  • default names, usernames and passwords are set
  • methods of automatic configuration are enabled (BOOTP, DHCP for example)
  • a wide range of protocols are installed/enabled
  • a wide range of services are activated, whether they are needed or not (web server, for example)

Although this is far from an exhaustive list, all of these are serious potential vulnerabilities. Default names will result in your system being easily discovered using open source methods. Default credentials will result in its compromise.

If they exist it is always worth using the vendor hardening guides to manage these risks.

Introduction of new features over time can catch out even the wary. My recommendation is to fully research all the features of your control hardware and software, as well as how to disable/secure/enable them effectively. Enable only what is needed. The temptation is always to leave well enough alone once working.


Several design choices can greatly assist with resistance to attack, post-event forensics and recovery from upset (both accidental and intentional). These include:

  • Correct initialisation of states and variables – set values explicitly at start-up
  • Strong typing of variables (in common with many programming languages)
  • Tight scoping of routines and variables (in common with many programming languages)
  • Boundary/limit checking (again, in common with regular programming)
  • Well defined and repeatable response to power cycles – hot, cold and warm restart behaviours
  • Known and repeatable procedures for bringing the process up from dark and cold
  • Independent logging of operator actions and equipment responses
  • Good User Interface / human factors design that minimises the chance of human error
  • Electronic signatures/ electronic records – record what happened and when.

Configuration control

Take the opportunity to configure security, also known as hardening, very early in a project, when risk to delivery is low. It won’t happen later, after all!

Some kit is well-behaved and allows you to load/save configuration data. Other equipment will require that you painstakingly note it down and change it manually. Having found the best settings, manage them and ensure they stay that way. Some hardware can automatically load settings and programmes from non-volatile (NV) memory on replacement, and optionally on power cycle. Ensure the correct settings and programmes are stored in NV memory. Record (and check) versions and checksums where possible.

Ongoing Management

Keeping your industrial control assets up-to-date will have benefits outside of improved security. A good starting point to ongoing management includes:

  • Survey/audit – know what assets you have and where they are
  • Information – subscribe to OEM updates to hear about patches, new features/releases and updated firmware
  • Adopt OEM security features – enable and actively manage them (code protection, security managers, access control passwords etc.)

The kind of information you need to secure a system can be a big help in maintenance. Understanding data flows and required services is really useful when it comes to troubleshooting. Making security an integral part of good system design will help to stop people seeing it as a tax.

All of these features require effort and carry some risk (locked out by your own security, for one). And while their implementation may not be completely ‘free’, you must balance the costs against the potential benefits – in cyber resilience, maintainability and Total Cost of Ownership.

UK & Europe,