Make Your Metadata Cybersecure
- By Wayne Dorris
- May 14, 2025
We all know that physical security devices capture a massive amount of information about the environment in which they’re deployed. When categorized and searched efficiently, that data transforms into actionable intelligence to better protect the organization. That is where metadata comes into play.
Metadata is often generated in conjunction with a digital file – be it a video image, a sensor reading, or a sound wave – to describe the file and its contents.
For example, a digital image file may include metadata like the date and time the image was captured, its location, as well as the camera ID and settings used. The metadata can also include details such as the type of object (vehicle, person, animal, etc.), its size, how fast it is moving, even the direction of its movement. In essence, the metadata provides a table of contents for the data to simplify the process of understanding, sorting, and locating the data it represents.
Business Intelligence
With metadata multiple stakeholders can extract different business intelligence from the same data source. For example, a security camera can read license plates to bar unauthorized vehicles from entering a restricted parking facility. It can also count cars, compare that number to garage capacity, and automatically trigger electric signage directing vehicles to an overflow parking lot.
It might be a security camera that watches a fire exit to prevent illegal usage can also alert on detecting a blocked exit, enabling the organization to avoid fire code violations and costly fines. Or security cameras observing for theft at a construction site can also be used to detect whether construction workers are wearing their personal protection equipment as OSHA requires.
It is the metadata that makes it possible for security camera data to contribute to operational efficiency and inform pivotal business decisions. For instance, cameras could confirm QA/QC activity on a production line to help reduce costly waste or frequent remakes. Or the data they collect could help the company find events affecting workflow and operation uptime, which in an industry like automotive or circuit board manufacturing could save millions of dollars in lost production time and help management figure out ways to increase output.
While this might seem like an ideal synergy – using the same device to channel critical insights to multiple stakeholders – it raises significant concerns about the safety and integrity of data flowing between systems.
Becoming a Target for Infiltrating Critical Systems
Once security cameras primarily designed for physical security tasks start streaming data and metadata to enterprise operational and business systems, it increases their visibility. Instead of being largely ignored by hackers, they suddenly become high-value targets that can be used to infiltrate and bring down vital production and business operations.
In the past, physical security solutions operated on their own independent networks. Or IT sequestered the physical security system in a separate zone on the network, isolating it from any critical business and production functions. These decisions were made because IT did not trust that the cybersecurity measures on those devices were up to IT standards.
What IT Expects from Devices on its Network
For many physical security system manufacturers, software developers and users, IT-level cybersecurity is a new ball game. To play in IT’s sandbox, physical security devices will need things like:
- Multilayer encryption
- Certificate protocols
- Zero-trust architecture
- Automated onboarding and provisioning
- Active Directory and Single sign-on
- Lifecycle management
These are not new security protocols. They have been standard requirements in IT systems
for more than a decade. But many are new to physical security devices.
Understanding These Security Protocols
IT security protocols serve two purposes: protecting the integrity of systems and data and making it easier to manage the devices on the network.
Multilayer encryption. While most physical security devices can encrypt data, IT security protocols take encryption to the next level. Employing multiple encryption layers and multiple encryption keys makes it more difficult for malicious attackers to gain access to the data stream. For example, MACsec encryption might be used at layer two for services like DHCP, NTP and ARP while HTTPS might be used at layer seven for API calls and WebGUI.
Certificate management. Many security devices employ certificates, digital documents that verify a device’s identity on the network and mechanisms for encryption used to transmit its data. However most physical security devices don’t support certificate management protocols like EST (Enrollment over Secure Transport) or SCEP (Simple Certificate Enrollment Protocol). These protocols automate the process of installing and replacing device certificates. Since certificates are crucial for encryption and authentication, it is unlikely that IT would approve devices that require manual certificate management.
Zero-trust architecture. IT relies on zero-trust architecture to minimize the radius of damage should a breach occur. This entails micro-segmenting sensitive resources, using end-to-end encryption, continuously monitoring user and device behavior for anomalies, and implementing robust incident response and recovery mechanisms. To support that goal, IT needs to be able to verify the authenticity of physical security devices before authorizing their access to the network.
In addition to protecting network access, zero-trust architecture enables IT to automate device enrollment, which, depending on the number of security devices being introduced to the network, can be a critical time saver.
That is why IT wants security devices that can be onboarded and provisioned automatically through secure network protocols. For instance, devices that use device IDs or 802.1 AR can be loaded onto the network automatically, right out of the box. Once installed, the policy engine server on the network checks the device’s ID and associated policies like which ports to open, and so forth.
So, the IT administrator doesn’t have to touch the device or assign it an IP address or a VLAN. To simplify things further while on a provisional VLAN device, IT can harden the security device with management software.
Active directory and single sign-on. In physical security systems, administrators tend to manage user privileges in local accounts. But in an enterprise environment, IT security protocols require that network devices be managed more securely through a centralized user rights management service like Active Directory.
To operate in this global enterprise domain, physical security devices would need to support protocols like Oauth 2.0, an IT industry standard for authorization. This would allow the physical security device to be managed more efficiently, like how servers and other IoT devices are managed on the IT network.
For instance, with Active Directory, HR could delete a resigning security officer from the Active Directory, which would automatically revoke their access privileges for all devices across the entire network at once.
Working with Active Directory also allows security devices to support Single sign-on, an authentication service that allows users to log in once to access multiple services without re-entering their user ID and password. This also allows IT to activate more secure authentication features like 2FA, or MFA on these devices, adding another layer of network protection.
Lifecycle management. Because cybersecurity risks exist at every stage of a device’s lifecycle, IT needs to be able to manage the security of every device on the network from the time it is onboarded until it is decommissioned and removed. IT will be looking for security devices that support features like secure boot, which ensures that the device is free of unauthorized software modifications prior to connecting to the network.
They will also want to be able to batch process security tasks like security patches, bug fixes, and upgrades to device operating systems. In addition, IT will want devices that allow them to easily manage device credentials, deploy certificates, disable unused services, and verify removal of outdated devices no longer supported by their manufacturers, which, unless detached, could become potential attack vectors.
Can these security protocols be retrofitted to legacy physical security devices? In most cases, the answer is no. One might be able to retrofit certificate management like EST or SCAP, but not zero-trust features. Things like a device’s digital identities need to be baked into the product at the start for it to be trusted. If security device manufacturers plan to follow these more stringent requirements, they’ll need to revamp their production process.
Investing in Cross-breach Prevention
As more stakeholders avail themselves of physical security metadata for business intelligence and operational efficiency, opportunities increase for organizations to identify ways to improve their bottom line. But using that data stream also increases the visibility of physical security devices, making them tempting targets for attackers to exploit.
Without IT-level security protocols on these devices, the potential for a breach into critical IT systems can escalate. On the other hand, having these protocols in place not only helps prevent system corruption and operation disruption, but it also assures the integrity and authenticity of the data being shared.
This article originally appeared in the May / June 2025 issue of Security Today.