Who changed the device configuration? Change control
in technical security systems

In technical security systems, the mere fact that a device is operational does not mean it is functioning according to requirements. A camera may be transmitting video and the VMS platform may remain accessible, even if permissions, communication parameters, or the configuration of one of the components have been altered.

For organizations managing complex infrastructure, three issues are critical: knowing the current state of the environment, controlling the changes being made, and being able to assess their impact on other system elements.

Incidents highlight the importance of device access

In November 2023, the U.S. agency CISA issued a warning regarding attacks on Unitronics industrial controllers, which are used in sectors such as water supply. The identified issues included devices accessible from the Internet and improperly secured passwords.

In January 2024, a cyberattack in Muleshoe, Texas led to a water tank overflow in the municipal water system.

These events involved industrial controllers. However, they demonstrate that access to a technical device can enable interference with the process it controls.

In technical security systems, it is also essential to know what changes have been made and who is responsible for them. This also applies to service accounts, remote access, and integrations between individual system components.

Three areas worth organizing

1. Up-to-date device inventory and dependencies

A list of devices is just the beginning. To assess the impact of a change on security, you need to know what role a given component plays, what it communicates with, and who is responsible for its maintenance.

In practice, it is worth keeping a record of at least:

• device identifier, location, and function in the system;
• manufacturer, model, and software or firmware version;
• connections to other components, e.g., a camera, VMS platform, server, or access control system;
• the technical owner and the entity responsible for maintenance

Such records make it easier to determine which elements need to be verified after replacing a device, performing an update, or changing an integration.

CISA guidelines regarding OT asset inventory emphasize the importance of documenting assets, their dependencies, and responsibility for their maintenance. A list of devices alone, without information about connections, may not be sufficient to assess the impact of a change.

2. Configuration change control

Replacing a camera, updating firmware, changing permissions, or modifying a connection to a VMS are typical operational tasks. However, each of these can affect other elements of the environment.

Therefore, it is worth implementing a simple, documented change management process that includes:

1. Change registration - what is to be changed, for what purpose, and by whom.

2. Impact assessment - which devices, integrations, and functions may be affected by the change.

3. Post-work verification - whether the device is working correctly and whether other components maintain their expected functions.

4. Documentation update - so that it reflects the actual configuration after the work is completed.

The scope of verification should depend on the type and significance of the change. In critical environments, procedures should be adapted to operational requirements so that the tests themselves do not disrupt infrastructure operations.

3. Administrative and service access

Service accounts and remote access are often necessary for system maintenance. However, they require control, especially when different teams, integrators, and vendors work with the devices.

It is worth periodically checking:

• whether active accounts have assigned owners;
• whether permissions correspond to the users' current responsibilities;
• whether remote access is limited to justified needs;
• whether it is possible to determine who used administrative access and when;
• whether accounts and access granted for maintenance work are properly handled once it is completed.

In this area, access policy is key, as is the ability to verify and enforce it in practice.

VMS: why is checking the video feed not enough?

In a video surveillance environment, a clear image at the operator's station only confirms a fraction of the system's functionality.

After replacing a camera or changing a configuration, it is also worth verifying whether the device is communicating with the correct VMS platformwhether the required permissions have been maintained, whether the expected features are available, and whether the change has affected other integrations.

In complex installations, it is also important to determine which components depend on a given device. This allows you to plan the scope of post-change testing rather than limiting the acceptance of work to checking a single function.

This is particularly important where technical security systems are part of a larger infrastructure and their operation depends on the cooperation of multiple devices and platforms.

Where to start?

A good first step is to select a few key devices and check whether you can determine their current configuration, change history, maintenance responsibility, and dependencies on other components.

Such a review helps identify gaps in documentation and processes, and then set priorities for further action. Methods for gathering information should be tailored to the specific environment—in OT systems, in particular, some forms of active scanning may carry the risk of disrupting device operation.

TSS Security Checklist

We have prepared a practical checklist covering six areas: device inventory, change management, access and permissions, VMS and integrations, updates and vulnerabilities, and responsibility and incident response.

This material can be used to structure internal discussions, conduct an initial review of documentation, and identify areas requiring further verification.

[Download the TSS Security Checklist (PDF)]

^{The checklist is for informational and auxiliary purposes only. It does not constitute an audit or a certification of the system's security level.}

Cybersecurity of technical systems - squareTec projects

The cybersecurity of technical security systems is also an area of research and development at squareTec.
As part of the PERUN project, we are developing SENTRIGRADE—an Intelligent Cybersecurity Platform for Technical Security Systems.

‍

If you are responsible for facility security, infrastructure maintenance, or SBT systems and would like to discuss the challenges of their integration and cybersecurity, please contact the squareTec team.

‍

squareTec - systems integration and cybersecurity.