NIST is Working Towards International Cybersecurity Standards for the Internet of Things With Draft Interagency Report (NISTIR) 8200
The Internet of Things (IoT) is here and growing. It has the potential to facilitate or obstruct the further evolution of the Fourth Industrial Revolution; largely depending upon whether it is used or abused. Its abusers will be the same criminal and aggressor state actors that currently abuse information systems. But while there are standards and frameworks for defending information networks against aggressors, there are no adequate international standards for securing the internet of things.
In April 2017, the Interagency International Cybersecurity Standardization Working Group (IICS WG) — established by the National Security Council’s Cyber Interagency Policy Committee (NSC Cyber IPC) — set up an Internet of Things (IoT) Task Group to determine the current state of international cybersecurity standards development for IoT.
NIST has now published the draft NISTIR document: The Status of International Cybersecurity Standardization for IoT. It is intended to assist the member agencies of the IICS WG Task Group “in their standards planning and to help to coordinate U.S. government participation in international cybersecurity standardization for IoT.” NIST is seeking feedback, especially on the information about the state of cybersecurity standardization for IoT, at [email protected] by April 18.
The scope of securing the IoT is a mammoth task. To aid the understanding of this scope, NIST describes the IoT in five separate functional areas: connected vehicles; consumer IoT; health and medical devices; smart buildings, and smart manufacturing (including ICS). There are nuanced differences between securing these functional areas and traditional cyber security. While security has traditionally prioritized confidentiality, integrity and availability (CIA) in that order of priority, for the most part ‘availability’ is the priority for IoT devices.
Consumer IoT is one area that may be different, with the traditional need for confidentiality (as in privacy) still dominant. Patient privacy is also a consideration for medical devices. But, “In addition to data privacy and patient safety”, comments Jun Du, Senior Director and Architect at ZingBox, “we must also put a heavy focus on ensuring uninterrupted service of medical devices. A cyber-attack can bring down the entire hospital by disrupting their service delivery, putting patient lives at risk.”
This is the fundamental difference between traditional information security and IoT security — it is closer to OT than to IT. “The objectives of confidentiality, integrity and availability altogether focus on information security rather than IoT security,” adds Du. “When it comes to IoT security, availability of the device is more relevant to business operations than just the security of information. We should focus on availability first, then look at confidentiality and integrity.”
Even in consumer IoT, there is an operational element. Many of the threat vectors are similar between IoT and information networks, but the effects of a successful attack could be more dramatic.
The biggest problem for IoT devices, comments Drew Koenig, security solutions architect at Magenic, “are IoT devices that limit or prevent updating and patching. That’s the killer; a zero day — and the only solution is to replace your fridge before someone hacks it and floods your kitchen.”
That metaphor traverses NIST’s five IoT functional areas: crashed cars, flooded kitchens and locked doors, malfunctioning heart pace makers, stuck elevators and power failures, and failing production lines.
To get the IICS WG Task Group started in its work to discover the current state of international IoT standardization, the NISTIR 8200 compiles a table of potentially relevant existing standards separated into eleven core cybersecurity areas. These areas range from cryptographic techniques and cyber incident management, through IAM and network security, to supply chain risk management to system security engineering.
Each one of these core cybersecurity areas will present its own IoT-specific difficulties. For example, Du comments, “While encryption is a highly recommended security trend, it isn’t without its drawbacks. Encryption can hide valuable details needed by various teams including security researchers, incident response teams, and security vendors in addition to hiding them from hackers. Insider threats may also attempt to leverage end-to-end encryption to evade detection. In order to protect against these risks, IoT vendors should provide limited visibility through exportation of logs, session stats and meta data information.”
A wide range of existing and potentially relevant standards are mapped against these core areas, providing links to the standard, the standard developing organization (SDO), and a description of the standard. It becomes the raw material for a gap analysis between existing and necessary standards. Such an analysis is also provided, mapping standards to the core areas across the five functions. Only ‘cryptographic techniques’ https://www.securityweek.com/review-nist-crypto-standards-and-developmen… and ‘IAM’ have available standards applicable to four of the five categories; but always with the rider that there is slow uptake of these standards.
The fifth and missing category is medical IoT, which fares worst of all the five categories for existing applicable standards. However, the two core areas of ‘IT system security evaluation’ and ‘network security’ have no available standards applicable to any of the five IoT categories. In reality, the entire gap analysis makes depressing viewing: there are no core areas that have standards adequately adopted in any of the five IoT categories. Even where there are standards, uptake is slow.
Missing from this draft document is any standard that requires the ability for firmware updates within the IoT device build. This may be because there is no existing standard that attempts this. Where ‘patching’ is mentioned in the draft NISTIR document, it is solely for patch management, or remediation where patching is not possible.
“This document is a good start,” comments Koenig. The reality, however, is that it will be a long time before any serious benefit comes from the work. He sees two areas of primary concern. The first is a lack of regulation. NIST doesn’t regulate the private sector, although its recommendations can be required for the public sector. Even if this work eventually leads to IoT standards recommendations, it will require separate legislation to enforce the recommendations across the private sector. That still won’t necessarily address the manufacture of overseas-sourced devices, or the assembly of devices with multiple foreign components.
Without regulation over device manufacture and development, Koenig’s second big concern comes into play: “IoT devices that limit or prevent updating and patching. That’s the killer,” he says.
But even with regulation controlling the manufacture of IoT devices, that still won’t necessarily solve the problems. Steve Lentz, CSO and director information security at Samsung Research America has always believed that security teams need to do their own ‘due diligence’ on products and processes, and not rely on what they are told by vendors. He suspects that standards and regulations “will bring out vendors claiming to provide IoT security. Again, this is where security teams need to do their due diligence and really check/test out these claims,” he warns. “IoT is also Wi-Fi which is now everywhere. We need to ensure complete work infrastructure is secure just not the traditional network defenses.
“We need to ensure we thoroughly research solutions that fit our environments,” he continued. “The government can give oversight and make recommendations, but we need to find the solution that works best for us.”
Related: IoT Security Foundation Launches