Industrial Internet Security Framework v 1.0

Security Framework 8: Protecting Endpoints component fails. However, if an attacker defeats the root of trust in a verified boot process, there is no way to determine that the system has been compromised. 1 With measured boot, it is possible to boot a maliciously corrupted system, however, this can be detected through attestation. Halting the process with verified boot is a terminal state for the device; with measured boot, on the other hand, the system completes the boot process even with failed attestation, and is still in the position to be fixed. The boot process protection provided by host processors can be enhanced with hardware. Depending on the host system and threat analysis, a choice can be made between several methods to involve the security hardware. Vendors of device CPUs promote the support of bootprocess protection inside their processors. For PC-based systems, the unified extensible firmware interface (UEFI) specification 2 specifies a boot process whereby the validity of system firmware is checked along with features to block unauthorized writes to the flash. It also defines implementation guidelines and preliminary evaluation methods. A significant problem with boot-process protection is the management of the measurements (integrity metrics). If the endpoint needs to be updated in the field, the integrity metrics approved for software and firmware in its boot process also need to be updated in a secure way. This management mechanism adds effort during the development and the lifetime of the device. The implementation of boot process protection on a device is not overly complex, but when this is extended to the whole system, implementation may require a significant effort. Normally, such complexity is managed by external management services, and is an integral part of supporting remote attestation protocols. 8.7.2 RUNTIME INTEGRITY After the boot-process integrity has been attested to, the OS is running and applications can execute. Runtime integrity controls monitor, and ideally, enforce the integrity of the endpoint beyond the boot process. Blacklist controls seek to identify files that contain malicious code elements, commonly known as malware. Blacklist controls define signatures that identify code elements as undesirable. It is challenging to provide a thorough blacklist of malicious indicators and keep the file size small enough on a resource-constrained endpoint. Moreover, new threats are constantly being discovered, so these definitions must be updated. The ever-present risk of an unknown vulnerability (a “zero-day vulnerability”) being exploited without being detected explains why blacklist technologies are commonly associated with traditional anti-virus products, and so more closely aligned with more loosely controlled IT operations rather than a safety-critical, and tightly regulated OT environment. The obverse of blacklist integrity protection, whitelist integrity protection, seeks to identify only those files that are deemed “good.” Signing an executable and validating the signature prior to 1 2 Physical attacks, such as booting from a USB drive, are common attacks to overcome verified boot. See [UEFI] IIC:PUB:G4:V1.0:PB:20160926 - 72 -

Industrial Internet Security Framework v 1.0 | Page 72