Recently the mainstream media has been awash with horror stories about ‘CCTV’ devices being used in DDoS attacks, opening up entire systems to state-sponsored hacking and allowing simple techniques to be used to break into systems with little to no effort or enterprise from the attackers. Benchmark considers the implications for the surveillance sector as a whole.
Recent mainstream media reports seem to have focused on the role of CCTV devices in DDoS attacks, the hacking of critical infrastructure and even state-sponsored spying via backdoors built into devices. How this impacts on the security surveillance industry will be very much based on who is reading the reports and whether they have an understanding of certain issues.
It is also important when considering the reports to be able to separate hard facts from speculation. Of course, the problem for the video surveillance sector is that its customers – including many who are reading the reports – will view CCTV as a generic technology. For them, the message is that CCTV is vulnerable and that’s all they’ll care about.
Some of the media stories have gone unchallenged by the professional security industry, and that is a significant problem for the more astute installers, integrators and manufacturers who do take security of the systems themselves seriously. The various bodies that claim to be the collective voices of the industry haven’t set out to clarify matters, and the commentary that has been offered is both unrealistic and unhelpful.
While much of the negative press doesn’t directly involve the professional video surveillance market, it does impact on us all. In recent times, end users have increasingly demanded that installers and integrators can prove steps have been taken to secure their systems. It’s no longer enough to state that systems are secure; customers want evidence. They are also taking a closer interest in all elements of their systems, and this is an area which manufacturers need to consider when creating software-based solutions.
While many of the problems emanate from outside the professional surveillance industry, it would be foolhardy to pretend that there have not been problems, and that there will not be further issues around the corner.
Hacking CCTV systems has become something of a trend, and the intensity of media coverage is likely to get worse before it gets better.
The manufacturer’s issue?
Professional manufacturers have taken steps to increase the security of their devices in recent years. Many are implementing processes that force default authentication credentials to be changed during installation. Some are even imposing secure password policies, ensuring that the new device passwords include upper and lower case letters, numbers and symbols.
This in itself has caused some issues as not all manufacturers take the same approach. The result is that unified policies, which are easier to police, sometimes cannot be created by installers and integrators.
Another issue has become obvious during Benchmark tests in recent times. Where manufacturers insist upon the use of a symbol in secure passwords, there can be problems with ONVIF implementations. We have seen devices become undiscoverable when certain symbols allowed by the manufacturer are included in authentication strings.
Whilst no one will argue against any step that increases the security of the system itself, these cannot impact on the use of systems, especially where products are integrated into a solution using equipment from a variety of vendors.
However, one of the biggest issues comes from a number of manufacturers using outdated technologies for configuration and set-up. ActiveX and Java implementations have proved to be attractive to hackers and cyber criminals in the past, to a point where the IT sector is developing browsers and services that reject them. Despite this, they still remain widely used in surveillance.
During surveillance system installations and configurations, it is not uncommon for processes to be identified as ‘not recommended’ by OS software. Indeed, there are many manuals that identify a warning will appear and instruct that it be ignored or that the action identified as ‘not recommended’ be taken. Certificates are often flagged as being not recognised or out of date. Often basic IT security needs to be disabled to allow configurations to run. All of these create warning messages which security installers and system integrators have been taught to ignore. In reality, these issues exist because it’s easier for the manufacturers.
As an example, in the recent Benchmark VMS test, one package created alerts for an incorrect certificate, and several people involved in test stated that some of their customers would have halted the installation on the spot if they saw those.
In truth, you can’t blame them for such an attitude. The manufacturers – and to some extent the installers and integrators – might be assured that no ill will come of it, but the customer simply will not accept anything flagged as a risk.
There also needs to be an appropriate level of responsibility taken when things do go wrong. In a number of recent cases, manufacturers who are active in the professional security industry have experienced problems with products, albeit ones in other sectors such as IoT or home (DIY) security.
In one case, simple security procedures were not followed which allowed a much-publicised exploit to be used to take control of a camera. In another a security key was accidentally revealed as part of a firmware upgrade and found itself in the public domain. This meant that hackers could have injected malware into systems and it would have been accepted as it was accompanied by an appropriate certificate.
In both cases the manufacturers did not act, instead preferring to ‘hope’ that the issues went unexploited rather than facing the risk of reputational damage due to admitting fault. In the latter case Microsoft itself retracted the security certificates to prevent potential risks as the manufacturer did not act.
A manufacturer might have different business strings, but to the customer it’s all one brand and is judged by its actions, regardless of the actual market the issues occur in.
The engineer’s issue?
Whilst manufacturers can certainly do more to reduce risks, so can installers and integrators. One of the simplest steps is to consider the credibility of systems and solutions that are being implemented. The inclusion of credible security features is not something that can be done on a shoestring, and it’s not a great shock that many of the systems being compromised for DDoS attacks and other hacking attempts reside at the ‘budget’ end of the market.
Low cost devices which are aimed at less skilled handymen and the DIY sector will always put ease of use above security. This is because any difficulty will result in a need for increased technical support, which again costs money.
However, using credible systems isn’t the be-all and end-all. Device hardening must be considered. Reducing the potential attack surface should be a standard approach to any installation. If a device does not need to be remotely accessible, then don’t implement connectivity. If a process or service is not needed in a given application, switch it off. Not only does code running for no reason impact on the performance of the processor, it gives another potential point of attack.
Implement secure authentication, use features and functions such as IP filtering and talk to suppliers about how to best protect their products. If they can’t (or won’t) help you, walk away.
The surveillance sector needs to deliver innovative and smart solutions that not only offer security, but are also secure!
Implementing a Security Policy
James Smith, Managing Director, Wavestore
The first rule when commissioning a surveillance system is to always change the default password. The failure to do so is a very common problem that affects thousands of sites, and it doesn’t take much searching on the internet to discover the default passwords for a wide range of equipment.
The second rule is to prevent unauthorised physical access to the server. Generally speaking, if somebody can get physical access to it, then they can breach security measures. The security of security equipment needs careful consideration in order to prevent attacks.
The third rule is secure the network. Good network design – and security across the network– is essential.
Wavestore’s VMS is an embedded Linux-based system and is provided preconfigured with stringent security measures in place, such as firewall protection and protection against ‘man-in-the-middle’ attacks. As a company we feel it is important that systems have these features preconfigured rather than relying on the user to set them up.
Because Wavestore is Linux based we also don’t have to worry about Windows security updates and vulnerabilities within the servers.
We can restrict access to all but authorised IP addresses to help eliminate the risk of unauthorised users logging in from other remote computers. This is a feature that is important and where available should always be implemented.
Another tool to reduce risks ins the implementation of ‘privilege separation’. This makes user accounts more secure. Key processes such as the Wavestore VMS server run as non-administrator users. This ensures that even if a certain process were hacked, the hacker would not immediately gain administrator access to the entire system.
At Wavestore we have an on-going third-party security programme that purposefully tests for vulnerabilities within the system. This gives us confidence that the solutions we are providing are as secure as possible. The reason this is an ongoing programme is because threats change as technology and working practices evolve over time. It is important to be certain that we are keeping up to date with the various evolving risks that systems face in the real world.
One issue that has cropped up recently via the media is conjecture about the ability of manufacturers or state bodies accessing private surveillance systems at will. Some equipment vendors have generic back-door access points, typically referred to as a ‘root login’. These access points are typically always open so that the manufacturer can access the system for reasons such as trouble-shooting and technical support. The problem is that unauthorised access to these root logins is not uncommon.
At Wavestore we don’t operate such a system. As a result, should an installer or system integrator have a need to grant our technical support team access for remote diagnostics, they have to be physically with the Wavestore server to grant access and also to provide the technical support operator with an administration account and password that they control. When the diagnostics are completed the installer or integrator can close the remote access and delete the administration account.
Wavestore offers up to 4096bit encryption for video, allowing the option for secure public keys to be used when encoding and decoding video if required.
In addition, we also offer password protected encryption. This ensures that if the user exports video footage of an incident and provides it to the authorities for evidential purposes, the secure public key details do not need to be shared to allow viewing of that specific export.
Finally, on Wavestore systems the log in details are always encrypted using very strong password hashes. We additionally provide ‘man-in-the-middle’ protection as standard.
A man-in-the-middle attack occurs when a hacker relays and alters communications between two entities that believe they are communicating with each other across a secure link. The attacker intercepts communications and injects false elements to take control of systems.
We can also ensure that password policies are enforced as users have to change the default during the first log in; passwords are also required to conform to a secure password policy.
Putting Cyber Security First
Tim Biddulph, Head of Product Management, Hanwha Techwin Europe
When it comes to the issues of cyber security, there are two separate problems which are often discussed. One is the use of ‘back doors’ in systems, usually created by the manufacturer to allow diagnostics and technical support. The second is third party attackers exploiting vulnerabilities – whether created by the installer or the manufacturer – to access and take control of systems.
Recent press speculation about the use of intentionally created ‘back doors’ to gain access to a surveillance system highlighted the first issue. This can be managed by manufacturers through company policy. Hanwha Techwin recognised the issues surrounding such an approach in 2012, and as a result removed a function used for remote customer support that had the potential to be exploited.
At that time the firmware for every model was upgraded to remove the feature, and third party agency testing was introduced to ensure that the firmware was secure. Since then this policy has remained in effect.
The risk of cyber attacks and hacking is based upon insecure passwords or other exploits to gain access to, and take control of, a surveillance device maliciously.
Cyber crime and hacking can have economic and social implications, but if the security sector responds appropriately it can manage the problem and ensure that attacks do not become a critical issue for end users.
Hanwha Techwin has decided to make security a fundamental feature of its products and systems. Cyber security is considered at the very start of the product design process; it is not just treated as an optional feature.
As a result, Hanwha Techwin products are designed specifically to incorporate best practice, and include measures to prevent unauthorised access to images and data as standard. It is also vital that such an approach does not lead to complacency, so the company is constantly monitoring and testing the latest methods of hacking using third party security agencies. When necessary, new firmware is released to ensure that the products can counter the latest threats.
It is important that a balance is struck between security and ease of use, but that balance must also reflect best practice. While Hanwha Techwin appreciates that security needs to be easy to implement, it is essential that there should be auto-enforced standards in respect of passwords. Sadly, a number of manufacturers have not built these standards into their products.
The standards-based approach includes basic steps such as prohibiting the consecutive use of the same letter or number, and enforcing the use of special characters as well as a combination of letters and numbers. It is vital that manufacturers force the creation of a secure non-default password during the initial installation process.
Hanwha Techwin has also looked beyond its own devices to implement solutions. One example is the partnership created with Veracity to offer a physical solution in the form of LINKLOCK. This is a device manufactured by Veracity which prevents any unauthorised network access. It does so by blocking connections to any cable or device that has been tampered with or disconnected. This makes it an ideal protection measure for security critical installations where network cabling or video surveillance equipment might be located externally or in non-secure areas.
There have been some recent high profile examples of hacking which have occurred simply because sensible password protocols were not implemented. Whilst the majority of cameras are not installed for mission critical or high security purposes where military level encryption may be required, users are entitled to secure video surveillance systems.
Cyber crime is a problem that is not going away unless the entire supply chain – system designers, security installers, system integrators, distributors and manufacturers – collaborates and shares information so that the security industry can always remain one step ahead of the hackers.
Hanwha Techwin would urge all manufacturers to follow the lead we are taking on this. In addition to the security functionality built into our products, we are ensuring through our training programmes that password protection is on the top of the list of priorities when installers and systems integrators commission cameras and recording devices.
A Proprietary Approach
Billy Hopkins, Technical Manager, IDIS Europe
Most often, network security breaches are not caused by exploiting the weakness of encryption technologies; rather they are mostly the result of human factors, such as not enforcing best practice.
Typically, when an organisation deploys a video management system (VMS) with around 300 IP cameras, they have to manage around 300 IP addresses, 300 MAC addresses, and 300 login credentials for the IP edge devices. This creates a high level complexity to manage during the whole life cycle of the system.
Most IP cameras and encoders now force users to change the login credentials during the first connection to the device. Often the secure password creation has to include upper and lower case letters plus numbers and special characters.
However, when there are hundreds of devices, most of the time installers and integrators do one of two things: they use a single login credential for all cameras and encoders or they create an Excel spreadsheet containing all of the authentication information.
Neither of these approaches are best practice and manufacturers should be educating installers and integrators on the importance of secure authentication as part of their certification programmes.
Any IP-based video surveillance systems should be developed with network security and data integrity in mind. For example, a system can be designed to utilise true plug-and-play connectivity with implicit pairing of devices, and in doing so the system reduces the amount of information that needs to be managed.
The registration (pairing) of IP cameras and NVRs can be implicit and hidden from users, similar to a Bluetooth headset and mobile phone. Once paired, the headset only communicates exclusively with the paired phone. In a similar way, using this approach, an installer does not need to manage the device, minimising the level of human risk during implementation.
This can be seen as a benefit, because it can easily reduce the system complexity significantly. A user only needs to manage one IP device: the NVR.
At IDIS we call this approach ‘manageable complexity’. It becomes an even more useful concept for large applications or as an organisation’s system grows with inevitable upgrades and expansions.
The era of the video surveillance industry promoting the idea of piggybacking the corporate network is long gone. More recently, common practice has been to design a surveillance system to use a dedicated subnet, separate from the customer’s corporate network. This has the effect of separating the video traffic, making it difficult to establish an unauthorised connection into a corporate network.
Manufacturers need to be educating installers to design a physically separate network, or to configure a dedicated network by VLAN, and move end users away from wanting to leverage the corporate network. This means the corporate network is protected, as any IP camera is a potential network breach if it’s not running on a separate network. Then everything a user does to the system is achieved via the NVR.
IDIS devices, such as NVRs, use a proprietary embedded Linux (not an off-the-shelf version) and only authorised network modules are allowed to run. The system also will not permit any third party app to run inside the IP camera. Since IDIS leverages proprietary protocols, this makes devices very difficult to exploit. The company also uses proprietary file structures whereas some manufacturers use Windows or standard Linux, so this is an example of how IDIS is hardening resilience. Even a common network module, such as the HTTP/HTTPS server, is a proprietary implementation, which will make many known attacks useless.
Lastly, installers and integrators should be looking for industry standard SSL/TLS when communicating across a network, and need to ensure all the usual industry standards are present such as encryption of login details, IP filtering, IEEE 801.1x, TLS/SMTP where applicable.
There have been concerns in the media that manufacturers could access an end user’s system. With IDIS, if the admin account password of an NVR is lost, there is no way to re-set it, not even by IDIS engineers who designed the system. There are recovery options, but these need to be set up when the system is installed. For that reason, IDIS cannot access any of its own installed systems.
