Devs! Here's how to secure your IoT network, in, uh, 75 easy pages An in-depth security guidance report aimed at Internet of Things developers has been released by the Cloud Security Alliance. Titled Future-proofing the Connected World: 13 steps to developing secure IoT products, the report offers practical and technical guidance to devs trying to secure networks of IoT devices. “An IoT …
It certainly does and it's not quite clear what "FIPS 140-2 validated modules" would provide you with anyway. All that Level 1 gives you is an assurance that an approved algortithm is used - there's no requirement for physical security - and even a cheap module that operated many times more slowly than a software implementation in the IoT device itself would likely cost the same again. And if you don't use it correctly (for example you encrypt known or easily-guessable plaintext), then FIPS compliance isn't going to help you.
That said, it's a very well-meaning document: I'm sure a lot of what they say makes a great deal of sense. However, it assumes that manufacturers of IoT kit want to invest heavily in the design of quality devices with sufficient longevity to get that investment back. The only bit of the document that is of much use to the "slap a reference design in a box and ship it" segment of the IoT market (which is almost all of it, at present, as far as I can see) is the bit that urges manufactures to "provide a secure update facility". Even that is a bit of a two-edged sword as it recommends digitally-signed updates which are unlikely to be available when your tat goes titsup and the vendor is no longer around - but will likely prevent anyone stepping into the breach without the keys.
It's not as if there's anything new here, and nor should there be.
However it is a matter of applying it correctly - too complicated, too expensive, far too much of a bother...
Unfortunately your average kettle manufacturer thinks a secure element is one that won't boil dry.
Just say no to IoT until at least 75% of vendors have done something wrt. security.
At the moment the whole schebang seems to be an open door to the hackers.
If I were a CEO I'd be keeping an eye on development but at the moment it is far too risky. At least that is what I'd hope my lawyers are telling me wrt. Liability Insurance.
1. Disallow/reject on network
2. Hunt devices with clawhammer if needed
3. Hunt (l)users bringing said devices with clawhammer if needed
4. Make this a signposted, less-than-zero-tolerance policy
5. Dispose of all evidence
6. (Id)IoT problem solved
7. ???
8. Profit
We use cheap Atmel 508a for cryptography in IoT projects here in Forres, SCOTLAND.
It includes the AES engine in hardware. So replacing the AES in software with hardware we remove cloning of nodes & servers in LoRaWAN systems.
Security is cheap, politics stops it from propagating society. Simple. Then they purchased Atmel, go figure oh 508a, hide the tech! Sell it preconfigured with backdoor root access. LOL Who for?
The 508a can also do full public key cryptography, this then removes the need to store AES keys in LoRaWAN specification. which is very poor regarding security. It uses static session keys with AES ECB keys. Very poor standard security if using software security.
With correct setup LoRaWAN can now be used for secure side channels. Even if ECB. Legacy in security arena. Another ball dropped by LoRaWAN specification, .
Even Semtech say end node providers of tech would be wise to use hardware cryptography units for public projects.
They built the LoRa modems they did not build the LoRaWAN security, i think they are the same company that purchased Atmel. Might be wrong.
This is a very important point how you implement security.
You don't do it with KEYS people can get to.
You don't ignore PUBLIC KEY CRYPTOGRAPHY in hardware.
Regards
Mark
We use cheap Atmel 508a for cryptography in IoT projects here in Forres, SCOTLAND.It includes the AES engine in hardware. So replacing the AES in software with hardware we remove cloning of nodes & servers in LoRaWAN systems.
That's nice. What happens when someone finds a bug in the hardware implementation of AES, or a weakness is found in the ciphersuite? We're back to forklift upgrades of apparently "working" FAGVO 'working') gear, on the say-so of those wild-eyed paranoid loonies down in the security dungeon in the sub-basement again. Commercial orgs are no keener on binning 'working' gear than consumers.
It's a tacit acknowledgement of the obvious: it's just not practical to fix the existing mess. All we can do wait for time and the bathtub curve to do their work. After all, little beige boxes with one green LED and a couple of wires in and out are famous for breaking down after six months... right, kids?
Since there is some IoT stuff I want to use but don't trust, I use three rules when connecting them up:
1) separate VLAN: they all go on a wifi that uses a separate VLAN, and the firewall allows access from my main network to the VLAN but not the other way around.
2) whitelisting: access from the network to the internet is blocked by default, only whitelisted devices are allowed. Guess what, none of the IoT are on it (in fact the VLAN is just blocked anyway)
3) reverse proxy: for stuff I do want to access for convenience, I set up a reverse proxy on the webserver.
I pity the poor consumer who has no network knowledge and buys some internet connected crap....
2) whitelisting: access from the network to the internet is blocked by default, only whitelisted devices are allowed. Guess what, none of the IoT are on it (in fact the VLAN is just blocked anyway)
So they can't update themselves, even if they want to? Interesting...
Good luck to any would-be IoT (although I hate the term!!) vendor that goes to their financial backers asking for time to implement things in a 75 page document. The bean counters will tell them to ship and get revenue coming in before spending time on issues everyone else is ignoring ....
NOT agreeing with that view - in any way- but been in one of those meetings, it's thoroughly depressing. Things like HP fundamentally changing the definition of "'security update" to include "significant loss of end-user amenity" certainly won't help, and if this document includes things such as a suggestion that only signed updates should be used, I hope it also includes a requirement that the keys are kept in escrow and the end customer able to get copies of keys in the event of a material change to the business.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
