Cyber Defense eMagazine May 2019

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 means 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
95