PoE was power. This is control: CCTV Network Security Hardening Guide

TL;DR

• Three layers, one missing and you leak: 1) accounts and passwords; 2) network segmentation (dedicated camera VLAN + ACL); 3) egress control (UPnP off, source whitelist, VPN or zero-trust for remote access).
• Default credentials are a supply-chain problem: most factories ship admin/admin, admin/123456, root/pass. White-label units keep the firmware default even after the nameplate is rebranded.
• Service pruning is a subtraction exercise: keep HTTPS management plus required RTSP/TCP only; Telnet (23), FTP (21), SNMP community, UPnP and automatic port mapping should be off on almost every site.
• Segmentation is not paperwork, it is containment: one compromised camera must not reach finance or ERP hosts. Default deny on camera egress toward the corporate subnet.
• Firmware lifecycle belongs in the contract: cameras live 5-8 years, but silicon platforms go end-of-life and updates stop. Ask for a written maintenance window and a vulnerability fix SLA.
• Acceptance tests three things only: a port scan (only whitelisted ports), a credential policy check (length, complexity, lockout), and the remote path (no plaintext RTSP reaching the public internet).

1. Why cameras get hit first: asset profile and attack surface

Three intrusion paths cover most real incidents: default credentials walked straight in; UPnP or a manual port mapping exposing the management page; and a flat network where the camera sits in the same broadcast domain as finance workstations.A camera is an awkward asset - long uptime (5-8 years without a reboot), spread out across floors and plants, weak CPU that cannot run any modern protection, and low perceived value. Those four facts together make it the easiest foothold in the network. 

• Default credentials walked straight in - an attacker scans the IP range with a public wordlist, signs in, then turns the camera off or changes the cloud account.
• Public exposure of management ports - UPnP enabled on the router maps 80/443/8443/8000, then a weak password finishes the job.
• Lateral movement - camera, NVR, access control and office PCs share one flat subnet and one switch, so a taken camera becomes a pivot into the office.

2. Credentials: where roughly nine in ten entries happen

Below is the baseline that any site should be able to demonstrate: a minimum length, a real lockout, no shared admin, and a clock that logs out.The uncomfortable part of breach statistics is not cracking - it is a password still stuck on the sticker under thedevice. Unlike servers, a camera does not join a domain, cannot be centrally managed, and keeps the credentials it shipped with until someone changes them by hand. 

• Baseline pass (before wiring): change every default password while the device is still isolated on the bench - zero risk at that moment.
• Register pass: record asset ID, IP, account name and a strength mark (strong / medium / weak). The register must never carry cleartext - at handover you deliver existence plus a complexity proof, not passwords.
• Verification pass: sample 5% of units at acceptance and attempt login with the factory default; every attempt must fail.

3. Segmentation: lock the cameras in a dedicated network

A workable four-zone split keeps the video tier physically and logically separate from the people and data tier. The core rule is one sentence: the camera is a device that gets connected to, not a device that is allowed to go out and connect.The point of segmentation is not a tidy compliance report - it is limiting one compromise to a single device. If cameras, NVR, access control and office PCs can all reach each other, you effectively built one flat network. 

• "We deployed VLANs so we are safe" - not by itself. Without private VLAN or port isolation, hosts inside the same VLAN still reach each other at L2, and without L3 ACLs a VLAN is only a broadcast domain.
• "Cameras do not need the internet" - mostly true, but NTP, syslog export and firmware upgrade need egress; skip them and your logs carry no trustworthy timestamps for forensics.
• "It is convenient for office PCs to open camera live view" - this is the most common anti-pattern. Office endpoints are the most phishable machines in the building; letting them reach cameras spreads the attack surface.

4. Egress control: the right way to expose remote viewing

Four patterns get the job done with very different risk profiles. Pick by who maintains the site, not by what the vendor sales deck prefers.The request "I want to watch footage from outside the office" is legitimate; the usual implementation - add a port mapping on the router - is not. 

1. Only forward the ports you truly need, and source-limit the management face (source IP whitelist or the site fixed egress).
2. Force HTTPS with TLS 1.2 or higher; never expose the plain HTTP management port.
3. Strong passwords, non-default accounts, fail-lockout enabled - the full kit from section 2.
4. Never publish plaintext RTSP (554) to the internet: unencrypted RTSP is a public video feed for anyone who knows the address.

5. Firmware, patches and lifecycle

Cameras do not get "rebooted back to normal" like a server. They sit in the field for years, which makes firmware discipline about risk windows rather than free time.

1. Critical (remote command execution / unauthenticated stream): upgrade and verify inside 7 days.
2. Normal vulnerability: within 30 days.
3. Air-gapped sites: require offline firmware packages with SHA256 from the vendor and distribute through a local upgrade server - do not open the camera to the internet just to patch.
4. Keep a rollback copy before every upgrade, do it in a non-business window, and keep one engineer on site for 30 minutes.

Two questions to ask before you buy, not after something breaks:

• Through which year is the firmware for this model / platform maintained? - Many industrial silicon platforms go end-of-life while the device keeps selling for another three to five years, but the firmware stays exactly as shipped.
• How fast do you issue a fix for a known vulnerability, and through what channel are we notified? - You want a written commitment and a notification window, not a verbal "we will update it".

a firmware register per model - version, release date, known CVE, patch status, owner. Without it you cannot answer an auditor or an incident responder.The deliverable that makes all of this provable: 

6. Compliance and where the liability sits

The table below maps the common ones for CCTV.The same hardware is judged by different frameworks in different markets, but underneath they all ask for the same evidence: you can prove access control, identity authentication and log retention. 

7. Contract fields and how to accept the work

Security requirements written into the technical specification cost far less than remediation later. Five fields belong in the contract or the tender.

1. Accounts and passwords: factory default accounts must all be removed or strongly changed; handover includes a password strength proof, never a cleartext register.
2. Services and ports: factory-enabled Telnet / FTP / UPnP / SSID broadcast / SNMP community must be disabled before delivery, and the disabled list is part of the delivery sheet.
3. Firmware and vulnerabilities: written firmware maintenance window (suggest >= 5 years), critical fix turnaround (suggest <= 15 working days), and how offline patches are supplied.
4. Logging and audit: SYSLOG to the specified collector, retention >= 6 months, timestamps NTP-calibrated within 60 s of UTC.
5. Physical traceability: serial plate per unit, tamper alarm wired to the platform, tamper labels scannable into the asset register.

Acceptance runs three checks, and that is enough:

• Port scan - from the ops segment and from a simulated external position, scan cameras and NVRs; only whitelisted ports should answer, and management must not be reachable externally.
• Credential brute-force - attempt the factory default set against sampled devices; all attempts must fail, and weak passwords (length < 8, all digits, model-related) must be rejected.
• Remote path audit - verify whether remote viewing traverses TLS or a VPN, and capture the public-side interface once with tcpdump / Wireshark to confirm the stream cannot be decoded.

network topology with VLAN and ACL placement; port and service list with per-model on/off state; asset register with account names and strength marks but no cleartext; firmware register with CVE and patch status; and a short security brief holding the scan results, the brute-force conclusion and the public-side capture evidence.Deliverables - missing any one of these counts as unfinished work: 

8. Frequently asked questions (FAQ)

Q: I forgot the camera password and the vendor will not help - what now?

A: Try three steps in order: read the nameplate or the sticker under the device, which carries the factory default on most models (admin/admin, admin/123456, root/admin) - and if it is still there, the install crew simply never changed it. Use the vendor client search or the physical reset button (hold 7-15 s); a reset restores factory defaults, so immediately set a strong password and disable unneeded services rather than keeping the default. The clean solution is to strip the default account while the device is still offline on the bench.

Q: Can RTSP 554 and ONVIF be exposed on the public internet?

A: Not recommended. Plain RTSP is unencrypted, so anyone who connects can pull the stream - a public video source. ONVIF WS-Discovery actively broadcasts the device list. Do this instead: keep the control plane (login, auth, configuration) and the subscription plane (RTSP / ONVIF) inside the VPN or tunnel, and expose only one gateway in front of the internet that enforces identity, source limits and TLS. If a cloud platform or third-party client must connect directly, at minimum apply source IP whitelists, channel encryption and strong auth - and accept that this path will be scanned continuously.

Q: Is a fully offline (no internet) camera the most secure option?

A: On paper yes, but in practice it creates worse problems: no time sync means recordings cannot be ordered forensically, no remote patching means the vulnerability is permanent, no remote diagnostics, and logs cannot be exported. The balanced design is "no internet egress, but a management egress": allow only three destinations - NVR, NTP and the syslog collector - and deny the rest. That is close to offline in security while staying manageable.

Q: Do I really need a Layer 3 switch for VLANs, or will a normal switch do?

A: Tagging on 802.1Q works on any manageable L2 switch, so dividing networks can be done there. Inter-VLAN access control cannot - that needs L3 (routing or a Layer 3 switch) to apply ACLs. So: if you only need "segments cannot reach each other", manageable L2 plus L3 is enough; for rules like "cameras may only be reached by this NVR" you need L3. An unmanaged home switch cannot tag at all, leaving physical separation as the only option.

Q: Which clauses of GB/T 22239 actually bite for CCTV?

A: Four, in practice: secure domain boundaries - access control between the camera segment and the office (no ACL is an automatic loss); secure computing environment - identity authentication (password complexity, failure handling, session timeout), intrusion prevention (unneeded services off) and security audit with at least six months of retention; secure communication network - communication confidentiality, i.e. whether the video stream is encrypted; and management system / construction management - evidence of periodic penetration testing and annual assessment. Video systems usually sit at level two or three depending on scale.

Q: A camera got hit by ransomware - what now?

A: Do not rush to pay. Cut egress for that segment first (unplugging the cable is fastest) to stop spread. Pull unencrypted older footage from the NVR or independent storage - that decides whether the ransom has any value. Then find the earliest intrusion point: check syslog and NVR login logs for which device, which IP and what time a login succeeded. Rebuild with offline firmware packages device by device; do not pull patches from the internet. Finally, check every other device on the same VLAN running the same firmware version - that is the usual replication path. Preventionally, the egress-deny plus dedicated VLAN from section 3 is what stops ransomware from reaching finance and ERP.

Q: For multi-site operations, VPN or cloud P2P - which one?

A: It depends on IT headcount. A single plant with IT staff who can build tunnels: site-to-site VPN - secure, controllable, no dependency on a vendor cloud, but every link needs maintenance. Dozens of stores with nobody to manage IT: cloud P2P or vendor relay is the realistic answer - NAT traversal is strong and the phone app just works; the cost is handing part of the control plane to a vendor cloud, so evaluate its compliance posture and SLA. The middle path is "control plane in the cloud, data plane over P2P" - but the precondition never changes: strong accounts, services pruned, VLANs split. The cloud solves connectivity, not device hygiene.