IoT and Security. Edge. Network. Tracking

by Albert Putnam November 15, 2016

IoT and Security. Edge. Network. Tracking

Security and IoT is a topic impossible to avoid. With the days of modern APIs, and smart edge devices, the days of isolated LAN architectures are numbered.

Recent DDoS attacks show systemic vulnerability in IoT device deploys. Some have taken the walled garden approach: Do not allow the user/owners local access to their devices. But that is not really what the customers want.

Others go with the status quo from twenty years ago. They transparently indicate that their devices are for open, shared LANs, and one had best put a series of walls around them. To be technical: Put them in a virtual private network. This puts a load, without much benefit, on IT. It also ignores internal to network breaches... systematic or accidental.

There has to be a middle road, some set of practices that is acceptable to end points and users, and IT and the enterprise.Three seem to arise.

One: 
Make some effort with the edge devices. This is old school but just recently becoming standard practice for IoT devices. When "password" is used below it can be interchanged with the term "access token" or even "authentication method".

A. Make sure edge devices have passwords.
B. Close all access methods not related to setup and operation.
C. Make sure no setup or access method can be repeated quickly, either to probe for entry, or deny others service.


In a way the ABCs are non-negotiable. D is probably the hardest, but most important:

D. Make sure edge devices have good passwords.   
This can be done by demanding first configuration password changes... Good for pilots, but unscalable in interesting large deploys. The other way is to set a strong and unchangeable password... which cannot by any means be deduced from the network. Generating a password from a network interface MAC address is close to this... except when MAC addresses leak from LAN to WAN - like when MAC are used for generating other defaults. Keeping manufacturer "cloud" databases of passwords leaves the end device a brick when the service expires. [NOTE this does not imply the owner of the device or the LAN on which it resides should not build and maintain a database of passwords - that is just their responsibility]. The key seems to be a unique long and strong local password, easy for human or machine entry, stored out of band, and only locally accessible. There are patentable and trade secret pathways therein... so let us leave it at that *grin*. Much of the above deserves to be credited to James Lyne at a Xively Xperience 2015.

Two: 
VPNs are still not easy to setup. And within a VPN their are no access controls. Modern IoT use cases of remote service beg for a way to keep the setup interfaces, for example of a motor controller and its allied pressing machine controller, available only to select external parties, while they freely communicate with each other directly in the LAN. This speaks to access control lists - ACLs. Modern microservice architectures are forging a pathway here where even "interprocess" communication needs and has ACL-like constructs. True ACL-likes are heavy weight and hard to configure... and add more pain to IT setup.

Can ACL-like setup, for by-port access tokens, be automatically templatized and deployed automatically? Software defined perimeter is an emrging standard with offerings from those like Cryptzone. Some like Illumio for VMs and containers have a method which might transfer well from IT to OT.

Three: 
Testing, tracking and logging. As well as one might develop edge and core and network and database strategies, they can be pried by inquiring minds, or they can be broken, by accident or misuse. One needs to do testing (like API testing by Smartbear, for development and production - DevOps)... but even more important, one needs continuous monitoring, so that one can learn each time something new arises -and something new will arise - one can find ways around passwords and network access controls.

At minimum on LAN and WAN, one should try watching transactions with NagiosWireshark tends to not run all the time, and MRTG is somewhat limited. And if one goes further there are tools for various types of tracking, like those from Genians and PRTG. I will go further than tools and suggest one needs to consult with someone who has experience in real world deployments, in the wild, large deploys and monitoring thereof. Like Cimetrics has with Analytikafor automation systems.




Albert Putnam
Albert Putnam

Author



Leave a comment

Comments will be approved before showing up.


Also in Cimetrics News

BACnet User Group New England March 30, 2017
BACnet User Group New England March 30, 2017

by Svetlana Lyons March 13, 2017

Do you work with BACnet - a data communication protocol for building automation and control network? Want to know more about it? You are invited to...

Read More

Analytics creates transparency
Analytics creates transparency

by Svetlana Lyons March 10, 2017

Even a cursory glance of the recent 2017 AHR Expo will affirm that information technology is creeping into every corner of the HVAC, Controls and…

Read More

The New England Women in Energy and Environment (NEWIEE) Annual Awards Gala on April 6, 2017!
The New England Women in Energy and Environment (NEWIEE) Annual Awards Gala on April 6, 2017!

by Svetlana Lyons March 06, 2017

Cimetrics is thrilled to be one of the sponsors of The Seventh Annual NEWIEE Awards Gala

Read More