Are there completely secure devices?
Early in my career as a programmer I worked as a consultant for a small agency. One day we were approached by a manufacturer of high-end AV equipment who was interested in streaming data from a server to their devices. It sounded like a great job, but there was a caveat. It had to be “completely secure”, under no circumstances should a user be able to decrypt and transfer the media library to a different device.
The problem I had with that requirement was that I didn’t (and still don’t) know of any devices that are completely secure. In this case the attacker owns the device; the code is stored on the device; and the owner is a willing participant in hacking the device in order to get to the media library. I did not see any way to make this unhackable.
Being naive, I did not promise “complete security”. Instead I told them the truth: that we could offer the best security proportional to the amount of money they were willing to spend. The more money, the better the security would be. However, for every security measure I put in place, I could also think of at least one attack vector. The attacks would get more and more elaborate, but if the value of a successful breach was high enough, even elaborate attacks would be feasible.
There are certainly plenty of devices that haven’t ever been breached, but does that mean that they are completely secure? Or does it mean that the cost/benefit of breaching these devices just isn’t worth it? I know that there are still thousands of vulnerable Windows XP machines out there, controlling a wide range of critical components for large and small companies, yet these PC’s keep humming away, completely oblivious to the carnage on the Internet, simply because they have no access to it.
IP video systems have become a high profile target the last couple of years. The vulnerability of low-end devices became a headline story when a relatively simple hack of IP cameras allowed the hacker to take down a famous security blog and a global DNS provider called DYN. The banality of the script known as Mirai should be depressing to people even remotely familiar with IP security. A real-world analogy would be leaving your front door unlocked, or leaving your key on the front steps. Mirai then is a bunch of goons walking from door to door, looking for keys and attempting one common password after the other.
In the boardroom, vulnerabilities present an interesting financial dilemma. On the one hand, fixing a bug in a legacy device costs money, and doesn’t generate any revenue at all. On the other hand, if the customer accepts that the vulnerability is comparable to a broken imaging sensor, then he might buy a new camera with better features and better (or different) security. In that case, no time is “wasted” and additional revenue is generated. So, when a company is faced with a choice between fixing vulnerability X and adding feature Y, it’s quite tempting to downplay the likelihood and impact of a vulnerability, while having great expectations of the value of adding a new feature.
Furthermore, if 99% of your customers know what precautions to take, then why spend all that time and effort on the ignorant few? Why deny the 99% a new feature, and instead spend the time on protecting the 1% from their own ignorance? There’s a real risk that people who know what they are doing are not willing to pay the premium for a product that saves the foolish from the consequences of their own behaviour.
To make matters even worse, programmers that work in the realm of software security are also a particularly annoying breed; hell bent on creating a seemingly bottomless pit, in which you can throw resources to protect against largely imaginary threats. As soon as the first million dollars are spent, they will come up with new, long winded arguments as to why the software is insecure, and therefore they need more money and the product needs to be less user-friendly and have less features.
In practice, it is impossible to determine the likelihood or impact of a vulnerability. A security breach is “binary” (either it is exploited, or it isn’t, there is no half-pregnancy here), but what are the chances that someone finds the vulnerability and writes a useful exploit? So, you’re sitting there, trying to determine if your product is simply safe enough, and decide if you are going to release the product even if there is a minute chance of a breach. Are you going to place a warning-sticker on your product, if no-one else in the market does so? Surely not. Instead, you ship, and hope for the best. Placing a warning sticker on the box, will be interpreted as knowledge of vulnerabilities, when it is an admittance that modern software is just too complex to have complete knowledge of every single vulnerability in it. This applies to all software and all devices.
With this in mind, if you truly want to stay safe, you have to treat your IP based CCTV system the same way you treated your good old analog VHS based system. Keep it closed down, with no access to the internet at all. This makes it impervious to infections that attack the OS and router firmware, and it also prevents cameras from calling home. If you insist taking your CCTV system online, then you should use a proxy between the CCTV network and the outside world.
|By Morten Tor Nielsen.
Morten Tor Nielsen has been a part of the IP Video Surveillance industry since long time. For more than 17 years, he has been developing software and services for IP surveillance companies. His software currently secures both small single-camera installations and large federated installations, with thousands of cameras across hundreds of sites all over the world.