designing a security policy to protect your automation solution

14
1 Designing a security policy to protect your automation solution September 2009 / White paper by Dan DesRuisseaux

Upload: schneider-electric-india

Post on 23-Jan-2015

127 views

Category:

Technology


2 download

DESCRIPTION

Network security for automation solutions is a concept that has been getting increased attention over the last decade. In the past, security was not a major concern because automation systems utilized proprietary components and were isolated from other networks within the business. Today, many automation systems are comprised of commercial off the shelf components, including Ethernet networking and Windows operating systems. In addition, legacy products are being updated to operate in these new network environments. The consequence is that formerly closed systems are suddenly connected to open enterprise networks and the Internet, exposing improperly protected systems to modern IT threats.

TRANSCRIPT

Page 1: Designing a security policy to protect your automation solution

1

Designing a security policy to protect your automation solution

September 2009 / White paper by Dan DesRuisseaux

Page 2: Designing a security policy to protect your automation solution

2

White paper: Designing a security policy to protect your automation solution

Contents

Executive Summary ................................................... p 3

Introduction................................................................. p 4

Security Guidelines .................................................... p 7

Conclusion ................................................................. p 13

Page 3: Designing a security policy to protect your automation solution

3

White paper: Designing a security policy to protect your automation solution

Executive summary

Network security for automation solutions is a concept that has been getting increased attention over the last decade. In the past, security was not a major concern because automation systems utilized proprietary components and were isolated from other networks within the business. Today, many automation systems are comprised of commercial off the shelf components, including Ethernet networking and Windows operating systems. In addition, legacy products are being updated to operate in these new network environments. The consequence is that formerly closed systems are suddenly connected to open enterprise networks and the Internet, exposing improperly protected systems to modern IT threats.

Page 4: Designing a security policy to protect your automation solution

4

White paper: Designing a security policy to protect your automation solution

Introduction

Security threats can be initiated from 4 different sources. Each source is defined below along with an example of a recent incident that illustrates the threat.

> Targeted External Attack – The CIA revealed that cyber attacks on utilities have caused at least one power outage affecting multiple cities.

> Random External Attack – The “Slammer Worm” penetrated a nuclear power plant and disabled a safety monitoring system for nearly 5 hours. The worm entered through an interconnected contractor’s network, bypassing the firewall.

> Internal Malicious Attack – A disgruntled former contractor gained access to the control system of a sewage treatment facility in Australia and flooded the surrounding area with millions of litres of untreated sewage.

> Internal Networking/ Configuration Issue – A data storm initiated by a PLC at a nuclear power plant required operators to shut down the reactor after two water pumps failed.

One way to address solution security is through the implementation of secure products. Secure products take two forms. The first is security features implemented in classic automation products. Examples include authentication and security logging in a PLC. The second form is stand-alone products developed specifically to address solution security. Examples include firewalls and intrusion detection software. It is important to note that secure products by themselves will not enable a secure solution. Companies also need to implement a comprehensive security policy. A security policy states the security objectives and guidelines that must be in place to ensure solution security. A company’s security policy should be a living document, not a static policy.

Page 5: Designing a security policy to protect your automation solution

5

White paper: Designing a security policy to protect your automation solution

Introduction (continued)

A company should also conduct a vulnerability assessment prior to creating their security policy. The vulnerability assessment is performed by reviewing the network architecture and auditing the equipment and software within the network. The assessment produces a document that defines and prioritizes the potential risks along with costs to address potential vulnerabilities. Many companies have defined and implemented security policies, while others have added security products (firewalls) but not addressed a security policy. This document is designed to assist companies in creating a security policy by providing a list of accepted security guidelines. Companies can review the list and select those that are suited to their application requirements.

Page 6: Designing a security policy to protect your automation solution

6

White paper: Designing a security policy to protect your automation solution

A disgruntled former contractor gained access to the control system of a sewage treatment facility in Australia and flooded the surrounding area with millions of litres of untreated sewage.

Page 7: Designing a security policy to protect your automation solution

7

White paper: Designing a security policy to protect your automation solution

Security Guidelines Many individual guidelines comprise a comprehensive security policy. Individual guidelines will be grouped into sub-categories to simplify presentation.

Physical Access to the Network One key to security involves restricting network access to specified personnel and equipment.

> Critical infrastructure should be placed in a secure location (preferably a locked room) to prevent unauthorized access. Ensure that portals to critical infrastructure are closed and locked.

> Disable all unused ports. > Do not let unauthorized laptops or memory sticks into a secure location. If laptops or

memory sticks are required, set up processes to ensure that all portable media are scanned for malware with up to date scanning software before allowing contact with a network host.

Authentication/ Authorization Authentication refers to the verification process to confirm identification for the purpose of accessing network resources. Authorization refers to access permissions allowing users to connect with devices. This combination allows the system to restrict network access and ensure that only the right personnel are accessing network resources.

> Each user should have a unique user name and password. User names and passwords should not be shared to enable easier tracking of system events.

> Solutions must enable the creation, editing, and deletion of users while the system is active. > System must not provide a “back door” allowing bypass of authentication procedures. > Critical data like user names and passwords must be stored in a secure data repository

using encryption technology. Access rights to the repository require authentication and should be made available only to trusted personnel.

> Implement password aging. > Passwords should be more than 8 characters, alphanumeric, and a mix of upper and lower

case characters. > Staff should change default passwords on equipment. > Use switch port-based MAC address management to deny access to non-authorized users. > Remote authentication should use encryption technology to transfer user name and

password through the system.

Page 8: Designing a security policy to protect your automation solution

8

White paper: Designing a security policy to protect your automation solution

> Limit software installation and execution privileges to specific employees. When risk is high, implement two and three factor authentication (password, physical device - smart key, and biometrics) or real-time confirmation by a second person.

> Restrict user access to data archives. > Authentication should be required to modify product firmware.

Network Design Vulnerability assessment will provide the data needed to create a secure network design. One key to securing the automation network is understanding the entry/connection points between it and the greater IT system. Potential connection points between networks include OPC servers, gateways, modems, and safety network connectivity. One key concept to network design is Defense in Depth. Defense in Depth is designed to protect control and safety systems. There is no single mechanism to protect against all types of attacks. Therefore it is best to create a series of protection layers designed to impede attackers. The layers also improve probability that attacks will be detected and repelled. Safety networks should be at least one layer deeper in a Defense in Depth architecture than the control network.

> If the automation network connects to a larger corporate network, a “demilitarized zone” should be created to buffer common resources between the two networks. A demilitarized zone is a buffer between a trusted network and an untrusted network. The zone is separated by firewalls and routers.

> Elements in the automation network or trusted zones within the network should be in a separate subnet from the greater network and should be isolated via a router and or firewall.

> The firewall fronting the automation system should include an intrusion detection system. > If using multiple firewalls, consider centralized firewall policies. > It should be possible to easily isolate the automation network from the corporate network if

an intrusion is detected. > Configure the network to eliminate requests from the control network to external computers.

A firewall should block all connections from the outside. > Remove or disable all unrequired services from automation hosts.

Page 9: Designing a security policy to protect your automation solution

9

White paper: Designing a security policy to protect your automation solution

> Utilize port restriction. For example, if you would like to allow an individual to program Modbus but not access the web server, then enable the device access to TCP port 502 (Modbus) but not port 80.

> Older Windows systems with limited security features should not be connected with an industrial system unless they are compartmentalized.

> Examine contractor network access levels. Prevent unprotected access to automation network. > Prevent incoming e-mail or Instant Messaging traffic to hosts in the automation network.

Disable or do not install e-mail or IM clients on computers in the automation domain. Additionally, block corresponding protocols at the firewall.

> Prohibit web browsing from hosts in the automation network. Prevent access by filtering at the firewall.

> Provide internet access from a separate host on a different network than the automation network so that information and updates from the Internet can be obtained if the main network is down.

> Prohibit drive sharing between hosts inside and outside the automation network. Enforce with firewalls.

> If necessary, restrict ability for personnel to configure devices via the web.

> Prohibit direct transfer of files into the control system. An intermediate staging server should be used to scan all incoming data for malware. Digital signatures can help verify that the file really originated from the assumed server and that it wasn’t modified between the scan and import into the control system.

> Firewalls should provide network address translation to protect the address data from the corporate network.

> Use trained, authorized personnel to add/remove new devices to/from the control network. > Non essential services with known weaknesses should be offered on one of several

redundant servers to reduce the effect of infection.

Drive

Control network/Automation systems

Demilitarized zone

Plant networkConnection to supervisoryand information systems

Fiber optic ring

Advantys OTB IP67 I/O Advantys STB Momentum Advantys OTB

Gateway

Modbus

Drive

Control network/Automation systems

Demilitarized zone

Plant networkConnection to supervisoryand information systems

Fiber optic ring

Advantys OTB IP67 I/O Advantys STB Momentum Advantys OTB

Gateway

Modbus

Figure above Typical security-enabled automation network design

Page 10: Designing a security policy to protect your automation solution

10

White paper: Designing a security policy to protect your automation solution

Remote Access Remote access should be enabled with the highest level of security available to the organization. Remote access should be provided with strong authentication, encryption, and, if possible, include the exchange and verification of certificates. Remote access policies should be restrictive, allowing the minimum number of rights for the minimum number of remote users. Remote access is typically provided through dial-up or VPN.

> If remote access is provided by dial up, protection can be provided via:

• Dial-out – connection initiated from inside the automation system.

• Dial-in with Call-back – the remote user dials into a server in the system which calls back to one of a limited set of pre-defined phone numbers.

• Temporarily enabled Dial-in – the modem is enabled for a specific dial-in event. The modem connection is disabled when there is no intended use, either physically or by switching it off, or by software means.

> VPN – The preferred way to provide remote access. If configuring safety or mission critical functions, organizations should define a fallback behaviour if there is a temporary loss of remote connection.

> Enforce application settings on both the client and server to change well known port numbers frequently targeted by virus attacks.

Wireless Many of the guidelines presented below require wireless devices to support specific security features. The guidelines below can provide input to features required in wireless devices.

> Place access points behind firewalls and use IPsec to prevent rogue access point access.

> Network access points should be positioned and arranged such that the useful signal strength is limited as far as possible to within the physically secured perimeter. Directional antennas can assist in forming a wireless footprint.

Page 11: Designing a security policy to protect your automation solution

11

White paper: Designing a security policy to protect your automation solution

> Many access points have the ability to define a list of approved clients (listed via MAC address). Undefined clients can not access the network. Network administrators should define approved clients. The ability to provision approved clients should be restricted to key personnel.

> Client devices must authenticate to enter the network. For authentication, use extensible authentication protocols such as EAP-TTLS, EAP-MSCHAPV2, or RADIUS.

> Do not utilize WEP security. Use WPA-2 security in addition to AES-CCMP or equivalent encryption.

> Do not broadcast SSIDs to prevent the network from showing up in wireless network scans. Also, do not enable ad-hoc connections.

> Monitor networks for denial of service attacks and alarm if detected. > Utilize frequency hopping radios to limit unauthorized access from external equipment. > Frequently review access logs to identify rogue devices and access points. Proactive

review can provide early warning of intrusion attempts. Maintenance

> Create procedures for dealing with security issues. Procedures include event identification, containment, root cause determination, resolution, and recurrence protection.

> Monitor system logs or use intrusion detection software to help anticipate attacks (configuration changes and creation of secondary accounts for example). Insure that there are no foreign IP addresses on your network or logs. If so, locate IP address origin and take action.

> Create detailed plans defining how to recover from attack. Examples include warm standby backup hosts isolated from the network and system backups on swappable and bootable hard disks for immediate restart. Generate a list of personnel to be contacted if an incident occurs and keep copies of device configuration files, programs, and SCADA images.

> Run virus checks on equipment on a regular basis. For critical infrastructure, scan communications to prevent viruses from accessing the platform.

> Software can be updated via CD/DVD or file transfer. If CD/DVD, insure that the discs are of proper origin and are virus free. If downloaded via file, insure the authenticity of the file via certificates and digital signatures and insure they are virus free. All files should be stored on a dedicated distribution server. Updates can only be administered by an authorized person operating inside the automation network.

> Monitor network traffic to enable early detection of possible data storms. > Test and approve software patches on standard machines that match the plant floor prior to

installing on live systems.

Page 12: Designing a security policy to protect your automation solution

12

White paper: Designing a security policy to protect your automation solution

General Security Policy

> Ensure that all security incidents are reported. > Hold regular audits of security policy. > Review incidents and new technologies to see if changes are required to existing policies. > For legacy systems where upgrades may have occurred over the years, obtain current

documentation to ensure knowledge of what is operating in the network. > Test detection and alert systems. > Test disaster recovery implementations. > Perform background checks on personal with access to critical systems. > Review people-management practices including methods to escalate and resolve

grievances to curb internally generated attacks.

Page 13: Designing a security policy to protect your automation solution

13

White paper: Designing a security policy to protect your automation solution

Conclusion A well designed Security Policy is essential to secure your automation solution Automation networks using standards-based operating systems and networks require greater security than the proprietary systems used in decades past. Standards-based solutions can be secured using existing products and technologies. Products and technology alone can not effectively secure an automation solution; they must be deployed in conjunction with a security policy. A well designed security policy coupled with diligent maintenance and oversight are essential to securing modern automation networks.

Page 14: Designing a security policy to protect your automation solution

White paper: Designing a security policy to protect your automation solution

Make the most of your energy

© 2

009

Schn

eide

r Ele

ctric

. All

right

s re

serv

ed.

Schneider Electric

1 High Street North Andover, MA 01810 USA Phone: + 01 978 794 08000 http://www.schneider-electric.com

14 October 2009