The bad guys aren’t supposed to be able to hack a video surveillance system, period.
Recent headlines about a casino scam in Melbourne brought the consequences of an insecure security system front and center as scammers allegedly walked off with $32 million after using the casino’s surveillance system to cheat at cards.
While we may never know the technical specifics of this case (and we probably shouldn’t), I would like to make a few design and operational suggestions that can significantly reduce the likelihood of this happening in your back yard.
Technically, we generally set up two separate networks for IP-based systems: a camera network and a workstation network. We like these to be separate networks rather than separate VLAN segments on the same network, to minimize the risk of a hacker circumventing the network switch.
All servers (NVRs) have two network cards and talk to both networks, but the servers and the cameras are the only equipment on the camera LAN. Any outside communication to the security system is done through the workstation LAN. This makes network security easier, as all camera access has to be done through the video management software, which can be as robust as you choose.
Limited access
We also like to limit outside access to proprietary clients rather than to a web-based interface, wherever possible. This adds an extra layer of security beyond the login and password, as your hacker would need the specific software to access your cameras, not just a browser.
This won’t help in the case of a targeted hack, but it will help keep out the casual “joyrider” which estimates say is responsible for the majority of intrusions.
If full-time remote access is not required, you can combine a technical layer with an operational layer. In gaming systems we have designed, there is occasionally a need for remote access to the system by the installing integrator for troubleshooting, upgrades, and maintenance.
In those cases, you can make the Internet link patchable, with a short RJ45-to-RJ45 patch cable. It is ordinarily left disconnected, and a call to the command center is required to initiate access.
Once credential information is exchanged, the cable is connected, the work is done, another call is made, and the link is broken. This limits the window of opportunity for hacking and provides a physical record of who accessed the system as well as when.
Threats to system reliability
The need to properly set up passwords, permissions, and the proper levels of security goes without saying — there are simply too many times where the software and hardware security features don’t even need to be hacked, as they were never set up properly. This pays off in greater system reliability as well, in an unexpected way.
We have found that the greatest threat to system reliability isn’t always from the outside, it’s from the late-shift security guard manning the command center who fancies himself an expert on computers. With eight hours of quiet time and no one looking over their shoulders, we’ve seen complex system servers turned into bricks, as settings were changed and recording came to a grinding halt.
Don’t ignore the social engineering aspect of these systems as well.
I was recently performing a system evaluation for a new client and wanted to look into the server settings. Knowing the integrator that had installed the system used the same password on all its projects, I walked up to the server control keyboard and monitor, and entered the password. Like magic, I was in, looking at the configuration settings, and feeling pretty proud of myself for remembering that login and password combination.
Until I looked down at the keyboard, that is. On the wrist rest, was a post-it note with seven layers of scotch tape protecting the writing on that piece of paper — which, of course, was the login and password information for the system administrator.
Click here to read full article on IFSEC Global
