Introduction
During the 1991 Gulf War, it is said that the use of American-made colour photocopiers by the Iraqi armed forces, to make copies of their battle plans, revealed their positions to American electronic warfare aircraft, and allowed the Americans to target the same locations. That is because the circuitry in some of the machines contained concealed transmitters that revealed their locations.
More recently, the Stuxnet worm was engineered to target industrial equipment and software; specifically Siemens SCADA systems. It turned out that the worm/rootkit combination was created to attack Government of Iran organisations involved in uranium enrichment.
The above incidents point to potential dangers contained in hardware and software imported from abroad, especially when the equipment and licenses are used in defence, homeland security, and critical infrastructure applications. These dangers have increased manifold with the quick adoption of intelligent sensors and IP devices. This brief looks at the insidious effects of root-kits and kill-switches on programmable sensors.
Rootkits, Kill-switches, and Back-doors
What are they and how do they impact the systems harboring them?
- Rootkit
A rootkit is software that enables privileged access to a computer, by subverting the OS, all the while remaining hidden from system administrators. A rootkit installs itself after gaining root-level access to the OS, either through a known vulnerability in the OS (not so widely known as to have been rectified) or through a password fraudulently obtained. Once installed, the rootkit can be used to execute programs without permission, steal confidential data, and affect the functioning of the infected system. A rootkit can target the firmware, the OS, or applications on the system.
Rootkit detection is extremely difficult, especially if it resides in the kernel, since it is in a position to affect the functioning of the software used to find it. In cases where it is detected, removal may be close to impossible and the only solution is to reinstall the OS. - Kill-switch
A kill-switch is a hidden or known feature of a software application or a hardware platform that allows the application or device to be shut down in an emergency situation, without having to go through the normal shut-down procedure. As a known feature, it is a fall-back in case of an emergency where the functioning of the application or device needs to be terminated with immediate effect, even if this results in some or extreme damage to the application (data) or device.
As a hidden feature, a kill-switch is used by the designer to render a system non-functional under certain circumstances or operating conditions. It is here that this feature has dangerous implications for homeland security. A section of video surveillance sensors may be killed by a designer of the kill-switch, prior to an alert-inducing activity by its associates. Once killed, the system cannot be revived again, without invasive repairs.
Kill-switches need to be programmed or wired at the design stage itself, so this feature is usually inserted by the manufacturer or with the knowledge of the manufacturer, so detection is impossible. If a system is suspected of harbouring a kill-switch, all the user can do is replace it with a functionally similar system. - Backdoor
A backdoor (or trapdoor) is an unknown-to-the-user access designed in silicon or in software, allowing the designer to access systems containing that piece of silicon or running that software. A backdoor is used to affect the functioning of the system in a manner that serves the purpose of the designer, even if it means working against the functional requirements of the user. Unlike a kill-switch, where the user will be aware that the system has been rendered functionally inoperative; in the case of a backdoor, the user is rarely aware of the fact that the system has been functionally compromised.
Backdoors are more commonly implemented on silicon, where it is next to impossible to detect the back-door without destroying the chip. As with a kill-switch, all a user can do is act on suspicion and replace the suspected electronics or software with a functionally similar system.
Protecting homeland security surveillance sensors against these threats is a difficult and resource-intensive task. Therefore, users need to work out a cost/benefit analysis before taking a decision on whether to protect surveillance infrastructure against the above threats.
Protection
Steps to protect surveillance infrastructure from the above threats differ, depending on whether it is software or hardware that is to be protected. Either which way, the activities are resource (person and time) heavy.
Software
Protecting against rootkits is an activity that starts at the point of deciding on the software application, for the requirement, itself.
- Â Identifying a secure OS as the platform would be the first step
- Build a database of known vulnerabilities of the OS and ensure that it is protected against these.
- Have a dedicated in-house team to research hacks, cracks, and malware; and to test the software set-up on a network-independent system.
- Scan the Internet for information on newly discovered or potentially discovered vulnerabilities, and build a database of these as well as their possible fixes
- If a rootkit is detected, ensure that it is expunged from the system, even if it requires the OS and applications to be reinstalled afresh.
Hardware
Protecting hardware is, if anything, an even more onerous task, since the user needs to be sure that the supplier of the hardware is a trusted source. Countries such as the USA have programmes such as Trusted Foundry Programme and the Trust in IC initiative to ensure that during the process of chip design and chip fabrication, no backdoors and kill-switches are inserted.
That too may not protect a user, since chip alteration can be done after the device has been manufactured. Using specialized tools and design data, a skilled technician can edit the chip’s design to insinuate a back-door or a kill-switch.
Apart from carrying out intensive and comprehensive destructive testing on random samples of key components of the hardware, to check if the components do indeed do nothing more than specified, there is little else a user can do to protect hardware infrastructure.
Conclusion
It is quite obvious, from the above write-up that it is neither viable nor advisable to protect all homeland security surveillance infrastructures. Critical infrastructure and critical surveillance requirements will need a higher level of preparedness than run-of-the-mill surveillance, and it is time security planners started laying down processes to address potential threats engendered by the surveillance infrastructure itself.
Mistral’s IP video surveillance camera is Mistral-designed device.
