First rule of security: there is no security
From the basics of our one-password-fits-all world, where we post answers to our security questions on Instagram, to the deeper threat of nefarious hackers actively trying to destroy the world one device at a time, the Internet of Things security tester has to be more creative than ever before.
“We are walking towards disaster, apocalypse. Not there yet but walking towards it. It’s a time bomb waiting to explode. Why? As with any new technology, when a new technology comes in, you’re obviously in a lab mode to experiment and then you’re in an innovation mode to make it work for your environment.
Then when you find something with value, you latch onto it and tell the world ‘This is what’s going to be the next big thing!’ In Go mode, nobody thinks about security.” IBM API and IoT expert Andy Thurai explains, “Security is always an afterthought with any innovation scheme, which is OK if you move from the Hype to Reality and take care of the security, privacy, governance, compliance, first, before you [have to] live with it.”
By the nature of how close it is to our daily lives, IoT testing and design must be all about understanding what risks we can actually manage and what we can do about them, as well as identifying the risks we can do nothing about.
IoT technology is advancing at a rate that’s outstripping enterprises’ ability to secure internal and cloud resources. Organizations are increasing cyber security budgets but not at a rate that is fast enough to be in line with this rapid-to-market innovation. And it’s not just security, particularly enterprise systems have to combine security testing with testing for compliance, privacy, security, authentication, keeping records, and keeping track of security, too.
Thurai strongly advises,
“Don’t move from hype to reality without fixing those holes, moving from that lab exercise to a reality mode. When you release to the public, out in the wild, you have to have security in mind.”
When you are selling a non-disposable product with a long lifetime, like a washing machine, you may not have access to it to patch up security holes. All usage and security must be considered and tested before a device is designed and developed for the market.
Security has to be tested before any release
“When you put the gadgets, the sensors, the metric collectors, traffic sensors, motion sensors so far away from your network, the majority of the IoT devices are completely away from your enterprise Fort Knox,” Thurai said.
Add to that, he says, “When cost is cheap, security isn’t a priority.” Thurai argues that many of the sensors and devices are extremely small and inexpensive by design. “If I’m making a sensor that’s two bucks apiece, the last thing I’m going to worry about is security for the device.”
He points out that in this situation, often “the liability issue moves from the producers of all those components into the operator. And then the operator shifts the liability to the consumer by making them agree to terms and conditions, or asking for permission, most times without the consumer even understanding the full implication of the agreement.”
According to Thurai “When you’re talking about devices being used unpredictably and connecting to unknown, potentially unstable sources, bad stuff is bound to happen — the question will soon surface: Who exactly is liable?”
Still, while we talk about how different testing the Internet of Things is, testing for security usually comes down to software security testing. Of course, all hardware also needs to be tested for functionality, usability, user experience, and safety, but the security issue isn’t usually in the hardware.
Bruce de Grazia, program chair of the cyber security management and policy department at University of Maryland, University College, pointed out that just about every time you read about technical vulnerabilities, it’s in the software end of IoT.
“There are hardware failures but considerably fewer of them have vulnerabilities that will give you access to something in the machine or system itself — a switch could go bad but it’s usually the software.” At UMUC, “We teach the importance of making sure the code doesn’t have bugs and all the testing that needs to be done on the software side as opposed to the hardware side. Software testing and software development for the Internet of Things is on the cutting edge because that’s where the vulnerabilities are,” he said.
Perhaps because it’s the simpler piece for security testing, Gupta recommends that when testing security in IoT, “Start with the device. Think about the security for the mobile app and the communication between the device and the mobile app, what protocol they use", constantly keeping in mind the device and the server.
There are certainly parts of Internet of Things testing that can be automated already, but IoT security testing will probably never be able to be fully automated, at least as long as humans remain more cunning than computers.
Manual testing will remain essential to IoT security
“I don’t think everything can be automated. I think there has to be a human kicking it off, being a part of it”,
API Evangelist Kin Lane explains.
He says this is one of the goals of API JSON, to make sure your device and cloud APIs are all indexed and available in one location for testing security, performance, and load balancing. “So the theory is that at the home level, every IoT device you bring into your home—
Fitbit, drone, etc. —they all register themselves with your home router and simultaneously there should be some sort of JSON router, that creates an overall index of all the surface area.”
He envisions one day soon a software or device that you can put on your home network that scans and reports back: “Here’s all the cloud-based APIs, devices…look for vulnerabilities, look for it in the device and cloud. Send back a report: Your firmware has to be updated. That Internet site doesn’t use SSL. You’ve got this one device on your network,” creating individual security reports per home, organization, or even person.
Aditya Gupta’s Attify offers up what could be the answer to Lane’s request. Their mobile testing automated platform AppWatch will soon be evolving into a full IoT security platform, with hardware that sits on your network, between the router and the devices, monitoring what kind of data is going on through those devices and checking if that data is secure. “If a new device tries to connect with this particular WiFi, it evaluates” if it’s secure. But it’s also the tester’s job to do her best to test all security scenarios and vulnerabilities before the IoT software, app, or device is shipped.
With great power comes great responsibility
As the role of the tester increases, so does the sense of responsibility. The voice of the tester must be heard clearly throughout any IoT related organization. It becomes the tester’s job not only to test for desired results and functionality, but to explore further, asking ‘why?’ at all times. Not only should the tester be heard, but they need to push to be heard now more than ever.
Director of API architecture at API Academy Mike Amundsen puts it this way: “Security is a context-based conversation.”
As tester, you need to be careful in your thought process, always asking why when you say: “This system needs to connect to this system.” What is the purpose? Does it add an important value? In the case of former U.S. vice president Dick Cheney’s implanted defibrillator, it was clear that connecting to WiFi leaned well toward the security risk over its intended purpose to deliver information to his doctor. Sometimes it’s a case-by-case situation and sometimes it’s just dumb for any default connection to certain systems.
Brian Knopf founder of BRK Security and 20- year veteran of security research and testing, says you need to ask, “Why did you have it open? A gimmick. You want to be able to monitor them when you aren’t with them,” referencing the hacking of a child’s insulin monitor. In general, there’s a need to have the WiFi turned off by default in the majority of devices.
For Knopf, everything IoT should be:
- Secure by default
- Secure by design
- Secure by deployment
He and Lane both talk often about how it is the responsibility of the IT community to educate the public on risk factors. This is why Knopf co-founded I Am The Cavalry to develop a five-star rating system, similar to that of the automobile industry, to educate the general community on the cyber security, safety, and privacy of IoT devices. He says “Every device should be tested and results published publicly.
For this, he decided to similarly apply OWASP’s Top Ten to IoT. “Let’s list the top ten vulnerabilities and allow people to learn how to protect from them. We’ve been talking about the same ten types of attacks for decades and no one’s fixing them. And now you have people building these IoT devices and it’s even worse, and they are low security.”
While the devices are getting more complicated, the risks we face have been the same for a while. In the end, all IoT security testing is as Thurai says:
"Don't trust, always verify"
And we need to remember that everything we have now is just the beginning. “It’s just so prototype-y — the whole Internet is a massive playground,” Trifa warns.
“We’ve gone from no computers to everyone having a computer everywhere in 20 years. It’s going to be so fast. It’s going to be a lot to change, as the Internet of Things come into our houses, it’s just going to exacerbate things.”
Start security testing now, before it's too late
SoapUI Pro includes advanced security testing capabilities. You can now add security scans to your new or existing functional tests with just a click. Instead of security experts, with SoapUI Pro’s easy to create scans, security testing lands squarely with the testers and developers of your team. This helps ensure that critical API security testing occurs every time your tests run and is no more considered as an afterthought. SoapUI Pro allows you to:
- Quickly generate security scans to run against all your API tests
- Protect your APIs by running standard scans designed to mimic standard hacking techniques
- Create custom scans or layer them over existing scans to cater to your own use case
- Integrate API security with automation to ensure your APIs stay secure after every code change