This is the 16th article in the “Real Words or Buzzwords?” series about how real words become empty words and stifle technology progress, also published on SecurityInfoWatch.com.
By Ray Bernard, PSP, CHS-III
The main problem with “IP-based” and similar terms is the industry’s initial misunderstanding of them, which led to products and systems that didn’t really live up to their labels.
About 15 years ago many physical security industry companies began jumping on the “IP Bandwagon”. Before long, there were three terms that appeared in materials and discussions about security industry products and systems: IP-based, IP-capable and IP-enabled. These terms are still used today, although “IOT” has become the growing replacement for “IP”, as in “IOT device” replacing “IP device” as a popular label. The next Real Words or Buzzwords? article will address the ramifications of that change.
For this article, we want to examine what the terms IP-based, IP-capable and IP-enabled have meant in the security industry, to understand how the security industry first misinterpreted those terms, and to finally determine what the terms really should mean so that we can start using them correctly in the context of 21st century networking. The main problem with “IP-based” and similar terms is the industry’s initial misunderstanding of them, which led to products and systems that didn’t really live up to their labels.
Internet Protocol (IP)
Internet Protocol is a network communications protocol that enables individual network devices to communicate to specific other network devices by using device IP addresses and a common data packet structure. IP addresses and IP data packets (formally called datagrams) are the two key networking elements defined by the Internet Protocol. That’s it.
However, it takes more than devices with IP addresses and correctly formatted data packets for communication to occur. There must be some standard way of handling data packet transmission, including error correction, transmission timing requirements, and so on.
Transmission Control Protocol (TCP)
The Transmission Control Protocol was developed to provide reliable, ordered, and error-checked delivery of a stream of data between computers and devices that communicate using the Internet Protocol. The World Wide Web, email and file transfer applications, for example, rely on TCP. Because the TCP and IP protocols are used together for local area networks (LANS) and the Internet, networks were initially referred to as “TCP/IP networks”, and the label was later shortened to “IP networks”. Thus “we speak IP” was one of several similar marketing phrases that arose within the physical security industry. These were used to assert that “Our company is IT-savvy, we understand TCP/IP networking, and our new products are IP-based.” The trouble was that—with the exception of the few companies which had strong roots in the IT world—these assertions were not really true.
The Internet Protocol Suite
In the IT world, the term “suite” is used to denote a collection of applications or communication protocols that work together. The two main protocols of the Internet Protocol Suite are TCP (Transmission Control Protocol) and IP (Internet Protocol).
However, networking and the Internet rely on a suite of at least 60 protocols, in addition to TCP and IP, to support communications for networked applications, and to support the management of network and Internet infrastructure. Furthermore, there are dozens of standards involved in securing network communications. In the IT world, due to the primary role played by TCP and IP, and because in the IT domain the need for the full suite of Internet protocols is well understood, the full Internet Protocol Suite is commonly referred to as “TCP/IP”, and the term “IP network” means a network whose infrastructure and its connected devices appropriately support the full Internet Protocol Suite.
This is a very different understanding than the one that existed for nearly 15 years after the security industry began placing security systems onto facility LANs and enterprise networks.
Many “IP-Based” Products Aren’t Fully IP-Based
As mentioned in the Real Words or Buzzwords? article, “State of the Art”, the industry was putting devices onto IP networks starting in the late 1990’s that didn’t support Simple Network Management Protocol (SNMP), and the industry didn’t develop a standard for a physical security device MIB (a management information base data file defined by SNMP) until 2015. As late as 2008, several brands of deployed IP cameras would go offline if the IT department were to run a basic Nmap scan of the network (a common practice), to get an up-to-date diagram and detailed information listing for all the devices on a network.
It is still easy to find security system deployments today where the cameras, IP card readers, access control and intrusion panels, servers and workstations don’t have their time clocks synchronized using Network Time Protocol (NTP). NTP is used to synchronize the clocks of networked computers and devices to within a few milliseconds of Coordinated Universal Time (UTC), which is the primary time standard by which the world regulates clocks and time. The full use of NTP, accounting for local time zone variations, is one requirement for obtaining forensic quality evidence from electronic physical security systems.
Many IP cameras still do not include an option for local time zone identification in their video time display overlay. When video camera time overlay capabilities are used, many video management systems aren’t configured to ensure that the date and time on the connected cameras is correctly set, even though the ONVIF protocol (for example) supports time verification and setting the time per an NTP time source.
In manufacturing environments—where video cameras monitor manufacturing processes at 30 to 60 frames per second—the Precision Time Protocol (PTP) should be used to synchronize video server and camera clocks to the same time source that the manufacturing systems use. The use of PTP is also appropriate for Indoor Positioning Systems that track, for example, packages on high-speed conveyor belts or warehouse vehicles moving throughout the facility.
Many products don’t support SNMP version 3, and many of those who do still default to an earlier (i.e. non-secure) version. Many systems don’t support end-to-end system encryption of both data in transit and data at rest. Many products and systems default to non-secure modes for ease of installation and configuration, yet lack a single switch or command that places the product or system into a highly secure mode. Current day IT practice is to provide secure and well-documented IP networks and systems.
It is not just protocols that must be considered, but also network architecture. I have come across many corporate enterprise networks whose designs included redundant network paths, but whose video system deployments did not take them into account, and so the network switches on the redundant paths were not configured to support security video. Thus, needless video system failures occurred while the IT systems remained fully functional.
Although many IP cameras support DiffServ and/or DSCP (two Quality of Service protocols), I have found congested networks where QoS capabilities were not enabled, in spite of the customers’ having them enabled for their IT systems. Cisco’s valuable IP Video Surveillance Design Guides (available free online) go into detail about these and many other network considerations for security video.
These are just a few examples of the shortcomings to be found in today’s security system deployments, without taking cloud-based applications and cybersecurity into consideration.
What IP-Based Means Today
The following four definitions should be applied to the design, deployment and upkeep of electronic physical security systems. The standard of practice for product engineering today is agile development, which typically means semi-monthly or monthly releases of product software, and monthly or quarterly releases of product firmware, with product security updates released as soon as they are developed and fully tested.
IP-Based. Refers to designs and features sets of networkable products and systems that are optimized for performance, robustness, security, manageability and interoperability using relevant current-day network protocols, and IT standards and practices, and are easily upgradable for the inevitable revisions to protocols and standards and to correct security vulnerabilities.
IP-Capable. Should be used to refer to products and systems that were originally designed for analog or non-IP based communications, but which have been updated to also support IP-network-based communications, with full support for DHCP, HTTPS, NTP, SNMP, IPSec or other secure network communications, plus appropriate support for other relevant Internet protocols such as LDAP, RTSP, SIP, and so on, and are upgradable for revisions to protocols and standards.
IP-Enabled. Similar to IP-Capable, should refer to simple products that were originally designed for non-IP based communications, but which have been updated to provide secure IP-network-based communications with a single managing device, including full support for DHCP, HTTPS, NTP, SNMP, and IPSec or other secure network communications, and are upgradable for revisions to supported protocols and standards.
IP-Connectable. Should refer to devices that can connect via an Ethernet cable or Ethernet network using media converter or serial tunneling technology, but whose communications capabilities were designed for a different type of network, or for direct cable connectivity. For example, there are still security industry control boards that were originally designed for RS-232 or RS-422/485 serial communications. Their manufacturers embedded chipsets to their circuit boards to enable the devices to communication over an Ethernet network. Lantronix is one source for these chipsets and other reliable communications products. This approach is intended to be used for connecting two or more serial- communications-capable devices over an Ethernet network. Thus, the devices still retain the restrictions of their original communications method. So, for example, cannot transmit or receive data at the full speed of the Ethernet network they are connected to, but are restricted to receiving data at slower serial port communication data rates. Thus, IP-Connectable devices should not be called IP-Enabled or IP-Capable as these two terms imply more network and communications capability than the devices have.
The Internet of Things
The industry has declared that most electronic security system IP-based devices are now Internet of Things devices, in spite of the fact that they were not designed to act like proper IoT devices. Thus, the next Real Words or Buzzwords? article will answer address these terms: “IoT-capable”, “IoT-ready”, and “IoT device”.
Ray Bernard, PSP CHS-III, is the principal consultant for Ray Bernard Consulting Services (RBCS), a firm that provides security consulting services for public and private facilities (www.go-rbcs.com). He is the author of the Elsevier book Security Technology Convergence Insights available on Amazon. Mr. Bernard is a Subject Matter Expert Faculty Member of the Security Executive Council (SEC) and an active member of the ASIS International member councils for Physical Security and IT Security.