What about RMF?

If you pay much attention to cybersecurity, especially in the government sector, then you are probably familiar with the National Institute of Standards and Technology (NIST) and their Risk Management Framework (RMF).  From the RMF website, "The Risk Management Framework provides a process that integrates security, privacy, and cyber supply chain risk management activities into the system development life cycle."  A major portion of RMF is the selection of relevant controls to protect information systems based on risk assessments.  These controls are detailed in the NIST Security and Privacy Controls for Information Systems and Organizations (SP 800-53) document which is currently in revision 5.  This document lists an array of controls that can be "implemented within any organization or system that processes, stores, or transmits information."  They satisfy system-level requirements that must be implemented, in some fashion, to meet security and privacy objectives of the organization.

NIST 800-53 controls are broken up into 20 high-level categories or groups, e.g. Access Control (AC), Media Protection (MP), or Identification and Authentication (IA).  The third subsection of the IA category (IA-3) is called Device Identification and Authentication.  This subsection is quoted in some detail below...

---

Control: “Uniquely identify and authenticate [Assignment: organization-defined devices and/or types of devices] before establishing a [Selection (one or more): local; remote; network] connection.”

• “Systems use shared known information (e.g., Media Access Control [MAC], Transmission Control Protocol/Internet Protocol [TCP/IP] addresses) for device identification or organizational authentication solutions (e.g., Institute of Electrical and Electronics Engineers (IEEE) 802.1x and Extensible Authentication Protocol [EAP], RADIUS server with EAP-Transport Layer Security [TLS] authentication, Kerberos) to identify and authenticate devices on local and wide area networks.”
• “Organizations determine the required strength of authentication mechanisms based on the security categories of systems and mission or business requirements. Because of the challenges of implementing device authentication on a large scale, organizations can restrict the application of the control to a limited number/type of devices based on mission or business needs.”

Enhancement: “(a) Where addresses are allocated dynamically, standardize dynamic address allocation lease information and the lease duration assigned to devices in accordance with [Assignment: organization-defined lease information and lease duration]; and (b) Audit lease information when assigned to a device.

Enhancement: “Handle device identification and authentication based on attestation by [Assignment: organization-defined configuration management process].”

• “Device attestation refers to the identification and authentication of a device based on its configuration and known operating state. Device attestation can be determined via a cryptographic hash of the device. If device attestation is the means of identification and authentication, then it is important that patches and updates to the device are handled via a configuration management process such that the patches and updates are done securely and do not disrupt identification and authentication to other devices.”

---

As one can see from above, there are not many options available to implement the device authentication control.  The document specifically refers to...

• MAC Address,
• IP Address,
• 802.1X,
• EAP-TLS,
• Kerberos, and 
• Device Attestation.

These are all valid implementations but they lack the universal applicability required for all systems.  First, it is well known that MAC addresses can be easily spoofed with simple software utilities.  It is also highly likely that IP addresses will be assigned dynamically by a DHCP server, making this control mostly irrelevant.  The 802.1X, EAP-TLS, and Kerberos options are great for certain use cases, such as generic enterprise systems.  However, these techniques are often impossible to implement in critical infrastructure systems that contain embedded, legacy, or low-power devices (IoT/IIoT).  They also often rely on usernames/passwords or digital certificates for authentication which creates maintenance issues for systems administrators.  Finally, device attestation builds high-level, easily spoof-able device profiles, base on attributes such as operating system, firmware version, etc., that can be cryptographically verified by a server.

​There is also a gaping hole in the above control that basically allows for systems to be accredited with heavy use of the phrase "Not Applicable."  Specifically, the allowance for the "challenges of implementing device authentication on a large scale," which basically means that it is reasonable to not perform device authentication in situations where it is too difficult.

We suggest a modification to the IA-3 controls that makes it device authentication a strict requirement and also includes the deployment of physical layer device authentication solutions, like IdentiPHY, as an enhancement to this important security control.

What are your thoughts?  Are there other solutions to device authentication that are relevant?  Let us know in the comments.