There is an interesting blog post over at ThoghtFest.co.uk
about how vulnerabilities in the ‘internet of things’ may impact cybersecurity
operations. The author, Bob Griffin, the Chief Security Architect at RSA, uses
recent reports about a ‘smart’ refrigerator being used in an DOS attack to take
a brief look at how we are going about security critical infrastructure.
Bob makes the point that while it is sad that the embedded processor
in the refrigerator is vulnerable to attack and subsequent use as a message source
during a DOS attack, it does not really make that refrigerator a cyber threat.
Instead, it would seem that it would be more profitable for a security manager
to focus on how his networked items respond to such an attack. If his network
is properly and adequately protected then a rogue refrigerator is no more of a
threat that a script kiddie with an old computer and slow modem.
The time spent responding to the ever increasing number of
vulnerabilities, and particularly the vulnerabilities being discovered in industrial
controls systems, will detract from the real core security problem here; the
detection and response on assaults on our systems. Regardless how good our
security teams are, something is going to get through the security perimeter
and assault our systems. Attackers only have to get it right one time while the
defense only has to fumble one attack to fail.
1 comment:
The issue is how we develop embedded systems. Usually someone picks an OS, and then adds some I/O, and some software, and voila, you have a "web-enabled" appliance.
The problem is that the OS parts weren't customized and exorcised of the other unused features. Many have back door systems with telnet enabled. Many have memory management and debug features that nobody bothered to remove before production. Some have complete FTP and TELNET servers still lurking in them, despite the OS having them disabled.
Do you want real security? Then start by removing everything but the things that absolutely must be there. Embedded systems aren't easily patched --nor should they be! The less stuff there is in the embedded system, the less likelihood that you will need to patch it later.
Honestly, I don't want my refrigerator to be web-accessible. Web accessibility has become like that guy with only one tool in his tool box: The hammer. And to him, everything looks like a nail.
Why not a read-only capability with a simple protocol such as Modbus? It's not as if you need to read refrigerators across the world. Let the device that is talking to it interpret the data and make the pretty pictures. Why should a hard-to-patch remote device have to do that complex stuff? A read-only ModbusTCP interface can be well understood and easily added in to a browser, a database server, or the maintenance systems for an entire enterprise.
If absolutely needed, a few supervisory commands such as "turn the icemaker on/off" or go in to "load-shedding mode" could be added within limitations that are hard-wired in the device.
But most of all, keep it simple, fuzz, and validate all inputs. Leave the OS stuff for the things that can be patched.
Post a Comment