Geh 6839

GEH-6839
Mark* VIe Control Systems

Secure Deployment Guide
For public disclosure

These instructions do not purport to cover all details or variations in equipment, nor to provide for every possible
contingency to be met during installation, operation, and maintenance. The information is supplied for informational
purposes only, and GE makes no warranty as to the accuracy of the information included herein. Changes, modifications,
and/or improvements to equipment and specifications are made periodically and these changes may or may not be reflected
herein. It is understood that GE may make changes, modifications, or improvements to the equipment referenced herein or to
the document itself at any time. This document is intended for trained personnel familiar with the GE products referenced
herein.
GE may have patents or pending patent applications covering subject matter in this document. The furnishing of this
document does not provide any license whatsoever to any of these patents.
This document is approved for public disclosure.
GE provides the following document and the information included therein as is and without warranty of any kind, expressed
or implied, including but not limited to any implied statutory warranty of merchantability or fitness for particular purpose.
For further assistance or technical information, contact the nearest GE Sales or Service Office, or an authorized GE Sales
Representative.
Issued: Dec 2015
Copyright 2015 General Electric Company, All rights reserved.

___________________________________
* Indicates a trademark of General Electric Company and/or its subsidiaries.
All other trademarks are the property of their respective owners.
We would appreciate your feedback about our documentation.

Please send comments or suggestions to controls.doc@ge.com

Document Updates
Location Description
Entire document Initial release
GEH-6839 Secure Deployment Guide 3

Contents
1 Introduction ....................................................................................................................................... 7
2 Security and Secure Deployment................................................................................................. 9
2.1 What is Security?.....................................................................................................................................9
2.2 I have a firewall. Isnt that enough? .............................................................................................................9
2.3 What is Defense in Depth? ........................................................................................................................9
2.4 General Concepts................................................................................................................................... 10
2.5 What is Hardening?................................................................................................................................ 11
2.6 General Recommendations ...................................................................................................................... 12
3 Mark VIe Controller Family........................................................................................................... 15
3.1 Security Capabilities .............................................................................................................................. 15
3.1.1 User Authentication and Authorization................................................................................................ 15
3.1.2 Access Control Mechanisms ............................................................................................................. 16
3.1.3 Modes of Operation ........................................................................................................................ 16
3.2 Communication Requirements ................................................................................................................. 17
3.2.1 Network Connectivity ...................................................................................................................... 17
3.2.2 Servers.......................................................................................................................................... 17
3.2.3 Gateways ...................................................................................................................................... 18
3.2.4 Ports and Services List ..................................................................................................................... 18
3.3 Configuration Hardening......................................................................................................................... 19
4 ToolboxST Product ........................................................................................................................ 21
4.2.2 Ports and Services ........................................................................................................................... 22
4.4 Additional Recommendations .................................................................................................................. 22
5 CMS Product.................................................................................................................................... 23
5.2.2 Servers.......................................................................................................................................... 24
6 WorkstationST Product ................................................................................................................ 25
6.2.2 Servers.......................................................................................................................................... 27
4 GEH-6839 Mark VIe Control System Secure Deployment Guide

6.2.3 Ports and Services List .................................................................................................................... 29
7 HMI Product ..................................................................................................................................... 33
7.1 Overview ............................................................................................................................................. 33
8 NetworkST Product........................................................................................................................ 37
8.1 Overview ............................................................................................................................................. 37
8.3.2 Servers.......................................................................................................................................... 41
8.5 Additional Recommendations .................................................................................................................. 42
9 SecurityST Product........................................................................................................................ 43
9.1 Overview ............................................................................................................................................. 43
Glossary.................................................................................................................................................. 47
GEH-6839 Secure Deployment Guide 5

Notes

1 Introduction
This document provides information that can be used to help improve the cyber security
of systems that include Mark VIe Control Systems. It is intended for use by control
engineers, integrators, IT professionals, and developers responsible for deploying and
configuring the Mark VIe Control System.
Each site will have its own philosophies, procedures, and audit requirements. In the
power generation field many of these will be based on industry standards and practices
such as described in ISA-99, IEC-62443, NIST 800, and NERC CIP documents. These
standards and practices should be used as guidance while configuring and maintaining the
site.
This document describes many tools that are available and concepts that should be
followed to help sites meet their security requirements, but tools alone cannot guarantee a
site's compliance. The best password policy enforcement tool cannot protect against
posting a password on a sticky-note on a computer monitor - an act that is likely to raise
issues during an audit. Site procedures (which are outside the scope of this document)
must be created, maintained, and followed to meet most audit requirements.
Certain sections of this document include information about optional products, such as the
NetworkST 4.0 product with its network hardening capability or the SecurityST product
with its wealth of additional security functions. These products are not required to run the
Mark VIe control system, but their pre-packaged functionality can be used to strengthen
the site security posture. Whether or not these products are used, the concepts presented
in this document should be addressed within each site's specific security requirements.
The controllers and supervisory level computers covered in this document
were not designed for or intended to be connected directly to any wide area
network, including but not limited to a corporate network or the Internet at
large. Additional routers and firewalls (such as supplied with the NetworkST
4.0 option) that have been configured with access rules customized to the
site's specific needs must be used to access devices described in this
document from outside the local control networks.
Introduction GEH-6839 Secure Deployment Guide 7

Notes

2 Security and Secure Deployment
This section introduces the fundamentals of security and secure deployment.
2.1 What is Security?

Security is the process of maintaining the confidentiality, integrity, and availability of a
system:
Confidentiality: Ensure only the people you want to see information can see it.
Integrity: Ensure the data is what it is supposed to be.
Availability: Ensure the system or data is available for use.
GE recognizes the importance of building and deploying products with these concepts in
mind and encourages customers to take appropriate care in securing their GE products
and solutions.
Different sites will have different needs and requirements surrounding these concepts.
Follow the site's requirements when building, deploying, and using systems, keeping in
mind the impact that decisions and procedures will have on the site's security posture.
2.2 I have a firewall. Isnt that enough?

Firewalls and other network security products, including Data Diodes and Intrusion
Prevention Devices, can be an important component of any security strategy. However, a
strategy based solely on any single security mechanism will not be as resilient as one that
includes multiple, independent layers of security.
Therefore, GE recommends taking a Defense in Depth approach to security.
2.3 What is Defense in Depth?

Defense in Depth is the concept of using multiple, independent layers of security to raise
the cost and complexity of a successful attack. To carry out a successful attack on a
system, an attacker would need to find not just a single exploitable vulnerability, but
would need to exploit vulnerabilities in each layer of defense that protects an asset.
For example, if a system is protected because it is on a network protected by a firewall,
the attacker only needs to circumvent the firewall to gain unauthorized access. However,
if there is an additional layer of defense, say a username/password authentication
requirement, now the attacker needs to find a way to circumvent both the firewall and the
username/password authentication.
Security and Secure Deployment GEH-6839 Secure Deployment Guide 9

2.4 General Concepts
There are a number of concepts that are used throughout this document that provide many
of the building blocks used to improve a site's security posture. This section describes
these basic concepts.
Authentication is the act of determining or verifying the identity of a user or element
that is requesting access to a resource or requesting that a particular action be taken.
Example: The Microsoft Windows Operating System typically defines a username

to establish an identity for a user and a password to verify that the user is in fact who
they claim to be.
Example: Many communications schemes use a Certificate to verify the identity of
the endpoint (or endpoints) of that communication. As part of the initiation of the
communication link one or both sides provide their certificate to verify their identity.
Authorization is the act of determining what identities are allowed (authorized) to
access a resource or perform an action. Most authorization schemes support multiple
levels of authorization, such as a distinction between the ability to view an item versus the
ability to modify an item.
Example: The Microsoft Windows Operating System supports multiple levels of

access on items (such as ReadOnly versus ReadWrite access to a file) and a set of
operating system privileges to control actions that users may take.
Example: The Mark VIe controller in secure mode uses a user's certificate to
determine the level of commands that the user can perform, such as Read, Set (write),
and Download (reconfigure).
Access Control Lists (ACLs) are often used as a method of binding together the
requester's identity with the level of access allowed. These ACLs are defined on a
per-item basis, so different items may have different ACLs.
Example: The Microsoft Windows Operating System supports ACLs on files and
devices to define which users have what access rights to those items.
Example: The network switches support ACLs on their administrative interfaces to
define which elements of the system have the right to access the administrative
functions.
Note When done at the operating system level, ACLs protect an item no matter what tool
(program) is used to attempt access - this is called authoritative security. This is a stronger
level of protection than when the tool being used determines whether to allow access or
not - this is called cooperative or client-based security. Cooperative security can be
bypassed by using a different client to access the resource, authoritative security cannot
be bypassed as easily.
The concept of Least Privileges states that each user should be granted only the access
rights and privileges that they need to perform their work function. This protects items
and configurations against inadvertent changes by users, possibly because of malware that
the user has inadvertently triggered
Example: The Microsoft Windows Operating System supports the concept of

Administrator level access for making changes to the operating system and software
running on the computer. If a user is running with administrative access, any malware
that they trigger could alter the operating system or any program in any way that it
desired. If the user is running in a non-administrative account it is limited in the
changes that it can make.

Example: The ToolboxST subsystem supports a Users and Roles concept to define
what operations a user is allowed to take, such as forcing variables, issuing alarm
acknowledge and reset commands, or downloading configurations to controllers.
The concept of Role Based Access Control (RBAC) is a consolidation of using the
user's identity (authentication) and their allowed rights (authorization) in a slightly easier
to maintain manor. An intermediate concept of a user's Role is introduced, which defines
a collection of users with shared access rights and privileges. This simplifying scheme has
a number of benefits:
Authorization (done on a per-item basis) is done not to a set of user identities, but
instead to a Role - it's ACL is not a list of usernames but a (much smaller) list of
Roles. As users are added and removed from the system the ACLs on each item do
not have to change since they were tied to the Roles and not the users, making
updates very fast and efficient.
Reporting on the members of a single Role is quick and easy compared to having to
visit all items and examine their individual ACLs.
If a user's Role changes (their job requirements change) it is a simpler task to assign
them to a new role, and perhaps change it back again if the change was only
temporary.
New roles are typically easy to define as the site's operating procedures change and
different classifications of users are required or different sets of privileges are
identified.
Example: The Microsoft Windows Operating System has a single security group that
grants Administrative access to computers - the Administrators group. Adding or
removing a user to the Administrators group will grant or revoke the user's
administrative privileges and the individual ACLs on all files and devices does not
have to be changed.
Example: The ToolboxST subsystem supports a Users and Roles concept, which
defines what rights and privileges are given for each Role. If a site decides to change
whether the Operators role is allowed to force variables, granting or revoking the
Force privilege to the Operators role is all that is required - there is no need to
change each user's privileges.
2.5 What is Hardening?

Hardening a system includes taking steps to reduce attack surfaces that may be used in an
attack on the system. These steps include removing functions that are not essential and
changing system settings to help deter attacks. Each section in this manual includes
information on how to help harden each component, but the following concepts apply to
most all products:
Disable unused Servers and Services on each device.

Create and maintain the list of users and their rights. Disable or remove a user's
account as soon as the person is no longer granted access rights to the equipment.
Implement the site's password policies, where possible by configuring the equipment
to reject passwords that don't meet the standards automatically.
Remove all as shipped accounts or (if the account is to remain) change all passwords
as soon as feasible during the site commissioning process. Implement strict site
policy and controls to limit the exposure of passwords.

2.6 General Recommendations
The following general recommendations should be used to improve the security posture at
the site:
Provide physical security for all devices - many, if not most devices can be
compromised by an attacker that has physical access to the device at startup/boot
time or direct access to the non-volatile media that the device boots from (hard drive,
flash memory, etc.). Access to network equipment (switches, routers) can allow for
introduction of new devices onto the networks, including network monitoring
equipment.
Disable unused services on devices to reduce the mechanisms available for attacks.
Wherever possible, configure the site's password requirements (length,
complexity) into the devices or operating systems to have each device enforce
them automatically. If it cannot be automatically enforced it must be done
procedurally.
The Windows Operating System password requirements can be enforced via
local policies, or if the computers are in a domain by Group Policy.
If the SecurityST product was purchased, the ANIXIS Password Policy
Enforcement program can be configured with additional password requirements
above and beyond what is supported by the Microsoft Windows Operating
System.
Implement Role Based Access Control wherever available, and keep the list of users
and roles current.
Some system components allow for logging (auditing) failures, use these if
available - preferably logging to a centralized site SIEM (if available) for both
convenience and pattern analysis across devices.
Implement a site-wide scheme for applying software patches, especially those
defined as security patches.
Implement a site-wide scheme for supplying anti-virus software wherever
appropriate, including a method to keep the anti-virus signatures up-to-date.
Consider the use of Whitelisting as an advanced method of malware protection.
Whitelisting is generally recognized as one of the most powerful methods to protect
against malware, but it usually comes at a relatively high maintenance/complexity
cost.
The Mark VIe controller supports whitelisting when placed into Secure Mode
(low maintenance).
The SecurityST product supports an optional whitelisting scheme targeted
towards applications running on an HMI, Engineering Workstation, Historian,
and the SecurityST Server itself.
Implement a Network Intrusion Detection scheme for communication traffic where
appropriate, especially traffic that crosses an electronic security perimeter.
Limiting visibility to the control system is a strong defense-in-depth approach to help
prevent attacks. This is accomplished by using separate communications networks
(Virtual Local Area Networks or VLANs) to isolate different types of equipment, then
tightly controlling the network traffic that can cross from one VLAN to another. There are
various schemes and recommendations (ISA-99, IEC-62443) that include network
segmentation and they should be followed when making any networking changes or while
introducing new equipment to the control system.
Consider using a dedicated point-to-point link instead of a shared network for

dedicated functions within the same network zone. Never bridge network zones using
a dedicated link, always go through a router that provides controlled access (and
optional logging).

Consider using an additional firewall even within a network zone to add additional
constraints on traffic, especially if the traffic includes a protocol that does not support
authentication.
Example: Consider using an additional firewall inside the Control Zone to limit
HTTP or MODBUS traffic to a Mark VIe controller to a particular client device
(or limited set of devices).
Example: Consider using either an additional firewall or additional Windows
Firewall rules to limit the clients that can connect to an HMI MODBUS or GSM
Server.
Consider using the Windows Firewall IPsec settings in an HMI or Engineering
Workstation to protect protocols that do not support authentication (such as
MODBUS or GSM). This adds an extra layer of protection in that clients that do not
know the IPsec keys will not be able to connect.
This is stronger protection than using just the Windows Firewall IP address or
MAC address filter, as both IP addresses and MAC addresses can be spoofed.
If a site requires encryption of protocols that do not support encryption the
Windows Firewall IPsec layer can be used to encrypt the traffic (in addition to
providing client-server authentication).
Visibility into the control system is not limited to just communication links, it also
includes removable media. There are many instances of malicious software delivered to
control systems via USB (thumb or pen) drives as well as via CDs and DVDs.
Verify the source and integrity of media before placing it into site equipment.
Software distributions should be verified by whatever method the manufacturer
supports, such as signed installation files or a separate web site that lists the
hashes for the files on the distribution media.
Use of password protected media does not ensure that the media is free from
malicious software, but it does help prevent the media from being infected while
left unattended.
Make sure that the AutoRun option in the Windows Operating System is disabled to
help prevent software from being automatically run when the media is inserted into
the computer.
Typically all USB ports cannot be disabled on an HMI or Engineering Workstation as
they are used for peripherals (keyboard, mouse, speakers) and hardware license keys.
If these functions can be supported by using internal USB ports, it may be possible to
disable the external USB ports if desired.
Consider using hardware USB port locks to prevent access to the USB ports, and/or
pulling the front or rear USB port connectors coming from the computer's
motherboard.
Consider using additional software packages (such as the Sophos Anti-Virus
package supplied with the SecurityST product) to control access to the USB ports on
computers.
Consider blocking the use of USB ports on all but one or two computers (often the
Engineering Workstation(s)) to limit USB exposure, then use the internal network to
transfer the information to the computers that need it.

Notes

3 Mark VIe Controller Family
3.1 Security Capabilities
3.1.1 User Authentication and Authorization
The Mark VIe controller includes a single administrative account for direct access to the
controller operating system. This account is only used for advanced diagnostics and is not
required for normal operation or for maintenance procedures.
The password for the Mark VIe controller's local account should be defined
according to the site policy and knowledge of the password should be limited.
The ToolboxST application is used to change the password, and it will enforce a
fixed set of length and complexity requirements. If the site requires additional
password constraints they should be addressed procedurally. The following
constraints are enforced by the ToolboxST application:
Minimum Password Length: 7 characters
Complexity Requirements: A minimum of 3 out of 4 character groups
represented, with the groups being: Lower case, Upper case, Numeric, and
Special characters.
The Mark VIe main processor board contains a serial port which is only used for
advanced diagnostics. It is not used during normal operation and no users are expected to
access this port. Limiting access to this port (via locked cabinets or controlled entry to the
room) enhances the security of the physical system. When the Mark VIe is placed into
Secure Mode the serial port console interface is disabled.
Access to the console serial port can be limited by limiting physical access to the
serial port - such as implementing room access control or locks on the Mark VIe
cabinet.
If the SecurityST product was purchased, place the Mark VIe controllers in Secure
Mode to disable the console ports.
The Mark VIe controller supports a Secure Shell (SSH) connection over the UDH
network for console access. This is only used for advanced diagnostics and is not used in
normal operation. Users connecting to the SSH server will be required to enter the
administrative mode credentials to gain access. When the Mark VIe is placed into Secure
Mode the SSH console interface is disabled.
SSH clients should be selected that include authentication of the server's public key.
Once each controller's public key has been recorded, users should NOT provide
credentials to devices that are not in the trusted controller list. (Some SSH clients can
be configured to deny connections to untrusted devices before prompting for the
user's credentials.)
If a UDH default gateway has been defined in the Mark VIe controller, verify that the
default gateway is a router with rules that prevent routing SSH connections beyond
the UDH unless this is an explicit requirement at the site.
Mode to disable the console ports.
Mark VIe Controller Family GEH-6839 Secure Deployment Guide 15

The normal interface to the Mark VIe controller is via the ToolboxST application run on
an Engineering Workstation or an HMI. The ToolboxST application will enforce a limit
on the user's capability based upon the Roles and Privileges assigned to the user. When a
Mark VIe is placed into Secure Mode the ToolboxST connection (SDI protocol) is
authenticated via the user's Controller Role certificate and the commands that are
accepted are filtered against the user's authorized Controller Role.
Use the ToolboxST Users and Roles capability to control the runtime commands that
individual users are allowed to issue to the Mark VIe controller.
Mode to ensure that the Mark VIe controller authenticates the user and limits their
actions to their assigned Controller Role.
3.1.2 Access Control Mechanisms

The access control mechanisms within the Mark VIe are not user configurable. Most
hardening actions are accomplished via the OS configuration (administrative account
password) or the interfaces (SSH, SDI).
If the SecurityST product was purchased, place the Mark VIe controller into Secure
Mode to activate the application whitelisting and user authentication subsystems.
There is a USB port on certain Mark VIe controllers (such as the UCSB version) but it is
not active during normal operation - no USB driver is even loaded. The USB port is only
used for an initial software load to provide a minimal system ready to accept a full
download via a ToolboxST Download operation. The USB port is only active when a user
holds down the USB Enable button while powering up the controller. With the button
held down, the controller will load an image from the USB device and then cease
operation. Upon the next power up (with the button not depressed) it will load the image
and await the full download.
3.1.3 Modes of Operation

Mark VIe controllers support running in Secure Mode to implement additional security
features. Secure Mode operation requires a SecurityST system providing additional
authentication, authorization, and certificate management functions. When a Mark VIe
controller is placed into Secure Mode its security is enhanced by adding the following:
The local administrative account is disabled.

The console ports (serial and SSH) are disabled.
A whitelist subsystem is activated to remove any process running in the controller
that is not trusted or has been altered.
All SDI connections request user authentication via a user Controller Role certificate.
If no user certificate is provided, the Mark VIe SDI connection will essentially
run in ReadOnly mode, allowing the user to read information from the controller
but not to change information. (Note: Other protocols not covered by the SDI
user authentication will still support write actions while in Secure Mode.)
If a user certificate is provided then the commands sent by the user will be
filtered against the user's Controller Role and only SDI commands allowed by
the user role will be accepted.
If the Mark VIe is hosting a Web Server it will require password authentication
before allowing commands that can change the state of the controller.

3.2 Communication Requirements
3.2.1 Network Connectivity
The IONet is a redundant network that is used to connect the Mark VIe controllers with
their I/O Packs. Access to the IONet is typically local to a single Mark VIe controller, but
there is an option to share I/O Packs between multiple controllers by using a Shared
IONet between multiple controllers. This is often used to share I/O between a Safety
System (Mark VIeS) and a normal controller (Mark VIe). (Refer to the Mark Controllers
Shared IONet User Guide (GEH-6812)for additional information.)
Do not add non-Mark VIe controllers or I/O devices to an IONet, including

Engineering Workstations or HMIs.
Do not use a bridge or gateway to expose the IONet to any external networks.
Do not extend the IONet outside of the single logical "control panel" for the Mark
VIe unless this controller is participating in a Shared IONet architecture.
The UDH is a special network reserved for control message traffic. Mark VIe controller
redundancy on the UDH is not accomplished by multiple connections per processor, but
instead by having different processors in the controller (such as <R>, <S>, and <T>
processors) each connected to different UDH segments and switches.
The Mark VIe configuration should not define a default gateway for the UDH unless
it is required. Common reasons for requiring a UDH default gateway include:
To be able to support communication to an OSM or Historian located on the
Monitoring Data Highway (MDH).
To be able to support a Security Information and Event Monitor (SIEM), or
Syslog server, that is not physically connected to the UDH.
If a default gateway is defined for the UDH in the Mark VIe configuration, it should
be directed to a router that limits communication to only required message traffic.
3.2.2 Servers
The Mark VIe controller includes an optional OPC UA Server for the exchange of real
time data and commands. The OPC UA Server will listen for OPC UA client connections
and respond to the client's request to read or write data values.
Do not enable the OPC UA Server unless it is required.

Follow OPC UA practices for certificate management to control the clients that will
be granted access to this server.
The Mark VIe controller includes an optional MODBUS server for the exchange of real
time data and commands. The MODBUS server will listen for MODBUS client
connections and respond to client's requests to read or write data values. The port number
defaults to port 502, but can be assigned to a limited number of other ports.
Do not enable the MODBUS server unless it is required.

Consider using additional firewalls to limit client connection points to the MODBUS
server.
Consider using IPsec to both limit client connection points and add encryption to the
MODBUS data flow.
The Mark VIe controller supports an optional Web Server interface for the exchange of
real time data and commands. The Web Server will listen for client connections on port
80 and respond to client requests.
Do not enable the Web Server unless it is required.

3.2.3 Gateways
The Mark VIe controller supports an optional Device Manager Gateway for
communications to certain I/O devices. The interface into this communication path (the
end of the tunnel) is on an Engineering Workstation or HMI. Security around access to
this tunnel (who is allowed to connect, is it encrypted) is performed at the end of the
tunnel, not in the Mark VIe controller. (Refer to the section, WorkstationST Product for
additional details.)
3.2.4 Ports and Services List

Port Protocol Service Description
22 TCP SSH Secure Shell interface for advanced diagnostics.
80 TCP HTTP Web Server for operational displays. (option)
Network Time Protocol, used for time

123 UDP NTP
synchronization.
MODBUS server for real time data and

502 TCP MODBUS commands in reply to an external MODBUS
client request. (option)
4841 TCP OPC UA OPC UA Server (option)
GE Proprietary SDI protocol for system

5310-5312 TCP GE SDI configuration, maintenance, and real time data
and alarm management.
GE SDI protocol for systems running in Secure

5313 TCP GE SDI (Secure)
Mode.
Valmet MODBUS server for real time data and
commands in reply to an external Valmet
5315 TCP V-MODBUS
MODBUS client request. (option-follows
MODBUS)
GE ADL protocol used for high speed data

7936 UDP ADL
captures and remote tuning.
Command Message Protocol (CMP) used to

7937 UDP GE CMP issue commands to variables exposed on EGD
pages.
EGD Configuration Server, used to provide EGD

7937 TCP EGD
page definitions to EGD clients.
Ethernet Global Data (EGD) service for

18246 UDP EGD
exchange of real time data.

3.3 Configuration Hardening
Use a separate Safety Protection System for critical safety related control loops.
Do not enable the Web Server unless it is required.
Do not enable the MODBUS Server unless it is required.
Do not enable the OPC UA Server unless it is required.
Do not define a Default Gateway unless it is required.
Use ToolboxST Users and Roles and configuration passwords to limit access to only
what is required.
Consider creating sequencing to add limit and validity checks around input values
(such as setpoints and pushbutton commands) to validate the requested value or
operation, warning (alarm) on values or operations that are deemed invalid.
Create a secure administrative mode password and limit exposure to only those who
require it.
Control physical access to the Mark VIe controller (serial port, USB Enable button,
internal flash memory device).
Configure the Syslog server address to point to the SIEM if one is available.

Notes

4 ToolboxST Product
Use the Authentication and Authorization methods defined in the section, HMI product to
provide Authentication for ToolboxST. The ToolboxST application uses the user's
Windows logon account for user authentication.
The ToolboxST application supports a Users and Roles scheme for defining a set of
Roles. Each Role is granted a set of Privileges that define the actions that they are allowed
to perform. Each user (based upon their Windows user account) is assigned to a particular
Role. This results in the user being granted the privileges associated with the Role that
was assigned to them.
Use the ToolboxST Users and Roles feature to define a set of Roles.
Grant each Role the Privileges required according to site operating policies.
Assign each User to a Role based upon the capabilities they require to perform their
job.

The ToolboxST application uses the user's current Windows identity when accessing file
resources on the user's behalf. This honors access control lists (ACLs) on the
configuration files to determine if a user has the rights to view or modify the
configuration file.
Use the Access Control methods defined in the section, HMI product to control
access to the ToolboxST configuration files.
Do not alter the Access Control Lists on the configuration files unless it is to
strengthen it to meet site requirements.
The configurations associated with devices, libraries, and software modules include a
Protection attribute that can be used to assign a password to various levels of access. The
available levels vary slightly based upon what is being protected, but in general they
provide specific types of access (View, Modify) only when the user enters the defined
password. These passwords propagate with the module to prevent the protection from
being circumvented by simply copying it to another (unprotected) device.
Use the Protection attribute in configurations at the device level and/or the software
module level to control access.
The Access Roles settings allow granting access according to the user's current role.
Password settings allow specifying a password required for various levels of access,
including View Design, Modify Data, and Modify Design. The passwords are
independent of the user that is logged in, and will continue to protect information
even if the configuration files are copied from one computer or system definition to
another.
Follow site password strength and complexity rules when defining these passwords,
the ToolboxST tool only places a minimal set of requirements on passwords.
ToolboxST Product GEH-6839 Secure Deployment Guide 21

The ToolboxST application is used to maintain and download configurations to various
devices, including both Mark VIe controllers and WorkstationST-based HMIs and
Engineering workstations. It also includes many data retrieval and observation tools for
viewing both real time data as well as diagnostic information including diagnostic alarms.
The computer hosting the ToolboxST application must have connectivity to the
devices that it must download or diagnose. This typically means UDH access for
Mark VIe controllers, and PDH access for WorkstationST-based computers.
4.2.2 Ports and Services

The ToolboxST application is run upon user demand to view, edit, or diagnose controller
or WorkstationST configurations and as such does not contain any server ports. It is a
client to other services (such as the EGD Configuration Server and CMS Server) and does
not act as a server itself.

If SIL Certification is required, do not configure Safety system programming into
non-safety systems - use a Safety System (such as the Mark VIeS product) instead.
Define and use the ToolboxST Users and Roles subsystem. (Refer to the sections,
Mark VIe Controller Family and ToolboxST Product for details.)
If passwords are used on devices or software modules, use strong password policies
and limit knowledge of the password on a need-to-know basis.
4.4 Additional Recommendations

Make sure to maintain backup copies of the system and controller configuration files.
Use site Change Management procedures and a Configuration Management System
(CMS Server) to enforce change control rules and record the changes and the user
identity associated with the changes.
When each user's CMS Client first connects to the CMS Server it will present the
Server Certificate and ask if it should be trusted. You should provide a method
whereby the user can determine the validity of the certificate prior to marking it as
being trusted. This prevents providing logon credentials to untrusted servers.

5 CMS Product
The CSM Server uses the current user's Widows account for authentication to the CMS
Server. Once the user's identity has been established access to the individual repositories
will be based upon the repository's access control list, maintained by the CMS
Administrator. Phrased another way, authentication is done via the user's Windows
account, and authorization is done via the access control defined for each repository.
For each Repository (one is typical, but there may be multiple) define the level of
access associated with each user (ReadOnly versus ReadWrite).
An Administrative level account is required on the computer that hosts the CMS
Server for the initial creation of a repository and to maintain the list of users and the
access level granted to each user.
The CMS Server uses a web interface for client connections. This interface uses the
HTTPS protocol to identify the CMS Server as being legitimate and to protect the
information flowing through the client - server connection. This requires a Web Server
Certificate in order to establish the HTTPS connection. Do not remove this layer of
protection, and instruct users not to provide their credentials to a server that is not trusted.
Do not enable HTTP (unencrypted) access to the CMS Server.

Do not remove the CMS Server Certificate enabling use of HTTPS for secure
communications - renew this certificate as needed.
Use a Self-signed certificate only if there is no SecurityST system to provide a
domain level certificate for the CMS Server, and provide users a method to know
how to trust the valid CMS Server before providing it with their logon credentials.
The CMS Server itself runs as a background service with limited privileges (Local
Service account) - it does not require more powerful operating system privileges to
accomplish its tasks.
Do not change the service definition to run the CMS Server (Apache Service) with
additional privileges (such as running it under the SYSTEM account).
Do not modify the ACLs on the directories that are used to store the information
placed into the repositories. Access to the files should be controlled through the CMS
Server and its internal access control lists.
Do not expose the raw files in the repositories via other mechanisms (such as a
sharename) as it will not honor the Repository access list definitions and the
information may be provided without encryption.
CMS Product GEH-6839 Secure Deployment Guide 23

The CMS Clients typically connect to the CMS Server over the PDH. CMS Server traffic
should not be routed over the UDH.
When configuring the CMS Clients to talk to the CMS Server, always use the CMS
Server's PDH address, never its UDH address.
If a Default Gateway is programmed into the computer hosting the CMS Server,
verify that the Default Gateway is a router with rules that prevent CMS Server access
from outside the PDH unless that is an explicit site requirement. If accessing from
outside the PDH, the Firewall rules on the CMS Server Host may need to be altered
to allow access to the CMS Server from outside of the local subnet.
5.2.2 Servers
The CMS Server provides its services via a Web Server. A single-purpose dedicated
Apache Web Server is used for this purpose. The CMS interface is exposed via the
HTTPS protocol, which uses a Server Certificate in order to both identify the CMS Server
as a trusted server and to encrypt information exchanges between the CMS Client and the
CMS Server.
If the site includes a domain controller (such as with the SecurityST product) then the
default certificate used by the CMS Server (self-signed) should be replaced by one
issued by the site domain controller. CMS Clients in the domain will trust the
certificate automatically instead of asking the users to validate the trust of the CMS
Server certificate independently.
If a self-signed CMS Server certificate is used, provide a mechanism for users to
verify the correct server is being contacted before marking the CMS Server as
trusted.
The CMS Server certificate may be placed into the client computer's Machine
Store so that each individual user does not need to validate the certificate
independently.

Port Proto- Serv- Description
col ice
443 TCP httpd CMS Server Web Interface (Apache)

Maintain the CMS Server Web Server Certificate, renewing as needed.
For each repository, define each user's authorized level of access.
Do not modify the Apache Web Server configuration to enable additional software
modules or functions.

6 WorkstationST Product
A WorkstationST OPC DA Server is available to respond to client requests for both
reading and writing variables. The Microsoft DCOM subsystem is used to authenticate
access to the OPC DA Server.
Make sure the DCOM security settings for the WorkstationST OPC DA Server match
the site requirements for access.
A WorkstationST OPC DA Client is available to communicate with other control systems
and devices. The WorkstationST OPC DA Client has the ability to run using a configured
set of credentials when establishing the connection, or run in an open mode where no
credentials are required.
The WorkstationST OPC DA Client should always be configured to use a set of

credentials (DCOM Impersonation) in establishing connections with an OPC DA
Server if the OPC DA Server supports that option. A special account should be used
that provides it with only the access that it requires to perform the operations
requested. (For example: Use an account granted ReadOnly access if the
WorkstationST OPC DA Client is only to read information from the other system, not
write it.)
The OPC UA protocol is supported by both WorkstationST Clients and WorkstationST
Servers. The OPC UA protocol typically uses both client and server certificates along
with a certificate trust list to control what clients are allowed to access the servers.
Configure the OPC UA Clients and Servers to require certificate authentication, do

not run in Authentication: None mode unless one endpoint cannot support certificate
based authentication. (The Use Security flag should always be enabled in the
configuration if both ends support certificate authentication.)
Configure the Application level certificates for the OPC UA communications
packages to allow mutual client-server authentication wherever possible.
The WorkstationST OPC UA Server has the ability to map a client certificate to a
local identity via a mapping configured using the ToolboxST application. This then
limits the client's capabilities to those granted to the user via the ToolboxST Users
and Roles subsystem. The OPC UA client should be mapped to a user identity
granted only the rights and privileges required by that OPC UA client. Most sites
require that this be a unique user for accountability purposes.
The WorkstationST subsystem is configured and downloaded using the ToolboxST
application. This provides the same level of Users and Roles and Download privileges
that are used with Mark VIe controller downloads.
Use the ToolboxST Users and Roles capability to define the set of users that have
download privileges to WorkstationST devices.
WorkstationST Product GEH-6839 Secure Deployment Guide 25

The WorkstationST product uses the current user's Windows identity to control access to
most internal resources. External communications is controlled in many different ways
depending upon the capabilities of the protocols involved as well as the capabilities of the
client or server on the other end of the communication link.
The OPC DA subsystem uses the Microsoft DCOM layer for access control, which
can be configured to restrict access to only the anticipated client accounts, or supply
a set of credentials to servers so that the WorkstationST client can be authenticated.
The OPC UA subsystem uses application or user level certificates to authenticate
users. Mapping certificates to Windows Users provides the ability to use the
ToolboxST Users and Roles subsystem to control what the remote client is allowed
to do, or to provide an identity to a remote server so that it can control what the
WorkstationST client can do.
Protocols that do not support native authentication can use additional firewalls to
limit the clients that are allowed to connect, or use IPsec to provide better control
over the clients that can connect as well as the ability to encrypt the communication.
The ACLs on the locations where WorkstationST stores its own configurations
(default is C:\Config) should not be changed unless it is to strengthen them to meet
site requirements.
The ACLs on the locations where WorkstationST stores its runtime data (Alarms,
Recorder, Historian configuration files) should not be changed unless it is to
strengthen them to meet site requirements.
If sharenames are created to expose WorkstationST runtime data to other
computers (such as Trip Logs), the ACLs on the sharenames should provide only
Read access.

Computers running the WorkstationST application are typically connected directly to the
networks that contain the controllers that it is monitoring. For most applications this
means the Unit Data Highway (UDH). WorkstationST Servers can be used to feed
information to other WorkstationST clients in which case the need for the direct network
connection are not required. (Examples of this include Alarm Viewer clients viewing
information from Alarm Servers, or WorkstationST computers configured to get
information from the WorkstationST service running on another computer by proxy.)
If a Workstation is to receive EGD messages from a controller that does not share
any networks with the workstation (such as a workstation in the MDH) then the
"Enable Routing" option must be enabled in the WorkstationST configuration.
If a Workstation is obtaining information from another Workstation "by proxy" or via
a client attached to the other Workstation's server, the information should be routed
over the PDH instead of the UDH (on a dual network system).
The WorkstationST application provides many servers to provide information to other
computers, and clients to be able to access information on other computers. These data
interfaces can cause significant message traffic, especially during the initial connection
period. These exchanges should not be done over a critical control network (such as the
UDH) unless there is no other option.
When the WorkstationST application acts as a client or a server to other computers,

the communication should not be routed over critical control networks (such as the
UDH) unless there is no other viable option.

The WorkstationST application is configured by modifying the configuration in
ToolboxST and then downloading it to the WorkstationST application. This download can
be from the same device or from a different device. If this is a different device the
download should be done via the PDH to keep the traffic away from the critical control
traffic on the UDH. The ToolboxST download will automatically favor a download over a
Plant network over a Unit network.
In a dual network control zone, make sure the UDH has been defined as a Unit
network and the PDH has been defined as a Plant network in the ToolboxST network
definitions.
6.2.2 Servers
The WorkstationST application is the main real time data interface to the controllers,
providing that data to a variety of clients over a variety of protocols. The protocol support
is typically accomplished by having multiple WorkstationST Server functions and
enabling the Server functions that are required for the site. Each Server and Protocol has
different capabilities when it comes to authentication and encryption of data over that
interface.
General Guidelines:
Favor the use of protocols that provide client and server authentication over protocols
that do not.
If a protocol does not provide authentication, consider using additional means
(outside of the protocol) to enhance the security of the client-server connections. This
includes controlling the clients that can connect to the server and adding signatures
and encryption to preserve the integrity and confidentially of the message exchanges.
Refer to the chapter, Security and Secure Deployment for additional information on
protecting unauthenticated protocols.
The following Servers are included in the WorkstationST package.
A WorkstationST Modbus Server is included, which can accept client connections via
serial RS-232 or Ethernet connections. The Modbus protocol does not support native
authentication.
A WorkstationST GSM Server option is included which accepts client connections
via Ethernet connections. The GSM protocol does not support native authentication.
A WorkstationST OPC DA Server is included which accepts client connections via
Ethernet connections. The Server uses Microsoft DCOM security to control the
clients that are allowed to connect.
A WorkstationST OPC AE Server option is included which accepts client
connections via Ethernet connections.
A WorkstationST OPC UA Server option is included which accepts client
connections via Ethernet connections. The Server can be configured to use
Authenticated users via certificates, and can map user certificates to local user
accounts to provide control over what actions the user is allowed to perform.
A WorkstationST FOUNDATION Fieldbus gateway option is included in the Device
Manager Gateway. The FOUNDATION Fieldbus gateway does not support native
authentication.
A WorkstationST HART gateway option is include in the Device Manager Gateway.
The HART gateway does not support native authentication.
A WorkstationST Profibus gateway option is included in the Device Manager
Gateway. The Profibus gateway does not support native authentication.
A WorkstationST NTP Server is included. The NTP protocol does not support native
authentication.

A WorkstationST Acoustic Monitor Gateway Server option is included. The Acoustic
Monitor Gateway server protocol supplies data without authentication, and uses a
Web Server interface that perfoms challenge-response authentication to access
components that can make changes.
A WorkstationST Alarm Server option is included which supplies alarm information
and accepts alarm commands from the WorkstationST Alarm Viewer (client). The
WorkstationST Alarm Viewer uses the Windows identity to authenticate users and the
Users and Roles information to authorize actions.
A WorkstationST Network Monitor Server option is included which provides
network status information to the Network Monitor Viewer (client). The network
monitor protocol is ReadOnly and does not support native authentication.
A WorkstationST Control System Health Server option is included which provides
network status information to the Control System Health Viewer (client). The Viewer
uses OPC UA for communication with the server which supports using certificates
for application authentication.
A WorkstationST SDB Server option is available and used for communicating Mark
VI configuration information (including EGD page definitions) between the Mark VI
Toolbox programming environment and the Mark VIe ToolboxST programming
environment. The SDB Server protocol does not support native authentication.
A WorkstationST EGD Configuration Server option is available to hold EGD page
definitions, allowing configuration changes while devices are not online. The EGD
Configuration Server protocol does not support native authentication.
A WorkstationST SDI Server is included for communication between the
WorkstationST Server and client applications, and is also used to download
configurations to the WorkstationST device. The SDI protocol in the WorkstationST
Server does not support native authentication.
The WorkstationST OPC DA Server includes an EGD receiver to receive and process
inbound EGD message traffic (data and commands). The EGD protocol does not
support native authentication.
A WorkstationST Web Server option is available to view certain information and
reports (real time and historical). The default configurations of the Web Server do not
require user authentication, but the reports are all ReadOnly. Authentication using the
user's Windows identity can be configured at the Web Server level.

37 TCP NTP Network Time Protocol, for time management
80 TCP HTTP Web Server for WorkstationST Web pages (option)
123 UDP ntpd Network Time Protocol (time management, broadcasts)
123 TCP NTP Network Time Protocol (time management, unicasts)
GeCssModbus, WorkstationST MODBUS server, port can be defined in configuration

502 TCP
GeCssTciModbus (option)
WorkstationST GE Standard Messaging server, port can be defined in

768 TCP GeCssGSM, GeCssTciGSM
configuration (option)
Used by OSM and Historian Interfaces to read real time data from
770 TCP WorkstationST
WorkstationST
1616 TCP GeCssAmGateway WorkstationST Acoustic Monitor Server (option)
3683--
TCP Used by eTCSS, Toolbox application
3685
4840 TCP Opc.Ua.DiscoveryServer OPC UA Discovery Service
5150 TCP SDB SDB Server (for Mark VI and other legacy device configurations)
5310--
TCP GE SDI WorkstationST SDI Server Interfaces
5312
GeCssControlSystem
7050 TCP WorkstationST Control System Health Alarm Server
Helath
7070 TCP GE Alarm Receiver interface
7071 TCP GE Interface with local CIMPLICITY External Alarm Manager
7072 TCP GeCssAlarmServer WorkstationST Alarm Server

7073 TCP GeCssAlarmServer WorkstationST Alarm Server
7074 TCP GeCssTciAlmRcv WorkstationST Mark V Feature Alarm Receiver
GeCssControlSystem
7077 TCP WorkstationST Network Monitor Server (overview data)
Health
GeCssControlSystem
7078 TCP WorkstationST Network Monitor Server (alarm)
Health
GeCssControlSystem
7079 TCP WorkstationST Network Monitor Server (detail data)
Health
7080 TCP GE HART Message Server WorkstationST HART Message Server (status)
GeCssDeviceManager WorkstationST Device Manager Gateway

7081 TCP
Gateway HART Status
GeCssDeviceManager WorkstationST Device Manager Gateway

7084 TCP
Gateway HART DTM
GeCssDeviceManager
7085 TCP WorkstationST Device Manager Gateway Profibus Status
Gateway
GeCssDeviceManager
7086 TCP WorkstationST Device Manager Gateway
Gateway

WorkstationST Device Manager Gateway FOUNDATION Fieldbus
7087 TCP GeCssDeviceManager
DTM Status
GeCssDeviceManager
7090 TCP WorkstationST Device Manager Gateway Status
Gateway
GeCssDeviceManager
7091 TCP WorkstationST Device Manager Gateway FOUNDATION Fieldbus DTM
Gateway
7937 UDP GeCssOpcServer WorkstationST EGD CMP Server

GeCssOpcUAServer,
7937 TCP WorkstationST Device EGD Configuration and Live Data (shared)
GeCssOpcServer
7938 UDP GeCssAlarmServer WorkstationST Alarm Protocol (ALM)
7938 TCP EgdCfgServer WorkstationST EGD Configuration Server
11020 TCP GeCssAmGateway WorkstationST Acoustic Monitor Server (option)
18246 UDP GeCssOpcServer WorkstationST EGD Receiver (OPC DA Server)
18310 UDP GE WorkstationST Inter-process Communication

Do not enable optional server subsystems (MODBUS, GSM, OPC, Device Manager
Gateway) unless they are required.
Use a redundant cascaded Client-Server architecture to prevent overloading
controllers due to too many WorkstationST computers asking for data. For example:
Set up two WorkstationST computers to act as alarm servers and configure all other
WorkstationST computers to retrieve alarm information from them instead of from
each controller directly.
Use Users and Roles to control access and ability to download WorkstationST
configurations.
Prefer OPC UA interfaces over other interfaces that do not provide for
authentication.
Use firewalls or IPsec to protect communication protocols that do not support
authentication or encryption when that capability is required.
Use and manage certificates for the OPC UA interfaces (dont use open or
Authentication: None mode).
Be aware of client-server connections that cross network boundaries as potential
security risks. Pay particular attention to any client-server connection that crosses the
Electronic Security Perimeter. Additional protocol-aware firewalls that examine
individual requests within a protocol are recommended when protocols that can
impact site operation must cross these boundaries.
Protect communication interface servers with reasonable timeout, connection, and
rate limits to help prevent overloading servers with client connections.
Set a reasonable SDI connection limit to limit the number of clients that can
connect to the WorkstationST OPC DA server.
Set a reasonable WorkstationST Maximum Client Rate to limit the maximum
rate at which OPC clients can request information updates from the
WorkstationST OPC DA Server.
Set a reasonable OPC UA connection limit to limit the number of clients that can
connect to the WorkstationST OPC UA server.

Notes

7 HMI Product
7.1 Overview
The HMI product is a separate product with its own documentation set. This section
focuses on features available in the HMI that can be used to improve the security posture
of the Mark VIe Controller, its ToolboxST programming environment, and the
NetworkST networking equipment.

The Mark VIe programming and runtime environment tools all use Windows user
authentication as their basis for determining the access levels and privileges assigned to a
user.
Individual accounts should be created to be able to grant only the rights and
privileges required by the user or users of that account. In many cases, site security
policy will require that the accounts be on a per-user basis for accountability.
Use the Users and Roles feature of the ToolboxST application to assign users to
Roles and then assign only the privileges that Role requires.

While the ToolboxST application can assign distinct privileges to the users and roles
defined, that is a cooperative scheme where access is controlled by the tool. The
Windows Operating System supports authoritative control through the use of ACLs
(Access Control Lists) on the files. The storage location for controller configuration files
is typically assigned the following access control list:
The Operators group is given READ access so that the go to code function can be
used to view the sequencing or logic tree that generated an alarm.
The Maintenance group is given MODIFY access so that they can make changes to
the configuration files.
The Administrators group is given FULL access for system management operations.
Use of an administrator level account for normal maintenance activity should be
discouraged.
Do not alter the default ACLs used to protect the controller configuration files unless
it is to strengthen them to meet site requirements.
ACLs should be granted on the basis of group membership to prevent having to
modify the ACLs on all resources when changes need to be made to the access level
of a user. By assigning access rights to a group the change can be made in one
location by adding or removing the user from the group, the ACLs on the individual
files or directories does not have to be changed.
HMI Product GEH-6839 Secure Deployment Guide 33

Sites that include a SecurityST system use the exact same HMI access control lists with
no modifications required because the SecurityST system automatically adds the domain
groups to the local groups. HMIs can be added and removed from the domain without
having to redefine the local access control lists.
The domain HMI Operators group is added to the local Operators group.
The domain HMI Maintenance group is added to the local Maintenance group.
The domain HMI Administrators group is added to the local Administrators group.

The HMI or Engineering Workstation is typically connected to the UDH to access
controllers, and to the PDH to access other computer-to-computer services (such as the
EGD Configuration Server and the CMS Server).
Follow the rules in the NetworkST section when configuring the HMI network
adapters, with a special emphasis on the protocol bindings allowed on the UDH.
A Default Gateway can be defined for the HMI if it requires communications with
devices outside of the PDH and UDH.
Do not define a Default Gateway unless this HMI is required to communicate with
devices off of the networks that it is connected to (UDH and PDH).
If a Default Gateway is defined it should be a router with access control rules that
allow only required communications.
If a Default Gateway is defined it should be located on the PDH, not the UDH. (The
NetworkST 4.x architecture defines a default gateway address on the UDH and on
the PDH, the PDH address should always be used in the HMI.)
Do not change the network bindings away from the standards defined in the
NetworkST section of this document.

The supervisory level computers (HMI, Engineering Workstation, Historian) are typically
configured for unattended operation. Upon restoration of power, the computer will
automatically boot with no user action required and restart normal operation. This mode
of operation precludes the use of any BIOS level password or full disk encryption
software that requires a person to enter a password during the boot process.
Physical access to the computer should be controlled, as it allows a user to potentially

boot from other media (such as a CD Drive or USB drive) and make uncontrolled
changes to the computer configuration or disk files.
If considering adding a BIOS level password to prevent users from altering the boot
device, explore its impact on unattended operation.
If full disk encryption is a site requirement, consider options for its implementation
and the impact each will have on unattended operation and disaster recovery
procedures.
The user's logon credentials and account are used by many subsystems to control access
to resources and actions. In general users should have their own accounts so that they can
be given only the access they require to various resources and certificates. Many sites
require individual user accounts for action accountability and change management control
and reporting.
Update the password policies on computers to match the site requirements for
passwords. Consider a SecurityST system if the password requirements are above and
beyond what can be enforced by a stand-alone Windows Operating System.
Make sure to remove all generic as shipped passwords as part of the commissioning
of the system.
Do not modify the ACLs on the HMI resources unless it is to strengthen them to meet
site requirements. This is especially important for controller configuration and CMS
related directories.
When dealing with multiple computers (Engineering Workstations, HMIs,
Historians) consider purchasing a SecurityST system to provide a single point
location for user and rights management.
If using a SecurityST system, make sure to define local accounts for Emergency use.
(Refer to the section, SecurityST Product for additional information.)
Use the SecurityST Group Policies to harden the HMI configurations, also available
to be applied to non-domain computers as a GPOPack in the GE DS226CHP
Computer Hardening Procedure product.
Computers are often configured to include sharenames, a named resource that allows
external access to the directories and files on the computer from other computers.
If any sharenames are created, set the access control lists on the sharenames
independently from the access control lists on the directories and files accessed via
the sharenames.
Sharename access control lists can (and often should) be more restrictive than the
ACLs on the files that it exposes, allowing the same user ReadOnly access via the
Sharename (remotely) but ReadWrite access if accessed locally.
Exercise extreme caution if any sharenames are exposed outside of the computer's
native networking zone. Additional firewalls and protection should be considered,
and a double hop through a DMZ based computer is recommended.
HMI Product GEH-6839 Secure Deployment Guide 35

Notes

8 NetworkST Product
The controllers and supervisory level computers covered in this document
were not designed for or intended to be connected directly to any wide area
network, including but not limited to a corporate network or the Internet at
large. Additional routers and firewalls (such as supplied with the NetworkST
4.0 option) that have been configured with access rules customized to the
site's specific needs must be used to access devices described in this
document from outside the local control networks.
8.1 Overview
The NetworkST architecture (NetworkST 3.1) provides a standard set of predefined
networks along with redundant sets of switches that implement those networks. A layered
option (NetworkST 4.0) adds a pair of redundant routers and a Firewall to support
additional communications options, with many sites choosing the firewall to be the
location of their Electronic Security Perimeter. Options are available to place the
management interfaces of the switches and routers onto a separate VLAN.
The most typical configuration includes two networks in the control zone. The Unit Data
Highway (UDH) and the Plant Data Highway (PDH) are separate networks that both
reside in the same control zone. The main difference between the two is that most critical
control messages are transported over the UDH and non-critical traffic is transported over
the PDH. This allows the switches and routers to give a higher priority to the critical
control messages on the UDH over the lower priority traffic on the PDH. Most
supervisory level computers (such as the Engineering Workstations and HMIs) are on
both networks, using the UDH for critical control messages and the PDH for
inter-computer communications (such as file sharing or historical data lookups).
The addition of the (optional, NetworkST 4.0) routers and firewalls allows for the
creation of additional networks with controlled access to the UDH and PDH. In typical
configurations this includes a Monitoring Data Highway (MDH) and one or more DMZ
style networks that can be used for Enterprise level access, remote access, or other
controlled access to meet the site requirements. These networks provide a
defense-in-depth approach where device communications must pass through both the
firewall and the routers to get to equipment in the control zone. Separate firewall and
router rules can be added to provide each additional network only the communications
capability required to meet site requirements. It is not uncommon for additional networks
outside of the firewall to be created for different device classes, such as for networked
printers or interfaces to higher level DCS systems.
The management interfaces of the network switches and routers can be exposed on a
separate Management VLAN (MGH) to isolate and control administrative access. In the
standard configurations all access to the MGH is controlled through access rules in the
router, no supervisory level devices are placed directly on the MGH. In addition, the
switches and routers have standard access control lists that allow management
communication from a limited number of addresses. The firewall is not placed on the
MGH to preserve the defense-in-depth protection provided by the routers in case the
firewall itself is compromised.
NetworkST Product GEH-6839 Secure Deployment Guide 37

Extreme care should be taken when modifying the access control rules in the routers and
the firewall as these devices are critical to blocking unauthorized network traffic. The
security ramifications of changes should be carefully reviewed against the site's policies
before implementing. Most changes to allow external access will require changes in both
the firewall and the router, but don't blindly apply the same access rules to both - treat the
two as separate control points and determine/apply the appropriate rules to each. Be
especially vigilant when creating rules that allow access to any device in the control zone,
with preference given to designs that provide data externally from non-control zones
(such as a computer in the MDH or the DMZ).

Switches and routers ship with only one set of credentials defined - a single local
administrative level account. This account is not used for normal operations, it is only
required for switch maintenance or advanced diagnostics.
Follow normal password policies when defining the local administrative level
password, and only expose the password to people with the need for it.
When a SecurityST system is present it provides a RADIUS server that is used for
authenticating individual users for switch and router administrative level access. When
the RADIUS server is detected the switches and routers no longer accept login via the
local administrative account, domain credentials (username and password) are used to
authenticate individual users. Users who are a member of the Network Administrators
group are granted administrator level access.
Do not bypass using the RADIUS server for authentication, as this preserves a single
point for authentication (Active Directory user account) and authorization
(membership in Network Administrators), and provides a unique user identity for
logging access.
Physical access to the switches should be controlled to prevent disconnecting the
switches from the domain controller and therefore bypassing the RADIUS
authentication. (When disconnected the local administrative account is automatically
enabled.)
The firewall is not placed on the Management VLAN and it does not use RADIUS
authentication. This enables isolation of the firewall from the MGH and the RADIUS
Servers running on the Domain Controllers such that a compromise of the firewall does
not grant unfettered access to these resources. A local administrative level account is
created internal to the firewall for management level access.
Follow normal password policies when defining the firewall's local administrative
level password, and control the distribution of the password to those with an
approved need.
Do not reconfigure the networks to place the firewall on the Management VLAN or
any control network (UDH, PDH) unless that is a specific site requirement.
Consider using the two factor authentication methods provided by the firewall to
control access through the firewall.

Access to the management interfaces of the switches (including the built-in console port)
will provide information about the switch configurations, and potentially the ability to
modify the configuration. Care should be used in granting administrative access to the
switches and routers.
Physical access to the networking equipment should be controlled, as it would allow

for altering the authentication method and also allows access to any emergency
switch recovery procedures provided by the manufacturer.
The network switches provide a set of switch ports that are mapped to a single network
(such as the UDH, PDH, or MDH) for use with devices that need access to that network.
A separate set of trunk ports are provided for network-equipment to network-equipment
connections (switch-to-switch or switch-to-router) which transport all the VLANs over a
single trunk connection. The configuration in the switch determines which ports are
mapped to which network and which are trunk ports. The standard is to ship with all ports
enabled.
Physical access to the networking equipment should be controlled, as it allows for

connecting unapproved devices to the networks.
If the site requires blocking access to unused ports, consider using either a physical
port lock device or altering the configuration to disable unused ports.
Network access control using 802.1X authentication is not include in the standard
switch configurations. Sites may consider adding it to the switch configurations, but
be aware that it may conflict with the network teaming used for network redundancy
by supervisory level computers (HMI, Engineering Workstation, Historian...).
Do not bridge any networks via interconnecting ports from different networks on the
switch. All network-to-network communication should pass through the routers for
controlled access.
Consider using one-time-password in the firewall for authenticating remote access
through the firewall.
If there are different levels of network access required through the firewall, consider
defining multiple different DMZ style networks with independent rules instead of
using (larger) targeted rules on a single network. This has the benefit of helping to
protect against network address spoofing.
The network switches provide additional features and settings that can address
spoofing concerns such as MAC or IP address spoofing and ARP poisoning. Sites
that choose to implement these features must address the impact on network teaming
used for network redundancy by supervisory level computers.
The network switches and routers ship with a default set of access control lists to limit
access to the management functions in the switch (SSH and SNMP). These are
coordinated with the rules in the routers to limit access to the management functions even
if the routers have been compromised.
Do not change the access control lists for the network equipment management
functions unless mandated by the site requirements.
The default set of router rules and access control lists provide for management access
by the main Engineering Workstation (EWS1_SVR) and the SecurityST primary
Application Server (AP1). Specifying two locations provide redundancy and
diagnostic capability in case of a single point of failure. If a site does not provide
both, the unused address can be removed from the access lists and router rules.

The use of a separate Management VLAN (MGH) for the administrative interface for the
network switches and routers is an industry standard practice that should be implemented
wherever feasible.
Do not remove the access control lists on management functions from the switches as
this helps prevent compromise if the MGH network is breached. Modify the access
control lists if the site requirements are not met by the as-shipped configurations,
don't remove them.
Do not place the firewall on the MGH as a compromise of the firewall would grant
unfettered access to the MGH and potentially all networks in the plant. All access
through the firewall should also have to go through the routers before landing on any
control or management network.
Do not add physical ports on the MGH network, access to the MGH should be
through devices on the PDH routing through the routers to the MGH. Add additional
router rules to permit only the required access from those devices to the MGH and
the devices on the MGH. (Devices on the PDH should require both router rules and
access control lists on the target device to reach management interfaces on the
network switches and routers.)

The network control zone typically includes both the UDH and PDH network, with UDH
critical control traffic being prioritized in the switches and routers over non-critical PDH
computer-to-computer traffic. (Some sites use a single network in the control zone, in
which case the following recommendations do not apply.)
All computers on the UDH (Engineering Workstations, HMIs, Historians) should

set the UDH adapter network bindings to include only the following protocols:
QoS Packet Scheduler
Internet Protocol Version 4 (TCP/IPv4)
The PDH network adapter bindings should typically set to:
Client for Microsoft Networks
QoS Packet Scheduler
File and Printer Sharing for Microsoft Networks
The following network adapter bindings should not be included for the UDH or the
PDH. (Site requirements may override the PDH recommendations, but should not
override the UDH recommendations.)
Link-Layer Topology Discovery Mapper I/O Driver
Link-Layer Topology Discovery Responder
There should be no computers connected directly to the Management VLAN (MGH).
All computer access to the MGH should be from computers connected to the PDH
and routed through the router using rules that limit access to only what is required.
The default gateway for all networking equipment (if required) should always be to
the router which provides rules to allow only approved access.

The firewall used for external access (sometimes chosen to be the electronic security
perimeter) supports connections to the redundant routers via the External Data Highway
(XDH). The XDH is an extremely limited network consisting only of a special XDH
switch which connects the firewall to a pair of redundant routers.
No additional devices should ever be placed on the XDH network.

The firewall should only be connected to the routers, with all traffic through the
firewall required to go through the routers before accessing any control or
management network.
Unless site requirements specifically require it, access to the management VLAN
(MGH) through the firewall should not be allowed.
The firewall supports multiple DMZ style networks. If there are requirements for
different levels of access from different sources consider using multiple networks
with rules specific for each network instead of using specific address based rules
within one network.
8.3.2 Servers
The network switches and routers support a set of servers to provide for management
functions. These servers are shipped with access control lists that limit access to the
server functions.
A Secure Shell (SSH) server is include to support administrative access for maintenance
and diagnostic activity. Access to the SSH server is controlled through an access control
list. Each server is configured with a unique server certificate to use for the secure
connection and to verify the identity of the device.
SSH clients making connections to the network equipment should verify the public
key signature of the device against a list of trusted devices. Users should be warned
not to provide logon credentials to devices that are not trusted. A method of updating
the trusted device list should be established to cover new or replaced devices.
The access control list for the SSH server should not be removed, if a site has
additional requirements they should be added to the existing access control list.
A Simple Network Monitoring Protocol (SNMP) server is included to support network
monitoring (Control System Health) functions. These functions retrieve switch
operational data (read only) to display conditions or alert on anomalies.
The access control list for the SNMP server should not be removed, if a site has
additional requirements they should be added to the existing access control list.
The SNMP protocol uses a community string to control access within the protocol
requests. The network equipment should only ever define a "read only" community
string, never define a community string with write access.
Maintain the community string according to the sites password policy for background
applications or service accounts - or (because this is read only) determine a specific
maintenance procedure.

The firewall provides an SSH interface, but it is only used to retrieve the configuration.
Management activity is done through an HTTPS interface.
If running in a SecurityST environment, provide the firewall with a domain signed

certificate so that connections to its HTTPS interface are trusted. Users should be
warned not to provide logon credentials to devices that are not trusted. A method of
updating the HTTPS certificate should be established to cover new or replaced
devices. If running outside of a domain environment a method should be provided to
mark the certificate as trusted. Due to the limited access to this management
interface, this may be as simple as adding the device certificate to the machine store
of the (limited) devices that must connect to it (typically only EWS1 and AP1).
The firewall ships with a single local administrative level account used in both the
SSH and HTTPS interfaces. This password should be maintained with limited
distribution according to the site password policies. Additional accounts can be
created (with reduced privileges) to meet the needs of specific site procedures. These
requirement may vary depending upon the individual site requirements for
controlling access from the (potentially multiple) networks that it supports.
The firewall supports various options for VPN type access. Some of these options include
support for two factor authentication. If implementing these access methods consider
using one of the two factor options available to increase access security.

Secure Shell for management operations (switches, routers,
22 TCP SSH
firewall)
161 UDP SNMP SNMP server for condition monitoring (switches, routers)
443 TCP HTTPS Management operations (firewall)

Maintain switch passwords according to site policy. Complexity and reuse rules are
not enforced by the equipment, they must be addressed procedurally.
Do not disable the access control lists on management functions - augment them if
site requirements are not met with the as-shipped configurations.
If a site SIEM is in use, configure the network equipment to log to the SIEM.
Consider disabling unused ports via either physical port locks or changes to the
equipment configuration.
Maintain the SNMP community strings as you would a password. Do not create a
community string that provides for write access.
Make sure to remove all as shipped passwords and community strings as part of the
commissioning of the system.
8.5 Additional Recommendations

Make sure to maintain backup copies of the network equipment configurations. If a
SecurityST system is present at the site, use its AP1 CatTools application to both maintain
backups and alert on configuration changes.

9 SecurityST Product
9.1 Overview
The SecurityST product is a separate product with its own documentation set. This
section focuses on features available in SecurityST that can be used to improve the
security posture of the Mark VIe Controller, its ToolboxST programming environment,
and the NetworkST networking equipment.

The SecurityST product provides user authentication and authorization mechanisms that
are used by many different subsystems. In some cases the subsystem provided by
SecurityST are required in order to achieve the higher security options, in others it
provides centralized management for things that can be accomplished (just not as easily)
without the SecurityST product.
The SecurityST product provides the Active Directory subsystem that creates a
computer domain allowing centralized management of user accounts and access
rights. Users accounts maintained on the domain controllers are available for logging
into each HMI or Engineering Workstation. Without the centralized management
individual accounts on each HMI must be maintained if individual user accounts are
used.
The SecurityST product provides the RADIUS server used by the networking
equipment (switches and routers) to determine if users are to be granted
administrative access. Without the RADIUS server only the local switch
administrative account is available. If individual accounting of users is required then
each piece of networking equipment must be configured with each user account.
The SecurityST product provides the Certificate Authority (including an MSCEP
server) which is required to put a Mark VIe controller into Secure Mode. Without the
Certificate Authority the Mark VIe controller cannot enter Secure Mode.
The SecurityST product provides the Certificate Authority which (in conjunction
with Active Directory user accounts) provides users with certificates used for secure
communications between the user's ToolboxST application and the controller.
Without the Certificate Authority only unsecured connections are available.
The SecurityST product provides the Certificate Authority which issues certificates
to various optional devices and servers to identify them as trusted. Without the
Certificate Authority, other mechanisms must be put into place to identify these
components (such as the External Firewall, SIEM, Whitelisting application) as
trusted. (For web applications this includes the HTTPS certificates that identify the
site as being trusted.)
The SecurityST product includes an LDAP server used to authenticate (credential)
and authorize (group membership) access to the SIEM. Without the LDAP server
individual local accounts would need to be maintained.
SecurityST Product GEH-6839 Secure Deployment Guide 43

The SecurityST product provides subsystems that are used to coordinate and control
access to various portions of the system. It has the advantage that it provides a centralized
location for making changes and a method to them push those changes out to the devices.
The SecurityST product provides the Group Policy subsystem that is used to define
and push a set of operating system and application settings out to the various
computers in the domain. These Group Policies configure many settings including
user and password management, network access, and encryption requirements, as
well as hardening policies that disable unused and unwanted services and windows
components. Without the Group Policy subsystem these changes have to be
maintained on each computer individually.
The SecurityST product provides a password policy component that extends the
Windows Operating System capabilities while providing more comprehensive
information to users attempting to meet these policies. Without this password
management system enforcement of the policies needs to be done procedurally.

The SecurityST product provides many benefits that enhance security. The following are
general recommendations when using a SecurityST system and how it relates to the Mark
VIe controller, its programming environment, and the HMIs.
Use the SecurityST Domain Controllers for all user account management, keeping
local accounts only for emergency conditions (domain down for more than 30 days).
Do not distribute the local passwords outside of emergency conditions, and reset the
local account passwords after the emergency period is over.
Use SecurityST Domain Users identities when configuring the Users and Roles and
CMS Administration capabilities.
Use the SecurityST password policy subsystem to enforce site requirements for
password management.
Use the SecurityST RADIUS server to authenticate users to network equipment
(switches and routers). Add users who require administrative access to the Network
Administrators group.
Use the SecurityST AP1 CatTools application for network equipment configuration
backup and change notification.
Use the SecurityST AP1 SIEM as the syslog server for network equipment and
controllers.
Use the SecurityST AP1 Patching subsystem to keep computer software current
(especially with respect to Security updates).
Use the SecurityST AP1 Anti-virus subsystem to protect all computers.
Use the SecurityST AP1 Backup subsystem to protect all computers, including the
Engineering Workstations, HMIs, and CMS Server.
Use the SecurityST Group Policies to enforce hardening policies on computers that
have joined the domain.

Sites with a SecurityST system but without the NetworkST 4.x (typically limited to
SecurityST V1.x system) should place only the AP2 (SIEM) and AP3 (Certificate
Authority) computers on the UDH.
Sites with a SecurityST system with NetworkST 4.x should place only the AP3
(Certificate Authority) computer on the UDH. Access to AP2 (SIEM) by UDH based
controllers is accomplished via the routers, which requires defining the router as the
default gateway in the controller.
SecurityST Product GEH-6839 Secure Deployment Guide 45

Notes

Glossary
Certificate Authority A server that provides certificates (and Certificate Revocation
Lists) for identifying users and devices.
DCOM Distributed Component Object Model, a Microsoft concept and protocol for
communicating between programs running on different computers.
Domain Controller A server that provides identity management functions. It holds a

database of the users defined and the groups that those users are members of that are used
to control user access to various resources.
DMZ Demilitarized Zone, a network that is separated from the Control and Monitoring
zones by both the routers and the firewall that is often used for locating computers that
serve plant information to entities outside of the electronic security perimeter.
EGD Protocol Ethernet Global Data, a UDP based protocol used to communicate
between devices. It is used for real time data and commands.
Electronic Security Perimeter An arbitrary boundary between sets of devices that

usually indicates a certain trust level of the devices. Communication traffic that crosses
the Electronic Security Perimeter is typically heavily restricted to prevent external
components from being able to compromise internal devices by the use of a firewall
and/or router.
Firewall A device that connects between multiple networks in order to limit the types
of traffic that are allowed to flow between the networks.
GPO Group Policy Object, a collection of operating system settings that are applied to
computers to configure items such as security settings or disabling unused services.
GPOPack Group Policy Object Pack, a mechanism for being able to apply a set of
Group Policy settings to computers that are not joined to domain. It decodes the objective
of the Group Policy settings and applies them (as best it can) as either direct operating
settings or local policy settings.
LDAP Lightweight Directory Access Protocol, a protocol that allows software to

authenticate users and determine group membership.
Mark VIe Controller A general purpose controller device.
MDH Management Data Highway, a network that contains devices that need to monitor
but not control. Traffic from the Monitoring Zone (MDH) to the Control Zone (PDH and
UDH) must go through a router with access lists that limit the allowed traffic.
MGH Management VLAN, a network that is used for the management interface for
networking equipment (routers and switches). Traffic from the Management VLAN
(MGH) to the Control Zone (PDH) must go through a router with access lists that limit
the allowed traffic.
Modbus A protocol used to transfer real time data between systems.
MSCEP Microsoft Simple Certificate Enrollment Protocol, a protocol that allows

devices that have not joined the domain to obtain domain certificates. Certificate
Authorities provide MSCEP servers.
OPC Open Platform Communications, a set of standards and protocols used for
communication between programs, typically running on different computers.
GEH-6839 Glossary of Terms 47

PDH Plant Data Highway, a network that is used to transport non-critical information
within the Control Zone. Traffic to the Control Zone (PDH and UDH) from outside the
Control Zone must go through a router with access lists that limit the allowed traffic.
RADIUS Remote Authentication Dial-In User Service, a protocol originally created for
authenticating dial-up users, now used to authenticate users from many different types of
devices that are not joined into the domain. Domain Controllers provide RADIUS servers.
SDI Protocol A TCP based protocol used to communicate between devices. It is used
for configuration information as well as real time data and commands.
SIEM Security Information and Event Management, a server that collects event
messages from various other subsystems to provide a central location for analyzing and
viewing these events.
Router (Network) A networking device that is typically connected to multiple

different networks with rules that define what message traffic is allowed to cross from one
network to a different network.
Switch (Network) A networking device that connects multiple devices together to

form an Ethernet Network.
UDH Unit Data Highway, a network that is used to transport critical control
information within the Control Zone. Traffic to the Control Zone (PDH and UDH) from
outside the Control Zone must go through a router with access lists that limit the allowed
traffic.
VLAN Virtual Local Area Network (LAN), a mechanism for logically connecting
multiple devices into one network within a switch or router. Networking equipment
typically support multiple different VLANs within a single switch to provide isolation of
network segments within a single switch. VLANs include the UDH, PDH, MDH, MGH,
and DMZ.
48 Mark VIe Control System Secure Deployment Guide


Geh 6839

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Geh 6839

Diunggah oleh

Hak Cipta:

Format Tersedia

GEH-6839

Mark* VIe Control Systems

For public disclosure

Issued: Dec 2015

Copyright 2015 General Electric Company, All rights reserved.

We would appreciate your feedback about our documentation.

For public disclosure

GEH-6839 Secure Deployment Guide 3

4 GEH-6839 Mark VIe Control System Secure Deployment Guide

GEH-6839 Secure Deployment Guide 5

6 GEH-6839 Mark VIe Control System Secure Deployment Guide

Introduction GEH-6839 Secure Deployment Guide 7

8 GEH-6839 Mark VIe Control System Secure Deployment Guide

2.1 What is Security?

2.2 I have a firewall. Isnt that enough?

2.3 What is Defense in Depth?

Security and Secure Deployment GEH-6839 Secure Deployment Guide 9

Example: The Microsoft Windows Operating System typically defines a username

Example: The Microsoft Windows Operating System supports multiple levels of

Example: The Microsoft Windows Operating System supports the concept of

10 GEH-6839 Mark VIe Control System Secure Deployment Guide

2.5 What is Hardening?

Disable unused Servers and Services on each device.

Security and Secure Deployment GEH-6839 Secure Deployment Guide 11

Consider using a dedicated point-to-point link instead of a shared network for

12 GEH-6839 Mark VIe Control System Secure Deployment Guide

Security and Secure Deployment GEH-6839 Secure Deployment Guide 13

14 GEH-6839 Mark VIe Control System Secure Deployment Guide

Mark VIe Controller Family GEH-6839 Secure Deployment Guide 15

3.1.2 Access Control Mechanisms

3.1.3 Modes of Operation

The local administrative account is disabled.

16 GEH-6839 Mark VIe Control System Secure Deployment Guide

Do not add non-Mark VIe controllers or I/O devices to an IONet, including

Do not enable the OPC UA Server unless it is required.

Do not enable the MODBUS server unless it is required.

Do not enable the Web Server unless it is required.

Mark VIe Controller Family GEH-6839 Secure Deployment Guide 17

3.2.4 Ports and Services List

80 TCP HTTP Web Server for operational displays. (option)

Network Time Protocol, used for time

MODBUS server for real time data and

4841 TCP OPC UA OPC UA Server (option)

GE Proprietary SDI protocol for system

GE SDI protocol for systems running in Secure

GE ADL protocol used for high speed data

Command Message Protocol (CMP) used to

EGD Configuration Server, used to provide EGD

Ethernet Global Data (EGD) service for

18 GEH-6839 Mark VIe Control System Secure Deployment Guide

Mark VIe Controller Family GEH-6839 Secure Deployment Guide 19

20 GEH-6839 Mark VIe Control System Secure Deployment Guide

4.1.2 Access Control Mechanisms

ToolboxST Product GEH-6839 Secure Deployment Guide 21

4.2.2 Ports and Services

4.3 Configuration Hardening

4.4 Additional Recommendations

22 GEH-6839 Mark VIe Control System Secure Deployment Guide

Do not enable HTTP (unencrypted) access to the CMS Server.

CMS Product GEH-6839 Secure Deployment Guide 23

5.2.3 Ports and Services List

5.3 Configuration Hardening

24 GEH-6839 Mark VIe Control System Secure Deployment Guide