MAR-APR 2017

Issue link:

Contents of this Issue


Page 35 of 53

SPECIAL SECTION: CYBERSECURITY (basic and RE) per line, as in table 1, we de- cided to have one line per SR and list the in- creasing RE on the various columns. Table 2 illustrates the same FR5 evaluation using this mode of presentation. Eventually, a more synthesized view was used without the RE text in order to present the overall picture for all FRs, which would span several pages otherwise. The overall estimated SLs are regrouped in table 3. The results depicted in table 3 are rather bad. Furthermore, half of the requirements could not be evaluated, and, therefore, this view is probably optimistic. On the right side, the estimated SL-As are listed for the seven FRs. We can see that the SL-As are zero except for: l FR5 (restricted data flow): mainly due to the IT-IACS firewall and strict flow control. To comply with this require - ment means that traffic between zones on the OT network should be filtered. The Ukrainian attack exam - ple demonstrates that this require- ment could be reviewed in future up- dates of the standard: Complying with SR 5.2 does not require one to define zones. As in the Ukrainian case, all OT systems could interact with each other. Note that recommendations about zone definitions are available in ISA/IEC 62443-3-2 that should be used be - fore applying ISA/IEC 62443-3-3. The requirement about traffic fil- tering between zones is set for SL=1. The return on investment is questionable, as the cost and risk of traffic filtering are high, and the effectiveness is questionable, as demonstrated by the Ukrainian case. It may make more sense to require detection as soon as SL- T=1 is targeted, and require active filtering/preventing for higher SLs. l FR6 (timely response to events): The very existence of detailed forensic in- formation is the result of minimal log- ging being in place. Table 4 shows a detailed analysis for some of the most significant SRs. Takeaways At first, looking at the reports about the various Ukrainian operator security con- trols, it looked like they had paid significant attention to cybersecurity issues. Indeed: l nonobvious passwords were used l a firewall with strict data flow restric- tion was in place l significant logging was performed But, as demonstrated in the SL-A eval- uation, most FR security levels were null, because at least one of the SRs was not addressed at all. There is no point in set- ting up advanced security controls when some basic ones are missing. The weak- est link drives the overall security effec- tiveness down. The fact that advanced security controls are useless if other basic security controls are missing is best illus- trated by the configuration of the firewall with a single SSH link requiring a nonob- vious password authentication. This is typically a painful operational constraint, as allowing direct remote desktop pro- tocol (RDP) access for several systems, or virtual network connections (VNCs), would have been easier to use. Unfortu- nately, these additional constraints did not lead to increased security, because: l The lack of IT network supervision did allow extensive network scans, vulner- ability searches, and discovery of the allowed SSH link. l The lack of strong authentication (two- factor) or local (OT) approval of remote connections made it possible to fre- quently connect from the IT to the OT network without detection over several months. l The lack of OT network intrusion detec- tion allowed extensive OT network scans, vulnerability detection, and mobile code (malware, exploits) transfer restrictions. When deploying security controls, it is essential to apply requirements in a consistent way across all aspects of security: detection, prevention, and re - action. It is best to use a well-designed standard such as IEC 62443-3-3. Do not aim for SL-T=2 or 3 on some FRs if the SL-A is still zero on other FRs, as this would likely be useless. Which SL would have been required to prevent the attack? Looking at the issues listed previously, it appears that raising the SL-A to level 2 would have allowed detection of the activity during step two, thus prevent - ing the cyberattack. Plenty of time was available for the post-detection reaction. Additional controls, such as strong/local authentication, anti-malware, and SL 2 requirements would actually have pre - 36 INTECH MARCH/APRIL 2017 WWW.ISA.ORG Table 4. Specific analysis for some the most significant SRs 1.13 There was no restriction for access from a nontrusted network, which was demonstrated by the fact that, once the hacker had the SSH access password, he or she could connect to the OT network without further credentials, local validation, etc. 2.4 Mobile code: The actual transfer of malware to several systems on the OT network demon- strated that there was no control of files in transit on the network. 2.6 During the attack, the OT operator had no straightforward way to terminate the remote con- nection, which is an SL-2 RE. 3.2 No malicious code protection: This is unfortunately most often the case in OT. Although it is not possible to install anti-malware software on all OT equipment, the total absence of such software paves the way for cyberattacks and allows the hacker to use publicly available exploits instead of having to develop custom ones. 5 Overall the FR5 SL is 2, which is fine. But this is a very effective demonstration that a firewall is not enough to ensure security. Indeed, as other controls (authentication, detection, local control) were missing, the hacker could use the single exception in the firewall rules without being detected or prevented. 6.2 The overall lack of network monitoring, both on the IT and OT networks, allowed the hacker to scan the network and identify vulnerabilities for days or even weeks. Note: This SR is set only for SL=2 or higher. It is strange that this requirement, much more effec- tive than SR 5.2 (see discussion above), is only required starting at SL=2 when filtering is already required for SL=1. 7.4 Disks were erased during the final step of the attack: The standard operating systems could have been restored with an adequate backup policy, except for the gateways where firm- ware, once overwritten, was unrecoverable.

Articles in this issue

Links on this page

Archives of this issue

view archives of InTech - MAR-APR 2017