The Internet of Things (IoT) is exciting... until things blow up in your face and you're left asking: What happened, why, how do I recover?
LED lighting is a huge money saver, and that's what blinds many companies. All they can see is the savings and not the need to secure what they're putting on their corporate networks.
I recently encountered this situation at a large facility -- several hundred thousand square feet -- that had newly implemented LED lights. In buildings such as these, a facility manager typically controls the lights through a hardware device -- i.e., controller -- or through software that allows the creation of lighting schemes and timers to switch them on and off. Schemes usually remain constant, but what may change is the color or some other requirement that goes with specific industries.
In this particular case, using the open firewall port (80) and a simple address on the LAN was all that was needed to access and control the six-figure lighting system for this complex. The client wanted engineering and facilities staff to access the system using their smartphones or mobile devices via in-house Wi-Fi. Security was not in its thinking.
Because the system wasn't secure, the immediate choices were to change the port for the controller Web interface and then require a password. As is the case with many IoT devices and other products involving networking, the password required use of one special character. Upon setting the password, the controller became inaccessible.
Based on my previous experiences, I suspected the special character was the source of the problem. Once the vendor arrived onsite, we used the design software to access the system. However, the installer couldn't access the system either. By entering the default username (admin) and then entering in the password I created for the controller, were we able to obtain system access.
Next, we changed the password to eliminate the special character, and we were able to restore access via the Web interface. The installer noted that neither his "Lights Day" or "Lights Low" lighting schemes would work until he changed one of the names. So, those schemes are now "Day Lights" and "Lights Low."
The programming nuances in not just lighting systems but other products remain undocumented, and often unchallenged. In this case, the technical support group that we called into on different occasions gave us the same answer: You must wipe the programming from an SD card and then load your backup program for the lighting controls minus the password requirement. Clearly this wasn't the case.
The other hook in setting up IoT on corporate networks is going to be the firewall. Content filtering gets things right, but it also gets things blocked. To avoid this, apply rules to restrict access and limit the firewall's scope.
The longer-term answer is to replace the hardware with something more secure. In the meantime, your best course of action is to work out the issue with the vendor or provider, if possible.
IT needs to take an active role in IoT implementations because vendors do what they always do. Being proactive is easier than being reactive, and unless you don't mind stirring things up and doing the break-fix thing, then pay particular attention to the vendor's equipment and solutions that touch your network.
More devices are coming to your network and people are eager to solve needs and management is always looking to cut costs and improve processes. Don't let vendors fool you into thinking that their wares are safe or protecting your interests; make them prove it.
Follow Matt Brunk on Twitter!
@telecomworx
