JOnline: Is the Business Network Connected to SCADA? Need for Auditing SCADA Networks 

 
Download Article

Stuxnet, a computer virus that attacked a widely used industrial system in Iran, woke up the world of supervisory control and data acquisition (SCADA)1 professionals and IT security professionals. Many SCADA professionals were until then evidencing a notion of security by obscurity, and many IT security professionals were either not interested or were not allowed to talk about SCADA security. The context of Stuxnet, which was first reported in June 2010, and its sophistication have been well discussed and there are many resources on the Internet for those who are interested in the details.2

Flame, one of the most complex threats ever, discovered in May 2012, is 20 times more powerful than Stuxnet, “the groundbreaking infrastructure-sabotaging malware that is believed to have wreaked havoc on Iran’s nuclear program in 2009 and 2010.”3 Although Flame has both a different purpose and composition than Stuxnet, and appears to have been written by different programmers, its complexity, the geographic scope of its infections and its behavior indicate strongly that behind Flame there could be other than common cybercriminals—marking it as yet another tool in the growing arsenal of cyberweaponry.

Why Integrate Business and SCADA Networks?

The term “business network (or systems)” is used here in the context of the IT systems network used for processing day-to-day general business transactions via enterprise resource planning (ERP) or other applications, databases, and the entire organization’s network connecting all users. As opposed to this, SCADA networks (or systems) are used for controlling the production of goods or services that may involve manufacturing, controlling, managing or monitoring. SCADA systems run many day-to-day utilities and service requirements, such as airports, railways, power, water, sewage plants, and oil and gas plants. To allow for better decision making, enterprises are feeling the need to have real-time updates for accurate production or related information on existing business networks. Therefore, the integration or connection of SCADA networks to business networks is more necessary than ever before.

The availability of technology and proliferation of the Internet have made it easier for SCADA vendors to integrate SCADA networks with business networks. Many process control industries, including public utilities, now take advantage of the ubiquity offered by public networks. Internet connectivity offers many conveniences, including remote access and control of systems; process efficiencies through integrated supply chains and outsourcing; centralization of database information; and interconnection of various private and public networks to create grids.

The size and scale of the enterprise side of operations have also grown, due to increased regulatory and reporting requirements and expanded use of commercial off-the-shelf (COTS) software for administration. Often, applications such as email, ERP and accounting now share SCADA network resources and use external network access for collaboration and updates.

SCADA Risks

Figure 1These administrative, communication and third-party interfaces present a risk for which process control and SCADA networks were not designed, so new cybersecurity mitigations should be mandatory. More and more zero-day vulnerabilities are being found every day. Many SCADA professionals are not IT security experts and, therefore, need the services of IT security professionals to integrate the two networks securely. The integration design given by some SCADA vendors often needs to be improved or customized by IT security professionals. For implementing the security requirements, additional budgets may have to be allocated, as security solutions may not be part of the initial budgetary estimate given by SCADA vendors. There are limited IT professionals who do understand the depth of security issues for a SCADA network.

Risk for SCADA systems is more severe and can have a greater impact than business systems; hence, the need for greater attention to security issues required for integration of SCADA networks with business networks. A compromise of a SCADA network can result in loss of lives, production, assets, monies and/or reputation. Attacks on SCADA systems may also occur for purposes of extortion and, in some cases, terrorism. Since SCADA systems run day-to-day utilities and service requirements, they are regarded as critical national infrastructure.

Figure 1 summarizes the major differences between old and new SCADA systems.

Figure 2CIA For SCADA Systems

For traditional business systems, the paradigm of confidentiality, integrity and availability (CIA) defines the technologies needed to secure the systems (figure 2). In contrast, the critical elements for SCADA systems are availability and message integrity. The typical SCADA system operates on a philosophy of “seven nines” of availability (99.99999 percent uptime). This leads to potentially different technological and security solutions. Typical tasks such as updating antivirus signatures or applying security patches can cause significant outages to these SCADA systems.

Figure 3 provides a summary of some of the major differences between business and SCADA systems.

Figure 3

Statistics

In September 2009, the Center for Strategic and International Studies (CSIS) conducted a survey of 600 security professionals worldwide. Their anonymous responses were relayed statistically in a McAfee report.4 This report was updated in November 2010 subsequent to Stuxnet.5 The charts in figures 4 and 5 provide statistics from the 2009 (pre-Stuxnet) report. Figure 4 presents responses to the question: “How long before you expect a major incident affecting critical infrastructure in your country?” The average response for “within next 12 months” was as high as 40 percent. Figure 5 shows the percentage who reported extortion using a network attack or the threat of it in the past two years. “One in five critical infrastructure entities reported being the victim of extortion through cyberattack or threatened cyberattack within the past two years. This striking rate was consistent with the anecdotal accounts of experts from several different countries and sectors; indeed, some suggested the real figure might be even higher.”6 Most such cases go unpublicized, if not unreported, the McAfee report says, because of reputation and other concerns by the victim company.7

Figure 4
Figure 5

Figures 6 and 7 indicate responses from the 2010 report, i.e., post-Stuxnet, pertaining to questions on interaction with government on cybersecurity and government audits for SCADA systems. The report reveals that 25 percent of critical infrastructure companies do not interact with the government on cybersecurity and network defense matters. For example, on the question of whether their security plans were audited by government, 100 percent of Japanese respondents reported undergoing such audits. This is a significant increase for Japan over 2009, when China led in security audits. In 2010, China ranked second in auditing, with seven of 10 respondents reporting undergoing such audits. The lowest audit rates occurred in the UK, Spain and the US, which all scored below 20 percent.

Figure 6
Figure 7

Looking at these statistics, it seems that governments may have to play a more focused role on regulation, compliance and audits for SCADA networks. More industry and government collaboration may be required to secure critical national infrastructure.

Auditing SCADA Networks

In view of the critical nature of such services, periodic audits of SCADA networks are necessary. As with audits of a business network, which are conducted periodically, SCADA networks must be audited irrespective of regulatory requirements. Though the basic audit methodology remains the same, the focus on SCADA network audits should be different from the foxus on business networks. For business networks, the priority is on securing the perimeter network and protecting the database holding confidential or personal data, such as credit card numbers. The highest priority for SCADA networks is to sustain operations and to secure human lives.

The following describe the major differences between audits for business and SCADA networks:

  1. SCADA security policy—As most audits start from the security policy, the auditor should check if a SCADA security policy exists and audit on that basis. In a business network, the auditor generally looks for an information/IT security policy.
  2. Risk assessments—For SCADA networks, risk assessments should be carried out prior to making the SCADA security policy and should recur periodically. SCADA risk assessments are more technical compared to business networks. SCADA risk assessments should be carried out by different vendors periodically to achieve better quality reports.
  3. Reviewing connections to the SCADA networks—All Internet connections, dial-up modems, wireless connections, satellite, microwave and Global System for Mobile Communications (GSM) links should be checked. Some SCADA systems use dial-up connections that might not be listed or specified in the connection diagrams. In business networks, dial-up connections are seldom used anymore. The auditor should also check for remote connections to vendors or third parties. Where modems are still used, war dialing could be used to detect them and get into the system.
  4. Perimeter and the DMZ—Auditors may challenge the network topology, if they feel that the access given is at risk. Auditors should make sure that the servers that need to be connected to the business networks are placed in the DMZ and not directly in to the SCADA local area network (LAN). The DMZ should have only reporting servers (such as the web server and Historian server). For example, in one security architecture, a SCADA vendor made a design for connecting the business network directly into the SCADA LAN connected to the servers, controlling production without any firewall in place. Such blunders should be avoided. Ideally, the connections of the SCADA network should not be directly connected through the DMZ of the business network. A separate DMZ may be created at the center where the view of SCADA reports is required. The workstations at the business network requiring these SCADA reports may be kept as independent workstations in another LAN connected to this new DMZ in the business network. The US Department of Homeland Security Control Systems Security Program (CSSP) recommends a defense in-depth architecture for SCADA networks.8
  5. Checking for backdoors—Some systems may have two network interface controller (NIC) cards—one connected to the SCADA network and the other to the business network—thus bypassing all controls. Such backdoors must be avoided.
  6. Auditing firewall access rules and reviewing previous firewall audit reports—The auditor should ensure that the firewalls in place understand SCADA protocols, such as Modbus. Many firewalls in the market do not understand Modbus protocols. In the business network, the audit of such specific protocol requirements may not be applicable.
  7. Hardening—The operating system (OS) and the applications running on servers in SCADA networks should be hardened and locked down. White-listing can be enabled so that only programs installed by the SCADA vendor are allowed to run on the servers. In such a scenario, a rogue program cannot be installed on the system even if it is able to reach the system. SCADA vendor participation is required in such an exercise.
  8. Patch management—The patch management policy in a SCADA network differs from that of a business network. Patches are normally applied by the SCADA vendor after they have finished testing in the lab. Since test beds are normally not available in production environments, the patch management becomes the sole responsibility of the SCADA vendor. Some proprietary systems may not have been patched at all. Patch management is normally streamlined in a business network.
  9. Configuration and change management—Configuration databases should be maintained and checked against the baseline at all times. Changes to the network should be justified and should follow a proper change management process, just as in a business network. Changes to production configurations may not be as frequent as in a business network.
  10. Logs or Security Information and Event Management (SIEM) solutions—Reports for any incidents should be monitored 24/7. SIEM solutions must understand SCADA protocols, such as Modbus.
  11. Intrusion detection or prevention systems (IDS/IPS)—IDS/IPS reports may be logged in the SIEM solution for analysis and further action. IDS/IPS for SCADA networks should be independent from those used in a business network.
  12. Encryption—Technologies such as Internet Protocol Security (IPsec) or Secure Socket Layer (SSL) should be used for virtual private network (VPN) or third-party connections. Communications over low latency connections should be encrypted. SCADA communications from the remote terminal unit (RTU) to the SCADA host should be encrypted using encryption technologies such as SCADA Cryptographic Module (SCM).
  13. Two-factor authentication—Two-factor authentication should be used to ensure strict access for remote control for third parties/vendors and for access to other critical systems in the SCADA network.
  14. Physical security—Such measures should include effective biometric authentication. Many SCADA sites are located in remote locations that are difficult to reach. Some oil and gas plants are on offshore platforms surrounded by water. The auditor should visit the plants to make sure effective physical access controls are in place. Business networks are not normally in remote places and physical access control requirements may not be as restrictive as they are for SCADA systems.
  15. Compliance with regulations—Regulations such as the North American Electric Reliability Corporation Critical Infrastructure Protection (NERC-CIP)9 must be followed. In addition, compliance requirements from other government or statutory bodies must be met, and standards such as ISA 99, Industrial Automation and Control Systems Security,10 can be followed. Compliance requirements for SCADA systems differ from business networks. Requirements such as the US Sarbanes-Oxley Act, the Payment Card Industry Data Security Standard (PCI DSS), and the US Health Insurance Portability and Accountability Act (HIPAA) may not be applicable in SCADA networks.

Some of the audit methodologies common to business and SCADA networks include:

  • Systems data backup and storage strategy
  • Segregation of duties
  • Systems hardware support and maintenance
  • Systems licenses and support
  • Systems and network security
  • Wide area network (WAN) connectivity requirements
  • Business continuity plan
  • Disaster recovery plan
  • The design of fields/solutions
  • The upgrade of old systems to new ones

Conclusion

Protecting SCADA networks that form critical national infrastructure is important, as shown by the points addressed in this article. IT security professionals should view it as their duty to collaborate with government and industry in the interest of protecting national assets from bad elements.

References

Endnotes

1 The term “SCADA” is used here to denote the industrial control systems (ICS) as a whole, including ICS, process control networks (PCNs), DMZ for SCADA networks, plant distributed control systems (DCS), programmable logic controllers (PLCs), remote terminal units (RTUs), intelligent electronic devices (IEDs), intelligent field devices and drives, smart meters, control systems for emergency shutdown (ESD), control systems for fire and gas (F&G) and other safety processes, and other embedded industrial control and monitoring systems and devices.
2 YouTube, “Stuxnet (Hungry Beast),” www.youtube.com/user/abchungrybeast?feature=watch#p/u/13/7g0pi4J8auQ
3 Zetter, Kim; “Meet Flame, The Massive Spy Malware Infiltrating Iranian Computers,” Wired, 2012, www.wired.com/threatlevel/2012/05/flame/
4 Baker, Stewart; Shaun Waterman; George Ivanov; “In the Crossfire: Critical Infrastructure in the Age of Cyber War,” McAfee, 2009, www.mcafee.com/us/resources/reports/rp-in-crossfire-critical-infrastructure-cyber-war.pdf
5 Baker, Stewart; Natalia Filipiak; Katrina Timlin; “In the Dark: Critical Industries Confront Cyberattacks,” McAfee and Center for Strategic and International Studies, November 2010, www.mcafee.com/us/resources/reports/rp-critical-infrastructure-protection.pdf
6 Ibid., p.8
7 Ibid.
8 Stouffer, Keith; Joe Falco; Karen Scarfone; National Institute of Standards and Technology (NIST), SP 800-82, June 2011, http://csrc.nist.gov/publications/nistpubs/800-82/SP800-82-final.pdf
9 North American Electric Reliability Corporation Critical Infrastructure Protection (NERC-CIP), www.nerc.com/page.php?cid=6|69
10 International Society for Automation (ISA), ISA99, Industrial Automation and Control Systems Security, www.isa.org/isa99

Ashwin K. Chaudary, CISA, CISM, CGEIT, CRISC, CISSP, PMP, has worked with SCADA security in the oil and gas sector. Chaudary has also worked on projects for compliance requirements such as the US Sarbanes-Oxley Act, ISO 27001, PCI DSS and SAS 70 (SSAE 16) and for the implementation of governance/risk frameworks. He can be reached at ashwin.k.chaudary@gmail.com.


Enjoying this article? To read the most current ISACA Journal articles, become a member or subscribe to the Journal.

The ISACA Journal is published by ISACA. Membership in the association, a voluntary organization serving IT governance professionals, entitles one to receive an annual subscription to the ISACA Journal.

Opinions expressed in the ISACA Journal represent the views of the authors and advertisers. They may differ from policies and official statements of ISACA and/or the IT Governance Institute and their committees, and from opinions endorsed by authors’ employers, or the editors of this Journal. ISACA Journal does not attest to the originality of authors’ content.

© 2012 ISACA. All rights reserved.

Instructors are permitted to photocopy isolated articles for noncommercial classroom use without fee. For other copying, reprint or republication, permission must be obtained in writing from the association. Where necessary, permission is granted by the copyright owners for those registered with the Copyright Clearance Center (CCC), 27 Congress St., Salem, MA 01970, to photocopy articles owned by ISACA, for a flat fee of US $2.50 per article plus 25¢ per page. Send payment to the CCC stating the ISSN (1526-7407), date, volume, and first and last page number of each article. Copying for other than personal use or internal reference, or of articles or columns not owned by the association without express permission of the association or the copyright owner is expressly prohibited.