3. Why do we need to protect the IoT?
Confidential data
Control systems
4. What is there to be protected in the IoT?
Defining the scope
5. What is there to be protected in the IoT?
Defining the scope
6. What is there to be protected in the IoT?
Grouping the elements
7. What is there to be protected in the IoT?
Grouping the elements
Interaction
8. What is there to be protected in the IoT?
A visual definition
Virtual World
End-Point
Network Interface
Object
Collector
Controller
Virtual Physical
9. Physical world – physical controls
Protect the data (risk analysis)
Protect control interfaces
Perimeter is not dead
How can we protect the IoT?
General considerations
10. Standardization
Large scale access to security solutions
Secure Design and Implementation
How can we protect the IoT?
A look into the future
I would like to speak a little bit about the big buzzword of the network connected devices. I love buzzwords, they don’t mean anything, it’s just a huge umbrella trying to cover everything and then the general public is trying use the term and apply in a way that suits their needs. In the end, the median of people’s perception will generate the definition.
Because we’re at a security conference I’ll try to stay within this field and address the security aspects related to the buzzword. The 3 main questions we need to ask ourselves and the industry are why, what and how can we build security for the IoT.
I’m not going to insist on this much because Max already made the case for securing the IoT. I would like to point out the 2 major aspects in my opinion of the interconnected world. Confidential data is sent between devices and the second one is that the IoT’s end goal is to provide automation but also remote access to control systems. If we lose the grip on security we endanger both aspects.
What are we trying to protect? In order to be efficient we need to align with the security controls and define the scope. So what exactly is this IoT? I turned my face towards the infinite wisdom of the Internet to find out what it is. What you see on the slide is not random, it is actually a visual interpretation of a dozen definitions that I collected. The bigger the word, the more times it appeared in the definitions, you get the idea. Looking at this I realized that the major terms can be grouped.
Removing the irrelevant.
I ended up with 3 main categories. There you have it, that’s the scope for securing the IoT.
I ended up with 3 main categories. There you have it, that’s the scope for securing the IoT.
I resisted the temptation to come up with my own (yet another) definition and because an image is worth 1000 words, here’s my visual definition of the IoT. It is simplistic view that gives us an image of what we have to protect. It’s funny how in this IoT paradigm, the things aren’t the ones that are in scope. Your water kettle is secure by default in the virtual world until you attach sensors, remote control options and a network interface. So the scope of the virtual world is everything else but the objects. The objects have security implications and needs in the physical world.
According to this visual definition, SCADA is yet another object or thing.
I would like to emphasize the differentiation between collectors and controllers. A collector is a sensor, it reads data. Data ca be anywhere between highly confidential and public domain. The thermostat example / The heart belt example / Risk analysis of the data.
Now the controller can have very damaging implications if breached in almost any situation as it impacts the physical world directly. The risk profile of the controller is, generally speaking much higher than the collector. Think about SCADA, critical infrastructure, transportation, etc.
We have the elements, how do we protect them?
The physical world requires physical controls. You don’t normally keep your water kettle outside your house, do you? And you usually lock your door when you leave the house. Anti-tampering solutions must be designed for the grey area between the object and the network.
Data must be protected according to it’s value.
Control interfaces have a higher potential impact, thus must receive the proper attention given the increased risk profile.
The perimeter must be protected. It’s according to a fundamental security principle, security in depth. Collectors and controllers can communicate between them without sending data outside the local network, if that communication channel is not protected, then any attacker with access or proximity to the local network can manipulate and intrude.
Standardization – proprietary protocols usually fail, especially from a security perspective. TLS.
Consumer access to business or military grade solutions, like IPS and Intelligence.
Last but not least, my favorite – proper secure design and implementation
These are the 4 towers of secure design and implementation.
Governance all around, have a strategy, measure it, be pro-active.
Intelligence – understand the threats and prepare to tackle them in advance
Development – analyze, review and test, end-to-end from the early stages until ready to ship
Implementation – be sure that whoever implements the solution will do it in a secure way, you most likely don’t control the implementation. Prepare the design in such a way that you can protect against new threats, consider how will the update process will go, collect threat intelligence from deployed items.
