Article
How A Prison Had Its CCTV Hacked | Lifehacker Australia
My Comments
In this article, it was found that a prison’s video-surveillance system was compromised. The security team checked the network but found that it wasn’t the institution’s main back-office network that was compromised but a Windows Server 2003 server that was affected. This box had to be kept at a particular operating environment so it could work properly with particular surveillance cameras.
The reality with “business-durable” hardware and systems
Here, the problem was focusing on an issue with “business-durable” hardware like the video-surveillance cameras, point-of-sale receipt printers and similar hardware that is expected to have a very long lifespan, usually in the order of five to ten years. But computer software works to a different reality where it evolves every year. In most cases, it includes the frequent delivery of software patches to improve performance, remedy security problems or keep the system compliant to new operating requirements.
Newer software environments and unsupported hardware
The main problem that can occur is that if a computer is running a newer operating environment, some peripherals will work on lesser functionality or won’t work at all. It can come about very easily if a manufacturer has declared “end of life” on the device and won’t update the firmware or driver set for it. This also applies if a manufacturer has abandoned their product base in one or more of their markets and leaves their customers high and dry.
Requirement to “freeze” software environments
Then those sites that are dependent on these devices will end up running servers and other computer equipment that are frozen with a particular operating environment in order to assure the compatibility and stability for the system. This can then compromise the security of the system because the equipment cannot run newly-patched software that answers the latest threats. Similarly, the system cannot perform at its best or support the installation of new hardware due to the use of “old code”.
In some cases, this could allow contractors to deploy the chosen updates using removable media which can be a security risk in itself.
Design and lifecycle issues
Use standards as much as possible
One way to tackle this issue is to support standard hardware-software interfaces through the device’s and software’s lifecycle. Examples of these include UPnP Device Control Protocols, USB Device Classes, Bluetooth Profiles and the like. It also includes industry-specific standards like ONVIF for video-surveillance, DLNA for audio-video reproduction
If a standard was just ratified through the device’s lifespan, I would suggest that it be implemented. Similarly, the operating environment and application software would also have to support the core functionality such as through device-class drivers.
Provide a field-updatable software ecosystem
Similarly, a device would have to be designed to support field-updatable software and any software-update program would have to cover the expected lifespan of these devices. If a manufacturer wanted to declare “end of life” on a device, they could make sure that the last major update is one that enshrines all industry-specific standards and device classes, then encompass the device in a “software roll-up” program that covers compliance, safety and security issues only.
As well, a “last driver update” could then be sent to operating-system vendors like Microsoft so that the device can work with newer iterations of the operating systems that they release. This is more so if the operating-system vendor is responsible for curating driver sets and other software for their customers.
The device firmware has to work in such a way to permit newer software to run on servers and workstations without impairing the device’s functionality.
As well, the field-updating infrastructure should be able to work in a similar way to how regular and mobile computer setups are updated in most cases. This is where the software is sourced from the developers or manufacturers via the Internet, whether this involves a staging server or not. This should also include secure verification of the software such as code-signing and server verification where applicable.
Conclusion
What this hacking situation revealed is that manufacturers and software designers need to look seriously at the “business-durable” product classes and pay better attention to having them work to current expectations. This then allows us to keep computer systems associated with them up to date and to current secure expectations.
