|
Most control network protocols do not differentiate between sensor reading and actuator writing. Nor do most of them have any concept of encryption of any kind. Thus the reason that air gaps remain the only viable option for 98%+ of existing SCADA systems.
And of course, that is often easily defeated by the "blue hose" - the employee who wants to access YouTube from his/her workstation and jumpers the control system Ethernet to the IT network.
This is a multidimensional problem of course. It's not just about encryption or ACLs, or certs or IP addresses. It's about looking at the application domain and solving the real problems that exist. And there are no magic bullets. The requirements for
M2M are insanely diverse.
Hi Andy,
There's three aspects of this I'm passionate about.
1) Sensor data vs. Control data
In my initial survey of the SCADA security space, I found several articles which classified the data as being control data or sensor data. The classification was based on the idea that messages that operate switches and vales
had better be authenticated but that sensor data doesn't operate anything and thus has a lower risk. Based on this premise, these papers and specs recommended different security controls for these categories.
My take on it is that sensor data operates *people*. We would not collect the data if there were no plans to make a decision on it. I don't need to forge control messages to drain the nuclear coolant tank if I can forge sensor
data showing the tank is overfull. The SCADA security folks call this "manipulation of view."
A more mundane but useful example is the ability of a homeowner to enroll in a discretionary load control program. In such a program, the utility would broadcast a query asking for available load abatement capacity. The devices
would respond with their current status. For example, an LED bulb might respond with ON, 100%, 10W, 10% abatement offered. The utility would then engage as many devices as needed to achieve the abatement goal. Participants would get a rate rebate or other
incentive based on participation.
In order for this to work, the devices need to be uniquely identified, associated with a specific account and not easily spoofed. Currently the textbook approach for this is a mutually authenticated TLS tunnel between the device
and the vendor. On the Personal Clouds list for architectures this is affectionately referred to as the "encrypted-tunnel vision" architecture.
2) Death to "encrypted-tunnel vision" architecture
The encrypted-tunnel vision architecture means the vendor is the first owner of *your* data, not you. If you are lucky you get it back in real time in a useable form. My power company gives access to smart meter data in summary
only and the next day. This is useless if you wanted to do real-time load control and analytics. And they wonder why people don't want smart meters. Also, for many of these devices, they fail to function is the Internet access is down.
To be attractive, devices must report locally and function with only local network access. Without any network access, they should still operate as well as a "dumb" device of the same type. The device owner is the first owner
of the data and may (or not) choose to grant access to the vendor. However, because it's published locally, it is also possible for the device owner to grant access to 3rd parties without depending on the device vendor for integration. This aspect provides
the maximum connection density that enables IoT to live up to its promise. Without it, all we have are lots of proprietary, isolated networks of siloed things.
3) Divorce security from topology.
So why are vendors clinging to encrypted-tunnel vision architectures? There are a few philosophical reasons. If we are willing to paint the vendors as evil we might assume they feel they have a right to be the first owner of the data. However, I prefer to
think that there's a more fundamental technical restriction going on. Because the device data is unsigned, it cannot be trusted unless it arrives directly from an authenticated device. If the discretionary load abatement messages came from the Mosquitto
broker in my NAS drive instead of the LED bulb, the utility would have know way to authenticate them. I might have reverse-engineered the protocol and written an LED bulb simulator to deduct 10% off my power bill a month. But when the data arrives over a
mutually-authenticated TLS connection the vendor has some assurance of its integrity and authenticity.
Consider that the only way the modern web was able to scale was that most things to which you connect using https are *not* the actual asset you believe them to be. Most large employers implement dynamically spoofing proxies
and your TLS connection is to the proxy, not to your bank. Most large content providers are using content distribution networks where the certificate may match hundreds of web sites. Most small to medium eCommerce sites are connecting you behind the scenes
to a payment processor and not their own web site. Partly these topologies were implemented to move content closer to users, but a significant driver was that it is difficult and expensive to require 1:1 connections between all nodes in even a medium-sized
ecosystem. It's almost impossible to manage true 1:1 physical topologies because connection density increases steeply (factorial of n+1, IIRC) so you can map connections to identities in only small systems. Furthermore, changing the topology breaks the security
when the two are bound. So we invented a logical topology that *looks* 1:1 but is decidedly not. Making it scalable and peformant required hiding this complexity from ordinary users so they perceive direct connections when in fact these are rare . Because
it *looks* like a 1:1 connection, there are common beliefs that the logical topology we interact with mirrors the underlying physical topology, and that attaching identity and policy to topology is something that works and scales. It doesn't.
So if we've reached the limits of security-bound-to-topology in the IPv4 address space with mostly human endpoints, how do we expect to scale to 50 billion devices on architectures that continue to require 1:1 encrypted tunnel
connections? M2M is pushing us to do with messaging what TCP and IP do separately for packets. TCP gets the packets where they are supposed to go. IP implements a logical session over those indeterminate, multi-hop routes. With devices we'll need to have
the data published locally into a local network or cloud, then optionally routed to interested 3rd party recipients, possibly but not necessarily including the vendor of the device. Applying encryption and/or signing to the data payloads enables this. Mocana
provides the tools and framework to do much of that.
My presentation on this topic to the Personal Clouds meet-up is here:
http://personal-clouds.org/wiki/Events::SF2013-02-16
-- T.Rob
m2m-iwg-bounces@xxxxxxxxxxx wrote on 03/11/2013 09:25:45 PM:
> From: "andypiperuk@xxxxxxxxx" <andypiperuk@xxxxxxxxx>
> To: General development discussions for paho project <paho-
> dev@xxxxxxxxxxx>, m2m Industry Working Group <m2m-iwg@xxxxxxxxxxx>,
> mqtt@xxxxxxxxxxxxxxxx,
> Date: 03/11/2013 09:26 PM
> Subject: [m2m-iwg] MQTT, OASIS, security
> Sent by: m2m-iwg-bounces@xxxxxxxxxxx
>
> (cross posting deliberately)
>
> Those following the MQTT-proposed-at-OASIS thread may be interested
> in Symantec taking an interest today:
>
> http://www.symantec.com/connect/blogs/internet-things-opportunity-
> threat-and-inevitability
>
> Whilst I am sure many of us agree that there are potential security
> concerns, is device-level control always appropriate for sensors? is
> MQTT appropriately secured for endpoint use cases? looks like a good
> opportunity to discuss.
>
> --
> Andy Piper | Farnborough, Hampshire (UK)
> blog: http://andypiper.co.uk | skype: andypiperuk
> twitter: @andypiper | images: http://www.flickr.com/photos/andypiper
> _______________________________________________
> m2m-iwg mailing list
> m2m-iwg@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/m2m-iwg
|
