IP surveillance is quickly becoming a commodity. As the price of high definition network cameras continues to fall, it’s easier to find room in your budget for a basic system. Physical security hardware sales are expected to increase 8.9% by 2025 according to Grand View Research, with the physical security segment market reaching $133.9 billion as of 2016.
This presents an interesting set of challenges for administrators that are charged with the task of securing devices that have well documented and glaring security vulnerabilities. Network engineers are aware of the dangers of jumping feet first into IoT. We’ve discussed it on the blog in the past, but what many may not realize is that IP surveillance cameras are open to the same types of attacks as the IoT devices that bring many security engineers to balk.
In 2017, "Devil’s Ivy" shook the physical security world. It was revealed that a simple buffer overflow attack would allow a hacker to gain root access to some cameras, giving them the ability to force the camera to run 2GB of any code they choose to load onto the camera. This can be used to simply bring down the camera, add your camera to a botnet, or even intercept and spoof the video stream of the camera. The code that made this attack possible was reused across 34 different manufacturers, and an untold number of cameras estimated in the millions. This is just one of the many exploits and vulnerabilities present in these types of devices, and these are premium cameras. When we start looking at bottom-of-the-barrel grey market cameras, the outlook becomes increasingly grim with some of the most popular manufactures being barred from sale to the US government due to security vulnerabilities and backdoors.
The rabbit hole goes deeper, as the DDoS attacks that come from these devices are sending GRE packets. This makes DNS based DDoS mitigation irrelevant when it comes to preventing these attacks. Many companies will need to entirely rethink their security measures as NGFW devices with DDoS protection might find themselves vulnerable to increasingly popular and increasingly severe attacks.
So, what can we do about this as network administrators? To start, we need to prevent our cameras and NVRs from becoming a part of the problem. Physical security and network security are two separate technologies that come together through a unified security philosophy. It all starts with proper building security and network segmentation. Small to medium surveillance systems have no reason to operate on the same hardware as the rest of your network. The most secure option is to keep your surveillance system entirely disconnected from your WAN and on its own dedicated hardware. Many NVRs even come with integrated PoE ports for this exact purpose, cameras can be connected directly to the NVR without needing any additional hardware.
This configuration is unrealistic for some customers, as sometimes the entire reason you’re looking for a surveillance system is to have remote access to live viewing and footage. In this case, make sure that your security system is on its own subnet without access to the rest of the network. Never rely on UPnP or vendor-provided utilities to enable camera access. This advice may seem simple for security-focused network administrators, but physical security integrators see network security as an afterthought at best and a hindrance at worst.
Bring Visibility to IoT Devices with ForeScout CounterACT
Beyond this, consider a tool such as ForeScout CounterACT coupled with a Garland Network TAP. CounterACT offers some campus IoT security features that simplify the implementation of IoT devices like security cameras. If ForeScout detects an IoT device like a security camera on your primary network, it will automatically provision your switch to put that device on to a separate subnet. Additionally, CounterACT will push down policies to cut the connection to devices that are sending out spam or running unauthorized programs.
Now that we’ve secured our cameras, how do we protect ourselves against a potentially looming botnet attack? We know that DNS based DDoS mitigation is useless in these attacks, so what are we to do? The solution is a dedicated appliance that will protect our network from the breadth of potential DDoS attacks possible.
The CheckPoint DDoS Protector is designed for just such a purpose. Paired with a Garland Technology Bypass TAP, we can be sure that the CheckPoint DDoS Protector will see every bit, byte, and packet that may be hurled against our network from any source. Additionally, the Bypass TAP will allow us to deploy the DDoS Protector inline while insulating our network from the failure of that device.
[Looking for more ways to protect your network? Read our whitepaper Protecting the Data: 5 Tools to Fight Against Today's Threats.]
If the inline security tool goes off-line, the TAP will bypass the tool and automatically keep the link flowing. The Bypass TAP does this by sending heartbeat packets to the inline security tool. As long as the inline security tool is on-line, the heartbeat packets will be returned to the TAP, and the link traffic will continue to flow through the inline security tool.
If the heartbeat packets are not returned to the TAP (indicating that the inline security tool has gone off-line), the TAP will automatically 'bypass' the inline security tool and keep the link traffic flowing. The TAP also removes the heartbeat packets before sending the network traffic back onto the critical link.
While the TAP is in bypass mode, it continues to send heartbeat packets out to the inline security tool so that once the tool is back on-line, it will begin returning the heartbeat packets back to the TAP indicating that the tool is ready to go back to work. The TAP will then direct the network traffic back through the inline security tool along with the heartbeat packets placing the tool back inline.
Some of you may have noticed a flaw in the logic behind this solution! You say, “What if the TAP should fail because it is also in-line? Then the link will also fail!” The TAP would now be considered a point of failure. That is a good catch – but in our blog on Bypass vs. Failsafe, I explained that if a TAP were to fail or lose power, it must provide failsafe protection to the link it is attached to. So our network TAP will go into Failsafe mode keeping the link flowing.
Single point of failure: a risk to an IT network if one part of the system brings down a larger part of the entire system.
Heartbeat packet: a soft detection technology that monitors the health of inline appliances. Read the heartbeat packet blog here.
Critical link: the connection between two or more network devices or appliances that if the connection fails then the network is disrupted.