Barriers to the use of intrusion detection systems in safety-critical applications

Intrusion detection systems (IDS) provide valuable tools to monitor for, and militate against, the impact of cyber-attacks. However, this paper identifies a range of theoretical and practical concerns when these software systems are integrated into safety-critical applications. Whitelist approaches enumerate the processes that can legitimately exploit system resources. Any other access requests are interpreted to indicate the presence of malware. Whitelist approaches cannot easily be integrated into safety-related systems where the use of legacy applications and Intellectual Property (IP) barriers associated with the extensive use of sub-contracting make it different to enumerate the resource requirements for all valid processes. These concerns can lead to a high number of false positives. In contrast, blacklist intrusion detection systems characterize the behavior of known malware. In order to be effective, blacklist IDS must be updated at regular intervals as new forms of attack are identified. This raises enormous concerns in safety-critical environments where extensive validation and verification requirements ensure that software updates must be rigorously tested. In other words, there is a concern that the IDS update might itself introduce bugs into a safety-related system. Isolation between an IDS and a safety related application minimizes this threat. For instance, information diodes limit interference by ensuring that an IDS is restricted to read-only access on a safety related network. Further problems arise in determining what to do when an IDS identifies a possible attack, given that false positives can increase risks to the public during an emergency shutdown.