The Industrial Internet Consortium (IIC) has followed up on its 2016 Industrial Internet Security Framework (IISF) with a more detailed document outlining best practices for ICS and SCADA endpoint security. In addition to the IISF, the IIC's Endpoint Security Best Practices (ESBP) build upon existing frameworks, including Industrie 4.0, IEC 62443 and NIST SP 800-53 (security and privacy controls for federal information systems).

The document is the first in a series to detail best practices across the six building blocks outlined in the IISF and is intended as a practical reference for industry stakeholders, including owner-operators, policy makers, certifying organizations, manufacturers and service providers, system integrators and to implement and evaluate the security of industrial endpoints.

The 451 Take
The ESBP should help to consolidate a variety of standards and frameworks into a unified ICS security benchmark. The recommendations come at a pivotal moment in the market's development, with near-ubiquitous connectivity seriously eroding concepts of an air gap between IT and OT systems and an increase in the efforts by state-sponsored groups to develop attack techniques targeting critical infrastructure. By bringing clarity to an articulation of relevant endpoint security measures, the ESBP has the potential to create a more even playing field between attackers and defenders. Any such consensus has its downside, such as measures that may lag behind the reality of the threat landscape or give adversaries an idea of what to expect in conforming environments.
The ESBP are also ambitious, specifying requirements such as cryptographic functionality that many endpoints may not yet be able to meet. Regardless, efforts such as these can give operators the leverage they need to put enough pressure on OEMs to build the recommended features directly into their equipment because competitive market forces are preferred as a source of change over regulation. While the ESBP also have the potential to influence regulatory policies in the event that OEMs or operators fail to respond to the heightened need for stronger ICS endpoint security, this would be a suboptimal outcome. Best practices are prone to change over time in response to an evolving threat landscape while regulation is typically slower to react.

Context
Activity in the ICS security market has accelerated in recent years, with a renewed private-sector focus on industrial and critical infrastructure threats contributing to a growing startup ecosystem, several industry consortia and increased venture funding year over year. Much of the attention paid by these vendors has focused on the security of ICS networks rather than on the endpoints themselves. Part of the reason for this network-based focus is a necessity to avoid disrupting performance because ICS networks require low latency and high reliability relative to IT networks, and older legacy equipment is unlikely to be able to support endpoint security functions typical of IT endpoints. Some more recently installed brownfield equipment may be able to support such functionality, however, and the IIC says that it is seeing greenfield equipment with a wider range of computing power capable of supporting endpoint protections, which is why the best practices document primarily applies to newer equipment.

Not to be outdone, the public sector has also stepped up its efforts to improve ICS security, at least for utility providers. Regulators like NERC continue to update the Critical Infrastructure Protection (CIP) standards, defining minimum security requirements primarily for electric utilities, but ICS security regulations remain lax across other markets. Standards bodies and industry groups such as NIST have also tried to guide the development of more secure critical infrastructure with SP 800-82, which outlines a general secure framework for ICS environments, and SP 800-53, which states minimum requirements for federal agencies and influences the private sector through the government's impact as a major technology purchaser. Despite these efforts, many industry stakeholders remain confused about what specifically constitutes an acceptable implementation of security measures in an ICS architecture and what are considered best practices. With its concise language and specific recommendations, the IIC ESBP hopes to remove that confusion as it pertains to endpoint security.

Business rationale of the document
The ESBP is intended to apply to broad groups of industry participants attempting to implement or evaluate ICS endpoint security, including owner-operators, policy makers, certifying organizations, manufacturers and service providers, system integrators and insurers. Owner-operators can use the document to evaluate their existing security processes and specify required technical features for OEMs. Policy makers and certifying organizations can apply the technologies described to future regulations or standards, while systems integrators and manufacturers can use the recommendations to build more secure ICS environments. For insurers, the best practices can be applied as a benchmark to determine an organization's overall risk level and the insurer's exposure.

Functional features
The ESBP defines three levels of security for industrial endpoints: security level basic (SLB), enhanced (SLE) and critical (SLC). The features required for an endpoint to meet SLB are root of trust, secure boot, endpoint identity, cryptographic services and secure communications. Root of trust underpins all the other services within SLB because it is the basis for the endpoint's identity and provides the ability to attest to software and hardware integrity in the secure boot phase. Although root of trust can be software based, the IIC states that it should be implemented in hardware for SLE and SLC. The ESBP also requires endpoints to support PKI and apply standard certificate management protocols to establish and manage a device's identity over its useful life. In terms of the specific cryptographic services recommended, the document states that endpoints should encrypt data in transit, at rest and in use with public key cryptography-based ciphers, hashing functions and random number generators, and that encryption algorithms should meet NIST or FIPS standards. In addition, endpoints should have the ability to upgrade algorithms after deployment and apply encryption based on user-defined policies with full interoperability for heterogeneous environments. The recommendations for secure communications build upon those for cryptographic services by specifying extensible authentication protocols and cryptographically secure communications from endpoint to endpoint and from endpoint to cloud.

SLE encompasses all the recommendations within SLB and adds a requirement for endpoint configuration and management, specifically the ability to remotely issue OS, firmware or application updates and change hardware configuration without the use of blacklists or whitelists. Again, this necessitates the use of public key encryption to secure push updates to the endpoint. SLC builds upon SLE with a policy and activity dashboard to provide visibility into and control over endpoint activity as well as a SIEM to ingest and analyze event logs to assist in security audits and incident response.

Outlook
While the industry is moving forward, both in terms of technological sophistication and cultural awareness of the safety implications of weak security, attackers continue to advance as well. The last few years have seen an increase in the number of malware campaigns targeting ICS and SCADA systems, specifically BlackEnergy, CRASHOVERRIDE, Dragonfly, Industroyer and most recently TRITON/TRISIS, which represented a new paradigm in targeting an ICS's safety instrumented system to increase the effectiveness and physical damage caused by the previous attacks. As the trend in more sophisticated campaigns against operational environments continues, a more rapid change in ICS security is also needed.

Most currently deployed industrial endpoints fail to meet the IIC's SLB requirements, in part because security is still in the early stages of becoming more of a priority for ICS operators. Requirements such as the implementation of cryptographic functionality at the endpoint may also ask more of ICS endpoints than many may be capable today or may degrade performance with the compute-intensive activity that cryptographic functions entail. While we are starting to see some improvements in terms of new endpoints with increased computing power capable of supporting broader security functions, there is still a long way to go. Given that a typical replacement cycle for an industrial endpoint is about 20 years, however, it will be some time before these endpoints are the rule and not the exception in ICS environments. Over that time, the ESBP and other documents like it will serve as invaluable guides to protect critical infrastructure and have the potential to affect future standards and regulation and influence the shape of the ICS security market.
Pat Daly
Associate Analyst

As an Associate Analyst in 451 Research’s Information Security Channel, Patrick Daly covers emerging technologies in Internet of Things (IoT) security.

Scott Crawford
Research Director, Security

Scott Crawford is Research Director for the Information Security Channel at 451 Research, where he leads coverage of emerging trends, innovation and disruption in the information security market.

Keith Dawson
Principal Analyst

Keith Dawson is a principal analyst in 451 Research's Customer Experience & Commerce practice, primarily covering marketing technology. Keith has been covering the intersection of communications and enterprise software for 25 years, mainly looking at how to influence and optimize the customer experience.

Want to read more? Request a trial now.