One of the primary security issues that arise in these implementation scenarios stems from the fact that embedded devices often lack local or remote logging capabilities. As a result, they cannot adequately log relevant security and compliance data. Additionally, interactive remote access can be cumbersome, hard to achieve or only available in an insecure manner.
To address the lack of visibility largely inherent in these devices, organizations should place network sensors logically near the devices to detect events which would normally be present in event logs. Network Intrusion Detection Systems and network flow tools are two such examples. Additionally, organizations should consider protocol-aware gateways or firewalls to restrict access and add a layer of security, since many industrial protocols lack authentication and security features.
2. Not So Automatic “Automation” – Whether or not they have the Critical Infrastructure designation, ICS operators of all kinds face growing internal and external (regulatory) requirements to produce ever-increasing amounts of operational data. It is a growing operational and administrative burden, and automation systems operators must find an efficient and secure way to deal with it. Since old habits – and cautions – die hard, many asset owners are averse to fully automating their data collection processes.
This reluctance to fully automate data collection often leads operators to conduct partial automation efforts. Examples include scripts being run manually on each individual host, or scripts that can run remotely but have to be initiated manually. These half-measures are not thorough and are often incomplete.
Operators do have other options for addressing this challenge. There are technologies and solutions available on the market today that enable operators to automate all of their data collections processes safely, securely and effectively. By embracing a fully automated approach to data collection, operators can safely meet their data collection and reporting requirements, while also alleviating many hours of manual work and human error.
It should be noted that automating data collection is not the same as “network scanning.” Automated data collection utilizes built-in, administrative capabilities in the cyber assets and can be performed in a controlled manner, which utilizes very little overhead on the cyber assets. “Network scanning” is associated with network-based port scanning, which when not done carefully, can affect cyber asset availability in some cases.
3. Dirty Data – Often times, raw output from tools used to collect security and compliance data is all-encompassing and complete. That’s the good news. The bad news is that it usually includes data that requires analysis by the asset owner in order to make determinations of security or compliance state. When raw output is treated as analyzed output, asset owners get an inaccurate picture of the security and compliance state of their assets.
For example, in the upcoming NERC CIP-010-5, asset owners are required to create a baseline of each cyber asset, which includes several categories of information, one of which is “logical accessible network ports.” If an asset owner utilizes raw “netstat” output as a final source of data for compliance, there will potentially be many additional records of data that do not apply, such as records for local host-only services, which are not available as “logical accessible network ports.”
4. Inability to Detect Anomalous Behavior – Zero-day attacks can be devastating to automation systems. They are exploit system vulnerabilities that are unknown at the time of the attack, so there is no patch or fix at the ready, and great damage can often result.