ICS/SCADA Hrozby

Hardware-based: The proprietary nature and lack of upgrade support of the hardware exposes systems to increased security risks. Executing hardware upgrades requires total replacement of systems from the same vendor, which is costly and often postponed or not executed at all.

Weak authentication/encryption: Hardware-based systems were not designed to support advanced encryption standards or complex authentication. Many hardware-based systems do not even have an authentication mechanism or, if they do, it consists of just a few numbers typed into a keypad or easily decipherable passcodes. Encryption in hardware systems is rarely strong due to the processing power that is required to support encryption.

Unsupported software/firmware: Due to the use of closed architectures and software, any modifications to the ICS requires using the vendor and may be limited if the software/firmware is no longer supported by the vendor.

Slow response time to patching/updating: Vendors often provide customers with approved/tested patches or updates to address identified vulnerabilities months after the security risk is identified.

Poor physical security: Many ICSs have a small form factor design, meaning that they are physically small in size and have very little computing power. This means that they can be easily stolen and then reconfigured. In addition, with the distributed nature of some ICSs, physical security that prevents theft can prove to be difficult to ensure without extensive costs.

Wireless Connectivity: Many ICS products are located in remote locations where network connectivity is only possible through wireless and/or cellular networks. These ICSs come preconfigured with standard configurations for encryption such as the encryption key and network/cellular passwords, which introduce a risk to the infrastructure if compromised.

No Antivirus or malware protection: The nature of ICS requires real-time, low-latency operating systems/environment. This requirement does not allow for traditional antiviruses or malware protection commonly seen in standard IT systems. The inability to add this protection to an ICS leaves systems prone to virus and/or malware infections, which can lead to loss of information, degradation in service and physical destruction.

Lack of Configuration Management: ICS programmers write control logic for their systems, which is a workflow for how a system is supposed to work. Many times control logic program files are not version controlled and configuration files are not monitored against an approved baseline to ensure integrity. This is a common problem with configurations and is an easy way for an attacker to add backdoors or malicious configurations onto systems without being detected.

To mitigate the increased security vulnerabilities of ICS, a layered security concept (referred to as defense in depth) should be implemented as part of ICS procurement, placing the security burden on vendors, to the greatest extent possible. During the design and acquisition processes, engineering and procurement organizations must consider critical security concepts and controls when making key implementation decisions. For example, contracts should require vendors to provide systems that are FIPS 140-2 compliant -- both for data at rest and data in transit encryption. Furthermore, vendors should be required to employ patch cycles that are frequent and agile enough to address security vulnerabilities. Vendor systems should employ an open architecture allowing the user and development communities to provide solutions to security concerns. Finally, vendors should offer an ICS solution that has some physical security requirements built into them to support the distributed nature of ICS.

After procurement occurs, leveraging standard architecture models (such as the Purdue Model) allows integrators and system developers to separate/segregate networks based on security requirements. Unidirectional gateways, firewalls, VPNs and many other networking hardware/software employed in the systems provide the required security and network segregation the Purdue Model recommends. Although ICSs are not able to run traditional antivirus and/or anti-malware software, an alternative that should be considered is whitelisting applications that block the execution of code that is not whitelisted at the kernel level, making it much more difficult for an attacker to execute random code to compromise systems.

Beyond the physical and technical controls employed, it is critical for organizations to implement and maintain a comprehensive suite of processes and procedures that support the regular maintenance and management of this equipment. This includes, but is not limited to regular maintenance and inspection cycles, incident and emergency response procedures, change control and configuration management processes and component life cycle management to include management of sunset products, management of inventory sparing and identification and testing of suitable substitutes.

The most critical action any organization can take to improve security is performing continuous monitoring of their system’s security posture. Continuous monitoring may include vulnerability assessments/scans, review of approved configuration baselines, penetration testing and table-top reviews of policies and procedures to ensure that they are up to date and that all personnel are trained on the company’s security policies and procedures. This holistic life cycle view of the system supports a risk-based management approach that seeks to identify risks to ICS security before they are realized and affords organizations the opportunity to address those risks through mitigation or avoidance before a situation becomes dire or urgent.