NIST releases IoT draft standards

Did you know that IoT security has not yet standardized? The world of Internet of Things has been in use for almost a decade, yet no body has organized to attempt to standardize this technology. In February this year the US Commerce department released a draft proposal to define IoT and recommend security standardization for the technology. Its findings however, list many vulnerabilities and ‘possible’ technologies to combat them, but few agreed-upon standards from the industry.

The Interagency Report on Status of International Cybersecurity Standardization for the Internet of Things is currently in its draft state awaiting comment. As for what the Commerce Department calls IoT, they are relying on a functional description of IoT rather than a pure example base as there are far more examples that exist and that haven’t been thought of yet to cover in the document. Here they describe that the Internet of Things consist of two things:

“IoT components are connected by a network providing the potential for a many-to-many relationship between components (this network capability may or may not be TCP/IP based); and some of the IoT components have sensors and actuators that allow the components to interact with the physical world.”

With such a broad definition, there’s a lot to be considered. In that light, there are a few mentions of particular uses for IoT that frame this document. They boil down these examples to Connected Vehicles, Consumer IoT, Health IoT and Medical Devices, Smart Buildings, and Smart Manufacturing. These examples are more divided on industry lines rather than practical application. However one thing that all these different use cases have in common is security requirements and risk. Interestingly, consumer IoT devices need the least level of security according to this document, likely owing to the number of different industries involved and providing a low level of entry.

So what are these security requirements? Commonly cited requirements include some method of verification of identity authentication against unauthorized access, protection of information and user data, and be made available to only to authorized users. There are some areas of security concern that XMPP can address directly, making it quite a good fit to address some of these regions. The document relies heavily on other standards created or approved by the National Institute of Standards and Technology, and divides this are of security into 11 different categories. Of these categories, only three are listed to have accepted standards that are finalized and readily employed. Cryptographic Techniques, which details the methods used to protect data in transmission and strong authentication. XMPP for its part already uses some of the standards listed. For example, the protocol allows for SSL and TLS integration allowing for encryption using TLS protocol which is a requirement for this section. To enhance this, digital signature keys are also recommended to be implemented, something already covered in XEP-0178. The next section, Identity and Access Management, details methods of using secure systems engaged in data retrieval from disparate systems. XMPP is already a secure technology for operating within these guidelines as there have been use cases using Lightweight Directory Access Protocol, among others, for user information and authentication have been proven in the field. The adaptability of the protocol allows for a large assortment of access management systems. Lastly, Cyber Incident Management, which details how to identify, handle, and remediate security breaches. This one is less XMPP specific, but any system using an XMPP-based-system can use the already-established standards for incident management. The rest of the categories list some standards, or none at all – a considerable concern for IoT products considering the amount of data a single IoT device can collect and provide.

IT System Security Evaluation, also lacks solid accepted standards for areas of concern. This concerns itself with providing security assessment of entire systems, including requirements and tests for cryptographic methods and checks for the same. Although many different types of automated testing exist, there is still yet an accepted method for doing this. Instead, relying on manufacturers to self-test, or worse, fix only when a security lapse has been found. Again, XMPP cannot address this specific issue, but there are some servers and testing methods that exist that could be modified to test the integrity of a server system and its cryptographic capabilities.

Next is Security Automation and Continuous Monitoring. This area fares better as there are standards in place for the protocols and data types that allow for consistent monitoring of software and hardware. There is some notation that these standards have been well developed through a number of bodies. However there is a concern that development and deployment is difficult and that, at least for the standards body, there is a lack of understanding of industrial communication protocols. Several XMPP servers have self-testing and monitoring systems built in and can easily detect the presence of malicious intent, poorly formed messages, or brute-force security breach attempts. Even such vulnerabilities, such as spam, are being looked at and addressed by the XSF currently to curtail these activities.
Network security addresses the integrity of the methods of communication, secure management of those communications, and the information sharing among inter-connected networks. Although a summary glance notes that standards are needed, an appendix lists a multitude of accepted network communication protocols but many are not mature enough for the IETF to consider a solid standard. XMPP is listed among the communication methods, but does not mention commercial availability and market acceptance. This is an unfortunate oversight as the protocol is widely in use in a variety of applications and industries. Perhaps this may be due to the ‘middleware’ type of software that XMPP is typically employed at.

XMPP backed-IoT systems can also take into consideration that many programs are open source, and thus can work within Software Assurance guidelines. These provide guidelines to reduce the number of vulnerabilities and exploits in IoT software. Depending on the architecture of the software it may be possible to build in these considerations to the code. For example, being able to update software under UL 2900 guidelines allows patching and update of software when vulnerabilities are found. Although not automated, an open source environment can pull considerable resources to produce a very solid code.

This also feeds into another area of Security System Engineering which overview the planning and design of systems in order to meet security requirements. This may employ a significant effort of engineering to produce, but systems designed for IoT should take into consideration potential security lapses, security protocols, and other similar activities. There are few accepted and in use standards for this area, so guidelines are scarce as to how to design a secure IoT system. Again, using XMPP as the backbone for information transmission allows for a robust suite of security standards from device, to user, or another device. Making it easier to comply with these engineering standards from the point of conception.

The remaining areas of concern, while important, aren’t necessarily XMPP related ones specifically. Hardware assurance deals with secure sourcing of hardware components, requiring that there is a minimal amount of vulnerabilities in the components. There are not many standards here, save for the Connected Vehicle and Healthcare IT fields. This likely due to cost, which is a considerable factor in many IoT devices. Sadly, this particular fact was exploited in 2016 during the Dyn Cyberattack which used hardware vulnerabilities to create a host of bots on thousands of cheaper web cameras using the same source for some hardware components. Supply Chain Risk Management broadens this somewhat to ensure that establishments that produce IoT software and hardware properly represent their product or service to do as it should. These standards also inform to combat counterfeit or malicious components that may be introduced during production. If such software happened to be open source, it would be easy to verify whether or not the code is working as intended. This may be more difficult for hardware to confirm, and indeed there are few standards to conform too in this respect. Finally Information Security Management Systems sets the framework for processes and controls to establish method to create a risk, governance, and compliance structure for an organization. There are a wide number of accepted standards available for this area of concern, but few of them are under broad implementation. This is more of an organizational approach towards IoT devices, and organizations may elect to use one or many to organize a secure environment. Here too, the document looks at the lack of assistance and established commercial use as an area of concern as it can be difficult, especially for large organizations, to have a focused approach toward security when existing structures may not be molded easily to better fit.

This document known as NIST 8200 located here: is currently in a public comment period, slated to end April 18, 2018. During this time those in the industry would be wise to espouse a better picture for the IoT world. Even moreso that it lacks confidence in the widespread use of XMPP technologies. I would recommend anybody willing to submit comments, especially as it currently paints a gloomy picture for IoT connected devices. A comment template is available here: and should be submitted to in order to be properly filed.

Back to Top