Designing a security policy to protect your ... - Schneider Electric

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

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
2

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.
3

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.
4

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.
5

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.
6

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.
7

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.
8

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
Plant network
Connection to supervisory
and information systems
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
Control network/
Automation systems
configure devices via the web.
> Prohibit direct transfer of files into the control
Fiber optic ring
system. An intermediate staging server should
Gateway
Drive
be used to scan all incoming data for malware.
Modbus
Digital signatures can help verify that the file
Advantys OTB IP67 I/O Advantys STB Momentum Advantys OTB
really originated from the assumed server and
that it wasn’t modified between the scan and
Figure above
import into the control system.
Typical security-enabled automation network design
> 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.
Demilitarized zone
9

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.
10

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.
11

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.
12

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.
13

White paper: Designing a security policy to protect your automation solution
Make the most of your energy
Schneider Electric
© 2009 Schneider Electric. All rights reserved.
1 High Street
North Andover, MA 01810 USA
Phone: + 01 978 794 08000
http://www.schneider-electric.com
14
October 2009