I have been looking into best practices for IoT and allowing access (or not) to various databases and systems that we’re using for a couple of projects. There have been some interesting points that have been made that frankly hadn’t been a consideration before.
Today, when you go buy (or provision) that next server, you typically look for a beefy enough instance that it will be able to grow with you, to keep up with where you’re headed and have some capacity left over. This is the case usually whether it’s a SaaS type instance an on-premise server or instance or a virtual machine.
When it comes to supporting Internet of Things-type solution or even setting up the overall environment to support that, things need to change. Unfortunately, this has proven to be a more difficult task than anticipated, but if you hold firm on protecting the database, and of course the information in it, you have a handhold on the core issues.
Specifically, there are multiple references to limiting the scope of the “thing” you’re attaching to only what’s needed. This is counter to the approach that’s typically been requested (like mentioned above). The reasoning for this is to limit surface area, that attackable space (or even just attackable functionality) that you can control and just flat out not have available if you have no call for it at this point.
As we have started working through some device inventories on a couple of projects, this has started to come up a bit more as people experiment with tools – this might be phones, might be wearables, might be tiny computers or cameras. It’s important to understand what types of connectivity they’ll need, and try to limit or control activity outside that space. One area in particular that I’ve seen popping up is the use of Linux boxes to do a particular utility function, perhaps a post-processing function after an IoT device spit out the data to be managed. That simple scenario introduces one fairly unknown device (the IoT device) and one extremely powerful resource, the Linux box.
In terms of attackable surface areas, both are susceptible, but both are also pretty manageable depending on your environment. The standard rules around security, updates and access points for that Linux box must be observed. With the IoT device, you’ll want to know what it is and what it needs, but also what else it’s capable of. In several cases, a very capable IoT device built on top of Raspberry Pi was something that was in the loop. It’s critical that you understand these pieces and what needs to be brought into your systems of management so you can support and manage those devices, even when they seem quite innocuous (it’s only collecting sensor data for SQL Server to analyze!). How do you repair it? Test it? Monitor it? Tell if it’s compromised? Update it?
It’s all quite possible (and if it’s not, it’s cause for pause) but should be on your list as you work to make your systems available on a broader use basis and support all of these great tools and collection devices.