(Part II of an II Part Series)
By Daniel Jetton, Vice President of Cyber Services, OBXtek
Carter Simmons, Deputy Program Manager, OBXtek
In the first part of this discussion, we demonstrated the need for standardized security for devices within the Internet of Things (IoT) because the proliferation of these devices has gotten ahead of security, not only due to the vulnerabilities they may have, but the sheer ubiquity of this phenomena and the unknown amount of personal data that may be at risk. While the government has taken some action in the form of the DHS Cybersecurity Strategy and legislation like the Cyber Shield Act of 2017, a tried and true process must be adopted. We are moving forward on these things to some degree but need a defined standard.
The Risk Management Framework
In February the National Institute of Standards and Technology (NIST) published the draft Interagency Report on Status of International Cybersecurity Standardization for the Internet of Things (IoT), also referred to as NISTIR 8200, to provide government and public entities information on developing and using cybersecurity standards in IoT systems, components, and services. It is an artifact derived from the Internet of Things (IoT) Task Group, established in April 2017 by the Interagency International Cybersecurity Standardization Working Group (IICS WG) established in December 2015 to coordinate on major issues in international cybersecurity standardization. Specifically, it describes IoT and representative applications of IoT; reviews core areas of cybersecurity with relevant standards; details IoT cybersecurity risks, threats, and objectives; analyzes current cybersecurity standards for IoT and; provides a mapping of IoT cybersecurity standards to core areas of cybersecurity. NISTIR 8200 states that “Standards-based cybersecurity risk management will continue to be a major factor in the trustworthiness of IoT applications and devices.” IoT is unique and will require tailoring existing standards as well as creating new standards to address the wide array of IoT devices. Without these standards, it would be nearly impossible to harden IoT devices across the board and across various sectors, while maintaining their functionality (NIST, 2018 Internet). In addition, the report states, “… the adoption of IoT brings cybersecurity risks that pose a significant threat to the nation.”
In September 2018, NIST releases a draft of their internal report (NISTIR) 8222 Internet of Things (IoT) Trust Concerns. In it, they break down 17 trust concerns that impact the security of IoT devices and services and is derived from their SP 800-183 (“Networks of Things”). They identify actions for mitigation and push additional areas for further exploration and study. As of the publication date of this article, the current draft has been withdrawn from the web, “to synchronize with other pending documents on this topic, and to ensure time for stakeholders to review and comment.” NIST adds that, “Once the draft document has been re-posted, the comment period will be extended” (NIST, 2018 Interagency).
To expand upon this, we feel a NIST Risk Management Framework (RMF) approach may be used to secure IoT devices. The RMF is a common information security framework used by the federal government to improve information security and risk management processes. Simply stated, the RMF provides a review of an information system’s security against established baselines. Identified risks are either fixed, mitigated, or deemed acceptable, in accordance with their usage. Once the system has gone through the testing phase of the RMF, the security and risk level of the system is vetted to the owner of the system. The designated “owner” may then accept the risk and grant the system an Authorization to Operate (ATO) on their network. The six-step process, involves 1) categorization of information systems based on impact due to loss of Confidentiality, Integrity, and Availability (CIA), 2) selection of security controls in accordance with a baseline and categorization results, 3) implementation of NIST security controls, 4) assessment of security controls addressing objectives and methods verifying compliance, schedule and procedures/validation and assessment with remediation as necessary, 5) authorization of information systems results in submittal and review of the package to the System Owner (SO) who will accept any residual risk and 6) monitoring of security controls to detect changes, their impact and updating of documentation to reflect current status. The cycle is typically three years before reassessment unless other continuous monitoring strategies are in place.
Figure 1. The NIST RMF Process
Applying RMF to IoT
To effectively apply the RMF to IoT applications and devices, security categorization data types listed in NIST Special Publication 800-60 (Guide for Mapping Types of Information and Information Systems to Security Categories) would need to be updated for IoT and an A&A effort would need to occur with IoT developers. These are not the only things that would need to be tailored to apply RMF to IoT, but they are major factors. To properly categorize the IoT devices, new data types will need to be developed based on the type of data a system or device stores, processes, or transports. Once all the related data types have been selected, the IoT developer will be able to determine the CIA of their product. Based on the CIA, the IoT developer can secure their product using a minimum-security baseline of security controls. The developer could conduct a “Type Authorization” on its products to establish a security hardening standard and ensure it is implemented with their respective applications and devices. This would force IoT manufacturers and developers to manufacture their components with security built in, meaning when an IoT device goes to market it will have already been hardened to a minimum set of security controls and configurations. As most of the world lacks security expertise, the average person would not be aware of or know how to better secure their IoT devices with best practices. Incorporating security-based configurations as default configurations within IoT devices would be a significant first step to securing the IoT environments.
Another Possible Solution (Plan B)
Underwriters Laboratories (UL) has worked in the public interest since 1894 providing a safe living and working environments in 46 countries. Most people recognize that the UL symbol on a product certifies it as having passed their rigorous test and review process for safety, quality, and performance (Underwriters Labs, n.d.). Over the years UL has established standards for myriad devices including electric lamps, heating and cooling equipment, appliances, smoke detectors and power cords (Internet Archive Wayback Machine, 2002). Similar to the way UL works, another independent organization could be formed to certify security standards for IoT devices. The organization can be governmental or an offshoot of a non-profit. A non-profit organization may be the solution to developing new standards and administering/grading/certifying products similar to the way the Joint Commission on Accreditation of Healthcare Organizations (JCAHO) stepped up to fill a void by creating standards for health care facilities. For example, the “IoT Accreditors (IoTA) Group” (let’s call it) could be the one-stop shop for companies to secure their IoT gear before introducing it to the public. Any device with the IoTA™ logo would have gone through the rigorous testing and inspection process developed by the IoTA Group and accepted as the de facto security standard similar to guidance from the Cyber Shield Act of 2017 about voluntary certification and labeling of IoT products.
A Fly in the Ointment
Whether we use a government agency like NIST, with established standards, or a non-profit organization like Underwriters Laboratories, who can develop their own standards for certification, one issue remains. The problem with certifying devices, in this day and age, is that the devices change. UL listed lightbulbs and power cords aren’t typically upgraded, augmented or altered in any way. Alternatively, today’s IoT products facilitate upgrades, updates, and modifications. While we may be heading in a positive direction with IoT security standards, alterations from upgrades, updates, modifications or added applications remain a major security certification issue. These alterations change the security configuration of a device, possibly voiding any prior certification and making the device vulnerable. Downloaded upgrades, updates, modifications, and added applications mean that the products that were once approved as safe are no longer the original secure product. The three-year NIST RMF cycle keeps government systems secure in continuity through continual review of any changes by the assigned engineers. Unless an IoT device is “set and forget” hardware that never requires alterations of any kind (unlikely in this day and age), they will need to be reviewed and re-certified when configuration changes are made. IoT security necessitates that: 1) IoT devices must be continuously monitored for changes to their risk status, 2) only pre-approved upgrades, updates, modifications, and applications, in accordance with security certifiers, are allowed on the device and/or 3) IoT devices, once certified, are hardened to prevent any changes (i.e. set and forget/secure and endure). Any unapproved upgrades, updates, modifications or applications void the certification/security.
The configuration change vulnerability forces us to focus on the continuous monitoring phase of the RMF which addresses continued security to address configuration changes. Re-certifying security is considerably easier in a controlled environment where an organization can readily track changes and adjust devices and systems ad hoc. This is a lot harder when dealing with the public at large. There is no magic pill to keep devices secure/certified, but we offer a few ideas for contemplation. Perhaps IoT devices, once upgraded, updated or modified could be re-examined by running something similar to the virus scans we do on our personal computers. These scans would be device specific and provided by the manufacturer free of charge. The IoT devices could connect to a laptop to run diagnostics/scans in the same way your car can be connected to a diagnostic computer to run tests. After a scan, the results would show current vulnerabilities and offer downloads to fix those shortcomings. Simply put, every time a device’s configuration changes (e.g. a downloaded update), a re-scan would once again certify the device as secure. Tesla vehicles receive “over-the-air” software updates that introduce new features and functionalities. There is no reason this same process can’t be used for IoT security.
Without a solution that allows consumers to conveniently and cheaply secure a device, vulnerabilities will abound, and security will suffer. Certifications will mean nothing. Even making the process easy won’t necessarily ensure security. 14% of cell phone users admit to never updating their software and 28% do not lock their smartphone (Anderson and Olmstead, 2017).
The government, especially NIST, has taken strides to identify and mitigate IoT security concerns but is yet to be seen how effective the DHS Cybersecurity Strategy, the Cyber Shield Act of 2017, NISTIR 8200 and 8222 are at this point. The NIST RMF, already a standard for systems security in the government, could be introduced as a proven process for securing IoT. Alternatively, non-profit organizations like Underwriters Laboratories and JCAHO have a definitive history of providing needed services to users by establishing their own accepted standards for safety. Whether the government or an independent organization take the reins, it will be necessary to adopt security standards and mandate their use in establishing a base-level of security to protect consumers and secure IoT devices. While we have options for developing those standards and processes, the problem of keeping those devices secure in perpetuity in lieu of updates, upgrades, and modifications will remain the primary challenge.
Anderson, M. and Olmstead, K. (2017). Many smartphone owners don’t take steps to secure their devices. Retrieved from http://www.pewresearch.org/fact-tank/2017/03/15/many-smartphone-owners-dont-take-steps-to-secure-their-devices/
Internet Archive Wayback Machine. (2002). Underwriters Labs3. UL’s Standards for Safety Standards Catalog. Retrieved from
NIST (2018). Interagency Report on Status of International Cybersecurity Standardization for the Internet of Things (IoT). Retrieved from
NIST (2018). Internet of Things (IoT) Trust Concerns: NIST Releases Draft NISTIR 8222 for Comment. Retrieved from https://www.nist.gov/news-events/news/2018/09/internet-things-iot-trust-concerns-nist-releases-draft-nistir-8222-commentUnderwriters Labs. (n.d) Our Mission: Working for a Safer World. Retrieved from https://www.ul.com/aboutul/our-mission/
About the Authors
Dan Jetton is the Vice President of Cyber Services for OBXtek. He is responsible for leading and defining cyber strategy while ensuring security, defense and risk mitigation for his clients. OBXtek’s accomplished teams have an established reputation for consistently and efficiently achieving goals for its portfolio of federal government customers. Dan Jetton, MBA, MS, MA is a CISSP, CAP, and PMP with 20 plus years of military service. He can be reached online at https://www.linkedin.com/in/danieljetton/ and at the OBXtek website http://www.obxtek.com/. You can follow him on Twitter @CyberPhalanx for cybersecurity news.
Carter Simmons, MS, CAP serves as deputy project manager on OBXtek’s State Department Bureau of Consular Affairs and Office of Consular Systems and Technologies’ Information Systems Security Support (ISSS) team on which he offers expertise in the risk management framework (RMF). In addition to his certification as a CAP (Certified Authorization Professional), he holds a master’s degree in Cybersecurity from the University of Maryland University College.