WinCC Open Architecture Security Guideline

Preamble 1
Targets of the Security

Guideline 2
Security Guideline References 3

SIMATIC
WinCC Open Architecture Definitions 4
3.16 FP2 (P009)
Strategy of the Security
Guideline 5
Implementation of the
Security Strategy for 6
Security Solutions
Security Checklist 7
Glossary 8
Lists 9
05/2019
Legal Information
Warning Concept
This manual contains notes that need to be considered, to heed the secure configuration of a plant
and to prevent damage to property.
The notes on security impacts are shown by a warning triangle in different colors or a warning light.
Notes referring to a minor or an improbably security issue have no symbols.
The alerts and warnings are illustrated here in descending order of its level.
DANGER
Means that death or severe security issues will occur, if the corresponding precautions are not
taken.
WARNING
Means that death or severe security issues may occur, if the corresponding precautions are not
taken.
CAUTION
With a warning triangle means that moderate security issues may occur, if the corresponding
precautions are not taken.
ATTENTION
With a grey warning triangle means that an undesirable event or condition may occur if the
corresponding note is not heeded.
CAUTION
Without a warning triangle means that damage to property may occur, if the corresponding
precautions are not taken.
With the occurrence of multiple hazardous levels, the warning for the highest level is used. If a caution
with the warning triangle warns of personal injury, it may also have a warning of damage to property.
ETM professional control GmbH | A Siemens Company 05/2019 Copyright © ETM professional control GmbH |
A Siemens Company A Siemens Company
Marktstraße 3
A-7000 Eisenstadt subject to alterations
7000 Eisenstadt
AUSTRIA
Qualified Staff
The product/system associated with this documentation should be handled only by personnel qualified
for the task. They should handle the tasks assigned to them and paying attention to the associated
documentation, like this document. Qualified persons, based on their training and experience, can
detect risks and avoid possible hazards when handling these products/systems.
Proper Use of ETM professional control GmbH products
Please take note of the following:
WARNING
ETM professional control GmbH products should be used only for the application areas foreseen in
the associated technical documentation. If third party products and components are used, they must
be recommended and/or approved by ETM professional control GmbH. The fault-free and secure
operation of the products assumes proper transport and storage, assembly, installation,
commissioning, operation and maintenance. The permissible ambient conditions must be followed.
Notes (Instructions) in the associated documentation must be seen and followed.
Brands
All names and designations marked with the registered trademark ® are registered brands of the
Siemens AG or affiliated companies like e.g. ETM professional control GmbH. The use of the
registered brands by a third party for their own purposes may infringe the rights of the owner.
Disclaimer
We have checked the contents of the documentation to ensure that they match the hardware and
software described. Nevertheless, deviations cannot be entirely excluded, and we cannot, therefore,
guarantee complete agreement. The information in this documentation is, however, reviewed regularly
and any corrections necessary are incorporated in later editions. Information about the current version
can be found in the page footer.
Page 3 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)

Table of Content
1 PREAMBLE .......................................................................................................................................................................... 7
SCOPE .................................................................................................................................................................................. 7
INTENTION OF THIS DOCUMENT ................................................................................................................................................. 7
DISCLAIMER ........................................................................................................................................................................... 8
1.3.1 License ........................................................................................................................................................................... 8
STRUCTURE AND ORGANIZATION OF THIS DOCUMENT ................................................................................................................... 10
REQUIRED KNOWLEDGE.......................................................................................................................................................... 10
1.5.1 Training center ............................................................................................................................................................ 11
PRODUCTS USED .................................................................................................................................................................. 11
ABBREVIATIONS .................................................................................................................................................................... 13
2 TARGETS OF THE SECURITY GUIDELINE ............................................................................................................................. 16
3 REFERENCES ..................................................................................................................................................................... 17
IEC 62443/ISA99 ............................................................................................................................................................... 17

OTHER STANDARDS AND RULES ................................................................................................................................................ 21
OPERATIONAL GUIDELINES FOR INDUSTRIAL SECURITY ................................................................................................................. 22
4 DEFINITIONS ..................................................................................................................................................................... 23
NAMING SCHEME IN FIGURES AND EXAMPLES ............................................................................................................................. 23

NAMES OF THE NETWORKS IN THE “SECURITY GUIDELINE WINCC OPEN ARCHITECTURE" ................................................................... 24
5 STRATEGY OF THE SECURITY GUIDELINE ........................................................................................................................... 25
SECURITY MANAGEMENT PROCESS .......................................................................................................................................... 26

DEFENSE IN DEPTH................................................................................................................................................................ 29
5.2.1 Defense in Depth concept ............................................................................................................................................ 30
5.2.2 Layers of protection ..................................................................................................................................................... 31
5.2.3 Implement Defense in Depth for different Types of Access ......................................................................................... 34
DIVISION IN SECURITY CELLS .................................................................................................................................................... 37
5.3.1 Process cells and security cells ..................................................................................................................................... 37
TASK-RELATED OPERATION AND ACCESS RIGHTS ........................................................................................................................ 39
TASK-BASED GROUPING, CENTRAL ADMINISTRATION AND LOCAL CONFIGURATION.............................................................................. 44
5.5.1 Requirements............................................................................................................................................................... 44
5.5.2 Tasks ............................................................................................................................................................................ 44
5.5.3 Workstation authorization in WinCC OA ..................................................................................................................... 45
USAGE OF ENCRYPTED COMMUNICATION PROTOCOLS .................................................................................................................. 46
5.6.1 Usage of TLS protocol .................................................................................................................................................. 46
5.6.2 Usage of Kerberos........................................................................................................................................................ 51
6 IMPLEMENTATION OF THE SECURITY STRATEGY FOR SECURITY SOLUTIONS .................................................................... 53
SECURITY CELLS AND NETWORK ARCHITECTURE .......................................................................................................................... 55

6.1.1 Definition of the Access Points to the Security Cells .................................................................................................... 55
6.1.2 Newly installed machine .............................................................................................................................................. 56
6.1.3 Highly Secure Large System ......................................................................................................................................... 56
6.1.4 Secure small system ..................................................................................................................................................... 61
Page 4 of 271

6.1.5 Secure security cell link via IT Infrastructure ................................................................................................................ 63
6.1.6 Secure security cell link via WinCC OA Proxy ................................................................................................................ 66
6.1.7 Secure network cell from power issues ........................................................................................................................ 67
6.1.8 Secure Access Techniques ............................................................................................................................................ 68
HARDENING ......................................................................................................................................................................... 77
6.2.1 Hardening IT-Infrastructure ......................................................................................................................................... 77
6.2.2 Hardening WinCC OA .................................................................................................................................................101
ADMINISTRATION AND CONFIGURATION OF OS .........................................................................................................................163
6.3.1 Administration of Computers .....................................................................................................................................163
6.3.2 Administration of networks and network services .....................................................................................................168
6.3.3 Configuration settings for all mobile devices .............................................................................................................169
6.3.4 Automatic user logout in OS.......................................................................................................................................170
ADMINISTRATION AND CONFIGURATION OF WINCC OA .............................................................................................................171
6.4.1 Administration of Role-Based user authorizations .....................................................................................................171
6.4.2 Automatic User Login .................................................................................................................................................172
6.4.3 Automatic User Logout in WinCC OA .........................................................................................................................173
6.4.4 Administering user rights ...........................................................................................................................................173
6.4.5 Single Sign On .............................................................................................................................................................174
6.4.6 Server-side Authentication .........................................................................................................................................176
6.4.7 WinCC OA Server Configuration .................................................................................................................................186
6.4.8 WinCC OA User Interface Configuration.....................................................................................................................187
6.4.9 Branding of WinCC OA MSI Installation .....................................................................................................................189
6.4.10 Configuration Settings for WinCC OA Video (vimaccOA) .......................................................................................190
6.4.11 Example configuration of TLS in WinCC OA ...........................................................................................................195
PATCH MANAGEMENT AND SECURITY UPDATES ..........................................................................................................................202
6.5.1 Patches and Security Updates ....................................................................................................................................203
6.5.2 Use of the patch management ...................................................................................................................................203
VIRUS SCANNER ..................................................................................................................................................................208
6.6.1 Use of virus scanners ..................................................................................................................................................208
6.6.2 Principle architecture of a virus scanner ....................................................................................................................209
LOGGING, AUDIT, MAINTENANCE AND ASSET MANAGEMENT ........................................................................................................212
6.7.1 Observe audit logging and transmit information to WinCC OA .................................................................................212
6.7.2 Implement Intrusion detection system .......................................................................................................................213
SECURITY TESTS ...................................................................................................................................................................215
6.8.1 Knowledge of Security Testing ...................................................................................................................................215
6.8.2 Blackbox scan .............................................................................................................................................................215
6.8.3 Whitebox scan ............................................................................................................................................................216
6.8.4 Penetration tests ........................................................................................................................................................216
6.8.5 Vulnerability Scanning................................................................................................................................................217
IMPLEMENT BACKUP AND RESTORE CONCEPT............................................................................................................................218
6.9.1 General Information ...................................................................................................................................................218
6.9.2 OS related backup ......................................................................................................................................................218
6.9.3 Network equipment backup .......................................................................................................................................222
6.9.4 DB-Server (Oracle) backup .........................................................................................................................................223
6.9.5 WinCC OA related backup ..........................................................................................................................................223
6.9.6 External Data Storage ................................................................................................................................................225
Page 5 of 271

6.9.7 Restore procedure ..................................................................................................................................................... 225
IMPLEMENT RISK ASSESSMENT PROCESS BASED ON VDI/VDE 2182 ............................................................................................. 226
6.10.1 Definition of Risk assessment process ................................................................................................................... 226
6.10.2 Example for VDI/VDE 2182 integration ................................................................................................................. 228
SYSTEM DECOMMISSIONING ................................................................................................................................................. 234
7 SECURITY CHECKLIST....................................................................................................................................................... 236
8 GLOSSARY....................................................................................................................................................................... 243
9 LISTS ............................................................................................................................................................................... 264
TABLE OF FIGURES ............................................................................................................................................................... 264

LIST OF TABLES ................................................................................................................................................................... 269
LIST OF CITATIONS ............................................................................................................................................................... 270
Page 6 of 271

1 Preamble
Scope
This „SIMATIC WinCC Open Architecture Security Guideline” is valid for WinCC Open Architecture 3.16
FP2 (P009) and newer for the usage of process control systems. This version stays valid until recalled. For
older versions of WinCC OA the corresponding security guidelines are valid.
The "WinCC Open Architecture Security Guideline" merely has the character of recommendations and is
meant to support SIMATIC WinCC OA customers in secure operations of their production systems. The
recommendations are based on state-of-the-art technology, current standards and the characteristics of the
products used.
Due to the continuously advancing threat level, a hundred percent/complete permanent protection cannot be
guaranteed even in case of full implementation. A regular validation of the implemented measures within the
scope of the security guideline is recommended.
Registered Brands
SIMATIC WinCC Open Architecture is a registered brand name of ETM professional control GmbH, a
subsidiary of Siemens AG. The use of product names and designations in this documentation by a third party
for their own purposes may infringe the right of the registered brands owner.
Copyright© ETM professional control GmbH | A Siemens Company 2019 All Rights Reserved
Marktstraße 3
7000 Eisenstadt
Austria
Intention of this document

This guideline serves as a supporting document for design, implementation and maintenance of
a State-of-the-Art SCADA system at customer’s site.
It is necessary to cover as many of the security goals expected by the customer. This guideline is intended to
provide ideas on available security concepts that customer-side security concept may follow to achieve the
targeted goals.
The proposed parameters for WinCC OA and settings for the operating system are derived from the
knowledge and experiences made at Siemens AG and ETM professional control GmbH but must be adapted
to match the requirements of the plant.
Page 7 of 271

Disclaimer
1.3.1 License
“The following notes and conditions shall apply for Software provided by Siemens by installing on your system,
by filing a copy on your system during the installation or by making available the Software in any other way.
Please note:
This Software is protected under German and/or foreign copyright laws and provisions in international treaties.
Unauthorized reproduction and distribution of this Software or parts of it is liable to prosecution. It will be
prosecuted according to criminal as well as civil law and may result in severe punishment and/or damage
claims. Please read all license provisions applicable to this Software before installing and/or using this
Software. You will find them after this note.
If you received this Software as "Trial-Version" this Software may only be used for test and validation purposes
according to the provisions of this Trial License stated after this note. TO USE THE SOFTWARE IN
PRODUCTION PROCESSES IS NOT ALLOWED. BECAUSE IT IS A TRIAL VERSION WE CANNOT
EXCLUDE THAT EXISTING DATA WILL BE MODIFIED OR OVERWRITTEN OR WILL GET LOST.
THEREFORE, WE WILL NOT BE LIABLE FOR ANY DAMAGES RESULTING FROM THIS INSTALLATION
OR FROM IGNORING THIS LEGAL NOTICE AND/OR FOR LOSS OF DATA.
ANY OTHER TYPE OF USAGE OF THIS SOFTWARE IS ONLY ADMISSIBLE IF YOU HAVE A VALID
LICENSE FROM US. IF YOU DO NOT HAVE A VALID LICENSE (WHICH HAS TO BE ESTABLISHED BY
SUBMITTING A CORRESPONDING CERTIFICATE OF LICENSE, YOU HAVE TO INTERRUPT THE
INSTALLATION PROCESS IMMEDIATELY. DON’T USE THE INSTALLED SIEMENS SOFTWARE AND
CONTACT OUR NEAREST OFFICE TO AVOID ANY DAMAGE CLAIMS.
Security information
Siemens provides products and solutions with industrial security functions that support the secure operation
of plants, systems, machines and networks.
In order to protect plants, systems, machines and networks against cyber threats, it is necessary to implement
- and continuously maintain - a holistic, state-of-the-art industrial security concept. Siemens’ products and
solutions constitute one element of such a concept.
Customers are responsible for preventing unauthorized access to their plants, systems, machines and
networks. Such systems, machines and components should only be connected to an enterprise network or the
internet if and to the extent such a connection is necessary and only when appropriate security measures (e.g.
firewalls and/or network segmentation) are in place.
For additional information on industrial security measures that may be implemented, please visit
https://www.siemens.com/industrialsecurity.
Siemens’ products and solutions undergo continuous development to make them more secure. Siemens
strongly recommends that product updates are applied as soon as they are available and that the latest product
versions are used. Use of product versions that are no longer supported, and failure to apply the latest updates
may increase customer’s exposure to cyber threats.
To stay informed about product updates, subscribe to the Siemens Industrial Security RSS Feed under
https://www.siemens.com/industrialsecurity.
General License Conditions for Software Products for Automation and Drives
(Status: January 31, 2019)”
Siemens Setup Information with integrated Security Disclaimer V5.2 (Siemens, 2019)
Page 8 of 271

Note:
To stay informed about WinCC OA product updates and security notifications such as detected
security holes and recommendations, sign up for our product-specific ETM-Newsletter. More
information is available under:
http://www.etm.at/index_e.asp?id=16&sb1=&sb2=&sb3=&sname=&sid=&seite_id=151
(acc.: 27th March 2019)
Page 9 of 271

Structure and organization of this document
The "WinCC Open Architecture Security Guideline" has various requirements and recommendations and
consists of multiple parts:
This document is the base document. It describes the general basic principles for a site-specific adjusted
security concept and the various approaches for possible solutions.
The document is structured as followed:

• Chapters 1-4: Information necessary to understand the security guideline
• Chapter 5: The security strategies and their basic principles

• Chapter 6: The implementation of the security strategies for security solutions
• Chapter 7: Security Checklist

• Chapter 8: Glossary of the document-specific terminology
• Chapter 9: List of figures and references
Further information about the "WinCC Open Architecture Security Guideline" can be found in the download
section of the SIMATIC WinCC Open Architecture Portal at: https://www.winccoa.com/.
ETM professional control GmbH suggests registering there to get the latest news for WinCC Open
Architecture.
The target audience of this document are people responsible for designing, developing, installing and
supplying services for automation systems based on the SCADA software WinCC Open Architecture
developed by ETM professional control GmbH.
This document can be used as an overview for decision-makers or as a basic introduction to the topic.
WinCC OA Documentation reference
This symbol refers to more information in the WinCC OA Documentation. The description points to
the specific information. Further details or configuration suggestions can also be provided by WinCC
OA Documentation.
Required knowledge
The following knowledge is assumed for understanding and implementing the concepts introduced in this
document:
• Advanced knowledge about WinCC Open Architecture

• Advanced knowledge about the project to be protected.
• Administration of IT technologies known for the office environment

• Configuration of the PLC hardware in use for communication via specific drivers (S7, IEC,
Modbus…)
• Configuration of used third party products.
Page 10 of 271

1.5.1 Training center
Specific trainings regarding the configuration of WinCC OA are offered by ETM professional control GmbH.
Those trainings give practical options to configure the recommended settings in a controlled environment
together with an experienced trainer.
For further information regarding the options of a user training session on the effective utilization of WinCC
Open Architecture, as well as certification by ETM professional control GmbH please refer to this online form:
ETM Training
ATTENTION
This Guideline cannot be a substitute for the training in the fields of networking techniques,
Microsoft® Windows or Linux administration of desktops and servers and their operation in the
Windows domains, but instead, assumes some knowledge in these areas.
Products Used
The following products, product versions and options are used for the implementation of approaches for
solutions described in this document:
Siemens SIMATIC WinCC Open Architecture 3.16 FP2 (P009) has an especially hardened process
visualization system (Control & Visualization System), installed on the operating systems mentioned below.
Basically, WinCC Open Architecture supports Microsoft® Windows and Linux (RedHat®, OpenSUSE®).
Installation / Requirements for WinCC OA

Installation / Requirements for WinCC OA / Software requirements
Updates for operating systems are in the responsibility of the OS producers. Please get more information
from the producers’ Website.
ATTENTION
For using WinCC Open Architecture on a Windows operating system the following information must
be considered:
When WinCC Open Architecture runs on a Microsoft® Windows operating system, Microsoft
handles updates of the operating system. ETM professional control GmbH will not explicitly test any
Windows patches or give any recommendation for the usage of those patches. For information on
the updates of the operating system see:
https://technet.microsoft.com/en-us/security (acc.: 27th March 2019)
https://technet.microsoft.com/en-us/security/bulletin/dn602597 (acc.: 27th March 2019)
Administration rights may be needed for the WinCC Open Architecture installation and for creating
WinCC Open Architecture project instances, depending on the rights that were set for the folder
structure.
Page 11 of 271

Note:
The TCP/IP protocol must be installed on the platforms since the WinCC Open Architecture
processes communicate through TCP.
Either TCP/IP v4 or v6 can be set active. Both protocols should never be set active simultaneously.
When both protocols are used simultaneously, the faultless communication between the WinCC
Open Architecture systems cannot be guaranteed. ETM professional control GmbH recommends
restricting the communication within the plant to TCP/IP v4 and deactivating v6 to avoid issues
caused by incompatibilities.
Page 12 of 271

Abbreviations
Abbreviation Explanation
ACC Access on – This is the date when an external Web reference was accessed
ACL Access Control List
AD Active Directory
AES Alert & Event Screen of WinCC OA
AS Authentication Server
BCC Backup Control Center (2nd node for WinCC OA DRS System)
BSI Bundesamt für Sicherheit in der Informationstechnik (Federal Office for Information
Security [Germany])
CA Certification Authority
CBC Cipher Block Chaining Mode
CIS Center for Internet Security
COM Component Object Model
CRL Certificate Revocation List
CSN Control Systems Network
CSP Cryptographic Service Provider
CTK Crypto Token
CTRL Control Scripting Language
DATA WinCC OA Data-Manager
DC Domain Controller
DCN Distributed Computer Network
DCOM Distributed Component Object Model
DCS Distributed Control System
DDoS Distributed Denial of Service
DIST DISTributed system, DISTribution-Manager (DIST-System, Dist Manager)
DMZ Demilitarized Zone
DoS Denial of Service
DP Datapoint
DPE Datapoint Element
DPL Datapoint List, typical usage as file extension e.g. export.dpl or dpl-file
DPT Datapoint Type
Page 13 of 271

DRS WinCC OA Disaster Recovery System feature, not a disaster recovery concept
ECDHE Elliptic-curve Diffie–Hellman protocol
ECN Enterprise Control Network
ERP Enterprise Resource Planning
ETM Company name of ETM professional control GmbH
EVENT WinCC OA EVENT-Manager
FR (IEC) Foundational Requirement
GEDI Graphical EDItor of WinCC OA
HDB History Database Manager of WinCC OA
IACS Industrial Automation and Control Systems
ICS Industrial Control System
IEFT The Internet Engineering Task Force
IPC Inter-Process-Communication
ISA International Society of Automation
ISO International Organization for Standardization
KDC Key Distribution Center
LDAP Lightweight Directory Access Protocol
MAC Message Authentication Code
MCC Master Control Center (2nd node for WinCC OA DRS System)
MCS Manufacturing Control Systems
MES Manufacturing Execution Systems
MQTT Message Queue Telemetry Transport
MMC Microsoft Management Console
MXPROXY WinCC OA Multiplexing Proxy
NSA US National Security Agency
NTLM NT LAN Manager
ODA Oracle Database Appliance
OS Operating System
PARA PARAmeterization Tool of WinCC OA (Data model configuration tool)
PAM Pluggable Authentication Modules
PCN Process Control Network
PLC Programmable Logic Controller
Page 14 of 271

PMON Process Monitor of WinCC OA
RAIMA Configuration Database of WinCC OA with last values and alerts (also historical)
RDB Relational Database Manager of WinCC OA
REDU Redundancy (e.g. REDU-Manager)
RSA Rivest–Shamir–Adelman cryptosystem
RPC Remote Procedure Call
SAN Storage Area Network
SCCM System Center Configuration Manager
SELinux Security-Enhanced Linux
SiESTA Siemens Extensible Security Testing Appliance
SL Security Level based on IEC 62443
SR (IEC) System Requirement
SSA Server-side Authentication
SSL Secure Socket Layer
SSO Single Sign On
TGS Ticket Granting Service
TGT Ticket Granting Ticket
TLS Transport Layer Security
ULC UX WinCC OA Ultralight Client – User Experience
UI User Interface
UUID Universally Unique Identifier
VA WinCC OA database to store historical data for HDB
VCI VIMACC Control Interface
VMS Video Management System
WinCC OA SIMATIC WinCC Open Architecture
WSS WebSocket Secure
XML-RPC Extensible Markup Language Remote Procedure Call
Table 1 - List of Abbreviations
Page 15 of 271

2 Targets of the Security Guideline
Maintaining the control over production and the processes in the application has the highest priority in
automation. Even measures to prevent security threats must not affect this. The "Security Guideline WinCC
Open Architecture" should ensure that only authenticated users execute authorized (permitted) operations
on authenticated devices based on utilization features assigned to them. This solution should take place only
via unique and planned access routes. This is to ensure secure production or coordination without hazards
for human beings, environment, product, goods to be coordinated and the business of the organization
during a task.
The "Security Guideline WinCC Open Architecture" recommends the use of security mechanisms available
currently for this purpose. This means the system operator uses all available security mechanisms from
Siemens AG, ETM professional control GmbH or third-party providers, to ensure the maximum possible level
of security.
The configurations illustrated in this document may also be implemented and scaled with modifications. This
depends on the level of protection needed by the system operator; the responsibilities present or security
mechanisms that have already been implemented. However, this should be planned diligently and carefully
by all technicians, specialists, administrators and others responsible in each case. To achieve the maximum
level of security, the modified configurations should not contradict the basic principles of this security
concept.
The “Security Guideline WinCC Open Architecture” should facilitate the cooperation and interaction between
network administrators of organizations (IT administrators) and automation networks (automation engineers).
Thus, the benefits of networking process control technology with data processing of the other production
levels may be used without increasing the security risks on either side.
Note:
It must be taken into consideration that not all common and existing security concepts from vendor
products of the IT environment can be implemented 1:1 in process automation.
The focus of the IT lies in global accessibility coupled with the maximum possible level of security.
ATTENTION
Any deviations from the recommended security guideline for WinCC OA may cause security gaps
with undesirable or adverse consequences.
Ensure that the considered system is always updated in such a manner that no security gaps may
occur. This document holds the security guideline for SIMATIC - WinCC Open Architecture 3.16
FP2 (P009).
Please get in touch with your contact person at ETM professional control GmbH | A Siemens Company,
regarding the related version of this security guideline if a document for a different WinCC OA
version is needed.
Page 16 of 271

3 References
To ensure a long-time validity of this document and to allow the involvement of third-party manufacturers and
their products in the security concepts, the following internationally approved standards and rules are
considered:
IEC 62443/ISA99
ISA/IEC-62443 is a series of standards, technical reports, and related information that define procedures for
implementing electronically secure Industrial Automation and Control Systems (IACS). This guidance applies
to end-users (i.e. asset owner), system integrators, security practitioners, and control systems manufacturers
responsible for manufacturing, designing, implementing, or managing IACS systems.
Figure 1 - IEC 62443 definition from 9th February 2018 (ISA99, kein Datum)
See also: http://en.wikipedia.org/wiki/Cyber_security_standards (acc.: 27th March 2019)
Page 17 of 271

This standard has 4 different parts:
• Part 1 (General) deals with general aspects and security standards. It defines a common basis in the
form of terminology, concepts and models for the electronic security in the fields’ industrial automation
and process control system. Following aspects are covered:
o Terminology
o Concepts
o Models
o Compliance metrics
o Security Levels (SL):
▪ SL 1 - Protection against casual or coincidental violation
▪ SL 2 - Protection against intentional violation using simple means
▪ SL 3 - Protection against intentional violation using sophisticated means
▪ SL 4 - Protection against intentional violation using sophisticated means with
extended resources
• Part 2 (Policies and Procedures) deals with implemented policies and procedures on site and must
be considered by the asset owner (see document 2-1, 2-2 and 2-3). It supports the development of a
program for the security of industrial automation and control systems. In addition, this part supplies
detailed support related to process activities and key elements when developing a management
system for the cyber security.
The following aspects are covered by this norm:
o Organization
o Training / awareness
o Continuity plan
o Policies, procedures
o Personnel security
o Physical security
o Network segmentation
o Account administration
o Authentication
o Authorization
o Risk management and implementation
o Solution development and maintenance
o Incident planning and response
Page 18 of 271

• Part 3 (System) deals with the overall and network system and must be considered by the integrator
(see document 3-2 and 3-3). It deals with the implementation of a security program in practical use in
connection with the conception and introduction phase. This also includes the definition and use of
parameters for an effective measurement of the program.
o System architecture, network segmentation
o Zones and conduits
o SL for systems
o FR 1 – Identification and authentication control
o FR 2 – Use control
o FR 3 – System integrity
o FR 4 – Data confidentiality
o FR 5 – Restricted data flow
o FR 6 – Timely response to events
o FR 7 – Resource availability
• Part 4 (Component) specifies the criteria for industrial automation and process control systems
where these systems differ from other IT systems from a security point of view. Based on these
differentiating factors the standard retrieves the specific security requirements for this system
category.
It deals with requirements on components such as WinCC OA. ETM professional control GmbH
already holds a 4-1 certificate for the development process and a certification for a 4-2 level is
targeted for the future.
o Product development process
o PLCs
o HMI devices
o PC stations
o Firewalls
o Gateways
o Switches
o Functions
o Applications
o Data
Page 19 of 271

Industrial Automation and Control System (IACS)
Asset Owner 2-1

operates and maintains Operational policies and procedures
2-3
Service Provider 2-4
Maintenance policies and procedures
+
Automation solution 2-4

System designs and deploys
Basic Process Safety Complementary 3-2
Integrator
Control System Instrumented Hardware and 3-3
(BPCS) System (SIS) Software
IACS environment / project specific

is the base for
develops control systems Control System

Product as a combination of components 3-3
Supplier develops components 4-1
Embedded Network Host 4-2
devices components devices Applications
Independent of IACS environment
Figure 2 - Responsibilities for asset owner, Integrator and Product supplier in IEC62443 (Kobes, 2016)
Reason and goal of an IEC 62443

implementation is to implement an overall
concept which affects all stakeholders within a
project. This is important because the overall
protection is as weak as the weakest part. All
parts of a chain of protections measure must
be assessed by this norm because all
stakeholders can create weaknesses along
this protection chain. Therefore, an
assessment of one single stakeholder is not
enough to protect the system.
Figure 3 - Weakest point in chain (Siemens, 2019)
Page 20 of 271

Other standards and rules
The table below gives information regarding other Security standards that can be applied to an IT
infrastructure by an asset owner or an Integrator.
ISO/IEC - International Organization for Standardization / International Electro

technical Commission
ISO/IEC 11770 “Information technology -- Security techniques -- Key management”
ISO/IEC 15408 "Information technology - Security techniques - Evaluation criteria for IT

security"
ISO/IEC 17799 "Code of practice for information security management""
ISO/IEC 27001 "Information security management systems – Requirements" as part of

IEC62443
IEC 61643 “Low-voltage surge protective devices”
IEC 61663 “Lightning protection - Telecommunication lines”
NAMUR - International User Association of Automation Technology in Process

Industries
NA 67 " Information protection for process control systems (PCS) "
NA 103 " Use of Internet technologies in process automation "
NA 115 " IT security for automation technology systems "
FDA - Food Drug Administration
FDA 21 CFR 11 " Electronic records and signatures "
Table 2 - Norms and Standards
Page 21 of 271

Other measures for security are:
• Close coordination of the security needs of the customers and system operators (e.g. via the
selected security-critical reference systems and reference customers).
• Cooperation with independent institutions and organizations (e.g. OPC Foundation, ISA, ISCI, ARC,
OMAC, MsMUG, PCSF and PCSRF).
• Close interaction with other manufacturers and suppliers (e.g. Microsoft®).
Operational Guidelines for Industrial Security

Further information and documents about security guidelines including Whitepapers e.g. for security of S7
controller are directly available from Siemens:
http://www.industry.siemens.com/topics/global/en/industrial-security/Pages/default.aspx
Page 22 of 271

4 Definitions
This document follows internationally recognized expressions:
“shall”: Indicates a requirement
“should”: Indicates a recommendation
“may”: Is used to indicate that something is permitted
“can”: Is used to indicate that something is possible (e.g. an organization or individual can do
something).
Naming scheme in figures and examples

Names, terms and icons which are used in the figures and examples shall simplify the handling of this
document.
Page 23 of 271

Names of the networks in the “Security Guideline WinCC Open Architecture"
The following network names are used in this security concept and the illustrated figures. If there is no
standardization available, the most common international network names are used in this security concept
and the illustrated figures to satisfy the current requirements of a uniform naming scheme for the different
networks.
The network names and the primary colors used (red, yellow, green) in the following figure show the
networks depending on production level according to ISA-S95 as well as on security area according to ISA-
S99. The automation level (MCS according to ISA-S95) is divided in further task-specific networks (green,
blue, violet) in this security concept. This distinction is needed to consider the different requirements of
bandwidth, availability, response times and climatic resistance.
ERP – Enterprise Resource Planning (Level)
ECN Enterprise Control (Systems) Network
MES – Manufacturing Execution Systems (Level)
MON Manufacturing Operations Network
MCS – Manufacturing Control Systems (Level)
PCN Process Control (Systems) Network
CSN Control Systems Network
FDN Field Device Network (Field Level)

Figure 4 - Automation levels (Siemens, 2019)
Page 24 of 271

5 Strategy of the Security Guideline
It is not possible to have specific defense against every individual current or possible future threat or method
of attack from the inside or outside. Based on this assumption, this security concept deals with general
defense strategies that should ward off the following attacks:
1. Reduction in availability (e.g. denial of service)
2. Bypassing individual security mechanisms (e.g. " Man in the Middle ")
3. Intentional wrong operation by permissible actions (e.g. after stealing a password)
4. Incorrect operations by non-configured user rights
5. Spying out data (e.g. formulations and corporate secrets or even the principle of operation of
systems and their security mechanisms)
6. Modification of data (e.g. to change alarm messages)
7. Deletion of data (e.g. log files to disguise or obscure hacking actions)
Those seven issues are only a subset of possible threats for an industrial plant. The German Federal Office
for Information Security has provided an overview of threatening scenarios on the following page:
https://www.bsi.bund.de/EN/Topics/ITGrundschutz/ITGrundschutzCatalogues/itgrundschutzcatalogues_node
.html (acc.: 27th March 2019)
Direct link to PDF-file : https://download.gsb.bund.de/BSI/ITGSKEN/IT-GSK-13-EL-en-all_v940.pdf

A list of recommendations, on Security Management, is provided by specialized companies. This referred list
has solutions about CIS vulnerabilities and is kept by the company Tenable.
https://www.tenable.com/blog/cis-adapts-critical-security-controls-to-industrial-control-systems
(acc.: 27th. March 2019).
The following defense strategies serve as an overall approach to supplement the required and desired
access types and operator control options with most available security mechanisms in a multi-level defense
(Defense in Depth) with many security layers and serve as an overview for SIMATIC WinCC OA customers
and are explained in detail.
Page 25 of 271

Security Management Process
An implementation of a Security Management Process needs a holistic approach where different targets and
ways needs to be considered.
• Security management is a significant part of any industrial security concept
• Definition of the security measures proper for the individual plant depending on found dangers and
risks
• Reaching and keeping the necessary security level needs a continuous security management
process
o Risk analysis with evaluation of current dangers and definition of counter measures to
reduce the risk to an acceptable level
o Adjusted organizational / technical measures
o Regular / event-driven repeats
• Products, plants and processes must follow standards of care, based on laws, standards, internal
guidelines and state of the art solutions.
The following defense strategies serve as an overall approach to supplement the required and desired
access types and operator control options with most available security mechanisms in a multi-level defense
(Defense in Depth) with numerous security layers and serve as an overview for WinCC OA customers and
are explained in more detail.
Page 26 of 271

Target and strategy Security Guideline chapter
Comprehensive protection against security

threats by access-based Defense in Depth.
Defense in Depth
Enhancing the availability and preventing the

spread of security threats by division in task-
oriented security cells.
Division in Security Cells
Preventing misuse by task-related control and

access rights for the user, software components
and devices.
Task-Related Operation and Access Rights
Response to future and current security threats

by centralized group-based maintenance,
service, update and distributed security of the
products used with defined distribution paths.
Task-based grouping, central administration and

local configuration
Encrypted and signed communication ensures

that integrity and non-repudiation requirements
are fulfilled.
Usage of encrypted communication protocols
Table 3 - Strategy of IT Security
Page 27 of 271

A one-time implementation of security functionalities to achieve the targets from the table above is not
enough. The implemented recommendations must be checked and maintained continuously to ensure an
adequate protection. The following figure shows that implementation of security is a cyclic process. A
detailed description of the involved steps is available in chapter: Implement Risk assessment process based
on VDI/VDE 2182.
Figure 5 - Security Management Process (Siemens, 2019)
Individual security measures (e.g. IP security or VPN) may be used multiple times or meet different
requirements simultaneously. These security measures are centrally described once and provided with notes
on this central description along with the respective security solution.
The different security measures and strategies can either supplement themselves favorably or affect
themselves unfavorably. In each case, it must be strived to achieve a reasonable balance between
availability, security, comfort and performance. If one of the security solutions described has such a problem,
attention is drawn towards this.
The main aim of the following description of the individual security strategies and their system
implementation is to support the system planner and operator with the composition of the current security
measures. In this manner, security measures in future can be supplemented efficiently and in a targeted
manner.
Page 28 of 271

Defense in Depth
Regarding WinCC OA, the IACS security competence covers three basic layers to support implementation of
holistic “Defense in Depth”
Product Security: Defines the security mechanism implemented into a product itself. The company
ETM professional control GmbH, as product supplier is responsible for the implemented features.
WinCC OA operational Guidelines defines how an Integrator, Service Provider or asset owner should
handle a product. In case of WinCC OA this information is provided by means of following list.
o This Security Guideline document
o WinCC OA Documentation
o Different trainings offered by ETM professional control GmbH (e.g. CSW workshop)
o White papers accessible via SIMATIC WinCC Open Architecture portal
(https://www.winccoa.com/)
o Consulting services
Industrial IT Security Services supports an asset owner (and system integrator as a contractor of asset
owner) in achievement and maintaining of a desired security level of an IACS in total. Different
vendors offer services to achieve a desired security level.
A possible vendor of Industrial IT Security Services is Siemens AG. The Siemens AG security
services portfolio covers security audits, SOC services, vulnerability management services etc.
More detailed information about Industrial Security from Siemens AG is available at the following
page:
https://new.siemens.com/global/en/company/topic-areas/future-of-manufacturing/industrial-
security.html (acc. 01st February 2019).
The following figure shows which layer needs to be covered for a defined responsibility. While Product
Security and Operational Guidelines are covered by WinCC OA security competence, Industrial IT Security
Services should be covered from a vendor company.
Industrial IT Asset Owner

Service Provider
Security Services
Operational System Integrator

Guidelines
Product Supplier
Product Security
Figure 6 - Basic layers of defense in depth according to responsibility
Page 29 of 271

5.2.1 Defense in Depth concept
A typical Defense in Depth concept based on three different methods of protections and each method holds
layers of protection.
1. Plant Security
o Physical Security
o Policies and procedures
2. Network security
o Security cells and DMZ
o Firewall and VPN
3. System Integrity
o System hardening
o User Account Management
o Patch Management
o Malware detection and prevention
Page 30 of 271

5.2.2 Layers of protection
The figure below shows how a Core system is protected via different layer of protection. A typical attacker or
a threat must defeat all existing layers until the Core system become vulnerable. This method ensures a
good level of security even in cases when the attacker found a way to overcome a few layers of protection.
This figure shows also how a potential threat may affect less likely the core of the system in dependency of
the configured layers of security.
Figure 7 - Layers of protection
While planning the systems or system migration, a decision must be taken, based on the types of access
needed. In cooperation with the asset owner following mechanism could by implemented for the described
layers of security.
Page 31 of 271

1. Physical security
a. Control physical access to various areas, buildings or individual rooms.
b. Lock cabinets, devices and equipment like cables and wires.
2. Policies and Procedures

a. Enforce usage of strong passwords
b. Implement a Security Awareness concept on side
c. Prepare a backup and restore concept to recover from a disaster
(see chapter: Implement Backup and Restore concept).
3. Security Cells and DMZ
a. A single access point for each security cell (should be a firewall system) for authenticating users,
devices and applications used, for the directional access control and assignment of access
authorizations and for detecting any hacking attempts. It acts as the main entry point to the network of
a security cell and serves as the first point of control for access rights at the network level.
b. Perimeter area techniques should be used. In this case, it means the use of exported data not
serving the process control directly, which is available on one system (data storage, database). It is
found between the main access point for the data entry (the so-called frontend firewall) and the deeply
embedded access point for the data entry (the so-called backend firewall) or in the third network
segment of a Three-Homed (found in three networks) firewall.
4. Firewall and VPN
a. Firewall configuration means the protection by the local firewall against access from any location
outside its own security cell. Additional it is necessary to configure all access points on the level of an
Operation System (Microsoft® Windows , Linux) very carefully. As a result, all objects that can be
reached via remote access such as files, registry entries and application (DCOM) are protected and all
systems are restricted to the tasks to be executed by them, e.g. operating system in kiosk mode
(see chapter: Secure Desktop – Kiosk Mode).
b. Application layer filtering should be applied as standard technique, i.e. an access mechanism, in
which every individual command can be checked at a high level. It can be checked with respect to
access rights available as well as malicious or criminal intent (in most cases, realized in standard
Webservers, published by the front-end firewall), where a possible failure of the access does not
impair the process control. Scanning of incoming viruses means that all files and readable data, which
are received on all systems, are scanned on the first system that allows access and allows reading the
file/data.
Page 32 of 271

5. System hardening
a. Disable all unused OS functionalities.
This layer ensures that only the required OS functions are enabled.
b. Certificate-based authenticated and encrypted communication should always be used when
possible. This can be done using tunnel protocols such as PPTP (point-to-point tunneling protocol),
L2TP (layer two tunneling protocol) or the IPsec (IP security) filtering.
It can also be done via channels that are secured by server-based certificates, such as, for example:
o RDP (Remote Desktop Protocol)
o Windows server 2012/2016 terminal server published securely via HTTPS
o Windows server 2012/2016 Webserver via the firewall using the TLS (transport layer security)
technology.
o Active Directory using Kerberos Tickets
c. Certificate based manager communication in WinCC OA can be done by using the supplied
WinCC OA proxy, whose communication is based on TLS protocol. WinCC OA uses openSSL for this
layer, please consider WinCC OA Documentation or Readme files from actual WinCC OA patches
about the required openSSL version (see chapter: Usage of TLS protocol).
d. Usage of State-of-the-art encryption methods
Additional it is recommended to use a tool with configurable block ciphers which allows increasing the
encryption to a higher level if required.
In general it is recommended to use an actual block cipher like AES256, please mind that old ciphers
like DES or 3DES are already deprecated and should not be used anymore. For recommended block
ciphers, see Appendix chapter: Block Cipher.
It is not possible to recommend a specific authentication tool at this time but ETM customer support
can help in such cases.
e. Network administration has the choice of centralized, time-related and task-specific password
guidelines as well as group-related access rights administration which are applied in WinCC OA and a
standardized audit trail.
Using an OS based user authentication would also be possible under Linux with Samba 4. However,
the configurations which are used there cannot be applied to WinCC OA automatically.
An implementation on site without an AD on Windows or on Linux via Samba 4 may be less secure
compared to the given recommendation but depending on the desired requirements of the plant
operator it might be enough.
f. Need to connect. A project solution must only allow the connection of required devices or interfaces.
Page 33 of 271

6. User Account Management
a. Operation authorization. The administration of these authorization levels within WinCC OA shall be
done wherever this is necessary. This is the "last line of defense", also called "access control". It
should be implemented or practiced by the Plant administrator and his operations personnel. Further
restriction could be implemented by running a remote user interface on a workstation where every
operation is limited to the WinCC OA application itself and the operator is not able to change the focus
to a different application, this restriction is also known as Kiosk-Mode
(see chapter: Secure Desktop – Kiosk Mode).
b. Single Sign On (SSO). Secure authentication and one-time login can be used if possible. At this point
an Active Directory (AD) system is mentioned as method of choice to inquire the user data from OS. In
cases where Kerberos authentication is used, a Login via SSO is mandatory.
Beside an AD environment it is also possible to use an external authentication tool instead of a
complete AD environment. This tool could work on LDAP basis but for security reasons it is essential
to select the tool wisely (see chapter: Single Sign On).
Although SSO gives some level of comfort it does not work together with Server-side Authentication
(SSA) (see chapter: Server-Side Authentication)
7. Patch Management
a. Security updates (primarily equivalent to this technique or a part of this technique) means having the
system security updates and virus signature updates available and installing them as soon as
possible. To exclude any impairment of the processes running currently by the security updates,
certain procedures must be kept in mind.
These are described in the section: Patch management and security updates
b. Automatic Updates should be implemented with prior careful analysis of possible risks.
8. Malware detection and prevention

a. Anti-Virus Software needs to be configured on side
b. Network specific intrusion detection and prevention systems needs to be configured
5.2.3 Implement Defense in Depth for different Types of Access

From the point of view of the plant operator, it should be possible to have secure access to the components
of the plant for the execution of regularly recurring tasks. The access is implemented by various components
and mechanisms of the process control and visualization system. Therefore, the possible risks for
unauthorized access are diverse. Subsequently, the access is classified more accurately from the customer's
point of view as types of access.
The strategy of the Defense in Depth in this documentation is not a simple list of the security measures that
can be used in process control technology such as, e.g. encoding, authentication, authorization etc. It is a
description of the meaningful use of these security measures in different layers of protection, customized
precisely to the types of access from the customer's point of view. Within this example, four different types of
access where used:
• Data exchange/Information exchange: Data and information exchange between different production
levels, neighboring systems, onshore/offshore components, automation/security and cells.
• Real-time Controlling/Remote Controlling: The control or remote support of onshore to offshore or
different systems or between the remote-control center and the system.
Page 34 of 271

• Maintenance: The normal monitoring and archiving of diagnostics information, data backups, updates
or even the fine adjustment of configurations.
• Support: All Engineering activities, upgrades or modifications of the process control system, as well
as error diagnostics and correction.
Types of Data Realtime

Maintenance Support
Access Exchange Controlling
Realtime Data
Layers physical protection
of single access points

Protection
perimeter zones perimeter zones perimeter zones perimeter zones
certificate based certificate based certificate based

standardize
authenticated authenticated authenticated
application layer
and encrypted and encrypted and encrypted
filtering
communication communication communication
secure secure secure secure

Authentication Authentication Authentication Authentication
and SSO and SSO and SSO and SSO
System hardening System hardening System hardening System hardening
Operator-Rights Operator-Rights Operator-Rights

Administration Administration Administration
Figure 8 – Implementation of Defense in Depth concept for different Types of Access (Siemens, 2019)
Every access should take place only via clearly authenticated network devices and by authorized
users. „Data Exchange“ and “Real-time Controlling“ in this overview represent the information-related
connections of the Enterprise Resource Planning (ERP) systems for the business level, the Manufacturing
Page 35 of 271

Execution Systems (MES) for production planning and the Manufacturing Control Systems (MCS) for the
automation level. “Maintenance” refers to the maintenance and service of the various systems. It includes
regular security updates or the collection and evaluation of diagnostics and log files. “Support” stands for the
remote access necessary to update, upgrade to fix errors and rectify faults in the systems used.
Moreover, there is a reference in the overview to an access type called "Real-time Data". This stands for a
mixture of "Data Exchange" and "Real-time Controlling". In most cases, this mixed type of access results
from the access technique used or it is the result of bundling of multiple tasks by the system operator.
However, this mixed type of access should be avoided, since the security measures that can be used are
very diverse and compromise solutions often are an enhanced level of risk.
Note:
User permissions should be limited to a minimum for the required type of access. Do not use
administrator permissions if this is not necessary!
Page 36 of 271

Division in security cells
The strategy for dividing plants and connected plants into security cells increases the availability of the
overall system, if failures or security threats that result in failure can thereby be restricted to the immediate
vicinity. Because this strategy results in the setup of a modern and securely networked process automation
plant, the planning of the security cells for this plant must be very thorough. The plant is first divided into
process cells for this purpose and then into security cells based on the security measures.
5.3.1 Process cells and security cells

Process cells are certain production-related areas, sections, sub-areas or sub-systems and they must meet
the following conditions:
• A process cell must be an independent "functional system or sub-system", which can be run for a
certain period without connection to the remaining systems or parts of the systems. In other words, a
process cell must be and remain autonomously functional for a certain period.
• All associated elements of a process cell must be connected directly (e.g. not over leased lines).
From the network point of view, it must be a LAN (Local Area Network).
• Parts of the system that could cause a high load on the network and processor, e.g. when they need
to connect via complex security mechanisms from the outside, should necessarily be integrated
directly in the process cell.
One or more process cells become one security cell when the following conditions are met:
• Only trustworthy and authorized persons having proper training should get entry to a security cell.
The following entries, among others, must be checked stringently:
o Physical entry to the production areas and rooms of the process control system
o Operation of the process control system and manual production sections
o Access to the file system and configuration of the process control stations
o Access to computer and controller networks, their power supplies and infrastructure (e.g.
network services, domain controller)
• Any access to a security cell should take place only after checking the legitimacy. For this purpose,
for example, persons and devices must be authenticated and authorized.
• Any access must be capable of being logged or must take place under supervision by authorized
persons, e.g. entry of persons, file access, use of support etc.
• Devices that often must communicate with each other shall be placed within one security cell to
avoid an impact caused by a slow bandwidth. A slow bandwidth could be caused by network
limitations on site or it could be configured to reduce the overall network load
(see chapter: Limitation of bandwidth between security cells).
Page 37 of 271

The planning of security cells is based on the actual areas of responsibility, the separable automation cells,
the physical entry options and the network design and access protection implemented on this basis.
As a result, the operation of the individual security

cells or segments is still ensured even in case of a
temporary loss of parts of the infrastructure (e.g.
network, displayed in red). For this purpose,
information and services needed within the security
cell, which are generated externally, must be saved
intermediately or provided as a substitute (e.g.
formulations and material data, network services
such as name resolution, IP address assignment and
user authentication). Suitable measures must be
adopted for this purpose within the security cell.
Figure 9 – Splitting of Security Cells

(Siemens, 2019)
Furthermore, in case of the occurrence of a security

threat within a security cell (e.g. virus, displayed in
red), the other cells or their members can be
protected. Therefore, it is possible to continue
running the entire system while the security threat is
eliminated.
Figure 10 - Communication in Security Cells

(Siemens, 2019)
Page 38 of 271

Task-Related Operation and Access Rights
The strategy of the task-related operation and access rights includes restricting the rights and functions of
the user, system operator, devices, network and software components to the minimum needed.
To achieve effective protection without restricting the normal activities, it is necessary to coordinate the
following aspects:
• Operation and access rights to the respective system and its area of protection
• Purpose of use of individual devices and software components
• Organization of the production and its areas of responsibility
• Administration of the system
• Tasks of the plant operator

This means that the task-related operating and access rights are differentiated based on roles. This depends
on the competence and area of responsibility of the respective operators or plant operator. The control within
the different network types, thus, is defined in a far more structured and secure manner.
This coordination can be executed on basis of the production levels and the production process and is
described in the following.
Note:
In smaller plants, the access is only divided in local or remote access and therefore no MES/ERP connection
is used.
Securing a simple remote access is described in the section: Secure Access Techniques
The organization of the production process is based on three levels, ERP (Enterprise Resource Planning),
MES (Manufacturing Execution Systems) and MCS (Manufacturing Control Systems). These are defined in
the ISA-95.
Page 39 of 271

ERP – Enterprise Resource Planning
MES – Manufacturing Execution Systems
MCS – Manufacturing Control Systems
Figure 11 - Operation Levels (Siemens, 2019)
The areas of responsibility for resources (e.g. personnel, material and systems) within an organization are
oriented at the production process. These areas of responsibility must be reflected in the assignment to the
structures and system components respectively:
• Permission management of users and computers (e.g. by administration in domains)

• Assignments of the plant operators (e.g. by the operator administration in the software of the process
control systems)
• Software components (e.g. by local access rights of the software on the computer)
• Devices
• Networking (e.g. also the administration of the network and the network access)
Page 40 of 271

In general, there is already an administration for the IT infrastructure and the office computer. The
administration of the production related computer systems must also take over the separate and specialized
administration for the automation devices and process control systems (marked as "responsible MCS
administrator"). The reason for this is that the responsibility for the entire production (MCS level) is up to the
production manager and his personnel.
Figure 12 - Operation levels Personal production (Siemens, 2019)
To avoid security gaps, the exact demarcation of the areas of responsibility must also be done at the network
and administration level. This must be done in coordination with the other production levels.
Page 41 of 271

Figure 13 - Operation levels production (Siemens, 2019)
To implement the areas of responsibility, the network structure and the technical options for controlling the
network traffic of individual networks (illustrated by way of an example with firewalls and perimeter) must
match these areas of responsibility.
The administration of the users and computers in the AD Domain or in a Samba 4 configuration on a Linux
system must be adapted to these areas of responsibility. The next figure illustrates the connection via
different types of trusted relationships between administrative domains (Microsoft® Windows ) for the office
IT (ERP level) and the production IT (MCS level). In the figure, the production planning area (MES level)
does not have its own IT administration. Instead, it is administered by the office IT and production IT areas
respectively, depending on where the associated users and computers of an organization are usually found.
Page 42 of 271

Figure 14 - Operation levels Domain Production (Siemens, 2019)
The trusted relationships between the domains simplify the secure and mutual identification of users of the
respective domain. The trustworthy users may get access to the domain at the other end.
The responsibility for meaningful restriction of the process operation authorizations for individual operators
needs to be defined by the plant operator (production manager). The settings are configured in the process
control system or process visualization applications (in case of WinCC OA via the WinCC OA user
administration).
Note:
With incorrect administrative rights for the plant operator at the operating system level, an
unauthorized user can change settings.
Each process control station, software part or network hardware should be able to execute only
those tasks locally or in the network that are assigned to them by the manufacturer. This limitation
reduces the possible potential of damage by a "security credential taken over" (e.g. password) for a
user or a device.
The example described above can only be implemented if there is an AD within a Microsoft®
environment. If that is not the case, the trusted relationship cannot be set up as described.
ETM professional control GmbH does not supply any generally valid and usable alternative at this
point.
Page 43 of 271

Task-based grouping, central administration and local configuration
This section describes the administrative tasks for maintenance, service and update of a system, which must
be planned and secured specifically because of its strategic significance. The requirements for carrying out
the work of maintenance, service and update of a system are very similar with respect to the security
solutions.
The described information in this chapter is related to the operating system and third-party components.
5.5.1 Requirements
• All tasks are implemented and administered respectively via a central storage location (e.g. backup
server, Windows update service server etc.).
• All tasks must have distribution and security paths (e.g. network connection, unlocks at firewalls etc.)
customized to the respective system.
• The grouping of systems with the same settings or purpose of use (e.g. in Windows software update
service) reduces the incidence of errors in individual local configurations.
• Important parts of the system must be defined and grouped in such a manner that these groups can
be processed independently of one another. This must also be possible without having to shut down
plant operation completely. The following groups could be created, for example:
o Grouping the WinCC OA servers to defined classes according to their purpose.
o All WinCC OA UI clients in one “Client group “.
5.5.2 Tasks
1. Software updates:
Planning and execution of the central distribution of software updates like
security updates, hot fixes, installations, virus signature updates, upgrades,
project updates, certificates etc. from one centralized storage location to the
individual components needed to be updated.
2. Software configuration:
Planning and execution of the central configuration of systems such as
operating system, virus scanner, Windows update etc. from one central
configuration server to the individual systems needed to be configured.
3. Backup and restore:

Planning and execution of the local and central backup of data, software
applications, operating systems, firmware etc. on a central storage location
and restoring the same.
4. Logging and diagnostics:

Planning and execution of the centralized backup of local diagnostics, log files,
logs etc. for centralized logging of the local events.
Deviations, if any, must be discussed and coordinated with the system operator. An example of this is the
exclusive local storage of data/backup data, which, in case of data loss on the local storage locations can no
longer supply the data needed.
Page 44 of 271

5.5.3 Workstation authorization in WinCC OA
Workstation authorization may have all permission bits or only some specific bits. Thus, permission bits can
be even further reduced. This means that an administrator user which has the permission bit 4 would not
have this right on the workstation if it is revoked for this workstation.
Therefore, it is possible to realize that tasks which need the permission bit 4 can only be done via a special
workstation (e.g. a locked-up office).
Page 45 of 271

Usage of encrypted communication protocols
WinCC OA uses two different technologies for encrypted communication between distributed and remote parts
of a project.
1. TLS communication
2. Kerberos communication
5.6.1 Usage of TLS protocol
5.6.1.1 TLS Basic communication

In order of Stapleton and Epstein description of TLS/SSL is defined as follows:
“Secure Socket Layer (SSL) and Transport Layer Security (TLS) are cryptographic protocols designed to
provide secure communications on the Internet. This protocol provided endpoint authentication and
communication privacy over the Internet using cryptography. Both SSL and TLS provide for server and client
side authentication. However, in typical use, usually just the server is authenticated (i.e., its identity is
ensured), while the client remains unauthenticated. To provide for mutual authentication requires a PKI
deployment of certificates to the clients. The protocol allows client/server applications to communicate in a
way designed to prevent eavesdropping, message tampering, and message forgery.
Jointly developed by Netscape and Microsoft, SSL version 3.0 was released in 1996, which later served as a
basis to develop Transport Layer Security (TLS), an IETF standard protocol.” (Stapleton & Epstein, 2016, S.
84)
Based on the OSI model TLS uses the layers Transport and Session for communication to the other host, in
contrast to IPsec which uses the Network Layer.
Application Application
Presentation Presentation
TLS/SSL
Session Session
TLS/SSL
Transport Transport
IP Sec
Network Network
Data Link Data Link
Physical Physical
Figure 15- Usage of TLS/SSL in OSI model between Client and Server
Page 46 of 271

TLS communication is based on an asynchronous mechanism to send a message between a sender and
a receiver.
The secure dispatch of a message needs three methods, which must be used together:
1. Encryption: The content of a message must not be readable for an unauthorized user.
2. Signing: The message needs a digital signature to prove the identity of the sender.
3. Integrity: The receiver needs verification that the message was not altered.
5.6.1.1.1 Encryption
Firstly, the receiver Alice shares her public key with the sender Bob. Next Bob encrypts the message
based on this public key from Alice. The encrypted message is transmitted to the receiver Alice.
Finally, Alice receives the message from Bob and can decrypt the content with her private key. This key
must be kept secret by user Alice. A theft of this Private Key could cause a threat, where the transmitted
messages may be sniffed and decrypted by a malicious user.
Figure 16 - Public/Private Key encryption (Gilliam, 2018)
Page 47 of 271

5.6.1.1.2 Signing
Signing of a message needs the private key of the sender. In this case Alice is signing her message with
her private key before the transmission to Bob. Bob can ensure that his received message was send by
Alice with Alice’s public key.
Figure 17 - Public/Private Key signature (Gilliam, 2018)
Page 48 of 271

5.6.1.1.3 Integrity with MAC
To prevent a message from altered during the transmission, a hash function is needed.
This function creates one-way cipher text which cannot be decrypted. The verification of an unaltered
message is possible by usage of a Message-Authentication-Code (MAC). This MAC is added as last
block to an encrypted message, with a Block-Cipher running in CBC mode.
The following picture shows how Alice adds a MAC to her message before Bob receives it.
Firstly the received message is split by the algorithm running on Bob’s side into the original message and
the transferred MAC.
Next this algorithm uses the “Master-secret” key (see chapter: TLS Handshake) to generate an own MAC,
based on the original message. Finally, verification is done, to ensure that Bob’s MAC is equal with the
original MAC created by Alice.
Figure 18 - Usage of MAC Signature
Page 49 of 271

5.6.1.2 TLS Handshake
WinCC OA uses the TLS-Handshake method to set up a protected stable communication between two different
endpoints. During the TLS-Handshake procedure the encryption method is changed from an asymmetrical to
a symmetrical one. The usage of a symmetric encryption increases the transfer performance between both
hosts compared to an asymmetric encryption. Since a symmetric encryption requires a secret key known by
both communicating parties, a generation of such a shared secret key and its distribution between both
endpoints is also a part of the TLS-Handshake procedure.
The figure below explains TLS-Handshake procedure in detail.
Figure 19 - TLS Handshake protocol (Zwodrei, 2015)
Page 50 of 271

Establishing a communication is split into four phases:
1. Start to set up a communication from client to server with a hello message.
2. Server sends its public key to client and demands the public key from client.
3. Client sends its public key to server. Next, the client and the server exchange Diffie-Hellman keys. After
that, each side generates the same common master-secret key required for symmetric encryption.
4. Encryption switched from asymmetric to symmetric one. TLS handshake finished.
5.6.2 Usage of Kerberos

Kerberos is a computer network authentication protocol that works on basis of tickets to allow nodes to
communicate over a network to prove their identity to one another in a secure manner. The purpose of
Kerberos is to connect a valid user or machine with a service (e.g. WinCC OA manager).
WinCC OA can be configured to use Kerberos 5 protocol for authentication of managers and ensures
optionally an encrypted communication between the components of a WinCC OA project. This involves also
a mandatory SSO mechanism, CRC message check and a proxy mechanism controlled by OS mechanism.
Special functions / Kerberos Authentication
Following example shows how an authorized user can access a service from a WinCC OA server host. The
AD controller holds the KEY Distribution Center (KDC) with Authentication Server (AS) and
Ticket Granting Service (TGS).
Figure 20 - Kerberos Ticket granting service
Page 51 of 271

The Kerberos Ticket granting process works a follow:
1. User from client (Remote UI) wants to access a service from a WinCC OA server.
In a first step the user sends a message (as_request) with login name and name of the requested
service to AS (Authentication Server) in KDC (Key Distribution Center), to get a Ticket Granting
Ticket (TGT). This ticket is required to request a service ticket for WinCC OA server.
2. AS from KDC sends encrypted TGT to WinCC OA user (as_reply).
3. User sends encrypted TGT to TGS in KDC to request an application ticket for WinCC OA server
(tgs_request).
4. TGS sends encrypted session key with service ticket to access WinCC OA server, based on full
service principal name (tgs_replay).
5. User sends encrypted service ticket with timestamp to WinCC OA Server (ap_request).
6. WinCC OA server accepts request and grants service for WinCC OA user (ap_replay).
Interesting points in usage of Kerberos:
• Kerberos does not protect the installed software from altering.
• All configured services (WinCC OA server) need to be configured in Active Directory and Service
Principal Names (SPN) need to be configured.
• Kerberos must run always: A redundant concept must be implemented via IT infrastructure
measurements to avoid a single point of failure.
• All passwords are encrypted with the same key (Kerberos master key).
• Lifetime of a TGT is configurable; the default value is eight hours.
A system could be vulnerable if a TGT is stolen during this period.
• AS needs physical protection.

• Based on time stamp a system is considerably well protected against attacks. A dictionary attack
needs a time less than five minutes to be successful.
In general Kerberos and especially the Kerberos 5 implementation is a common network protection
mechanism. This stands for the actual State of the Art in Security measurements.
Kerberos is used in many systems that need a holistic security implementation.
Page 52 of 271

6 Implementation of the Security Strategy for
Security Solutions
Successful implementation of the security strategies for security solutions in automation plants realized with
WinCC OA can be achieved only with the awareness of responsibility and cooperation of all those involved.
This includes particularly:
• Manufacturer (development, system test and security test)

• Project manager and integrator (planning, setup and factory acceptance test)
• Operator (operation and administration)

The strategies and their implementation must be checked and updated over the entire life cycle of a system
and are described in this chapter, from the beginning of offer preparation, planning and design to migration
and right up to disassembly of the system.
Security Cells and Network Architecture

Hardening
Administration and Configuration
Patch Management and Security Updates
Virus Scanner
Logging, audit, maintenance and asset management
Security Tests
Backup and Restore concept
Continuous Risk Management
Decommissioning
Figure 21 - Phases in Security Strategy
The following aspects enable the security concept in automation plants described here to become effective:
• The use of robust and system-tested products having a high degree of availability, a basic hardening
(e.g. IP hardening) and predefined security settings.
• Customization that uses current techniques and standards facilitates system design adapted to the
security needs.
• The effectiveness of the security solutions is achieved only with diligent and responsible operation of
the systems and components. In addition, they must be used following the typical application
specified by the manufacturer.
Page 53 of 271

The following table gives an overview of exemplary security solutions that are recommended here for the
implementation of the security strategies mentioned above. These security solutions are counted in the
following sections and dealt with in greater depth in the detailed documents (configuration of a Kerberos
domain) respectively. They are aimed at supporting the system operator, aware of his responsibility, with
discharging his tasks for improving the security of the automation plant.
Security Requirements Chapter in the Security Guideline
A plant shall be split into different Security Cells. Security Cells and Network Architecture
The surface for vulnerabilities shall be limited. Hardening
OS and WinCC OA shall be configured Administration and Configuration of OS

according to recommendations. Administration and Configuration of WinCC OA
A plant shall regular get updates to close newly Patch management and security updates
discovery security gaps.
A plant shall check incoming files for harmful Virus Scanner

content.
A plant shall record security-related and Logging, audit, maintenance and asset
process-specific data management
The implemented security level shall be checked Security Tests

regularly for improvements.
A process to recover from a disaster shall be Implement Backup and Restore concept
defined.
A continuous Risk assessment process shall be Implement Risk assessment process based on
implemented. VDI/VDE 2182
A plan shall be decommissioned in a secure way System Decommissioning

after end-of-life.
Table 4 - Security Solutions
Important for every security solution is the usage of highly available network periphery that is provided by
various manufacturers. The corresponding manufacturers must clarify the reliability of the components. ETM
professional control GmbH cannot give a binding statement to the compatibility between WinCC OA and the
components of special manufacturers.
Siemens for example supplies components of the SCALANCE product family from SIMATIC NET. Detailed
information on SIMATIC NET as network periphery can be found on the Siemens Website:
http://w3.siemens.com/mcms/industrial-communication/en/scalance/Pages/default.aspx
(acc.: 27h March 2019)
Page 54 of 271

6.1.1 Definition of the Access Points to the Security Cells
Network access points should
• Prevent the impermissible data traffic to the process control and visualization systems
• Enable permitted data traffic and thus the normal operation of the process control and visualization
systems
Access points can be:
Protects the perimeter and enables access to web publications of the

Front-end Firewall perimeter and remote dial-up options for the back-end firewall
Protects the production control network PCN and enables the primarily
certificate-based, encoded and signed access to individual trustworthy
Back-end Firewall remote stations and networks (e.g. MON of the manufacturing execution
system, MES) and the remote and support access to the PCN.
Three homed- Combined front-end and back-end firewall with certain "Minimal Perimeters"
Firewall for scalable security solutions
(Special Case) Offers access to a security cell exclusively for maintenance

Access point-Firewall tasks, which otherwise, would not need any connection (e.g. to the MES).
Enables load decoupling with high throughput, usually in combination with an

Back-Router upstream Three-Homed firewall
Table 5 - Firewall Overview
The design of the security cells and networks should also limit the scope of responsibility of the system
operator precisely (e.g. with respect to the IT administrators of the ECN and office networks). This means
that the system operator must clearly have the administrative rights and obligations in his security cell. It
needs to be decided which security cells and network design should be implemented. This decision, in
general, is influenced by the significance and size of a system, its spatial division, the risk obtained and the
budget available.
CAUTION
It is essential to use and configure reliable network equipment (e.g. Switches) with hardened
configuration to avoid negative impact caused by an attack. The documentations of the network
equipment can give enough help to protect the network against DOS and other attacks to the
network.
Page 55 of 271

The examples in the following paragraphs supply an overview about the implementation of a security level
on site. Generally, the following criteria have been used for the choice and names of the sample plants:
• A plant is called "highly secure" if it has a high amount of possible number of security layers (e.g. the
combination of front-end and back-end firewalls is more secure than a single firewall). This is
because in case the front-end suffers from a hostile take-over, the production-related network is still
protected by the back-end firewall.
• A plant is called "secure" if it has the basic security mechanisms (e.g. the perimeter technique of web
publication instead of direct access to the Webserver).
• A plant is called "large" if it has its own infrastructure (e.g. domain controller) or it is connected to the
information processing system of the organization.
• A plant is called "normal" (and thus, not given a special name) when it is configured as a classical
multi-user DCS process control system (without special infrastructure) and holds only rudimentary
connections or its own MES.
• A plant is called "small" if it is primarily a single-user or small multi-user system without connection to
other systems or to the information processing system of the organization.
6.1.2 Newly installed machine

A newly installed and not yet hardened Microsoft® Windows or Linux machine is vulnerable for attacks. An
attacker could place any harmful tool on the machine without detection by the operator. The attacker could
place sleeping processes on the machine and activate them during a later phase when the machine is in
production and holds sensible information.
To avoid this situation, it is recommended to run a machine within an own Security cell until the OS is
hardened with all available patches and prepared to run in an operative environment.
6.1.3 Highly Secure Large System

The highly secure large system has its own perimeter and infrastructure, its own network services and
administration, protected maintenance access, protected remote control, secure web publication and
protected production planning connection.
The following figure gives a simple illustration of a possible sample for the structure of a large and highly
secure production plant. This example shows only a possible solution and it does not show the mandatory
configuration for secure systems.
Following areas are marked in color:
• The Process Control Network PCN (green network).
• The Control System Network CSN (blue network).
• The upstream perimeter network belonging to the plant's scope of responsibility (orange network),
protected by one front-end and one back-end firewall.
• The office and business network office LAN (red network) is secured by its own firewall
All three production-related areas (marked in red, orange and light blue) are secure network systems,
secured as security cells, and can work independently for a specific period. They have their own domain
controller
Page 56 of 271

The web-based access from the ECN to a Webserver of the plant in the perimeter takes place via a web
publication of the front-end firewall. The user activities can be checked and logged there via application
filters. The process control system Webserver in the perimeter retrieves its data from the process control
servers in the PCN via a certificate-based connection (TLS) through the back-end firewall. The back-end
firewall checks whether this connection can be authenticated and set up mutually by both subscribers. This
ensures a high-performance level and the security that only known and trustworthy systems from the
perimeter get specific access via the back-end firewall to certain systems of the PCN.
The support and remote access may take place using multiple access types and paths. The access is
authenticated, authorized and logged centrally in the back-end firewall. More information on this is given in
the section Protected Maintenance Access.
Page 57 of 271

Figure 22 - Highly secure large system with WinCC OA DRS System
Page 58 of 271

Detailed System Description:
• The system operation is maintained by two redundant WinCC OA servers as a WinCC OA DRS system in
the PCN. The PCN is separated into two different locations. Visualization is performed by two distributed
clients who are also configured inside the PCN.
• Archiving of historical data in the database is done in an Oracle–RAC where the archived data is written
to a SAN system. Data replication is configured via WinCC OA DRS System.
• Administration and authentication within the PCN via Active Directory using its own and independent PCN
domain (production domain) with primary domain controller (PDC) and backup domain controller (BDC).
Important network services are provided within the PCN, for example:
o Name resolution (IP address, host)
o Address allocation (IP address)
o System clock synchronization (NTP, SNTP): In WinCC OA the data transmission uses time stamps.
Depending on the time stamps logical decisions are made for the processing. Therefore, it must
synchronize the system time on all clients, PLCs, RTUS and modules. The system time progress must
be constant.
• Inside the perimeter network (PN) the application gateway is used for publishing the process control data.
In this example following services are used
o WinCC OA HTTP-Server (WinCC OA Webserver) with the complete process diagram for the
visualization on the WinCC OA Desktop UI inside the Enterprise Control Network
o WinCC OA OPC server for transmitting selected data (OPC items) to other OPC clients.
o The virus scan server inside the PN
o WSUS server to deploy Microsoft® Windows updates to receive updates from Microsoft®
o Linux Mirror Server to receive CentOS® packages and make them deployable for all Clients on a
CentOS® based platform.
o SCCM Server to deploy updates within the system.
• Remote trustworthy clients and servers of the process control system (e.g. Webserver, MES server),
without direct process data link, are integrated via encoded SSL/TLS communication in the PCN security
cell. The authentication takes place mutually via certificates; the back-end firewall allows IPsec traffic that
has been set up.
• Non-trustworthy devices in the ECN office network receive user-dependent access to web publications of
the production system in the perimeter via the front-end firewall. The authentication takes place via an
encoded connection on the server side with a username and password.
• Trustworthy users of the MES production planning area, who work in the ECN office network, may be
granted access to data for selected applications via firewall client software of the front-end firewall. The
use of these applications depends on whether the application can take over the function of the firewall
client
• The access of the external support stations is performed over specific nodes inside the back and front
firewall. The required ports for communications between the zones need to be configured on these
firewalls.
Page 59 of 271

• SSA is activated in WinCC OA (see chapter: Server-Side authentication). The verification of user
credentials is done by the WinCC OA Webserver. This Webserver needs to be part of the PCN domain or
a trust to the PCN domain needs to be configured.
• The router for external access should only be activated if needed. This means if a remote controller
should access the site the local available operator on site activates this access point. This helps to reduce
the amount of access points to the plant or the project to a very small period.
• Network equipment (Routers, Switches) are hardened against DOS attacks.
• Domain Controllers run in redundant mode to avoid a single point of failure scenario.
Page 60 of 271

6.1.4 Secure small system
A secure small plant is a sample system of a security cell, which is connected to an external unprotected
network via an access point firewall. However, all process control system functions are implemented within
the security cell. This includes both multi-user systems and any number of WinCC OA single-user systems.
The following figure gives a simple illustration of the structure of a secure and small production plant with the
following areas marked in color:
• The PCN (green network).
• The CSN (blue network).

• The entire security cell is protected by one access point firewall belonging to its own scope of
responsibility.
• The office and business network, ECN (Enterprise Control Network: red network) secures itself
optionally via its own firewall. This assumes that the access of non-trustworthy computers to the
WAN/Intranet will not always be controllable.
• The WAN/Intranet stands here as an example of the organization's own network that is configured to
allow remote access.
The production-related area, that is the application area of the
WinCC OA ULC UX / WinCC OA HTTP-Server, is secured as a security cell.
In general, the system structure of small security-relevant systems consists of multiple WinCC OA
workstations with remote user interfaces and a WinCC OA server. Active authentication method is SSA
(see chapter: Server-Side authentication)
Note:
Systems that are used exclusively within a security cell should not be connected to an external
unprotected network unless there is a compulsive need to do so. The only exception is access for
maintenance. The following is applicable, in principle: One or more single user systems with direct
connection to the process operation should not be run in an unprotected network (that is, beyond a
security cell). The reason for this is that in case of just one possible threat to the security, the
process control is endangered (too few security layers).
The support and remote access for maintenance may take place via multiple access types and paths.
However, it must always be authenticated and authorized for this security cell centrally at the added firewall
(access point firewall).
Page 61 of 271

Enterprise Control Network
WinCC OA Firewall
Support Station Office PC
WAN
WinCC OA
Support Station
Firewall
Accesspoint
WinCC OA
WinCC OA Desktop UI
Client
Process Control Network
WinCC OA
WinCC OA Server Webserver
Control System Network
S7-400H S7-400 S7-400 S7-400FH
Figure 23 - Secure small system
Page 62 of 271

6.1.5 Secure security cell link via IT Infrastructure
The connections between mutually trusting security cells must be provided via encoded tunnel
communication, for example, IPsec or SSL/VPN tunnel. These security mechanisms have no effect on the
communication within the security cell. The communication that the security cell abandons is encoded and
hence, limited in its performance.
ATTENTION
All tunnel mechanisms and firewalls are potential "predetermined breaking points" of the network.
If a DoS attack is recognized the firewall is put into a safe state resulting in a heavily reduced data
transmission. All plant sections must be designed to be able to continue operation in case of a security cell
failure.
Security cell links are implemented between the following components:
• At all access points (back-end firewall, Three-Homed firewall and access point firewall)
• At the security cell subscribers (local IPsec filter rules of the individual operating systems)
• At the security control devices (SIMATIC SCALANCE S, product series of the security modules)
Page 63 of 271

The following diagram illustrates two security cells protected by access point firewalls as an example
(production sub-systems, plant1A and plant1B). They use a common MES part in the sub-system plant1A.
Both firewalls allow established IPsec communication between the MES components and the stations of the
process control system of the second sub-system, plant1B. The MES part and the process control stations
involved have been configured for IPsec communication.
The communication is set up if one of the participating target IP addresses is addressed
Figure 24 - Secure security cell link
The figure shows a security cell link of the CSN implemented for "Industrial Ethernet" (WinCC OA S7 driver)
with security modules.
Page 64 of 271

The communication between automation plants, developed particularly for industrial use, cannot be tunneled
via a conventional IT firewall. The increased computing power of an end-to-end encoding of automation
plants would lead to overall performance degradation. An IT firewall cannot protect this communication
adequately, since there are no filter rules available for this purpose. The security modules especially
developed for this purpose, hence, take over the task of protecting the communication. This enables
protected data exchange between the automation and process control systems between the sub-systems,
plant1A and plant1B.
Figure 25 - Secure security cell link with security tunnel
Page 65 of 271

6.1.6 Secure security cell link via WinCC OA Proxy
Beside the common solution to set up a connection between security cells via IT Infrastructure it is also
possible to design this in a logical way via WinCC OA mxProxy manager. It must be noted that this service
supports only a connection between WinCC OA systems and has no direct effect to the selected network
and will also not affect any external vendor software.
The provided example shows three different security cells realized by usage of the WinCC OA mxProxy. In
this case the WinCC OA mxProxy runs on a dedicated machine inside from Security Cell one which is
defined as Master Cell. Each other WinCC OA server runs without a WinCC OA mxProxy manager.
The two other security cells set up a connection to the dedicated machine (WinCC OA mxProxy) inside
security cell one. This machine is also defined as predetermined breaking point. It is necessary that this host
can establish a connection to the WinCC OA hosts running in security cell two and three.
An attack could result into a fail of the WinCC OA mxProxy machine which disables the communication
between the security cells but keeps the internal communication active.
Figure 26 - Sample configuration for security cell connection via a single WinCC OA mxProxy
This figure above shows only a possible way to implement a security cell architecture based on WinCC OA
mxProxy manger.
Page 66 of 271

But there are many other options and an implementation needs to fulfill and consider the specific
infrastructure environments on each side. Here is a small wrap up about some other and different solutions:
• Execute a WinCC OA mxProxy as dedicated machine in each security cell and define the inbound
and outbound connections to the remote WinCC OA Dist Managers in each other security cell.
• Improve the solutions by using a redundant implementation of the WinCC OA mxProxy manager.
Special functions / Security / Multiplexing Proxy / Configuration of Multiplexing Proxy
ATTENTION
There is no mandatory recommendation about the split of security cells provided by ETM
professional control GmbH. Every implementation on site needs to fulfill special requirements from a
security point of view. This means the security design for each site typically has a unique
architecture.
Also consider chapter: “Usage of mxProxy and restriction of open ports and limitation of the IP access list”
inside this document.
6.1.7 Secure network cell from power issues

Beside the protection from a hacker, it is also recommended to protect the system from natural disasters, like
lightning or power failures inside the internal network. Both scenarios could result in a situation where the
SCADA system is partly or completely not available. This may result in bad and unforeseen side effects.
To protect the overall system from this negative impact it is recommended to protected electricity grid based
on following standards:
• IEC 61643 - Low-voltage surge protective devices

• IEC 61663 - Lightning protection - Telecommunication lines
(Gerhard Ackermann, Robert Hönl, 2006)
Page 67 of 271

6.1.8 Secure Access Techniques
The implementation of the "Defense in Depth" security strategy involves specific access techniques
depending on the access type and secure cell design.
• Data exchange / information exchange:

Data exchange between various production levels, neighboring plants, onshore/offshore
components, automation and security-cells.
Access technique:
o Secure Web Publication
o Secure integration of manufacturing control
• Realtime controlling / remote controlling:

Control or remote support of onshore to offshore or different plants or between the remote-control
center and the plant
Access technique:
o Secure data exchange
• Maintenance or Support:
All engineering activities, upgrades or changes of the process control system, as well as error
diagnostics and correction. Monitoring and archiving of diagnostic information, data backups,
updates or fine tuning of configurations.
Access technique:
o Protected Maintenance Access
• Realtime data:
Combination of "Data exchange" and "Realtime controlling"
Access technique:
o Secure integration of manufacturing control
o Secure data exchange
Page 68 of 271

6.1.8.1 Secure Web Publication
Web publication is one of the most modern and secure access techniques. In the process, the web pages of
the Webserver to be published are protected from external attacks in the perimeter at the front-end firewall.
The protection is possible by switching the identity. The name and IP address of the respective Webserver
are thus not subjected to any direct access. The front-end firewall acts as the "authorized representative" of
the Webserver. The network topology and IP addresses of the perimeter are not visible to the external
network.
Webservers can be provided by various third-party suppliers, e.g. the Apache Webserver from the “Apache
Software Foundation” or the Microsoft® Forefront Threat Management Gateway Server (TMG) server
from Microsoft®. For these Webservers various security solutions, e.g. in combination with OpenVPN are
available. Further details can be found on the homepages of the Webserver provider.
An example of a configuration with WinCC OA is given with the Hide secure network behind a Reverse Proxy
chapter.
Page 69 of 271

6.1.8.1.1 WinCC OA HTTP-Server
For quickly displaying plant data an integrated Webserver, which communicates via HTTPS and HTTP, is
part of the software WinCC OA.
The WinCC OA HTTP-Server is used to read and publish data. The responsible integrators must define
individually which data is available over the intranet or internet. This service from WinCC OA can be
activated using the httpServer CTRL function. With this function it is possible to activate a mandatory
authorization via existing user credentials.
ETM provides a default configuration for this service with the CTRL script webclient_http.ctl. It is
recommended to run this service as predetermined breaking point with an own CTRL Manager running
within a DMZ (see chapter: Highly Secure Large System). The start mode for this CTRL Manager needs to
be set to “automatic” to ensure that it is started and running while the project is in run mode.
Usage of WinCC OA HTTP-Server feature allows the automatic deployment of scripts, panels or
configuration files to the requesting client machines. This feature enables a kind of comfort but to avoid a
negative security impact; following recommendations need to be considered:
1. Encrypted panels and scripts need to be used for security relevant tasks,
see chapter: Script and Panel Encryption.
2. A Desktop-UI needs a local cache of all project related files including the required certificates, to establish
a connection to the WinCC OA server. A WinCC OA HTTP-Server automatically deploys the required
certificates for the WinCC OA mxProxy to the requesting client:
a. Public Key for the root certification authority (root-cert.pem)
b. Public Key of the WinCC OA mxProxy (host-cert.pem)
c. Private Key of the WinCC OA mxProxy (host-key.pem)
This means a client can use the same certificates as the WinCC OA HTTP-Server host for the WinCC OA
mxProxy communication. To avoid a negative security impact one of the following recommendations,
need to be considered:
a) Usage of Microsoft® Windows Certificate Store (see chapter: Windows certificate store).
With this feature enabled it is necessary to create and import the client certificate for the client
machine.
This disables the functionality of the default certificates inside the config folder from the WinCC OA
HTTP-Server project. Although the three mentioned files are still deployed by this server to the client.
They will have no functionality and are useless for an attacker. Another benefit is that the certificates
inside the store are protected via OS based mechanism.
Although this is the recommended configuration for all Windows based system, this is not applicable
for a Linux or Mobile OS (Android, iOS).
With the actual version from SIMATIC - WinCC Open Architecture 3.16 FP2 (P009) only the Windows
certificate store is supported.
Page 70 of 271

b) Use File based certificates outside the project config folder
The created certificate files (see chapter: Create own openSSL certificates) need to be placed
outside the config folder from WinCC OA HTTP-Server project but with the project structure. It is
recommended to secure this path by OS settings to prevent a theft of manipulation.
The path to this certificate must to be configured via “sslCertificate” config entry. This functionality
will use the certificates inside this specific and secured folder for the authentication mechanism
instead the default certificates. This allows the WinCC OA HTTP-Server host to keep his private
key for WinCC OA mxProxy communication secret.
Following example shows where certificate and private key are loaded from data folder of a project
instead of the config folder:
sslCertificate = "data/CERT/host-cert.pem data/CERT/host-key.pem data/CERT/root-cert.pem"
For the client machines it is necessary to create own certificates and deploy them manually to the
client machine. Although there is no existing functionality in WinCC OA to make this step
automatically it is possible to implement a tailored mechanism which fulfills the given requirements
by the customer.
To ensure a correct reading of the certificates for a client machine it is necessary to configure the
“config.webclient” on WinCC OA HTTP-Server with a folder that exists on the client host.
This manual configuration makes the default certificates obsolete and closes the attack vector for
the certificate theft from a client.
Reference tables / Configuration file / Possible config entries in WinCC OA → sslCertificate
Page 71 of 271

6.1.8.1.2 WinCC OA Ultralight Client – User Experience (ULC UX)
The ULC UX uses browser technology to display plant information on a device without any need of
installation on the client device.
This ULC UX is useable in an unsecured environment (see chapter: Intended operational environment (UI))
because no code is executed on client side.
A web browser sets up a connection to the WinCC OA HTTP-Server running in a secure environment. It is
recommended to run this server inside a DMZ as a predetermined breaking point. The complete logic is
handled within this secured zone and only the visualization information is transferred to the web browser.
Although a single WinCC OA HTTP WinCC OA server can provide information to multiple clients, it may be
possible that a several number of clients could cause scaling problems.
Those problems can be solved via the Load-Balancing feature from ULC UX servers. In that case it is
necessary to start multiple WinCC OA httpServer projects (on different hosts) to ensure a good and reliable
scaling.
WinCC OA UI / ULC UX / Architecture
A configurable load balancing function will help to distribute the load between the different Webservers.
Reference tables / Configuration file / Entries for different sections / [httpServer] / loadBalance
The amount of necessary WinCC OA HTTP-Server inside the DMZ depends on the amount of user
interfaces and the typical load inside a WinCC OA panel (e.g. dynamic elements in a panel). The correct
amount needs to be evaluated for each project separately.
Possible configuration suggestions are available within WinCC OA Documentation.
WinCC OA UI / ULC UX / Architecture
6.1.8.2 Secure integration of manufacturing control

Trusted clients or servers of manufacturing control system (MES or IMS), without a direct process interface,
are integrated via encrypted communication (e.g. TLS) in the security cell in the following cases:
• When protocols and mechanisms are used for internal data exchange, which was developed for
operation within local networks and domains (e.g. OPC / SQL / ODBC).
• The mutual authentication of encrypted communication is made via X.509 based certificates.
• The authorization is made with OS-based and application-specific access rights.
Page 72 of 271

6.1.8.3 Secure data exchange
It is often necessary that plant data must be made available to or from the plant without using any functions
of the process control system or 3rd party tools (e.g. Apache Web server, Microsoft WSUS Server).
A distinction is made between the following application scenarios:
• Data made available for the plant (e.g. documentation, PCS updates, device descriptions)
• Data made available for external networks (e.g. reports)

These two application scenarios should not be implemented on the same computer. Both scenarios have
different security requirements and should therefore be separated. Further it is recommended to install the
required servers in the perimeter network.
During the installation following requirements need to be considered:
• A virus scanner must be installed to scan reading and writing operations.

• All options of a virus scanner (e.g. heuristics) should be set to maximum.
• Viruses must be removed at once.
• Connection via trusted network

o Authentication and authorization should be needed.
o Encryption should be used.
• Connection via external Network

o Authentication and authorization must be needed.
o Encryption must be used.
Page 73 of 271

6.1.8.4 Protected Maintenance Access
Very high requirements about the security concept are caused by the need for remote access and remote
engineering for a site because every misusage could harm the system. Fundamentally the devices differ
between reliable devices (they are in control and administrated by the facility operator) and devices that are
only used for these activities by a reliable person (therefore called as non-reliable devices).
To ensure the maximum possible security for the system to be kept, every access must be authenticated and
authorized. This can be done centrally at the access point firewall using a combination of multiple techniques
and security mechanisms. A "direct dial-up" to the device supplies too weak testing options and hence, it is
not recommended.
Depending on the type of the dial-up planned – whether local or via remote – and the maintenance access,
there are different requirements and solutions depending on the risk level expected.
6.1.8.4.1 Reliable devices

Remote but reliable devices without direct process interface will be integrated into the security cell via
encrypted communication.
• Mutual authentication of the encrypted communication via certificates
• Authentication and application specific access privileges.
6.1.8.4.2 Non-reliable devices

Non-reliable devices get via remote dial-up a user specific access to the process control engineering system
via Access Point firewall.
6.1.8.4.3 Remote Dial-up

In case of remote dial-up, the security techniques used depend on the specific risks. They need the release
by the system operator and the encoding of the information transfer.
A secure or protected network connection, a connection via a VPN client, is used as the basis for
maintenance access.
Compared to local dial-up, the following other factors must be taken into consideration:
• Type of the dial-up medium

• Type of the dial-up device
• Purpose of the access
6.1.8.4.3.1 Dial-up Medium

• Point-to-point connections on layers 1-2 (e.g. ISDN, modem, serial).
Lower risk, since only specific devices can dial up (depending on the technology)
• Point-to-point connections on layers 3-4: (e.g. VPN, PPTP and L2TP).

Higher level of risk for the access point, since every (device or user) could try to dial up to set up a
connection.
Page 74 of 271

6.1.8.4.3.2 Dial-up Device
• Specific support PC used only for this purpose
This is a situation where the asset owner maintains the plant itself. The risk level is low since the
support PC, its configuration and its security level are known and under control.
• Specific support PC used but not under own control

This is a situation where the Integrator maintain the plant. The risk level is medium, but it is possible
to reduce them by a mandatory usage of a VPN software which ensures mandatory security level for
the remote PC.
• Any support PC not known

Very high level of risk with unknown security level and not recommended
6.1.8.4.3.3 Purpose of the Access

• Support of the process control system software
Lower risk level since access needs to be granted only to software that is largely proprietary
• Support for the customization of the process control system
Lower risk level since access needs to be granted only to proprietary customization data.
• Administrative access
High risk level since full access is available to the complete systems
• Access to devices in the Control Systems Network (CSN)

Very high-risk level since the access to the plant process cannot be fully restricted
6.1.8.4.4 Remote access

Remote access devices get the web-based user specific access to the process control system via Access
Point firewall.
• Authentication ensued via server-sided encryption (for example: HTTPS) via username, password
and certificates.
• Authentication is OS based and specific for a web application. It is necessary to adjust the
hostname/IP addresses with the local OS system to access the connected WinCC OA system.
6.1.8.4.5 Remote engineering

Maintenance access takes place after the dial-up to the process control site.
Based on the task, the following options are recommended:
• Remote maintenance, remote engineering (VPN client with maintenance application)
• Remote desktop (VPN client with remote desktop for MES, OS or any but uniquely defined target
system)
• Remote terminal (VPN client with access to the terminal server and the applications released for this
purpose in the terminal client)
The authorization for the maintenance tasks takes place via username and password at the maintenance
software or at the terminal.
Page 75 of 271

6.1.8.4.6 Summary
To sum it up, these results in the following requirements being made on the access techniques and ensuring
their security:
• A protected maintenance access should be performed by using a VPN connection to the firewall.
The security for the connection (e.g. encryption level) must be selected depending on the level of
risk.
• The VPN dial-up is authenticated with the help of username and password at the firewall. The firewall
verifies this login.
• If the access to the software of the process control system takes place with a specific support PC,
the support PC connected via VPN can be secured like a remote process control computer.
• If administrative access or, in fact, access to the CSN is necessary, this should be done only via
remote desktop, net meeting or remote support to selected plant PCs and the stationary MES.
• The Administrator from asset owner must approve administrative access.
Page 76 of 271

Hardening
Hardening for SIMATIC WinCC OA means that the functions and software applications, which are not
necessary for the operation of the computer within the system environment, are disabled or restricted.
Any possible security threat can be restricted effectively only if each individual member of the security cell is
hardened. The following measures are necessary for hardening:
6.2.1 Hardening IT-Infrastructure

Regarding the hardening of IT-Infrastructure a few guides are already provided by the BSI and an evaluation
of those should be considered:
https://www.bsi.bund.de/EN/Topics/ITGrundschutz/ITSecurityGuidelines/itSecurityguidelines_node.html
Although a virtual environment (e.g. running on an ESXI server) extends the configured environment,
additional security requirements need to be considered.
An own catalogue of security settings are usually published by vendors of the chosen virtual infrastructure,
e.g. VM-Ware offers a few suggestions regarding the configuration on their Web-page.
https://docs.vmware.com/en/VMware-vSphere/index.html (acc.: 27th March 2019).
Furthermore, recommendations from the following chapters must be considered.
6.2.1.1 Shutting down/Uninstalling services that are not needed under Microsoft® Windows
A general list of not needed services cannot be given for a WinCC OA project due to the dependencies of
the plant configuration of the customers. It is to consider if a service is needed. Examples for services that
can be disabled in most of the cases:
1. “Wireless Zero Configuration”
Service for the configuration of wireless services to Windows
2. “Domain Time” or “Windows Time”
If a custom tool is used for the synchronization of the system clock
3. “CD/DVD-Autorun”
Automatic start of auto run files of inserted CD/DVDs
4. “SNMP Service”
SNMP poses a security threat on network level and should only be activated if it is needed for the project
solution. If SNMP is needed following chapter should be considered:
Restrict SNMP driver communication to SNMPv3
Page 77 of 271

6.2.1.2 Shutting down/Uninstalling services that are not needed under Linux
Disable all unnecessary services and daemons (services that run in the background). All unwanted services
need to be disabled. Attached a few command line parameters which works on a CentOS based Linux
machine. For command which fits to other Linux distribution the man pages can be consulted.
Type the following command to list all services which are started at boot time in run level # 3 on a CentOS
machine:
chkconfig --list | grep '3:on'
To disable a service currently running the following command can be used on CentOS:
service serviceName stop
If a service should not be started during an OS startup procedure, following command needs to be executed
on CentOS:
chkconfig serviceName off
It is recommended to disable the SSH Daemon and the Bluetooth service if none of that is needed. Both
services could be disabled in following way, on CentOS:
systemctl stop sshd; systemctl disable sshd

systemctl stop bluetooth; systemctl disable bluetooth
6.2.1.3 Configure BIOS Settings

Configure BIOS to disable booting from CD/DVD and external devices in BIOS. Also define a BIOS
password.
6.2.1.4 Different Disc Partitions

A configuration of different disc partitions helps to prevent important data if any disaster happens. By
creating different partitions, data can be separated and grouped. When an unexpected software accident
occurs, only data of that partition will be damaged, while the data on other partitions is not affected (but
consider that this suggestion beware only from software accident not for hardware accident where the
complete hard disc including all configured partitions fails).
6.2.1.5 Deactivate unused interfaces

Deactivate all interfaces that are not needed. Following interfaces can be deactivated as an example:
• WLAN, Bluetooth
• USB, Firewire, etc.
• Turn Off IPv6

This list is not complete! A complete list can only be defined and applied for each plant separately.
6.2.1.6 Delete or disable unneeded default users on OS Level

Every installed OS system has predefined users (e.g. guest user) and some of them are not needed. These
users should be disabled for security reasons to prevent a security problem caused by a login try with one of
these users.
Page 78 of 271

6.2.1.7 Limitation of internet access
It is recommended to strictly limit the internet access of a live system. This also applies to the accessibility of
a server for installing patches and security updates. It is recommended to restrict access to certain elements
in the system, see chapter: Patch management and security updates for further details.
6.2.1.8 Uninstalling not needed software

In most cases a newly delivered computer has software that is not needed for the plant operation and poses
a potential risk. Therefore, it is recommended to remove all unnecessary software and only keep the
required software packages on the computer.
6.2.1.9 Activate SMB signing

According to Microsoft® TechNet the SMB protocol is defined in following way.
“The SMB protocol provides the basis for Microsoft file and print sharing and many other networking
operations, such as remote Windows administration. To help prevent attacks that modify SMB packets in
transit, the SMB protocol supports the digital signing of SMB packets. This policy setting determines whether
SMB packet signing must be negotiated before further communication with an SMB client is permitted.”
(Microsoft, Require SMB Security Signatures, kein Datum)
It is possible to activate SMB signing for Windows and for Linux systems:
• Microsoft® Windows:
Local Security Policy: Security Settings → Local Policies → Security Options →
Microsoft network server: Digitally sign communications (always) --> Enabled
• Linux CentOS:
Configuration is possible by changing the file: /etc/samba/smb.conf with following line:
server signing = mandatory
Note:
According to Microsoft® an activation of SMB packet signing can degrade the performance up to 15
percent.
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-
2003/cc786681(v=ws.10) (acc.: 27th March 2019)
Page 79 of 271

6.2.1.10 Definition of Access Control List (ACL)
Following points need to be considered for ACL configuration:
• Disable root login for Linux systems

Never login directly as root unless necessary. Use “sudo” to execute commands.
It is also possible to disable the remote login for ssh by changing the “/etc/ssh/sshd_config” file. Search
for the entry “PermitRootLogin” and set the value to “no”.
• Restrict local access to files, registry settings (only Microsoft® Windows), shared files/folders and
databases (Oracle, SQL-Server) for individual and known local groups, users, services and applications.
To get a higher security level while using WinCC OA, it is recommended to restrict the access privileges
of user groups on the file system layer. ETM professional control GmbH differentiates in this
recommendation between server (host system where the WinCC OA project with Data- and Event
Manager is running) and workstation (host system with a remote UI).
• Set read and write permission settings.

This configuration prevents manipulation of config files, scripts and panels through a non-authorized user.
User role Server (Data/Event…) Workstation (UI)
<proj_path>/data
<proj_path>/log
<proj_path>/log
<proj_path>/db
All directories
All directories
Project folder
Project folder
Project execution account X X W W W X X W
Plant administrator WX WX W WX WX WX WX W
Operator R R W
Table 6 – User authorization on folder level
Legend:
• W → Write access
• R → Read access
• X → Execute access
• Project execution account: User which executes the project on site. This user may also be a machine
account like “NETWORK SERVICE” if the project runs as service
(see chapter: Start a WinCC OA project as a service).
• Plant administrator: Administrator on site which is in responsibility of the deployment and maintenance
of the project.
• Operator: Operator on site which operates the system, usually running in kiosk mode with limited
privileges.
Page 80 of 271

Secure handling of configuration data (e.g. export configuration data from TIA Portal to the “data” folder of
the WinCC OA project) is mandatory for security reasons. It is necessary to protect the folders with limited
access privileges to avoid a negative impact caused by a theft of configuration data. It must be ensured that
the configuration data is protected if this file is transferred to another device like an USB-stick or a different
machine. The originator of this file (e.g. configuration file by TIA portal) handles the secure transport to the
target host. On the target host this file is usually placed in a specific folder (e.g. “data” folder) of the WinCC
OA project. This folder needs to be protected as well.
Page 81 of 271

6.2.1.11 Whitelisting/Application Control
Whitelisting and Application Control are techniques that allow running only trustworthy applications
respectively only allow defined file operations. Different to blacklisting software (virus scanner) that only
protect from known threats, the Whitelisting allows blocking all unknown or not trustworthy applications. It is
possible to distinguish between two different solutions:
• Whitelisting, list based:
A list with trustworthy applications is used to decide whether the application can be started or not.
• Whitelisting, rule based (Application Control):

A few rules decide whether an application can be started, and which file operations are allowed for
the application.
A strict distinction between these solutions is not always possible; often a mixed version is used.
List based whitelisting Software is easier to configure. The list can be created automatically and if there are
no changes to the installed software no further administrative tasks are needed. Therefore, this method is
suited for smaller plants or plants with non-permanent IT administrator.
Rule based Application Control may need more effort for configuration and maintenance but supplies more
possibilities and allows a more detailed configuration of applications and file operations. This method is
better suited for large plants with an own IT administration.
Whitelisting and Application Control is no substitution for classic blacklisting software. Instead it is a further
part in a whole Defense in Depth concept. Due to less resource demand of Whitelisting and Application
Control software compared to black listing software it is to be favored on time critical systems and systems
with fewer resources. It is to consider that every computer with access to the internet or a web-based intranet
should have an up-to-date virus scanner.
A typical Application Control allows verification of digitally signed files like libraries and executables. This
functionality allows a configuration, where all files with a digital signature signed by ETM professional control
GmbH are marked as secure files. (see chapter: Digital signatures for binaries and libraries).
Figure 27 - Digital signature signed by ETM professional control GmbH
This functionality may be extendable by usage of digital signs, implemented by an integrator or asset owner
on site. An approach is applicable for all files like panels, scripts, compiled libraries or executables created
by API interface. Finally, all used files on site should have a digital signature.
To sum it up it is recommended to use Application Control software which allows the verification of signed
files.
SIMATIC - WinCC Open Architecture 3.16 FP2 (P009) has been tested with the following Whitelisting
software:
• McAfee® Application Control (AC), formerly known as Solidcore

• Kaspersky® Industrial Cyber Security Suite (KICS)
Page 82 of 271

6.2.1.12 IPsec Bypass Technology
The use of the "IPsec Bypass Technology" stands for a special measure. By using local IPsec filter rules, it is
possible to set up IPsec protected communication with another computer without any specific configuration
of the local personal firewall. This communication setup needs either a Kerberos authentication, or Active
Directory domain membership of the relevant computer.
6.2.1.13 Usage of interlocks for the PLC

Some PLCs allow the usage of interlocks. This allows preventing wrong commands from the UI to the PLC.
Further details can be acquired from the developers of the PLC software project.
6.2.1.14 Secure Desktop – Kiosk Mode

Multiple options are available to restrict the desktop of an operator so that only the UI for the WinCC OA
system can be used and no other software applications can be started.
The following options can be used for the configuration:
• Configuration of GPO settings on AD server for Microsoft® Windows systems

• Configuration of system settings for Linux based systems
• Usage of third-party tools

Details about configuration settings for Kiosk Mode are available for different OS installations:
https://en.wikipedia.org/wiki/Kiosk_software (acc.: 27th March 2019).
The detailed configuration and recommendations for Kiosk Mode differs between Linux distributions as well
as between different Windows versions. ETM recommends the reading of actual suggestions for the chosen
OS.
Within the chosen possibility to implement Kiosk Mode, it is recommended to avoid the execution typical
shortcuts, which may be used to escape the Kiosk Mode:
• ALT + F4 → Close the actual application window
• ALT + TAB → Switch to the next application-level window
• CTRL + ALT + TAB → Opens Dialog to lock machine, shutdown machine, etc.
• Windows Key → Open Start menu
A complete list of shortcuts which can be used to escape the Kiosk Mode can be given by OS manual.
6.2.1.15 Limitation of bandwidth between security cells

The security cell can be protected from external network overload by limiting the bandwidth between security
cells and therefore enabling an uninterrupted data flow inside the cell. The time critical communication inside
the cell is not affected.
Page 83 of 271

6.2.1.16 Secure coding standard for API extension
WinCC OA offers the opportunity to implement own C++ or C# code and connect via API interface. This
code could cause security issues if the implementation wasn’t done carefully. Problems can be avoided by
following general secure coding guidelines. These guidelines are defined by official authorities and ETM
professional control GmbH suggests following the given recommendations.
An option for actual coding guidelines is available here:

https://www.securecoding.cert.org/confluence/display/seccode/SEI+CERT+Coding+Standards
Another source of useful information is also available by the BSI (Bundesamt für Sicherheit in der
Informationstechnik). Here is a start link to the provided service:
https://www.bsi.bund.de/EN/TheBSI/thebsi_node.html (acc.: 27th March 2019)
6.2.1.17 Usage of Obfuscation tool for API code

Besides secure coding it is also recommended to protect a system from reverse engineering caused by
Decompilers.
The generation of a build without debug symbols is often the justification for requirements which may protect
the intellectual property. For instance, there are tools called Decompilers that can take the debug build of a
program and re-create the application’s source code. (Blunden, 2013).
A process for decompiling delivers following data:
• Control flow
• Fix coded values for first values or keys
• Processing inputs (e.g. hidden functions, options)

• Existing test code (without security check)
• Existing mechanism (to disguise data or check of licenses)

All this information could be used for the preparation of further attacks. To reduce the threat, caused by this
situation, it is recommended to use an Obfuscation tool. Such a tool cannot completely avoid the threat, but
it can increase the effort of an attacker and reduces the attractiveness for an attack. This is possible as an
obfuscation tool renames the identifiers like the names of variables and methods and it removes the
debugging information. In general, these tools also change the program sequence which makes it very hard
to understand the logic of a script.
Different obfuscation tools from different vendors can offer divergent functionalities. Here is a small choice:
• 2LKit Obfuscator
• Cloakware
• ConfuserEx
• The Marvin Obfuscator
• Zelix KalssMaster
Page 84 of 271

6.2.1.18 DCOM Settings
The DCOM interface is infamous and can be used by attackers to gain access to an OS with only one
exploit. This treat is caused by remote procedure calls (RPC) which gives a program on computer A the
ability to call a software function on computer B. Although this capability stands for a very powerful
mechanism for distributed computing architecture, it is significant security vulnerability. (Shaw, 2006, S. 411)
Due to historical reasons some features from WinCC OA like the OPC DA driver needs DCOM to set up a
connection between the different parts of a plant. Based on this information it is recommended to select one
of the following options.
1. Disable DCOM: This is the recommended way if DCOM is not used at all in the entire system
2. Hardening DCOM: If DCOM is needed it is suggested to implement hardening to reduce the threat
caused by this vulnerability.
6.2.1.18.1 Disable DCOM

The DCOM protocol is infamous for some security leaks and needs a special hardening to avoid a threat
scenario. If DCOM interface is not needed inside the project or plant, it is recommended to disable this
functionality. The required information is available by Microsoft®:
https://technet.microsoft.com/en-us/library/cc771387(v=ws.11).aspx (acc.: 27th March 2019)
Page 85 of 271

6.2.1.18.2 Hardening DCOM for OPC DA driver
Due to security reasons it is recommended to run an OPC DA server and OPC DA client on the same host.
This makes it possible to avoid security issues caused by remote access. In that case it is possible to limit
the DCOM communication to a single host and to send the data via secure way to the remaining system.
But in dependency of the plant environment this approach is probably not possible and a remote connection
between an OPC DA client and an OPC DA server is needed. Details about the configuration to set up a
communication are available within the WinCC OA documentation.
Drivers / OPC Data Access / Initial setup of OPC communication / DCOM settings for Remote
Servers
The negative effect of the described configuration is that it weakens the security configuration on OS level
and allows remote access of users without privileges like anonymous or everyone. This approach allows a
remote attack from malicious users via this open interface and therefore this setting is only recommended in
a full secured environment where an access from a malicious user is not possible. The following figure
shows a possible attack scenario via this open interface.
Figure 28 - Access from malicious user via DCOM interface
The following description in chapters Usage of secure tunnel to avoid remote DCOM communication and
Usage of hardening guideline for OPC DCOM can give a hint to avoid or reduce this attack scenario.
Page 86 of 271

6.2.1.18.2.1 Usage of secure tunnel to avoid remote DCOM communication
A DCOM tunneling tool allows the elimination of an open DCOM interface by replacing the DCOM network
protocol with TCP. Instead of connecting the OPC DA client to a networked OPC DA server, the client
program connects to a local OPC tunneling application, which acts as a local OPC DA server. The tunneling
software accepts messages from a local OPC DA client and converts them into a TCP messages. These
messages are sent to the remote OPC Tunneling software and are converted back into the OPC protocol for
the OPC server.
The described communication works for both sides and simulates a local OPC DA server/client connection.
The following graphic shows how an attack could be prevented via IT-Infrastructure with a typical action like
the implementation of a firewall.
Figure 29 - Usage of DCOM Tunneling Software
Different vendors offer options for OPC tunneling, the integrator or the asset owner must choose which
solutions can fulfill the requirements on site. A possible solution is offered by the OPC Training institute with
OPC Expert.
Figure 30 - OPC tunnel protocol from OPC Expert (https://opcexpert.com/)
Page 87 of 271

6.2.1.18.2.2 Usage of hardening guideline for OPC DCOM
Another way to limit the surface for an attack is to harden the DCOM interface. Different vendors offer
options to limit access to the DCOM interface but none of them can drop the complete risk of an attack.
Before applying any remote communication via DCOM it is strongly recommended to use this in an
environment where the possibility of an attack was already reduced by IT infrastructure measures.
Regarding the hardening of the DCOM interface itself we can suggest the OPC Security Whitepaper from
“byres research”. This whitepaper is hosted by the SCADAhacker webpage (login required):
https://scadahacker.com/library/Documents/OPC_Security/OPC%20Security%20-
%20Hardening%20Guidelines%20for%20OPC%20Hosts.pdf (acc.: 27th March 2019)
To ensure the working functionality it is necessary to trigger the startup of WinCC OA OPC DA server by the
OPC DA client. A startup via WinCC OA console would start this OPCDA-Server with the local permissions
of the WinCC OA Process Monitor and this could result into issues caused by a wrong set of privileges.
Following details from WinCC OA recommendations should be considered:
Drivers / OPC Data Access / Initial setup of OPC communication / DCOM settings for Remote
Servers
6.2.1.19 Hide secure network behind a Reverse-Proxy

A WinCC OA HTTP-Server, which can hold sensitive information, should be protected behind a
Reverse-Proxy, to control and limit the access points to this Web server. In computer networks, a
Reverse-Proxy is a type of proxy server that retrieves resources on behalf of a client from one or more
servers. These resources are then returned to the client as if they originated from the Web server itself.
This figure shows a symbolic implementation of a Reverse-Proxy which controls the communication between
a Web Server from a secure network with the internet.
Figure 31 – Reverse-Proxy schema
Page 88 of 271

6.2.1.19.1 Example for Basic configuration with Apache Reverse-Proxy
A possible way to implement a Reverse-Proxy is the usage of the Apache Server software.
More information is available within a whitepaper (login required):
https://www.winccoa.com/downloads/detail/wincc-oa-secured-by-apache-
en.html?tx_mddownloads_mddownloadsfe%5Baction%5D=show&cHash=517b4b9c361294c4ba4c727a319
d8db3 (acc.: 27th March 2019).
Based on this whitepaper it is possible to suggest a configuration for the usage of an Apache Reverse-Proxy,
which holds following parts:
• WinCC OA project runs on two redundant WinCC OA server controllers inside the PCN.
Data- and Event manager accepts WinCC OA messages without SSL-encryption
(config entry: mxProxy = “none”).
• WinCC OA HTTP-Server runs on a separate host in PCN.

• Apache Server runs with a connection to PCN and PN on a Linux based OS.
• WinCC OA mxProxy on “PenTestProxy” communicates with both WinCC OA server projects.
The configuration of a remote WinCC OA mxProxy is essential for the communication between the
UI on the client and WinCC OA Data- and Event manager on WinCC OA server hosts due the
configuration of different networks. With this design the WinCC OA server hosts cannot be
directly accessed by the client machine.
• Client Machine with Desktop UI or Remote UI, running on a Microsoft® Windows 10 OS is

connected to PN. It is possible to configure this machine without access to any IP address inside
PCN.
• Certificates for WinCC OA mxProxy, WinCC OA HTTP-Server and WinCC OA Servers are deployed.
• Root certificates are imported in “Trusted Root Certification Authorities” on client machine.
• Client device is unlocked in WinCC OA Device Management panel
Page 89 of 271

Figure 32 - Example for Apache configuration with Desktop UI or Remote UI
ATTENTION
This configuration encrypts the communication between Client and PenTestProxy.
The communication between PenTestProxy to all three WinCC OA servers is not encrypted.
This applies also to the communication between the WinCC OA server machines (remote CTRL
Manager with WinCC OA HTTP Server and both REDU managers) which communicates not
encrypted. Therefore, it is necessary to protect this unencrypted communication with IT
infrastructure measurements.
The basic configuration for the Apache server is already applied as recommended in the whitepaper. For the
configuration following content in the configuration file (/etc/httpd/conf/httpd.conf) could be used:
Listen 80
<IfModule mod_ssl.c>
# Listen to port 443 for https communication

Listen 443
</IfModule>
Page 90 of 271

##Section to load additional modules
# Proxy base module which is necessary for all the other proxy modules
LoadModule proxy_module modules/mod_proxy.so
# Proxy functionality for the HTTP Connect method.

LoadModule proxy_connect_module modules/mod_proxy_connect.so
# Proxy functionality for HTTP/HTTPs communication

LoadModule proxy_http_module modules/mod_proxy_http.so
# Proxy functionality for webSocket communication (ws and secure wss (secure websockets)
LoadModule proxy_wstunnel_module modules/mod_proxy_wstunnel.so
# Proxy functionality for SSL communication via the Apache HTTP server
LoadModule ssl_module modules/mod_ssl.so
##Section for SSL configuration

<IfModule ssl_module>
SSLRandomSeed startup builtin
SSLRandomSeed connect builtin
SSLProxyCheckPeerCN off
SSLVerifyClient none
SSLProxyEngine on
SSLProxyVerify none
SSLProxyCheckPeerName off
SSLProxyCheckPeerExpire off
</IfModule>
## reverse proxy setting for http communication

<VirtualHost *:80>
ProxyPass / http://PenTestWEB/
ProxyPassReverse / http://PenTestWEB/
</VirtualHost>
## reverse proxy setting for https communication
AllowCONNECT 443
<VirtualHost *:443>
##### SSL Configuration with https certificates created for WinCC OA HTTP Server
SSLEngine on
SSLCertificateFile /opt/WinCC_OA/cert/certificate.pem
SSLCertificateKeyFile /opt/WinCC_OA/cert/privkey.pem
SSLProtocol All -SSLv2 -SSLv3
SSLHonorCipherOrder on
SSLCompression off
ProxyPass / https://PenTestWEB:443
ProxyPassReverse / https://PenTestWEB:443
</VirtualHost>
Page 91 of 271

This suggested configuration reads all requests to the root path for the Apache Proxy and transfers them to
the WinCC OA HTTP-Server running on the PenTestWEB machine.
For the Client machine it is necessary to import the created root certificate in to the „Trusted Root Certification
Authorities“ store.
Figure 33 - Import certificate into Trusted Root Certification Authorities
Page 92 of 271

The navigation to the URL of the Apache Server sends the request to the internal
WinCC OA HTTP-Server from WinCC OA and the certificate is marked as trusted like this screenshot
explains:
Figure 34 - Start page from WinCC OA HTTP-Server with trusted certificate via Apache Server
Client to Data/Event communication via Apache proxy

With this configuration it is possible to install the Desktop UI via a secured communication channel (https) and
configure the project. As a parameter for the hostname it is necessary to use the name of the Apache and
WinCC OA mxProxy (PenTestProxy in the given example) instead of the DNS name of the WinCC OA server.
The WinCC OA mxProxy will get the connection request and set up a connection to the WinCC OA servers
inside the PCN network. This means that the entire communication between the internal WinCC OA servers
and the external WinCC OA client are handled with this Apache Reverse-Proxy. This makes it possible to trace
suspicious activities and implement more security layers, to fulfill given security requirements based on an
Apache Reverse-Proxy configuration. This solution is applicable for Desktop UI and Remote UI.
Page 93 of 271

6.2.1.19.2 Apache Configuration for ULC-UX
The example from chapter Example for Basic configuration with Apache Reverse Proxy shows a possible
configuration between a Desktop UI or Remote UI client to WinCC OA server host via Apache proxy server.
But the explained scenario contains a possible threat caused by an unsecured client
(see chapter: Intended operational environment (UI)) or an unsecured communication between WinCC OA
mxProxy and WinCC OA server hosts.
This situation can be avoided by usage of the ULC UX as a client solution via Apache proxy with a complete
end to end encryption. In this case the WinCC OA mxProxy applies on both WinCC OA server hosts and the
communication is completely encrypted. This is possible due the behavior of the https communication
between ULC UX client and WinCC OA HTTP-Server. The ULC UX features uses WebSocket technology to
upgrade https communication from the initial connect to a secured web socket communication. And this
needs to be configured on the Apache proxy server. The suggested configuration is based on this
architecture:
• Two WinCC OA redundant hosts are connected to PCN

• One remote WinCC OA HTTP-Server is connected to both WinCC OA server hosts
• Apache Reverse-Proxy is configured to send and upgrade the https communication to web socket
secured (wss).
• Certificate files are deployed on all server machines including Apache server
• Host with ULC UX client has imported the root certificate into the “Trusted Root Certification
Authorities” store.
Page 94 of 271

Figure 35 - Example for Apache configuration with ULC UX
The figure above shows https/wss communication between ULC UX client to WinCC OA HTTP-Server and
SSL communication to both WinCC OA servers. Details about functionality of ULC UX are available within
WinCC OA documentation:
WinCC OA UI / ULC UX
To ensure a working communication via Apache proxy following settings needs to be configured for the
Apache configuration file (/etc/httpd/conf/httpd.conf for CentOS®):
Page 95 of 271

This section loads all required modules for this communication:
# Proxy base module which is necessary for all the other proxy modules
LoadModule proxy_module modules/mod_proxy.so
# Proxy functionality for the HTTP Connect method.

LoadModule proxy_connect_module modules/mod_proxy_connect.so
# Proxy functionality for HTTP/HTTPs communication

LoadModule proxy_http_module modules/mod_proxy_http.so
# Proxy functionality for webSocket communication (ws and secure wss (secure websockets)
LoadModule proxy_wstunnel_module modules/mod_proxy_wstunnel.so
# Proxy functionality for SSL communication via the Apache HTTP server
LoadModule ssl_module modules/mod_ssl.so
This section sets the required configuration for all ports:
<IfModule ssl_module>
SSLRandomSeed startup builtin
SSLRandomSeed connect builtin
SSLProxyCheckPeerCN off
SSLVerifyClient none
SSLProxyEngine on
SSLProxyVerify none
SSLProxyCheckPeerName off
SSLProxyCheckPeerExpire off
</IfModule>
This section configures the message transfer via incoming port 443:
AllowCONNECT 443
<VirtualHost *:443>
##### SSL Configuration #####
SSLEngine on
SSLCertificateFile /opt/WinCC_OA/cert/certificate.pem
SSLCertificateKeyFile /opt/WinCC_OA/cert/privkey.pem
##### set communication address for wss communication #####

ProxyPreserveHost on
ProxyPass /UI_WebSocket wss://PenTestWEB:443/UI_WebSocket
ProxyPassReverse /UI_WebSocket wss://PenTestWEB:443/UI_WebSocket
##### set communication address for https communication #####

ProxyPass / https://PenTestWEB:443/
ProxyPassReverse / https://PenTestWEB:443/
</VirtualHost>
Page 96 of 271

A successfully configured architecture results into a full encrypted communication between Client and Server
ensured by https certificates:
Figure 36 - Secure ULC UX communication via Apache Proxy
Page 97 of 271

6.2.1.20 Secure Oracle connection
6.2.1.20.1 Use Oracle Server with Oracle Database Appliance (ODA)

Beside a secure connection between different nodes it is also recommended to ensure a good and secured
storage. WinCC OA allows reading and writing to an Oracle DB via WinCC OA RDB-Manager.
Since security incidents, like the Equifax-Data-Breach (https://www.mass.gov/equifax-data-breach acc.: 08th

May 2019), are becoming bigger and occurs more frequently, it is necessary to secure the centralized
logging system as well. Oracle itself provides a few general recommendations but especially a configuration
for an ODA (Oracle Database Appliance) should be considered.
ODA is available up to a two-node plug-and-play RAC cluster. Oracle Standard Edition 2 (within Oracle VM)
and Oracle Enterprise Edition are fully supported and certified to run on every ODA; it reduces typical
deployment times from weeks to less than a day. ODA uses also best practices for operating system and
database security to fulfill the given security requirements. (Fernandez, 2015, S. 69)
Figure 37 - Oracle Database Appliance X7-2M ( (Oracle, 2019)
For a secure configuration of an ODA different configuration attempts are possible. Different suggestions
regarding hardening are available by different vendors. One example vendor is the DOAG group
(https://www.doag.org/en/home/ (acc.: 05th February 2019), which has published following document during
an exhibition from 20th to 23th November 2018:
https://www.doag.org/formes/pubfiles/10852341/2018-Infra-Tammy_Bednar-
Oracle_Database_Appliance_built-in_Security_features_-Manuskript.pdf (acc.: 05th February 2019).
Methods for improving the security maturity for the selected Oracle solution needs to be provided by an
Oracle specialist. This is part of “Industrial IT Security Services” from a Defense in Depth concept
(see chapter: Defense in Depth).
6.2.1.20.2 Activate encryption between Oracle Client and Oracle Server

The WinCC OA RDB manager communicates with the Oracle client and sends the data to the Oracle server.
To prevent the communication from being intercepted and used for the harm of the company, the activation
of the Oracle encryption is recommended. It is also recommended to activate SSO login for the Oracle
connection.
Different Hardening Guideline are also provided by Oracle itself. Due to the situation that this document
cannot give specific recommendation regarding hardening of Oracle it is recommended to consult an Oracle
specialist to implement specific security requirements.
Page 98 of 271

6.2.1.21 Enable SELinux
Security-Enhanced Linux (SELinux) is usually activated by default on supported Linux systems like CentOS
to implement mandatory authentication mechanisms. This feature is usually activated by default and must
not be disabled for security reasons.
Figure 38 - SELinux
The figure above shows how a process tries to request an action from an object (e.g. manipulation of a file).
The request is checked inside the Linux Kernel by SELinux Modules. After a successful check, the access to
an object is granted and the activities are performed. A denied access is logged as a security relevant event
and can be analyzed. It is recommended to keep the default setting with the enforced mode of SELinux. In
some special cases it may be necessary to change the mode to permissive, but this could reduce the overall
level of security at the configured system.
Page 99 of 271

The configuration can be applied in the file:
/etc/selinux/config
Following configuration is recommended for this file:
# This file controls the state of SELinux on the system.

# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - No SELinux policy is loaded.
SELINUX=enforcing
# SELINUXTYPE= can take one of these three values:
# targeted - Targeted processes are protected,
# minimum - Modification of targeted policy. Only selected processes are protected.
# mls - Multi Level Security protection.
SELINUXTYPE=targeted
According to NSA it is essential that end systems (with a running WinCC OA application) can separate
information based on confidentiality and integrity requirements to provide a secure system. Security
mechanism which are implemented into an OS are the foundation of this separation (NSA, 2019).
CAUTION
A disabled SELinux layer could result into a Security threat because unfortunately, existing
mainstream operating systems (without SELinux layer) lack the critical security feature required for
enforcing separation: mandatory access control. Therefore, application security mechanisms are
vulnerable to tampering and bypass, and malicious or flawed applications can easily cause failures in
system security (NSA, 2019).
Page 100 of 271

6.2.2 Hardening WinCC OA
6.2.2.1 Delete or disable all default users on WinCC OA level

A default WinCC OA project installation comes with a few default users like para or guest and they have a
weak default password. To avoid any security issues caused by these users it is recommended to change the
default password to a secure password and to disable the not needed users in the WinCC OA user
administration, except user root which cannot be disabled.
6.2.2.2 Script and Panel Encryption

A special utility for hardening the system is the encryption of WinCC OA project files (panels, scripts). The
files created in the WinCC OA project can be saved encrypted. This has no effect on the run-time behavior of
the WinCC OA project because all panels and scripts are useable even when encrypted.
The encryption of scripts and panels is recommended if securing the know-how inside the project is needed.
The encryption prevents attackers from getting information about the internal technical details of a project as
they are not available in plain text.
ATTENTION
Encryption of panels and scripts is very important for all Desktop UI projects
(see chapter: WinCC OA HTTP-Server). Because they are responsible to deploy the required panels
and scripts to the requesting clients.
The files are transferred in the same state as they are placed inside the server project. This means
an unencrypted panel is also transferred and saved unencrypted on the client.
To avoid a security incident caused by clear text panels and scripts it is recommended to encrypt all
security relevant panels and scripts on the WinCC OA HTTP-Server project.
Special functions / Encryption of Panels and CTRL Scripts / Encryption of Panels and Encryption of
CONTROL scripts/Libraries
6.2.2.3 Local access to the Process-Monitor of WinCC OA

The manager for the Process-Monitor (PMON) in WinCC OA has a HTTP server which allows remote access
for the configured project.
Due to security reasons the default settings for the Process-Monitor (WCCILpmon) limit the access (HTTP,
TCP) only to the local machine.
For detailed information please have a look in the SIMATIC WinCC Open Architecture Portal:
https://www.winccoa.com/forum/ (Section Security/TOPIC: Security Advisory Report)
To re-enable the access from any computer following config entry is needed:
[pmon]
localAddress = ""
Page 101 of 271

The configuration example with an empty string for the config entry “localAddress” opens the connection for
every host in the network. A limitation of the accessible hosts is still possible by usage of the config entries
“ip_allow” and “ip_deny”
# allow access for the local computer and the IP address 192.167.153.122
[pmon]
# deny access for everyone
ip_deny = "*"
# allow access for the local computer

ip_allow = "127.0.0.1"
ip_allow = "::ffff:127.0.0.1"
ip_allow = "::1"
# allow access for a specific IP address

ip_allow = "192.167.153.122"
Further IP addresses of trusted computers can be added by more ip_allow entries. Depending on the
requirements an access limitation is also recommended for other WinCC OA managers.
System management / Settings / IP access list for TCP server sockets

ATTENTION
Configuration setting for remote PMON access needs to be designed very carefully because http-
Server from PMON communicates only via http protocol and not via https. A secure configuration on
IT-Infrastructure level is mandatory to prevent the system from a security threat.
6.2.2.4 Usage of WinCC OA mxProxy and restriction of open ports and limitation of the IP access list
Restrict the external accessibility of services to known devices or external applications by a local firewall via
specified network addresses and protocols or an access authority.
The list of the open ports can be checked with the “netstat” command within a command shell on Windows
and Linux systems.
Using the port security allows to limit the access via the network by using IP access lists.
The restriction of access should be configured in the firewall settings. All ports should be closed except the
port for the WinCC OA mxProxy which is necessary for the WinCC OA manager communication. This port is
configurable.
Port Protocol Description
5678 TLS/SSL WinCC OA mxProxy
Table 7 – Port WinCC OA mxProxy
Page 102 of 271

The WinCC OA mxProxy is used as port concentrator and uses following protocols for the communication.
• TLS/SSL: Secure communication between devices. This communication is encrypted to prevent

unauthorized reading data on the communication line. It is recommended to set up a secure
communication between different security cells where a sniffing of network data would be possible
(see chapter: Usage of TLS protocol).
• TCP: TCP is used for the communication inside the secured network or inside a security cell.
Figure 39 - Schematic graphic of the communication using the WinCC OA mxProxy with a remote UI
The advantage of using the proxy is that only a single port must be opened inside the firewall.
More ports must be opened when using following functions from WinCC OA:
• Port 443 for https

Is used by WinCC OA httpServer to establish a Desktop UI or an ULC UX connection.
This port is configurable via config entry “httpPort” inside the “[webClient ]” section
(default port: 443).
• Port 1521 for Oracle

WinCC OA RDB Manager – The RDB Manager communicates directly with the local installed Oracle
client. Therefore, the corresponding port must be opened on Oracle server side to allow the
communication between Oracle server and client. The information about the defined ports can be
found in the tnsname.ora file which is found inside the Oracle client installation folder in the subfolder
“\network\admin” after the Oracle connection between server and client has been configured
(default port 1521).
Page 103 of 271

• Port for Driver communication
The communication to external devices (via API or driver) is not handled via WinCC OA mxProxy
and therefore it is mandatory to open the specific ports as well to set up a working communication. It
is recommended to encrypt this communication as well if possible and supported.
• Port 9370 for Video
The Video Feature from WinCC OA uses an own Software component named “vimacc®” from
Accellence Technologies which is optionally installable via WinCC OA setup. This part uses port
9370 in the default configuration. This port needs to be opened as well if Video functionality is
needed.
6.2.2.5 Remote access to WinCC OA mxProxy manager via Dist Manager
Following example configuration shows the usage of a distributed communication between different WinCC
OA systems via a WinCC OA mxProxy manager.
Figure 40 - Sample configuration for a remote WinCC OA mxProxy
The architecture above shows a possible example for communication between 3 different WinCC OA
systems via Dist Manager and a single WinCC OA mxProxy. In this example the machine Server1 inside
from security cell 1 sets up an SSL connection to Server2 and Server3 inside security cell2. Server 3 sets up
a direct and unencrypted communication to server2 inside the same security cell.
A failure of the WinCC OA mxProxy will disconnect the Dist Manager communication between Server1 to
Server2 and Server3 and the communication between Server2 and Server3 still is active.
Page 104 of 271

For the configuration following settings need to be applied for the different WinCC OA hosts. Details about
the required config entries are available within the WinCC OA Documentation.
Reference tables / Configuration file / Possible config entries in WinCC OA
ServerSystem1:
No WinCC OA mxProxy running on this machine. The necessary entries for the config file are:
[general]
distributed = 1
mxProxy = "none"
[dist]
mxProxy = "192.168.107.200 192.168.107.105:5678 cert"
mxProxy = "192.168.107.202 192.168.107.105:5678 cert"
distPeer = "192.168.107.200" 2
distPeer = "192.168.107.202" 3
ServerSystem2:
No WinCC OA mxProxy running on this machine. The necessary entries for the config file are:
[general]
distributed = 1
mxProxy = "none"
ServerSystem3:
No WinCC OA mxProxy running on this machine. This machine sets up also a dist connection to
ServerSystem2 and therefore an added distPeer entry is necessary in comparison to config file from
ServerSystem2. The necessary entries for the config file are:
[general]
distributed = 1
mxProxy = "none"
[dist]
distPeer = "192.168.107.200" 2
mxProxySystem:
This machine has only a WinCC OA mxProxy manager from WinCC OA and nothing else. Needed config
entries for the suggested configuration are:
[proxy]
server = "192.168.107.200:4777"
server = "192.168.107.202:4777"
Page 105 of 271

6.2.2.6 Activate httpAuth for WinCC OA HTTP-Server
The WinCC OA HTTP-Server is part of every WinCC OA installation, and it can be started with the control
function: httpServer (). The WinCC OA web services are using this command to start the specific server.
With the default configuration the WinCC OA HTTP-Server starts already with activated authentication. It is
possible to disable this feature for special reasons, but it is not recommended for a productive system.
For a default configuration with activated authentication following authentication methods are possible:
• Basic: Needs a Login of a configured user in WinCC OA. Username and Password are stored inside
from Web browser.
• Negotiate: This method requires a ticket granted by a Kerberos KDC for authentication.
(see chapter: Usage of Kerberos) .
• NTLM: This method can be used if a Kerberos KDC is not available for “Negotiate” method. NTLM
is an authentication method which uses a challenge and response protocol where Windows
credentials are used for a Login to WinCC OA.
CONTROL / Control functions / Functions H / httpServer()
6.2.2.7 Communication with WinCC OA – Desktop UI

Especially for the usage of a remote WinCC OA mxProxy and the WinCC OA Desktop UI a few other
configuration settings must be mentioned.
• Usage of separate config file with the name config.webclient

• Configuration of mxProxy entries in the related config file
• Usage of IP addresses instead of DNS names if the client applies outside of the DNS zone where
hostnames cannot be translated to IP addresses.
• Reverse IP Lookup is disabled in WinCC OA by using the config entry: “noReverseLookup = 1”

• Hardening of clients and correct Firewall configuration.
• Load the correct host certificate
• Unlock every device in WinCC OA Device Management to allow a connection between client and
server
WinCC OA UI / Desktop UI
WinCC OA UI / Mobile UI Application / Device Management
It is possible to access the WinCC OA Desktop UI via Apache proxy redirection and in this case the correct
configuration for visible IP addresses from outside of the trusted network must be mentioned. This feature
will increase the security level of the site since the real IP addresses are not visible from outside the secure
MCS network.
Page 106 of 271

Following Whitepaper shows a possible usage of an Apache proxy as Reverse-Proxy:
https://www.winccoa.com/downloads/detail/wincc-oa-secured-by-apache-
en.html?tx_mddownloads_mddownloadsfe%5Baction%5D=show&cHash=517b4b9c361294c4ba4c727a319
d8db3 (acc.: 27th March 2019)
6.2.2.8 Usage of TLS/SSL for plant communication

If not disabled, TLS/SSL communication is selected as default for each project to ensure a secure
communication without using a Kerberos environment (see chapter: Usage of TLS protocol).
ATTENTION
The default certificates provided by ETM professional control GmbH allow an easy distribution of
WinCC OA projects. Those certificates can be compared to a default password
(see chapter: Password strength).
To avoid the risk caused by a default password, ETM professional control GmbH recommends the
replacement of those certificates. A WinCC OA project running on a plant must not run with the
provided default certificates, for security reasons.
WinCC OA provides the creation a customer specific CA with a configuration panel which can be used to
create certificates based on openSSL. This WinCC OA panel triggers the required openSSL commands from
WinCC OA to the local openSSL installation. This implementation is realized via WinCC OA “system()”
function. With this functionality it is possible to create X.509 based certificates without usage of the cmd-line
interface from openSSL.
ATTENTION
This WinCC OA panel uses only a small set of openSSL commands, to generate a CA and host
certificates.
It is not possible to handle e.g. a Certificate Revocation List (CRL) with this functionality. This
limitation may have a negative impact to the security maturity for the asset owner because it is not
possible to revoke a certificate in field.
In cases where extended openSSL commands are required, it is recommended to prefer the
command line compared to the WinCC OA panel.
In cases where the asset owner already operates a CA with X.509 based certificates the usage of this
certificates is the recommended choice. It may be possible that Security Measurements where already
implemented by the asset owner to protect their CA and so a creation of an additional CA to create
certificates for WinCC OA is not required.
Special functions / Security / Multiplexing Proxy
Page 107 of 271

Please note that certificates created by custom CAs are not trusted by 3rd party software like browsers. So, it
is necessary to import the created CA (root-certificate.pem) into the “Trusted Root Certification Authorities”.
After the deployment of a new certificate it is necessary to restart the WinCC OA mxProxy on the effected
machine to enforce an immediate read of the new certificate; then the connection can be set up again by the
client process, e.g. a UI.
ATTENTION
WinCC OA will not create an alarm if a certificate became outdated and so it is recommended to
configure a reminder to replace the certificates in time.
Depending on the security demands the WinCC OA proxy can be adjusted to needed level of security, e.g.
the redundancy partner can communicate directly while the communication to a distributed project (WinCC
OA Dist Manager) or a UI/Desktop UI is routed over the proxy and therefore is TLS/SSL encrypted.
Special functions / Security / Multiplexing Proxy / MultiplexingProxy,Basics
The usage of the WinCC OA proxy is the default way for secure communication in WinCC OA. It is
automatically activated with every fresh installed WinCC OA project. Another way is the usage of the
Kerberos authentication method instead. This functionality can be configured and detailed information is
available in chapter: Activate encryption for WinCC OA for Kerberos authentication and Usage of Kerberos.
6.2.2.8.1 Alternative communication without WinCC OA mxProxy

Usage of the WinCC OA mxProxy is not mandatory for WinCC OA communication. Inside a secure network
or in a network with active Kerberos communication
(Activate encryption for WinCC OA for Kerberos authentication) it is possible to use TCP communication with
signed and encrypted messages by Kerberos.
When firewalls are configured inside this internal and secure network it is essential to open the required
ports to allow a WinCC OA communication.
A list of all necessary open ports when not using the WinCC OA proxy is shown in the following table:
Port Protocol Description
4776 TCP WinCC OA Redundancy Manager
4777 TCP WinCC OA Distribution Manager
4778 TCP WinCC OA Split Manager
4897 TCP WinCC OA Database Manager
4998 TCP WinCC OA Event Manager
4999 TCP WinCC OA Process Monitoring
Table 8 - Default communication ports used for alive-message communication
The ports can be configured in the config file for the WinCC OA project. This can be necessary if specific
ports are used by other applications or due to plant specific guidelines about the usage of ports.
Page 108 of 271

6.2.2.8.2 Create own openSSL certificates
The explained panel in chapter: Usage of TLS/SSL for plant communication shows only a basic way to
create own certificates by a custom CA. This CA needs special protection and should be placed outside from
the common network infrastructure on site. This recommendation helps to prevent the files from being stolen.
The mentioned panel was developed to create simple certificates without a deeper knowledge about the
opportunities of openSSL directly. In fact, that described panel starts only a few system () commands (this is
a control function from WinCC OA to trigger a system command).
CONTROL / Control functions / Functions S / system()
The openSSL webpage (https://www.openssl.org/ (acc.: 27th March 2019)) show the complete list of
available options to create own certificates. More information can be given by openSSL wiki
(https://wiki.openssl.org/index.php/Main_Page) (acc.: 27th March 2019).
Due to the different options and opportunities of openSSL a deep knowledge of that library is essential for
the creation of specific certificates. This makes it necessary that the implemented command line interface
should only be used by experienced users. At this position ETM professional control GmbH cannot give a
mandatory configuration for the creation of those specific certificates. For all users without this deep
knowledge of openSSL ETM professional control GmbH suggests using the given WinCC OA panel for the
creation of own certificates. This will fulfill the majority part of all security requirements.
Page 109 of 271

6.2.2.8.3 Create and deploy certificates
WinCC OA offers a panel to create own files-based certificates for communication via WinCC OA mxProxy or
WinCC OA HTTP-Server.
Special functions /Security / Create SSL Certificates
Figure 41 - SSL host certificates panel
Page 110 of 271

Following example shows a way how certificates can be created and deployed by usage of this panel.
1. Open the SSL Certificates panel on WinCC OA server machine via SysMgm → Communication
a. Create HTTP root certificate
In Frame Root certificate click: “Create” and enter following data:
Certificate Type: “Certificate for WinCC OA HTTP-Server”
Destination Path: Select config folder from the actual project
Root keyfile password: Type a password, e.g.: “MakeYourProjectC4secure.KeepItSave!”
Expiration in: Select the lifespan of this certificate. The default value is approximate 3 years.
According to the given security requirements by the asset owner a correct lifetime needs to be
configured. It is suggested to give the CA a longer lifetime than the created host certificates. This
allows a defined process to renew the deployed certificates if required.
Country Code: e.g.: “AT”
Province: e.g.: “Burgenland”
City: e.g.: “Eisenstadt”
Organization: e.g. “ETM CA”
Department : e.g. “RD01”
CN Name : This is the Common name used in the certificate,
e.g. select a hostname: “example.server.com”
b. A click on “Create” button creates two new files, inside the config folder:
root-certificate.pem → this is the public root certificate file
root-privkey.key → this is the private root key and keeps the secret for SSL encryption.
These CA-files are used to sign host certificates and should be kept in a secured place.
It is important to keep the passphrase. Without that it is not possible to renew, revoke or create
new host certificates.
The root-certificate creation panel can be closed afterwards.
2. Create WinCC OA HTTP-Server host certificate

a. It needs to be ensured that the input fields in the “Root certificate” frame are filled with the correct
files and the correct password
b. Certificate Type: Select “Certificate for WinCC OA HTTP-Server
c. Destination path: Select config folder from WinCC OA project
d. Expiration in, Country Code, Province, City, Department, and CN Name: The same data as in the
creation of the root certificate can be used.
e. Organization:
This value needs to differ from the value in the creation of the root certificate. This example
suggested “ETM CA” as a value for the root certificate and for the host certificate the value “ETM”
can be used. This is essential due SSL standards otherwise the host certificate is assessed as
altered or corrupted.
f. Click “Create Button”
g. Two new files are created:
• certificate.pem
• privkey.pem
Page 111 of 271

3. Create certificates for WinCC OA mxProxy
a. For creation of WCCILproxy certificate the steps from the HTTP root and host certificates can be
repeated after “Certificate for WCCILproxy” was selected for Certificate Type. It is necessary to
select the correct root certificate files because they are different to the http certificates.
This procedure creates following files in config folder:
root-cert.pem → WinCC OA mxProxy certificate
root-key.pem → root key for the proxy communication who keeps the secret for SSL
communication
host-cert.pem → host certificate for the WinCC OA mxProxy manager
host-key.pem → key file for the WinCC OA mxProxy
4. The entire project with these created certificates needs to be restarted without issuing any error in this
regard.
5. Establish Desktop UI communication
a. Start the “webclient_http.ctl” CTRL script on WinCC OA server machine
b. From client navigate to address to WinCC OA server via Internet Browser (Chrome, IE or Firefox)
and install the application, if necessary.
ETM recommends loading of the root CA certificates into the “Trusted Root Certification
Authorities” store of the browser. This makes the browser aware of any available certificates for the
project. This drops the certificate error from the URL where it is possible to download the setup for
Desktop UI.
c. A creation of a new project (default folder: [User folder]\.wincc_oa-cache) transfers the following
certificates from WinCC OA Webserver to the client machine
host-cert.pem, host-key.pem, root-cert.pem
A repeat of the descripted steps is necessary for every WinCC OA host. The other hosts can use the same
Root CA for their host certificates. It is strongly recommended to create all required host certificates on a
centralized machine with the Root CA and to copy them manually to the WinCC OA hosts.
Note:
It is noted that an open connection between WinCC OA managers (e.g. EVENT to UI, EVENT to
CTRL, REDU to REDU) is not closed, even if the certificate becomes outdated. The next connection
attempt will be denied.
Although an open UI connection stays open after a certificate expired, this cannot be behaved as a
security issue due following reason:
• A theft expired certificate is not usable

• An active connection stays open because of the usage of a session key created during the
initialization event. This session key allows a symmetric encryption between server and client
which allows a higher data transfer performance compared to an asymmetric encryption
mechanism.
This session key was created by the client with the public key of the server. And the private key
of the server started the symmetric encryption.
Page 112 of 271

6.2.2.8.4 Storage of openSSL certificates and private keys
Beside a secure generation of certificates, it is also essential to store them on a client to prevent any
unauthorized extraction of those private keys which could result in a Man in the Middle attack. File based
certificates are protectable with file system access control, and this is suitable for Microsoft® Windows and
Linux if the hosts are secured against unauthorized physical access. To protect those certificates, it is
necessary to implement different IT infrastructure mechanism.
WARNING
Especially the private key of a root CA needs special protection as mentioned by Kapil Raina
“The actual method of issuing certificates involves the CA using its private key to digitally sign the
incoming request for a certificate. By using the CA’s public key, anyone can verify the contents of
the certificate, ensure that the contents have not changed, and ensure that the certificate was
issued from a trusted source. The value of the entire CA process is in its brand and its ability to
protect its private key. Should the private key be compromised, it would cast a shadow of doubt over
all certificates issued by the CA, especially if the exact time of the compromise could not be
established. Furthermore, many certificates issued after the CA private key compromise would have
to be revoked, creating massive end-user logistical problem. Realistically, a compromise of a CA
private key would most likely lead to the end of the CA’s business because the brand would
severely tarnished.”
(Raina, 2003, S. 30)
This treat makes it necessary to keep the private key of a root CA always secure and if necessary,
to transfer it only via secure channels by IT infrastructure measurements like encrypted E-Mails or
storage devices.
6.2.2.8.4.1 File based certificates

After the creation of certificates, it is necessary to ensure a secure deployment and storage. Especially the
private keys need to be protected to avoid a threat caused by a stolen certificate.
• Protect folder which contains certificates on WinCC OA Server

A folder which contain the required certificates for private- and public key are usually protected via
ACL settings because they may be part of the project folder itself
(see chapter: Definition of Access control List (ACL)).
The recommendation from the chapter above ensures that only the Plant administrator has written
access to configuration files. Other users like the machine account which executes the project need
read access to validate the certificate and to set up a connection.
• Protection of certificates for Desktop UI

WinCC OA http server deploys all required files from the server to the client machine and this will
also affect the transfer of the required certificates. Due to the behavior that this process will copy all
required files into the user cache folder of the operator, those files are not protectable via OS
measurements and the definition of ACL settings. A possible solution is a manual deployment of
private keys into a zone where the certificates are protected, and details are explained in chapter:
Page 113 of 271

• Protection of certificates on Mobile Devices
Please note that Mobile Devices uses the same mechanism to deploy certificates into a local cache.
In a default configuration those certificates are not protectable and such devices must not be used in
an operation environment that needs a high level of security
(see chapter: Intended operational environment (UI).
• Protection of certificates for WinCC OA video

Certificates which are used to implement a secure Video stream can be created, details are
explained in chapter: Configuration Settings for WinCC OA Video (vimaccOA).
• Protection of TLS certificates for encryptable driver communication

WinCC OA uses drivers which uses the TLS method to encrypt the message between driver and
PLC, see chapter: Create and deploy certificates. The required certificates need to be created and
deployed according to WinCC OA documentation.
Page 114 of 271

6.2.2.8.4.2 Windows certificate store
Beside the file-based certificates it is also possible to store certificates for mxProxy with OS mechanism.
A possible way is offered by Microsoft® Windows.
The Microsoft Management Console (MMC) Snap in “Certificates” offers a way to store and distribute
certificates inside a Windows Platform. This system needs own certificates which combines the certificate
with the private key in a PKCS12 format.
Here is an example how those certificates can be created:
With existing certificates already created using the WinCC OA certificate panel the following openSSL
commands will convert the required certificates:
• RootCA:
openssl pkcs12 -export -in root-cert.pem -inkey root-key.pem -out rootCert.pfx
• HostCerticate:
openssl pkcs12 -export -in host-cert.pem -inkey host-key.pem -out hostCert.pfx
The created certificate files are importable into the Certification MMC from Microsoft® Windows. The given
example uses the Computer Certificate store. To access this store, it is recommended to open the MMC
console as an administrator and select the “Computer account” for “Certificates” Snap-in. Usage of
“Computer account” is recommended to bind the certificate to a computer instead of a user.
Figure 42 - Certificates Snap-in for MMC
To allow reading it is important to check the “Mark this key as exportable…” checkbox for the host certificate.
Page 115 of 271

Figure 43 - Settings to import PKCS12 certificate
The root certificate must be part of the Trusted Root Certification Authorities and the Host Certificate should
be stored into the Personal Certificates. A successfully imported certificate will show the reference to the
private key and a verified certification path including a certification chain host to the certification authority:
Page 116 of 271

Figure 44 - Imported host certificate and certification chain (chain of trust)
To complete this example the following line needs to be added to the config file from the WinCC OA project:
[general]
securityMode = "winCert"
winCert = "MACHINE:MY:W2012_RCC_WEST"
winRootCA = "MACHINE:ROOT:RootCA"
This configuration reads the certificates from the Windows certificate store instead of directly from the file
and former activities about deployment could be applied.
Page 117 of 271

6.2.2.8.4.2.1 Configure Read Permission for Private Key to WinCC OA Users
Although the created certificates by this configuration are readable by the local machine account,
(see chapter: Start a WinCC OA project as a service) it may be possible that the logged in user is not able to
read the private key, if a UI is required. In those cases, it is necessary to apply read permission to the private
key for the group of configured WinCC OA users.
The following screenshot shows how this configuration can be applied inside an MMC. Within the popup
menu, from the required certificate, it is possible to manage the privileges of private keys. The permission
settings of the required certificate show that a Read-Permission was granted to the group of
WinCCOAUsers.
Figure 45 - Configure Read Permission to Private Key for WinCC OA Users
Page 118 of 271

6.2.2.8.4.2.2 Install certificates into User Account instead Machine account
Alternatively, it is also possible to install the certificates for the “Current Users” instead “Local Computer” as
explained in this screenshot:
Figure 46 - Certificate in store of Current User
If this way is chosen it is necessary to adapt the configuration and to read the certificate from the “USER”
store instead the “MACHINE” store.
[general]
securityMode = "winCert"
winCert = "USER:MY:W2012_RCC_WEST"
winRootCA = "USER:ROOT:RootCA"
ATTENTION
Those certificates are exportable and could be used by an attacker if he was able to hijack a
machine with valid certificates. The attacker could export the valid certificates and use them with a
different machine for an attack. Therefore, it is essential to consider the Defense in Depth approach
and to secure all machines to protect them from any theft or misusage. A theft device with a stolen
certificate should result into an intermediate task where all certificates need to be replaced to keep
the level of security and to prevent the hacker from doing any harm to the site facility.
Page 119 of 271

6.2.2.8.5 Usage of certification chain
The WinCC OA client config entry chainPrefix allows the client to connect only to hosts via mxProxy that
have specific named certificates or certificates from a certain CA/Sub-CA with a configured content. It is
recommended to configure this setting to avoid a Man in the Middle attack scenario in an environment
with unsecure clients.
Example based on this configuration:
Figure 47 - Example for chainPrefix
Description: PenTestSRV01 runs with WinCC OA Data- and Event Manager including
WinCC OA mxProxy, PenTestWEB runs with a WinCC OA HTTP-Server and PenTestClient is a simple
Windows 10 client.
This means that the client can assure that the client is connecting to the correct server by usage of the
chainPrefix, only if the Server uses the certificates which the client chainPrefix config specifies the
connection is set up. To make this useable the certification Path of the server certificates and the client
certificates needs to be different. It increases the protection from a stolen certificate from a client where it
could be possible to use this certificate to decelerate the own machine as a server project to start a Man
in the Middle attack.
The config file configuration shown below is an example for the usage, the name of the RootCA is the 1st
position, the 2nd position gives the name of the certificate where a wildcard is automatically added, and
therefore a client certificate could also be named PenTestFirst or PenTestSecond but not PenMachine.
The following configurations apply to configure a certification chain:
1. PenTestClient runs with a Remote UI

Enter following line into the config file from the UI project:
[general]
chainPrefix = "RootCA;PenTest"
2. PenTestClient run as Desktop UI.

Enter following line into the config.webclient file from PenTestWEB:
Page 120 of 271

[general]
3. PenTestClient runs as ULC UX

Enter following line into the config file from PenTestWEB:
[general]
All those configurations will harden the system to allow only certificates that fit to the configured CN-
Name. All other names or contents are interpreted invalid and the connection is denied.
For security reasons it is important to protect the config folder to prevent them from altering by an
unauthorized user. This must be configured on OS level, see chapter: Access control.
Page 121 of 271

6.2.2.8.6 Enforce usage of strong cipher suite
To ensure a good and secure connection between two nodes of a WinCC OA project the usage of a strong
cipher is recommended. This is also recommended by BSI in following document.
https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-
02102-1.pdf?__blob=publicationFile&v=8 (acc.: 04th Feb. 2019).
A WinCC OA project can enforce the usage of a strong cipher with the config entry: “cipherSuiteList”. This list
contains a comma separated list of all cipher suites which can be used for communication. The server
chooses the first cipher suite of his list which is also offered by the client.
Although openSSL understands many different cipher suites, the list of useable cipher suites in WinCC OA is
limited, according to following table.
Cipher Suite Description
AES128-SHA Deprecated
AES256-SHA These cipher suites exist for compatibility reasons and must
not be used on secure systems due to a weak MAC algorithm.
AES128-SHA256 RSA Certificates and private keys are used for key exchange
AES256-SHA256 and partner authentication. Key exchange and authentication
are done with RSA.
DHE-RSA-AES256-SHA256 The Diffie–Hellman key exchange method allows two parties
DHE-RSA-AES256-GCM-SHA384 that have no prior knowledge of each other to jointly establish a
DHE-DSS-AES256-GCM-SHA384 shared secret key over an insecure communications channel.
Key exchange is done with DHE, while authentication is done
with RSA certificates.
ECDHE-RSA-AES128-GCM-SHA256 Elliptic curve Diffie–Hellman (ECDH) is an anonymous key

ECDHE-RSA-AES256-GCM-SHA384 agreement protocol that allows two parties, each having an
elliptic curve public–private key pair, to establish a shared
secret over an insecure channel. Key exchange is done with
ECDHE, while authentication is done with RSA certificates.
Attention
These ciphers suites supports only communication via WinCC
OA mxProxy and not http communication via WinCC OA
httpServer.
Table 9 - List of useable cipher suits in WinCC OA
Page 122 of 271

Following example shows a secure example to configure this config entry. If both ciphers are existing on
WinCC OA server and WinCC OA UI the cipher “ECDHE-RSA-AES256-GCM-SHA384” will be used for
mxProxy communication. The second cipher will be selected by WinCC OA httpServer because an ECDHE
key exchange mechanisms is not supported by this service. This cipher uses RSA for key exchange instead.
cipherSuiteList = "ECDHE-RSA-AES256-GCM-SHA384,ECDHE-RSA-AES128-GCM-SHA256,AES256-
SHA256"
WARNING
The usage of cipher suite “AES256-SHA” with this config entry on a WinCC OA server will allow an
attacker to enforce the usage of a weak cipher. The following line gives an example for a weak
configuration of this config entry:
cipherSuiteList = "ECDHE-RSA-AES256-GCM-SHA384,AES256-SHA256,AES256-SHA”
An attacker has only to add following line on a client machine to enforce the usage of a weak cipher:
cipherSuiteList = "AES256-SHA”
This attack is possible because the client informs WinCC OA server that a communication via
“AES256-SHA” protocol is requested and WinCC OA server accepts it because it is inside the list of
valid and accepted cipher suits.
This attack scenario can be prevented by removing the weak cipher from the list of acceptable
ciphers on the WinCC OA server. In this case the WinCC OA server denies the connection, when a
client understands only a weak cipher.
Page 123 of 271

6.2.2.9 Protection via authorization levels in WinCC OA
The definition of operation authorizations for workstations is an elementary and integral part of WinCC OA.
The standardized authorizations are mapped with the help of levels (bits).
A set of authorization levels are predefined in WinCC OA and used in some panel for a client-side
authentication check by usage of the CTRL function getUserPermission(). Among other things those
permission bits are used to check if a user has the permission to open a specific panel (e.g.: SysMgm).
Beside the client-side panel check it is also possible to implement a server-side authorization check by
adding _auth configs to datapoints (see chapter: Add authorization config to Datapoint).
The predefined set of authorization levels is defined as follows:
1. Visualization: This permission bit allows the reading of panels. This authorization
level is declared as 'bit 1'.
2. Operating authorization: This permission bit allows to open detail panels. This authorization
level is declared as 'bit 2'.
3. Extended operating authorization: The user can execute commands, set substitute and correction
values and change ranges of values.
4. Administration: The user can use the module 'PARA' (for the configuration of the
data model). Further the WinCC OA System Management can be
used for the configuration of the plant.
5. Acknowledgement: This level authorizes the acknowledgement of alerts.
Those authorization levels can be altered, or additional levels can be configured during the development of a
WinCC OA project by the Integrator. This approach offers a way to implement a tailored authorization check.
Note:
The operation authorization "authorization level 2" as 'bit 2' is linked to the "authorization level
1", the 'bit 1'.
The level 'bit 2' for opening panels can be assigned only if the authorization level 'bit 1'
(Visualization) has already been defined as the operation authorization.
Bit32 has a special meaning and is used to configure the Single Sign On functionality (SSO) for
workstation hosts (see chapter: Single Sign On).
Page 124 of 271

Assigning this principle of bit-based operation authorizations is displayed in the following screenshot.
Figure 48 - Default user role in WinCC OA
This permission bit can be evaluated within WinCC OA in the following way.
Page 125 of 271

6.2.2.9.1 Add authorization config to Datapoint
It is possible to add an authorization (_auth) config to a Datapoint which needs protection. This allows deciding
which config is worth being protected. So, it is possible to define a user which has permission bit 3 that is
needed to set an original value or to manipulate an existing alert handling config. A few Datapoints within a
newly created WinCC OA project are already protected by this mechanism.
Figure 49 - Datapoint with authorization config
CTRL function getUserPermission() with a permission bit as parameter checks if the actual user has the
required permission bit. With this function it is possible to create a project specific CTRL code to limit the
navigation and control permission to a limited number of authorized users.
Due to compatibility reasons it is not possible to provide a configuration database with fully configured _auth
config settings. It is recommended by ETM professional control GmbH to protect system essential Datapoints
with an authorization config to make a Server-side authorization check possible and to avoid the risk that
unauthorized users gain control of the client. Most of the internal WinCC OA Datapoints are protectable via
an authorization (_auth) config.
Although this configuration is possible by project specific tailoring, some DPE must not be protected with an
_auth config. Reasons are special circumstances where a DP update is needed, even if no user is currently
logged in (e.g. The login panel needs the _Ui DP to open a module to ask for user credentials).
6.2.2.9.2 Example for protection of internal WinCC OA Datapoints

The following lines show a way how the internal WinCC OA Datapoints could be protected with “_auth”
configs for special Datapoints where an own configuration is needed.
In this example most of the Datapoints are protected with “_auth” config level 4 where at least the para user
must update those Datapoints. The following lines show a CTRL code to configure all internal Datapoints in 3
steps.
Page 126 of 271

Please keep in mind that new versions or patches of WinCC OA may have more Datapoints and they must
be configured separately if needed. These three steps describe only the required steps to configure the
internal Datapoints from WinCC OA. The project and tailored specific Datapoints from a WinCC OA project
must be configured in a similar way. Security awareness on the Datapoints with outgoing address config
(e.g. switches) is strongly recommended. Only an authorized user should be allowed to trigger specific
switches.
It is recommended to repeat these steps on a regular basis. Some Datapoints (e.g. _AESProperties) are
created dynamically by the system and they will be created without an existing authorization config.
1. First step: Protect all Datapoints with _auth config level four.
The following lines get all internal Datapoints even those without a leading prefix and add an auth
config with level four to each of them. This script also ignores all Master Datapoints.
dyn_string allVal;
//general setting for all internal Datapoints
//get list for all Datapoints with leading _

allVal = dpNames( "_**" );
//append Datapoint list with internal Datapoints without leading _

dynAppend( allVal, dpNames( "*", "_AlertClass" ));
dynAppend( allVal, dpNames( "*", "_AlertHorn" ));
dynAppend( allVal, dpNames( "*", "_CommCenterDomains" ));
dynAppend( allVal, dpNames( "*", "_HistSynch" ));
dynAppend( allVal, dpNames( "*", "_IS_TableType" ));
// this loop will configure all internal Datapoints where a permission bit 4 could be placed.
for(int i=1; i<=dynlen(allVal); i++)
{
//check and ignore MasterDP
if(strpos(dpSubStr(allVal[i], DPSUB_DP), "_mp_") != 0)
{
dpSetWait(allVal[i] + ".:_auth.._type", 62,
allVal[i] + ".:_auth._original._write", 4,
allVal[i] + ".:_auth._dp_fct._write", 4,
allVal[i] + ".:_auth._address._write", 4,
allVal[i] + ".:_auth._default._write", 4,
allVal[i] + ".:_auth._u_range._write", 4,
allVal[i] + ".:_auth._pv_range._write", 4,
allVal[i] + ".:_auth._alert_hdl._write", 4,
allVal[i] + ".:_auth._alert_class._write", 4);
}
else
{
DebugTN("ignore MasterDP: ", allVal[i]);
}
}
Page 127 of 271

2. Second step: define Datapoints and Datapoint elements where a protection with auth config level 1
is needed.
dyn_string allVal = dpNames( "*", "_Ui" );

dynAppend( allVal, dpNames( "*.Password", "_Users" ));
dynAppend( allVal, dpNames( "_AESPropertiesRT*", "_AESProperties" ));

{
if (strpos(allVal[i], ".") > 0)
{
//dpSet for DPE
dpSetWait(allVal[i] + ":_auth.._type", 62,
allVal[i] + ":_auth._original._write", 1,
allVal[i] + ":_auth._dp_fct._write", 1,
allVal[i] + ":_auth._address._write", 1,
allVal[i] + ":_auth._default._write", 1,
allVal[i] + ":_auth._u_range._write", 1,
allVal[i] + ":_auth._pv_range._write", 1,
allVal[i] + ":_auth._alert_hdl._write", 1,
allVal[i] + ":_auth._alert_class._write", 1);
}
else
{
//dpSet for DP
allVal[i] + ".:_auth._original._write", 1,
allVal[i] + ".:_auth._dp_fct._write", 1,
allVal[i] + ".:_auth._address._write", 1,
allVal[i] + ".:_auth._default._write", 1,
allVal[i] + ".:_auth._u_range._write", 1,
allVal[i] + ".:_auth._pv_range._write", 1,
allVal[i] + ".:_auth._alert_hdl._write", 1,
allVal[i] + ".:_auth._alert_class._write", 1);
}
}
Page 128 of 271

3. Last step: Define Datapoint where an auth config must not exist if the default client-side
authentication is activated. This step can be canceled if the recommended SSA feature is activated.
SSA (see chapter: Activate Server-Side authentication) allows more security functionality and
increases the protection from security attacks. Using this feature, it is also possible to set more _auth
configs to protect the system from hijacking. The positive effect is that a deactivation of the _auth
config as described in the earlier step is not necessary and so at least the permission bit 1 could be
activated for these DPEs.
dyn_string allVal = dpNames( "*.UserName", "_Ui" );

dynAppend( allVal, dpNames( "*.ModuleOn", "_Ui" ));
dynAppend( allVal, dpNames( "*.ModuleOff", "_Ui" ));
dynAppend( allVal, dpNames( "*.PanelOff", "_Ui" ));
dynAppend( allVal, dpNames( "*.RootPanelOn", "_Ui" ));
dynAppend( allVal, dpNames( "*.RootPanelOrigOn", "_Ui" ));
dynAppend( allVal, dpNames( "*.ChildPanelOn", "_Ui" ));
dynAppend( allVal, dpNames( "*.Inactivity", "_Ui" ));
dynAppend( allVal, dpNames( "*.DisplayName", "_Ui" ));
dynAppend( allVal, dpNames( "*.Result", "_CtrlDebug" ));
dynAppend( allVal, dpNames( "*.SessionToken", "_Ui"));
dynAppend( allVal, dpNames( "_CtrlCommandInterface_1", "_CtrlCommandInterface"));

{
if (strpos(allVal[i], ".") > 0)
{
dpSetWait(allVal[i] + ":_auth.._type", 62,
allVal[i] + ":_auth._original._write", 0);
}
else
{
allVal[i] + ".:_auth._original._write", 0);
}
}
ATTENTION
Some DPEs like “_Users.Password” are only protectable in cases where other features like external
authentication (see chapter: Usage of WinCC OA external authentication method) or SSA (see
chapter: Server-Side Authentication) is configured.
The WinCC OA Standard authentication method needs write permission for a user who wants to
change his own password, even in case where this user possesses only reading permission. An
external authentication method or SSO are using a different method to update the password. Please
check also warning phrase in chapter Usage of Operating system (Windows or Linux) based user
management.
Page 129 of 271

6.2.2.10 Access Control via Area authorization
Areas are logical or geographical zones of e.g. a tunnel or a plant. As an example, let’s assume a tunnel that
is divided into different areas and run by users assigned to different groups. Users of these groups can have
different rights for different areas (parts of the tunnel) depending on permission bits set for a combination
Group-Area.
The pairs Group-Area are defined with User administration panels through definition of the group
membership in the areas. The permission bits that were set for a pair Group-Area can be further evaluated
within Control scripts for example in a panel with functions described below and processed in needed way
(by means of e.g. “IF” instructions).
Please consider following demo configuration for a detailed explanation:
• There are three different areas tunnel1, tunnel2 and tunnel3
• There are three user groups OpAll_tunnel1, OpAll_tunnel2 and OpAll_tunnel3
• There are following pairs Group-Area (memberships of groups in areas)
o OpAll_tunnel1: Member of areas: tunnel1 and tunnel2
o OpAll_tunnel2: Member of areas: tunnel2 and tunnel3
o OpAll_tunnel3: Member of area: tunnel3
• Permissions for pairs OP_All_tunnel1-tunnel1 and OP_All_tunnel1-tunnel2 configured as:
Figure 50 - Permission bits for pairs OpAll_tunnel1- tunnel1/tunnel2
Page 130 of 271

• OP_All_tunnel2-tunnel2/tunnel3 :
Figure 51 - Permission bits for pairs OpAll_tunnel2-tunnel2/tunnel3
• Op_All_tunnel3:
Figure 52 - Permission bits for the pair OpAll_tunnel3-tunnel3
Page 131 of 271

The example of effective permission bit matrix in WinCC OA for a selected user:
Figure 53 - Effective user permissions for user tunnelOperator1
In total, WinCC OA allows to implement a granular permission matrix for every environment with different
Control functions of WinCC OA. Two of them:
• getUserPermission: This command will always deliver ’true’ if Permission Bit 4 is evaluated for the
user tunnelOperator1 shown on the Figure 28. The area is not evaluated in this function.
• getUserPermissionForArea: This function also needs the area name as mandatory parameter. It will
still deliver the value ‘true’ if the permission bit 4 is evaluated for area tunnel1, but it will deliver ‘false’
if the permission bit 4 is evaluated for area tunnel2.
This feature makes it possible to implement a region-specific permission concept.
System management / Authorizations / Areas
Page 132 of 271

6.2.2.11 Activate Kerberos encryption for WinCC OA systems
Every communication between two devices can be easily intercepted and used for the harm of the company.
Therefore, it is recommended to encrypt the communication. In the default configuration WinCC OA uses the
openSSL encryption method via WinCC OA mxProxy.
As an alternative solution it is also possible to use Kerberos security instead. With activated Kerberos setting
with an AD controller it is also possible to encrypt the message traffic by OS mechanism.
With WinCC OA an encryption can be activated using the config entry:
[general]
kerberosSecurity = “enc”
6.2.2.12 Restrict SNMP driver communication to SNMPv3

WinCC OA is designed as open system and therefore SNMPv1 and SNMPv2 can be used even though no
security features are available.
If the plant has a high demand of security it is recommended to restrict the configuration to SNMPv3.
Page 133 of 271

6.2.2.13 Distributing the Tasks on several Computers
Using WinCC OA on the same computer as other services (e.g. WinCC OA and a Windows Domain
Controller) is explicitly not recommended!
Starting several projects on one computer stands for a security threat due to a failure of one part will have
impact on other components and can lead to multiple failures.
Due to this fact ETM professional control GmbH recommends:
• Run WinCC OA Servers and Active Directory controller on separate physical or virtual machines.
• Run WinCC OA and Oracle server on different physical or virtual machines.

• It is prohibited to start multiple WinCC OA project instances on the same machine. As an alternative
it is possible to create virtual images (e.g. on an ESXI Server), but every virtual instance must not
run more than one WinCC OA project at the same time.
Non-conformance in these points, e.g. the usage of multiple WinCC OA project instances on the same
machine shall only be made after consulting ETM professional control GmbH to ensure the availability of
necessary system resources.
6.2.2.14 Start a WinCC OA project as a service

Hardening can be achieved by starting the WinCC OA project as service with a specific user account. This
allows restricting the access of the project to specific resources.
With this modified configuration a second security layer is added. Access to files and other resources is
limited by restricted permissions for the user starting the service.
A basic rule is that services should always be started with the least necessary amount of privileges. ETM
professional control GmbH recommends the usage of a managed service account due to the higher security
level compared to the other options when only the default configuration is used.
In general, following options in configuration of a service are possible:
• Starting the service under NetworkService Account. The project user has no rights on the system.
The necessary privileges can be added for the network service user on the local machine. No
access to other systems is needed.
• Starting the service under Managed service account is favored. The managed service account is a
Windows specific user with a periodic update of the password in comparison to the NetworkService
account.
• Starting the service under Specific user. Freely configurable management of privileges for the
current and unknown systems.
For all options it is mandatory to configure the required folder permissions for the project and the WinCC OA
installation folder. Details about the required permissions see chapter: Access control.
Details about the configuration and installation of WinCC OA as a service are available in WinCC OA
Documentation for Microsoft® Windows and Linux based systems.
Installation / Windows / WinCC OA as service

Installation / Linux / WinCC OA as service
Page 134 of 271

6.2.2.15 Usage of WinCC OA Access Control Plug-In
Although a default WinCC OA installation holds an amount of security layers, it is possible to increase this
given security level by usage of WinCC OA Access Control Plug-In.
For example, API plug-in allows denying the read access to Datapoints for a specific user. WinCC OA API
can be used to implement a high number of hardening features by the plant operator during the project
development.
The necessary configuration must be implemented by developers using the WinCC OA API class “Security
Plugin” (name of the API class reference).
Add-Ons / API / Access Control Plug-in
More details about ways for implementation are available within Doxygen-help from the API
installation ([WinCC OA Setup Folder\api\doc\index.html:
WinCC OA API\Classes\Class List\SecurityPlugin
or via direct link:

[WinCC OA Setup folder] \api\docu\class_security_plugin.html
Page 135 of 271

6.2.2.16 Disable Automatic Unlock for Mobile Devices (Android and iOS) and Desktop UI
To allow an easy connection of new devices the feature for an automatic unlock of new devices is active for
all new created WinCC OA projects.
To increase the security aspect, it is possible to disable the automatic unlock feature within the device
management panel. If this feature is disabled, it will be necessary to manually unlock every new connected
device by a site administrator.
Note:
Activated SSA needs unlocked devices as well (see chapter:

Server-Side Authentication for User Interfaces).
Figure 54 - Disable Automatic Unlock for mobile devices and WinCC OA Desktop UI
6.2.2.17 Define Reporting Manager as predetermined breaking point

To avoid a negative impact like a DoS attack to the productive system via reporting interface it is recommend
placing that Reporting Manager in a DMZ. This should help to protect the WinCC OA system inside the
trusted network zone. With a correct configuration a DoS attack will not cause any negative CPU and
Memory load impact to the WinCC OA servers.
Additionally, it is recommended to store created reports on a network share. This allows a configuration,
where an allowed but unsecured client can read data without query them from a running WinCC OA system.
Page 136 of 271

6.2.2.18 Secure driver communication
WinCC OA offers different protocols for communication between WinCC OA drivers and periphery devices
like a PLC. In dependency of the implementation different methods needs to be considered.
6.2.2.18.1 Recommendations for encryptable protocols
6.2.2.18.1.1 Create and deploy TLS certificates

Following WinCC OA drivers use TLS technology and certificates to ensure an encrypted communication
between driver and PLC.
• WinCC OA S7Plus driver

• OPC Unified Architecture driver
• TLS Gateway driver
• IEC 60870-5-104 driver

• MQTT client
It is recommended to read the manuals of those drivers carefully in WinCC OA documentation. Some of the
described drivers are provided with default certificates to ensure a fast deployment on site. But those
certificates must not be used in live operation due to security reasons. A default certificate is comparable
with a default password of a device and this means everybody may be able to get the secret very easily and
may start a threat with this knowledge.
6.2.2.18.1.2 OPC UA configuration

The OPC UA protocol could be vulnerable for attacks and different security bullets are collected by the OPC
foundation. Information regarding these bullets is available with following webpage:
https://opcfoundation-onlineapplications.org/faq/#t=SecurityBulletins.htm (acc.: 27th March 2019).
To reduce the level of attack a few recommendations for configurations are given by the OPC foundation.
Detailed information is available here:
https://opcfoundation.org/security/ (acc.: 27th March 2019).
Page 137 of 271

6.2.2.18.1.3 Definition of MQTT broker
The WinCC OA MQTT driver operates as a client in a MQTT system. It reads and provides data from and to
a centralized MQTT broker. The figure below shows a typical implementation.
Figure 55 - WinCC OA as MQTT client
WinCC OA provides the MQTT client as a driver which can establish a connection to an MQTT broker.
Different vendors do provide MQTT brokers and ETM cannot give a specific recommendation for a special
vendor. The vendor of the MQTT broker must be chosen very carefully by asset owner or the Integrator.
Following points must be considered in the selection process of a MQTT broker:
• Communication between MQTT client and MQTT broker must be encrypted with a state-of-the-art
protocol like TLS.
• Hardening Guide for the selected MQTT broker is available and implemented.
6.2.2.18.1.4 Usage of encrypted communication between Driver and PLC like S7-1500 Controllers
Even if WinCC OA offers different security functions for a plant system, no 100% security for false signals
sent to the PLC can be granted. Siemens recommends the usage of Scalance S-Modules or the usage of
S7-1500 controllers with integrated security features for plants with higher security demands. Especially
newer configuration protocols like the S7+ driver support the encrypted communication to an S7-1500 PLC.
Details and contact information concerning these Siemens modules can be found on following Website:
http://w3.siemens.com/mcms/industrial-communication/en/scalance/Pages/default.aspx
(acc.: 27th March 2019).
Page 138 of 271

6.2.2.18.2 Recommendations for unencrypted protocols
6.2.2.18.2.1 Drivers with Ethernet connection

Some older driver protocols do not support a secure communication between a PLC and the WinCC OA
driver running on a dedicated machine. This also applies to secure driver-based communication between two
WinCC OA nodes running on different hosts.
For those protocols it is essential to implement more security configurations if the nodes are not running
within the same security cell and are vulnerable for Man in the Middle attacks. In those cases, it is essential,
for security reasons, to handle those nodes as 2 different security cells to prevent such attacks on the IT-
infrastructure level. Some authorities recommend different ways to set up a security communication for an
unsecure protocol. Usually a VPN communication is recommended between those nodes, to prevent any
observation or manipulation of the transmitted messages.
See chapter: Secure security cell link via IT Infrastructure.
The following figure shows a possible implementation by usage of a remote WinCC OA driver host which
delivers the received data to a redundant pair of WinCC OA hosts. It is also possible to execute the remote
drivers directly on the redundant pair of WinCC OA server, but this example gives a possible solution to
reduce the scaling workload by usage of a specific architecture. It is also possible to extend this architecture
by usage of a distributed WinCC OA system.
Figure 56 – Protect unsecure WinCC OA driver communication with Secure Tunnel
Page 139 of 271

The figure above gives only a possible example to set up a connection between different security cells which
use an unsecure protocol for communication. In that case it is essential to implement security measurements
via IT infrastructure.
This recommendation is valid for all unsecure protocols, it is essential to harden the environment if any of
these functionalities is used.
ATTENTION
Although usage of a fully encrypted protocol is recommended the majority of WinCC OA driver uses
an unsecured communication protocol. This leads to the recommendation that most of the
communication between driver and device must be done in a secure environment.
It must be mentioned that only following protocols use a secure communication between WinCC
OA and the device:
• WinCC OA S7Plus driver
• OPC Unified Architecture driver
• SNMPv3 driver
• TLS Gateway driver
• IEC 60870-5-104 driver
• MQTT driver
Page 140 of 271

6.2.2.18.2.2 Drivers with serial connection (RS232, V.24, COM)
Some WinCC OA drivers use a serial interface to set up a connection between WinCC OA and the PLC or
periphery device. Although other protocols like Ethernet connections are standard for this connection, some
technical facilities use a serial protocol.
Following WinCC OA drivers use this method:
• DNP3
• IEC60870-5-101
• RK512
A mixed communication mode is supported by protocols like IEC60870-5-101. This mode allows an RTU 101
device to communicate to a V.24 converter with a serial connection. The converter translates the serial
communication into an ethernet protocol, which can be protected with a secure tunnel.
Following figure shows a comparison of both options. In this case the Ethernet connection between WinCC
OA driver and V.24 converter is protected via VPN encryption.
Figure 57 - Compare Ethernet- to Serial protocol protection
This figure shows a WinCC OA server project which establish a connection to an RTU 101 device. Each
device is running as a security cell. For configuration of a connection two options are possible:
1. IEC101 is connected via an Ethernet protocol and the connection is protected with a VPN tunnel.
Inside the security cell the ethernet protocol is translated to a V.24 protocol. This scenario avoids a
MITM attack threat.
IEC 101 is directly connected via serial cable to an RTU 101 device.
Although this connection method ensures a point to point connection it may be possible that the message
traffic could be vulnerable to an eavesdropping attack. A standard radio receiver may be able to pick-up the
transmitted signals (Smulders, 1990).
To avoid an attack scenario the usage of a shielded RS232 cable should be mandatory to reduce the risk
of a MITM attack for this connection.
Page 141 of 271

“RS-232 circuits also have a limitation on cable length. This is because it does not take advantage of the
twisted-pair style cable which reduces line noise through differential mode rejection.”
(Zvarych, A.G.; Pomales, I.; Rodriguez, J.; Villasmil, D., 2014)
A shorter cable length reduces also the possibility of an attack and the Baud rate specifies the maximum
cable length. A Baud rate of 19200 allows a maximum length of 15 meter but a Baud rate of 2400 allows a
cable length of more than 900 meters. Overland connections between buildings must be specially secured
by IT infrastructure measurements.
6.2.2.18.2.3 Other protocols – XML-RPC

XML-RCP (Extensible Markup Language Remote Procedure Call) interface should only be used in a secure
environment where an attack scenario is avoided by IT infrastructure.
In cases where a connection to an XML-RPC server is needed, a secure connection can be configured by
usage of the “secure” parameter within the xmlrpcConnectToServer() function.
Special functions / XML-RPC
Page 142 of 271

6.2.2.19 Digital signatures for binaries and libraries
6.2.2.19.1 Check digital signatures for Windows systems

Installation packages from WinCC Open Architecture uses the extended validation technology for digital
signing of all installation packages.
https://en.wikipedia.org/wiki/Extended_Validation_Certificate (acc.: 27th March 2019).
The packages are signed with a timestamp as a best practice method, this ensures that the digital signature
will not expire even when the certificate is expired (https://theniceweb.com/archives/491 acc: 09th May 2019).
Based on this mechanism a SHA256 hash is created to prevent installation packages from manipulation.
Every manipulation will result into a loss of the digital signature and the setup package becomes corrupt.
Consequently, an installation attempt is denied by OS settings.
Figure 58 - Signature for Desktop UI installation package
Page 143 of 271

Beside the installation packages WinCC Open Architecture specific executables and libraries are also
protected by a SHA-256 hash algorithm verified by VeriSign.
Figure 59 - Digital signature for executable
This mechanism works automatically for every installation package within a Microsoft® Windows OS system;
there are no further steps for verification necessary. In detail it is possible to adjust the GPO settings of the
Windows system to configure the validation settings if needed.
In the case of self-developed API manager, drivers or control extensions these binaries should be also
signed with the customers certificates.
Page 144 of 271

6.2.2.19.2 Linux
This mechanism works on a private key handled inside the workspace from ETM professional control GmbH.
A check of the digital signature is possible in combination with the public key which is available inside the
RPM installation package of ETM professional control GmbH. This mechanism protects every RPM package
from manipulation.
A check of installed files from an RPM-package is possible with the rpm command with the –V flag. For
example, an “rpm -V WinCC_OA_3.16-base-sles” or “rpm -V WinCC_OA_3.16-base-rhel” checks all installed
files, from this package and generates a list with detected manipulations.
Code Meaning
S File size differs
M File mode differs
5 The MD5 checksum differs
D The major and minor version numbers differ on a device file
L A mismatch occurs in a link
U The file ownership differs
G The file group owner differs
T The file time (mtime) differs
Table 10 – Faults in RPM file check
To implement a periodic check of the installation it is necessary to generate a script-based environment

which checks periodically the installation and warns the user if a manipulation is detected.
As an example, a check was implemented into the start_pvss2 script from the WinCC OA installation on
Linux systems. Here is a snippet from the manipulated Shell script file. The modifications began in line #143
from the original script. The manipulated content is marked with a yellow back color.
Within this script package verification is triggered every time when start_pvss2 is executed. It writes the
result to a temporary file, checks for a MD5 checksum and denies the startup if an alteration was detected.
The yellow highlighted lines where manipulated compared to the original start_pvss2 file which comes with
the default setup of WinCC OA.
Page 145 of 271

……
HP-UX)
if [ "x${SHLIB_PATH}" = "x" ] ;
then
SHLIB_PATH=${SHLIB}
elif [ `expr "${SHLIB_PATH}___EOL___" : "${SHLIB}___EOL___"` = 0 -a `expr "${SHLIB_PATH}" :
"${SHLIB}:"` = 0 ] ;
then
SHLIB_PATH=${SHLIB}:${SHLIB_PATH}
fi
export SHLIB_PATH
;;
esac
#create text file with verification details

rpm -V WinCC_OA_3.16-base-sles > /tmp/verifyWinCCOA
#remove altered config file from check

sed -i '/config\/config/d' /tmp/verifyWinCCOA
#check for MD5 checksum failed flag

cut -d " " -f 1 /tmp/verifyWinCCOA | grep 5 > /dev/null
if [ "$?" == 0 ]
then
echo 'MD5 checksum verification failed. Details:'
cat /tmp/verifyWinCCOA
exit 1
else
echo 'Everything OK start WinCC OA'
fi
if [ "$stopOpt" != "" ]
then
( set -x; cd $PVSS_PATH/bin; ./WCCILpmon $stopOpt -PROJ ${PROJ} )
else
( set -x; cd $PVSS_PATH/bin; ./WCCILpmon -PROJ ${PROJ} -config $PVSS_II $* ) &
fiecho ""
Page 146 of 271

6.2.2.20 Limit usage of root user
Since the “root” user of a WinCC OA project has all permission bits, it is a special case for the user
administration. In many cases there is no authorization check if this user executes tasks or programs.
During the creation of a new project a dialog will be opened to enter a password for the root user. It is
possible to set an empty password to simplify the project engineering, but this is not the recommended
solution. ETM professional control GmbH | A Siemens Company recommends assigning a secure password
for this user during the project design. Only the PKCS#5 hash of the password will be stored in the database.
It shall not be defined in the config file of the project; otherwise the root password is visible in plain text. The
config file can be opened with any text editor.
Further tasks of the project planning shall be done by newly created users with suitable right permission bits
so that the ”root” user is only needed in exceptional cases.
6.2.2.21 Deletion of unused Datapoints

A default WinCC OA installation comes with some example and pattern Datapoints like “ExampleDP_Arg1”.
In addition, WinCC OA holds a few empty Datapoint types like “LABOR_ANALOG” or “WH_SC1”. In some
situations, those Datapoints may not be needed within a WinCC OA project. A typical example are the
Datapoints and Datapoint types for the WinCC OA S7 driver, because they are only needed if this driver is
configured and active.
Although a deletion of those Datapoints and Datapoint types may reduce the size of the Raima database, it
may result into unforeseen and irreproducible behaviors in WinCC OA.
Another key point would be the later usage of WinCC OA features like “WinCC OA S7 driver”, “Maintenance
counter” or “Labor value” if the required datapoints and types where deleted. Even as it is possible to import
the missing data with WinCC OA standard mechanism like the WinCC OA ASCII manager and existing data
files it could result in a situation where existing configurations may be overwritten. A manual redesign of the
existing data files will be necessary by the integrator to avoid a situation which could harm the existing
configuration. To sum it up a default configuration to fix a created problem by deletion cannot be given by
ETM.
Therefore neither datapoints nor datapoint types that are part of the WinCC OA installation shall be deleted.
A much better approach to avoid any unwanted usage is to protect all Datapoints with an authorization config
(see chapter: Protection via authorization levels in WinCC OA).
Page 147 of 271

6.2.2.22 Keep secure settings in WinCC OA config file
The default values in the WinCC OA config file were defined to protect the entire WinCC OA project from an
overload scenario, as a predetermined breaking point. A reliable configuration must reduce the risk of a
complete failure of a WinCC OA project. Following settings are used and activated by default to configure a
scenario where Data- and Event Manager are protected from an overload:
• Definition of input and output buffer size
• Definition of maximum response time

It is possible to disable or modify the configured limits to fulfill the project specific requirements.
The following chapters explain possible attack scenarios and give recommendations how the risk for an
attack may be reduced.
6.2.2.22.1 Possible Attack via WinCC OA UI

The following figure shows a possible DoS attack via a WinCC OA UI. During an attack, the configured limit
is exceeded, and the WinCC OA Event Manager closes the connection to the causing UI Manager, to protect
the overall system against this attack.
Figure 60 - Prevent DoS Attack via config settings
In this scenario the Attacker compromises an UI but due to correct settings in WinCC OA config file
(“maxBcmBufferSize” is configured correctly according to the WinCC OA project requirements) the overload
is recognized by WinCC OA Event Manager and the remaining system is protected. The Event Manager
closes the connection to the compromised UI manager and the Attacker loses his attack vector.
Page 148 of 271

ATTENTION
Be aware that a configuration with a big value (e.g. 300MB for “maxBcmBufferSize”) makes this
security layer useless and an attacker may easily harm the entire system.
Following config entries may be of interest to configure a secure environment. This list is not complete and
shows only a few basic example options:
maxBcmBufferSize maxRequestMemSize maxAlertRequestCount

maxRequestLineCount maxValueRequestCount maxLinesInQuery
Reference tables / Configuration file / Possible config entries

Error tolerance and stability (accessible via search tab)
6.2.2.22.2 Possible attack via WinCC OA driver through Man in the Middle
Beside a possible attack via WinCC OA UI it may be possible, for an attacker, to get an attack vector via
WinCC OA driver. In case of a Man in the Middle attack, countermeasure needs to be configured, to reduce
the risk of the overall system.
The following figure shows how an attacker compromised the internal network and sets up an attack vector
between PLC and WinCC OA driver, through a Man in the Middle which triggers a DoS attack.
Figure 61 - Prevent DoS Attack to WinCC OA driver via config settings
Page 149 of 271

WinCC OA documentation gives possible options how WinCC OA can be hardened to reduce the risk of this
attack to the remaining system. The according settings for the used WinCC OA driver should be configured
carefully, to reduce the negative effect of an attack.
A few possible drivers related config entries to implement an overload control are following examples:
maxTrapsPerSecond maxOutputQueueSize maxRequestQueueSize

maxTrapsBufferSize
Reference tables / Configuration file / Possible config entries
6.2.2.23 Usage of WinCC OA external authentication method

WinCC OA uses a dedicated integrated user authentication mechanism. This supports the creation and
maintenance of project specific user groups including the definition of roles based on permission bits. It is
possible to use the build in user management during development process (e.g. creating Testcase users).
Therefore, ETM professional control GmbH recommends using an external User authentication Mechanism
like the user management shipped with the operating system or another third-party tool like LDAP. This
enforces the usage of strong passwords.
A weak password can easily be decrypted by an attacker and therefore it is mandatory that a password has
to fulfill a few minimum requirements (see chapter: Password strength
or https://www.us-cert.gov/ncas/tips/ST04-002 (acc.: 27th March 2019)). It is possible to define such rules
within a site-specific process, but it is not possible to control the strength of a password with default WinCC
OA mechanisms.
ATTENTION
Some sites may have specific security requirements, regarding user authentication, where a
mandatory password length or a cyclic password switch is necessary. For those sites following
options are applicable:
• Operating system based User administration (with or without SSO and Kerberos)
• User defined authentication (must be implemented as customer side solution)
Page 150 of 271

The following table should provide a help to select the correct method to handle the user credentials. It lists
different features or requirements and informs how this is applied with each authentication method.
Security Feature or WinCC OA user Operating system User defined

Requirement authentication based user authentication with a
authentication 3rd party tool
Duplicate storage of Username and hashed Username stored in Username stored in

password hash password in WinCC OA WinCC OA Datapoint WinCC OA Datapoint
Datapoint
Password hash conform to PKCS #5 State of the art and OS Depends on the
algorithm related. authentication tool but
should be able to handle
an IEC62443 compliant
algorithm (see chapter:
Block Cipher)
Financial Costs Intergraded in WinCC Handled with OS license Depends on the license
OA costs of the 3rd party tool
no additional cost Additional costs for
implementation and
maintenance may occur.
Mandatory usage of Not implemented, Configurable Must be configurable for

strong password password strength full standard (IEC62443)
depends on the user compliance with the
selected tool.
Cyclic change of a Not implemented, user Configurable Should be configurable

password must change the with the selected tool.
password in own
responsibility
Easy start of WinCC OA has own User and groups must User, Groups and
configuration and users to start with be created in OS level. maybe also permission
tailoring implementation Permission bits must be bits must be configured
configured in WinCC OA in the external tool
Centralized user Not existing, user must User Administration is User Administration may
administration be synchronized centralized but OU be centralized in
manually (Sync tool (Organization units) do dependency of the tool.
inside from WinCC OA not exist in WinCC OA
available)
Disabling of a user User can be disabled Restore of a disabled or Depends on the external
but can easily be deleted user will need Tool but should provide
restored Domain Administrator this functionality
privileges
Page 151 of 271

Security Feature or WinCC OA user Operating system User defined
Requirement authentication based user authentication with a
authentication 3rd party tool
Usage of SSO Not possible Optional configurable Not possible, at least

but mandatory if own OS user
Kerberos security is authentication required
active in WinCC OA.
Combination with Not existing Login to WinCC OA with Depends on the

hardware related login SSO activated authentication tool
mechanism (fingerprint,
smartcard, …)
Effort in creating users Effort in creating users Effort in creating OS Effort in creating users
and groups and groups on WinCC users and assignment to and maybe permissions
OA level a group with WinCC OA inside the ext. auth. tool.
related permission. No additional effort in
Additional effort in WinCC OA necessary.
assignment of
permission bits in
WinCC OA to imported
groups from OS
Conform to Not conform Conform if configured Conform if requirements

IEC62443 4-2 and on OS level regarding user
IEC62443 3-3 authentication are
requirements supported by the
system.
Notification of failed Only as entry in local Configurable on OS Depends on the

login procedures text-based log file but no level (Group policy for authentication tool
automated mechanism Windows) with option to
exists to handle this lock the affected user.
event.
Support of password Not existing Configurable on OS Depends on the

expiration level (Group policy for authentication tool
Windows)
Storage of password Encrypted password Secure password Password storage by

hash hash stored on _Users storage by the OS. No the authentication tool.
Datapoint. valid password hash will The security level
be transmitted to an UI depends on the tool. No
client. valid password hash will
be transmitted to an UI
client.
Table 11 - Compare methods of user authentication
Page 152 of 271

In Summary the usage of an Operating system based user authentication gives a best practice procedure to
implement a secure system. It combines the existence of a good and reliable authentication tool with the
permission bits mechanism inside WinCC OA. In addition, an OS system should always stay up to date
(see chapter: Patch management and security updates). Security issues will be corrected automatically via
OS security updates. This helps to fulfill the user specific requirements in IEC 624443 3-3 and
IEC 62443 4-2. This combination gives the best achievable level regarding security requirements.
In addition, an OS with activated Kerberos increases the security maturity of the overall system.
By this consideration it is possible to rate the authentication methods in an order, with begins with the
highest level of security.
1. Operating system based user management with Kerberos enabled SSO.

Windows and Linux are supported.
2. Operating system based user management. Windows and Linux are

supported.
3. User defined authentication with a 3rd party tool
4. WinCC OA internal authentication
Table 12 – Security assessment of authentication method in WinCC OA
The referenced list from Table 12 shows the highest maturity for the Operating system based authentication
methods, but that configuration needs a fully configured domain concept. If this complete domain concept is
missing, then the following points show the advantages of an external authentication tool against the WinCC OA
method:
• Allows WinCC OA to support environments with mixed operating systems, where all users are not
authenticated by a Windows or Linux domain.
• Allows users to connect from unknown or untrusted domains. For instance, an application where an
established user connects with WinCC OA HTTP-Server (ULC UX).
(See chapter: User Interface Configuration)
• Allows WinCC OA to support web-based applications were users create their own identities, based on
API managers
• Allows software developers to test applications by using a complex permission hierarchy based on
temporary logins.
Following chapters shows the possible options to implement an external authentication concept based on the
operating system of a 3rd party vendor tool.
Page 153 of 271

6.2.2.23.1 Usage of Operating system (Windows or Linux) based user management
Activation of OS based User Administration for Windows or Linux system is the common choice to avoid
problems caused by a weak password. This mechanism allows the usage of OS users for the Login process in
WinCC OA. On a Windows system this feature needs a running AD and a Samba 4 configuration for Linux
systems.
Detailed information regarding the configuration of a WinCC OA system with this feature is available within
System management / Authorization / Windows user administration

System management / Authorization / OS Auth. user administration
An Active Directory system allows the usage of mandatory requirements regarding the password strength
which can be configured via group policy editor. With enforced settings it is possible to ensure good and
strong passwords for user credentials which protect the project or plant from jeopardizing by the usage of
weak passwords.
Beside a strong password, an OS based user authentication mechanism allows the synchronization of users
and groups inside a domain. This makes it easier to trigger a login to a WinCC OA project running on a host
within the same domain. For a more granular permission design it is possible to define different permission
bits (authorization level) for every role (group membership) of a user. With this configuration it is possible that
the same user can perform administration activities on a WinCC OA project but only reading activities on
another WinCC OA project.
The following example shows a central user administration based on an AD/LDAP system. The user with the
name “siteadmin” exists on the Domain controller and this user is member of specific groups. The 1st login of
a user on a WinCC OA host will create this user inside the local configuration database and the assigned
groups are created automatically. In the default configuration the permission bits must be applied manually
to each group and this means that members of the same group can have different permission levels for each
WinCC OA host. This example shows that the user siteadmin has only full permissions on WinCC OA
system 1 and 2 but can only acknowledge alarms on system 3. On System 4 the same user is only able to
visualize the system and he will not have the option to configure these systems if all authorization configs are
configured correctly.
Page 154 of 271

Figure 62- Central user administration with Domain Controller and different permissions
Page 155 of 271

WARNING
WinCC OA uses a datapoint of DP-Type _CtrlCommandInferface to create new users for an internal
algorithm. The required DP is created automatically with the first switch to OS based authentication
method. The new generated DP is protected with permission bit three for _dp_fct, _original, _address
and _default in a default installation. This DP is used to create users, add users to groups and
change user passwords.
Although a switch to OS based authentication mechanism increases the level of security of the
system it could be harmed directly after the switch due to a temporary situation where those
permission bits are set to zero. This is essential to establish the login of new users.
1. Firstly, it is necessary to import the required groups from OS Level.

When the user logs in, the appropriate groups are created in WinCC OA on the server. To create
all necessary groups in WinCC OA, we recommend that the user who switches to the OS Auth
User Administration, must possess Active Directory Administrator rights. Note also that the
server must be started with Active Directory Administrator rights. This means that the user who
logs on to the server must possess Active Directory Administrator rights.
2. Secondly it is also essential to activate SSA,
see chapter: Server-Side Authentication for User Interfaces.
3. Thirdly it is important to protect the _CtrlCommandInterface_2 DP with the same or more
restrictive settings via _auth configs. At least the datapoint attributes _dp_fct, _original, _address
and _default must to be protected with permission bit 3.
This configuration could also be applied via WinCC OA configuration panel from System
Management: SysMgm → Permission → System Permissions
Figure 63 - System authorization panel to set permission bit 3
4. Finally, the level of security was increased due the realization of the given recommendations.
Keep in mind
A login of new OS users - without activated SSA - in WinCC OA is only possible, when
“CommandInterface permission” is set to 0.
Every different configuration result into errors during the creation of new users!
System Management / Authorizations / System authorizations
Page 156 of 271

6.2.2.23.1.1 Windows
A Windows system requires a configured AD running on a dedicated Domain Controller. A switch from
WinCC OA user administration to OS based administration requires a user with administrative privileges.
After a switch, a login from any configured user in AD is possible, the assigned groups are created
automatically in WinCC OA, but the permission bits must be set manually, for the required AD groups. This
also affect an update of the group relations from an existing user, the new groups will be created
automatically after the next login of this user.
To ensure a good functionality without permission issues it is recommended to use the same user which is
currently used in the actual Windows session. This is necessary to avoid problems caused by configured
permission settings on Windows level. For example, if the actual Windows user tries to trigger a login with a
different user, it could be possible that the Windows user does not have the permission to read the assigned
groups of that user that is created in WinCC OA. This situation results in a scenario where the user is
created in WinCC OA but has no groups assigned.
6.2.2.23.1.2 Linux
For OS authentication on a Linux system WinCC OA uses the Pluggable authentication module (PAM)
interface. This interface supports the login of local users from the Linux system as well as configured users
from an AD domain. The benefit of the PAM API is the usage of an independent user authentication
mechanism (e.g. LDAP, Winbind). Following drawing shows the overall implementation of the PAM library
model. This model is configured via a configuration file and runs on the low-level modules implemented into
the operating system. The Service application in this case WinCC OA uses the PAM library for the
authentication mechanism.
Configuration file
PAM Library
(etc/pam.d)
WinCC OA
(Service application with
LDAP, Winbind, ...)
Low level modules
(pam_unix)
Figure 64 - Usage WinCC OA in PAM architecture
This PAM mechanism was tested with a Windows DC and a Linux DC implemented via Samba 4. A user
replication was configured, and a Linux Client was integrated via LDAP to this test environment. This means
that a login to GNOME UI was possible with a user existing in AD.
Page 157 of 271

The following picture shows an example how the system was configured. The domain user exists inside the
AD.
Figure 65 - Windows/Linux DC Architecture
The Linux WinCC OA Host was integrated into the Domain by usage of following configuration. Attached is
the content of the required configuration files for a CentOS® system as an example. For other systems refer
to the OS Manual for the correct configuration.
#
# /etc/nsswitch.conf
#
# An example Name Service Switch config file. This file should be
# sorted with the most-used services at the beginning.
#
# The entry '[NOTFOUND=return]' means that the search for an entry
# should stop if the search in the previous entry turned
# up nothing. Note that if the search failed due to some other reason
# (like no NIS server responding) then the search continues with the
# next entry.
#
# Valid entries include:
#
# nisplus Use NIS+ (NIS version 3)
# nis Use NIS (NIS version 2), also called YP
# dns Use DNS (Domain Name Service)
# files Use the local files
# db Use the local database (.db) files
# compat Use NIS on compat mode
# hesiod Use Hesiod for user lookups
# [NOTFOUND=return] Stop searching if not found so far
#
# To use db, put the "db" in front of "files" for entries you want to be
# looked up first in the databases
#
# Example:
passwd: sss files
shadow: sss files
group: sss files
Page 158 of 271

#initgroups: files
#hosts: db files nisplus nis dns

hosts: files dns nis myhostname
# Example - obey only what nisplus tells us...

#services: nisplus [NOTFOUND=return] files
#networks: nisplus [NOTFOUND=return] files
#protocols: nisplus [NOTFOUND=return] files
#rpc: nisplus [NOTFOUND=return] files
#ethers: nisplus [NOTFOUND=return] files
#netmasks: nisplus [NOTFOUND=return] files
bootparams: nisplus [NOTFOUND=return] files

ethers: files
netmasks: files
networks: files
protocols: files
rpc: files
services: files sss
netgroup: files nis sss
publickey: nisplus
automount: files nis sss
aliases: files nisplus
The file /etc/pam.d/other was used with following content:
#%PAM-1.0
auth [user_unknown=ignore success=ok ignore=ignore default=bad] pam_securetty.so
auth substack system-auth
auth include postlogin
account required pam_nologin.so
account include system-auth
password include system-auth
# pam_selinux.so close should be the first session rule
session required pam_selinux.so close
session required pam_loginuid.so
session optional pam_console.so
# pam_selinux.so open should only be followed by sessions to be executed in the user context
session required pam_selinux.so open
session required pam_namespace.so
session optional pam_keyinit.so force revoke
session include system-auth
session include postlogin
-session optional pam_ck_connector.so
With this configuration it is possible to change to the OS based authentication method inside from WinCC
OA user administration panel.
Page 159 of 271

6.2.2.23.2 Usage of user defined authentication with a 3rd party tool (e.g. based on LDAP)
Besides the OS authentication method, WinCC OA also supports the usage of a user defined authentication
mechanism like LDAP from an external user authentication tool.
ETM professional control GmbH offers an interface which makes the usage of an external tool available.
Detailed information regarding the configuration of a WinCC OA system with this feature is available within
CONTROL / Control classes / Authentication
Like an integrated OS based authentication mechanism for an AD system it must be possible to set policies
within an external authentication tool. ETM professional control GmbH cannot recommend any specific tool
but during the analysis it is important to define the following as must have criteria:
• The evaluated authentication tool should be able to enforce the usage of good passwords.
• It should be robust against Denial of Service attacks.
• It should use a state-of-the-art hash algorithm for user passwords.

• Support of encrypted user credentials transfer. The external tool should be available via VPN
connection to make a secure remote connection possible.
Beside an OS integrated user authentication based on an Active Directory concept it is also possible to use
an external tool from a vendor to check the user credentials. This user authentication can be activated by
configuring the required service using config file entries.
Depending on the integration of the external authentication tool it is also possible to configure the permission
bits directly within this tool and the user in WinCC OA will be created automatically with the centralized
configured permission bits. Both options have their advantages and disadvantages, in coordination with the
integrator and the asset owner it is necessary to find the correct method to implement a solution which fulfills
all requirements regarding user role security.
The following figure shows a handling of a user if the authentication bits are also handled inside the
centralized system. With this configuration an own and different configuration of permission bits for a user to
different systems is not possible on this level. Every user will get the same permission bits in the overall
system. But if a more granular configuration is required it can be implemented with the area concept
(see chapter: Access Control via Area authorization)
Page 160 of 271

Figure 66 - User defined authentication with external tool
ATTENTION
It is essential to implement a secure interface for the external user authentication tool. The
integrator of the site must do this task directly. This interface should be robust against Man in the
Middle attacks to prohibit a confidentiality related attack scenario.
Page 161 of 271

6.2.2.24 Secure implementation of WebView EWO
With WebView EWO it is possible to display platform independent web pages inside a WinCC OA panel.
This implementation contains a JavaScript interface.
The WebView EWO JavaScript Interface is a bidirectional communication interface between JavaScript and
Control. It allows to create parts of your user Interface with a wide variety of available JavaScript frameworks
and widgets while still being able to access your plant data that is collected and processed within your
WinCC OA project.
Graphic editor (GEDI) / Complex graphic objects / EWO (External Widget Object) / WebView EWO
To apply state-of-the-art security requirements, it is necessary to follow regulations during the

implementation of a JavaScript interface. Although ETM offers an option to implement a JavaScript, the
implementation itself is in responsibility of the integrator or the asset owner. Beside the functional
requirements of the interface it is essential to consider following points.
• Ensure secure coding practice.

During the implementation it is essential to consider and verify all output and input activities. It is possible
to reduce a security risk by following common coding practice which consider security requirements. With
a good implementation, it should be possible to consider following points:
o Avoid common mistakes in JavaScript coding
o Avoid implementation of vulnerabilities to keep the application secure.
o Implement a way to recover from error
Whitepapers and Guidelines regarding a secure implementation are available from different sources and
some are also available via internet.
(e.g. https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Security_best_practices/
or: https://code.tutsplus.com/articles/client-side-security-best-practices--net-35677
acc.: 27th March 2019)
• Implement Server-side security

With JavaScript interface it is possible to read and write datapoints by usage of JavaScript function. To
avoid a possible altering of a system it is essential to protect the datapoints with an authorization config.
This implements a Server-side security layer and avoids a possible situation where a system may be
harmed, see chapter: Protection via authorization levels in WinCC OA.
• Use obfuscation methods and avoid default names

With a JavaScript interface it is possible to manipulate shapes and widgets from WinCC OA directly but
only for the own interface. An attacker may be able to overfill a table object, but this will only affect the
already hijacked interface of an attacker itself.
To execute this attack it is necessary to know the shape name from an object to trigger a possible
overload scenario. To reduce the risk and to delay the attempts from an attack it is recommended to use
own names and not the default names for the shapes (e.g. TABLE1).
Even if this step does not implement a high level of security it may weaken the attack vector because an
attacker must guess the name of a shape before he is able to execute a script.
Page 162 of 271

Administration and Configuration of OS
6.3.1 Administration of Computers
The administration of computers and users, of a production plant, can be organized centrally by a Domain
(AD domain) or decentralized.
One benefit of centralized administration is the significant reduction of maintenance effort and the
considerable enhancement of security. For example, this can be achieved using the Kerberos authentication
in an AD domain. If usage of Kerberos authentication is not utilizable, the common authentication method of
NT LAN Manager (NTLM) can help for a Windows based OS.
The decision about centralized or decentralized should be taken based on the number of systems to be
supported or the necessity (e.g. organization's own security guidelines) of using an AD domain. Due to the
operation of a machine / plant by different persons the usage of a central user administration is
recommended.
The following situations require an AD domain:
• Highly available user administration by usage of multiple AD controllers.
• Use of the Kerberos authentication

• Public key infrastructure (can also be used for IPsec)
• Centralized SSO user login and verification

• The centralized user login and verification from an "external" domain (e.g. via a "one-sided trusted"
to another network with its own Active Directory administration)
• The centralized, group guideline-based configuration
Regardless of the type of the administration (centralized or decentralized), it is necessary to ensure careful
separation of the areas of responsibility and administration of the IT department for the office networks and
the operations personnel.
The following examples clarify and illustrate the meaning of separating the areas of responsibility and
administration:
• An administrator of the IT department cannot reboot or incorrectly configure a plant PC inadvertently.

• An administrator of the plant operations personnel cannot make changes to the domain settings of
an external domain inadvertently.
An administration concept must always be prepared if administration needs to be done by a domain. The
infrastructure design with respect to the name space, domain structure, overall structure and trusted
relationship to other domains, e.g. the domain for an office, must be specified in the administration concept.
The decision regarding the infrastructure design depends to a large extent on the number of systems, the
size of the systems and the associated effort and cost. The organizations own guidelines need to be followed
and implemented in the same way.
Page 163 of 271

In principle, it is recommended that separate structures are used for the office networks and the production
networks. The reason for this is that data security, authorizations and rights take place for both overall
structures separately including the folder replication. Even changes in the scheme and configuration and
adding a new domain to an overall structure have an effect only across the entire structure. Access to
resources is enabled via single or mutual overall structure trusted relationships. Since each overall structure
(office and production) is administered separately, the administrative effort increases by adding to the overall
structure.
Trusted relationships of the overall structure simplify the administration of a segmented Active Directory
infrastructure within an organization. This happens since they support access to overall structure-
independent resources and other objects.
As an example, it is possible to configure a one-way Trust from ECN to PCN. This allows the operators to
use resources from the Enterprise network (e.g. printer), while Enterprise users are not able to login to a
WinCC OA project for security reasons.
The rules for the necessary password complexity can be defined on the layer of organizational units (OU).
An increased complexity (number of special characters, length,) increases the effort for cracking the
password. A cyclic change of the password also adds additional security.
Page 164 of 271

6.3.1.1 Password strength
Many applications are provided with a default password to ensure an easy startup, directly after installation.
This default password needs to be changed as soon as possible because an unchanged default password
may be used by attackers to cause a threat and harm a CIS system. The article in this reference shows how
an attacker was able to steal military data because the default password was not changed:
https://www.bleepingcomputer.com/news/security/hacker-steals-military-docs-because-someone-didn-t-
change-a-default-ftp-password/ (acc.: 27th March 2019).
Beside the change of the default password a good password should fulfill these requirements:
• Use a minimum password length of 12 to 14 characters.
• Include lowercase and uppercase alphabetic characters, numbers and symbols to increase the
alphabet size.
• Avoid using the same password twice (e.g., across multiple user accounts and/or software systems).
• Avoid character repetition, keyboard patterns, dictionary words, letter or number sequences,
usernames, relative or pet names, romantic links (current or past) and biographical information (e.g.,
ID numbers, ancestors' names or dates).
• Avoid using information that is or might become publicly associated with the user or the account.
• Avoid using information that the user's colleagues and/or acquaintances might know to be
associated with the user.
• Change the password periodically
• Change password only on secure hosts (especially for users with administrator permission)
Page 165 of 271

The listed requirements help to reduce a risk caused by a brute-force attack. Following two charts give an
example how password length and alphabet size effects the time for a successful brute-force attack. Both
charts show the maximum amount of possible combinations.
The first chart shows the effect of increasing Password length while the alphabet size remains stable. The
second chart shows the opposite solution with a stable password length of 5 while the Alphabet size was
increased (e.g. by usage of special characters).
impact of Password length impact of Alphabet size

250000 120
amount of combinations in Mio.
amount of combinations in Mio.

200000 100
80
150000
60
100000
40
50000 20
0 0
5 6 7 8 10 20 30 40
Password length size of Alphabet
increase of combinations increase of combinations
Figure 67 - Increasing Password length with Figure 68 – Increasing Alphabet size with
fixed Alphabet size of 26 fixed Password length of 5
The amount of possible combinations is calculated with the power function. Alphabet size is used as base
parameter while Password length is used the exponent:
Possible combinations = Alphabet size Password length
Due to mathematical reasons an increase of Password length is more important than an increase of
Alphabet size to prevent a system from a brute-force attack.
Following table shows examples for the required time of a brute force attack with the assumption that this
attack can generate 2 billion keys per second. These values assume that 52 letters (lower/upper case), 10
numbers and 32 special characters are used to increase the Alphabet size to 94.
Alphabet size Password length Amount of combinations Time for brute-force attack
94 5 7339040224 3,67 seconds
94 8 6,09569E+15 ~ 35 days
94 12 4,7592E+23 ~ 7,5 Mio. years
Table 13 - Time for brute-force attack
This table also shows the importance of Password length to prevent the configured system from a brute-
force attack. It also shows the mathematical proved reason why a minimum password length of 12 is
recommended in this chapter.
Page 166 of 271

The suggested requirements at the begin of this chapter are configurable within the user settings of the OS
itself. In a Windows based OS those requirements should be configured via Group policy editor and in a
Linux environment with the specific configuration setting, e.g. for a CentOS® system this setting is
configurable within the etc/pam.d/system-auth file
Example description:
https://www.digitalocean.com/community/tutorials/how-to-set-password-policy-on-a-centos-6-vps
Note:
Every active user account allows access to the system and is therefore a potential security threat.
Following steps are recommended:
• Reduction of configured / active user accounts to the necessary minimum
• Periodic verification of the configured user accounts
• Usage of secure access data for the available accounts
• Important: Change system default passwords as well as the “root” password of the WinCC
OA project before setting the system active
• System access only for users that are necessary for the plant operation
Page 167 of 271

6.3.2 Administration of networks and network services
Network services of a production system can be organized in a centralized or decentralized manner. In
principle, it is also possible to have mixed configurations of centralized and decentralized administration.
Mixed configurations should be adapted specifically for each system. Incorrect configurations occur more
frequently in the case of components configured in a decentralized manner based on experience. In addition,
conflicting settings are difficult to find.
One benefit of the centralized administration is the significant reduction of the maintenance effort and the
considerably higher level of security, for example, by the following options:
• Using the Kerberos authentication within the domain in place of the NTLM authentication within a
workgroup.
• Adding the host names/IP addresses in the hosts files to access the WinCC OA servers connected.
The decision regarding centralized or decentralized should be taken on the basis of the number of systems
to be maintained or the necessity of using centralized administration.
The need for an AD domain is explained in detail in chapter: “Administration of Computers”.
6.3.2.1 Centralized administration (primarily of the domains)

All information and settings required can be configured centrally:
• IP address
• Name resolution of the IP address → host (automatic, central name registration, can finally be
inquired by other network subscribers)
• Time synchronization (NTP, SNTP)
6.3.2.2 Decentralized administration (mostly workgroups)

• All information and settings required must be configured locally. The IP address is used for unique
identification of a network subscriber in a network.
• The computer name and NetBIOS computer name are used for unique identification of a computer
for persons and applications in the network.
• The name resolution is used to convert the computer name (FQDN) and the NetBIOS computer
name of a computer to an IP address.
ATTENTION
These numerated settings are the most frequent sources of errors, since typos or duplicate usage
can occur easily.
Page 168 of 271

6.3.3 Configuration settings for all mobile devices
Since all mobile devices, like tablets or Smartphones, have become more popular over the last years, these
devices became also more vulnerable from a security perspective. These devices and laptops are vulnerable
for thefts and this makes it easier for an attacker to get valid user credentials or to login to a protected
network, because the attackers could enter with a valid UUID number of the device. To reduce that risk
following recommendations must be considered:
• All devices must be protected by a password and or a PIN code.
• A screen timeout and an automatic screen logout must be configured

• Device must be encrypted
• Password must not be stored on a mobile device
• Confidential data must not be stored unencrypted

• Boot loader must not be unlocked
• Do not root an Android or Apple device and do not install apps requiring root privileges
• Always keep the system up to date
• Do not install apps from untrusted sources
• Only activate debug mode when necessary

• Process confidential data only with secure applications
• Do not install third party software keyboards requiring internet access
• Every user must report a stolen device at once to the responsible administrator of the site facility.
The administrator must remove stolen devices from the list of the accepted machines in the Active
Directory.
• There is also an additional configuration part inside WinCC OA for mobile devices accessible via
SysMgm panel. The stolen devices must be removed manually from the list of accepted devices.
See chapter: Disable Automatic Unlock for Mobile Devices (Android and iOS) and Desktop UI
and User Interface Configuration
• Please consider also information given by the BSI:

o iOS System:
https://www.allianz-fuer-cybersicherheit.de/ACS/DE/_/downloads/BSI-
CS_074E.pdf?__blob=publicationFile&v=2 (acc.: 27th March 2019)
o Android System (only available in German):
https://www.allianz-fuer-cybersicherheit.de/ACS/DE/_/downloads/BSI-
CS_109.pdf?__blob=publicationFile&v=8 (acc.: 27th March 2019)
Page 169 of 271

CAUTION
WinCC OA offers the option to locally store the password on the mobile device for comfortability
reasons. Although this password storage uses an encryption mechanism, it was designed for
environments with low security requirements. This feature offers a possible threat in case the device
was stolen.
To avoid a negative impact, usage of this functionality is prohibited, in endowments with high
security requirements!
6.3.4 Automatic user logout in OS

An unattended operating station with logged in user is a security threat and could be used by attackers. It is
mandatory to deploy a process which ensures that a user’s workplace is locked when the user leaves it for a
couple of minutes. This process can be enforced by usage of the automatic logout feature after a time of
inactivity.
Within a Microsoft® Windows OS it is recommended to configure this inactivity with a GPO.

Within a Linux system it is possible to configure a bash logout inside the /etc/profile.d/timeout-settings.sh file:
#!/bin/bash
TMOUT=300
readonly TMOUT
export TMOUT
Alternatively, it is possible to configure this setting by a graphical interface. This configuration is usually
possible within the settings menu; please consult the documentation for the Linux distribution for additional
help. (e.g. for a CentOS® system this option is available within: Applications → System tools → Settings →
Privacy)
Page 170 of 271

Administration and Configuration of WinCC OA
6.4.1 Administration of Role-Based user authorizations
One of the most important security measures for any organization is the unique identification of persons and
assignment of authorizations to them.
It is necessary to consider the characteristics of automation with respect to the administration of Role-Based
user authorizations and their integration in the WinCC OA Security Guideline.
6.4.1.1 Difference between users and plant operators

When logging in to a process control computer, a differentiation is made between logging in by the user to
the operating system and logging in by the system operator or operator to the process control system.
The principle of minimum is applied when assigning all rights and authorizations. In the process, each of the
users is assigned exactly those rights that he requires to fulfill his duties.
6.4.1.2 Deletion of User Accounts in WinCC OA

To secure the traceability of historical data the deletion of an existing WinCC OA user is prohibited. Every
operation is logged in the history with the changed values, a time stamp and the user ID of the operator. If
the user is deleted the logged information with the user information will be lost. The usage of the panels for
the user administration in a WinCC OA system prevents the deletion of users. There is only the way to
deactivate and reactive users in WinCC OA. By deactivating a user, the user information is not removed, and
the consistency is granted. A log-in attempt of a deactivated user will be blocked until the account has been
reactivated.
Note:
Every active user account allows access to the system and is therefore a potential security threat.
The following steps are recommended:
• Reduction of configured / active user accounts to the necessary minimum
• Regular verification of the configured user accounts
• Usage of secure access data for the available accounts
• Important: Change system default passwords as well as the “root” password of the WinCC
OA project before setting the system active
• Define user roles and differ between administrators and operators. A typical operator must
not be able to change the system configuration.
Page 171 of 271

6.4.2 Automatic User Login
The continuous graphical display of the process operation and control remains in the foreground for
visualization in process control systems. An operator logging off is handled by the software of the process
control system and normally, this does not end the graphical display.
To prevent the unauthorized start of applications by the system operators, WinCC OA allows forcing an
automatic log-in when activating the corresponding Kerberos settings.
As alternative the WinCC OA config entry “username” and “password” in the [general] section of the project’s
config file can be used but these settings should only be used for testing purposes during the project
development due to the user name and password being unencrypted inside the config file. For security
reasons these config entries must be removed before deployment of the system.
CAUTION
A password for a user (especially for „root“) must not be part of the config file nor be part of a start
option for a manager! The config file and the start options are plain text and the password is
therefore not secure!
Page 172 of 271

6.4.3 Automatic User Logout in WinCC OA
To prevent manipulation by an unknown user it is recommended to enable the automatic logout or the
activation of the screensaver including the mandatory password query for continuing the session on the OS
layer. In both cases the input of a password is necessary after a defined number of minutes which prevents
the access of unauthorized personal.
As an addition the WinCC OA feature for the inactivity settings can be used. This feature allows defining the
behavior after the inactivity time-out has been reached. One of the following actions can be used:
• WinCC OA-Logout
• Start the screensaver
• Logout and screensaver
• Close local UI connection
• Windows logout
System management / Settings / Inactivity management
ATTENTION
Please consider that this functionality is not available for an ULC UX user interface.
6.4.4 Administering user rights

The general principle of the user rights administration is that each WinCC OA user belongs to one or several
WinCC OA groups.
The members of a WinCC OA group then inherit the rights assigned to this group. The user rights for a group
are defined via permission bits. WinCC OA users and groups can be either directly created on WinCC OA
level or inherited from the AD or external authentication tool
(see chapter Usage of WinCC OA external authentication method).
In case users and groups are created directly on WinCC OA level or inherited from the AD, the permission
bits are set always on the WinCC OA level. In case users and groups are inherited from the external
authentication tool, the permission bits could be set either on WinCC OA level or can be set on the external
authentication tool level (depending on possibilities of external authentication tool).
Page 173 of 271

6.4.5 Single Sign On
The feature Single Sign On (SSO) can be activated for a workstation host by usage of the authorization
Bit32. Due to Security reasons the input of user credentials is always mandatory for users with activated
Permission Bit 4 (Administrator Users), even if the workstation host is configured as SSO host.
System management / Authorizations / Login
The best combination for security and Single Sign On comes with active Kerberos security. With the usage of
Kerberos SSO is mandatory. The entire system will benefit from this higher level of security.
More extensions regarding this authorization levels can be defined with the Access Control Plug-In for
WinCC OA (see chapter: Usage of WinCC OA Access Control Plug-In).
Note:
A joint configuration of SSA (see chapter: Server-Side Authentication) and SSO is not supported by
WinCC OA.
The purpose of WinCC OA Single Sign On is to provide centralized sign on information (SSO principle) to the
operator. A well-engineered security mechanism, by usage of the Operating system login
(see chapter: Usage of Operating system (Windows or Linux) based user management) is used for this
purpose.
Operator’s username and password (identity) are saved as user accounts within the domain by the
Operating system. They are used to authenticate an operator in a WinCC OA server project. The Role-Based
operator authorizations are configured via group membership of the user/operator.
Page 174 of 271

Figure 69 - Single Sign On
Page 175 of 271

6.4.6 Server-side Authentication
The feature SSA stands for a method where the user credentials are verified on server side instead of client
side. Although WinCC OA uses client-side authentication in the default configuration to increase the speed of
deployment and development it is strongly recommended to activate SSA for the life operation of a site. A
default client-side authentication is vulnerable to an attacker because this attacker may be able to
manipulate the authentication process directly and trigger a login without knowledge of correct user
credentials.
Following list represents the security related ranking on usable authentication methods with WinCC OA. It
starts with the most recommended authentication process and ends with the default rollout of WinCC OA.
The default rollout of WinCC OA is defined to offer a maximum level of compatibility. It is in responsibility of
the Integrator or the Asset-Owner to implement a suitable solution for each plant.
1. SSA for Managers with session binding with AD integration

2. SSA for User Interfaces with AD integration
3. SSA for Managers with session binding
4. SSA for User Interfaces
5. Client-Side Authentication (Default Rollout from WinCC OA)
Each step of the most recommended authentication processes requires additional configuration tasks which
are explained in this chapter. The suggested top two methods which represent the highest level of security
maturity also require knowledge regarding the Active Directory implementation
(see chapter: Usage of Operating system (Windows or Linux) based user management).
6.4.6.1 Server-side Authentication for User Interfaces

Although the default login mechanism offers a practical security implementation it is possible to increase the
level of security by usage of the SSA feature. The reason for the improvement is that the password check is
done on the client in the default configuration after a creation of a new WinCC OA project. An attacker - with
development knowledge - could hack the default and client-side login mechanism to set up a connection with
any user (privilege escalation) and without knowledge of a correct password.
This threat can be avoided with SSA feature which needs a running WinCC OA HTTP-Server and specific
config entries on client and server side. For a logon, the WinCC OA HTTP-Server provides a dialog where
the user credentials need to be entered in a form. Those credentials are used to save a token in the
database and to check the user credential directly on the server. The following picture shows an explanation
of the login process and compares it with the default WinCC OA user authentication.
It should be considered that a successful Login is only possible for unlocked devices,
see chapter: Disable Automatic Unlock for Mobile Devices (Android and iOS) and Desktop UI
Page 176 of 271

Figure 70 – Compare SSA login process with WinCC OA default mechanism
Page 177 of 271

ATTENTION
Activation of SSA or usage of Kerberos with SSO is mandatory in a secure environment where
unsecure clients are used.
Details regarding the configuration are available within WinCC OA documentation
Special functions / Security / Authentication / Server-side Authentication
To activate this feature, a few other config entries are needed. The settings given in the example are defined
for a pair of redundant WinCC OA server projects with a remote WinCC OA HTTP-Server (CTRL script:
WebClient) and a remote User interface (Remote UI, Desktop UI or ULC-UX).
Figure 71 - SSA example
This example requires the existence of project related panels or scripts on the server host (“PenTestWEB”)
which provides the data information for the client (“PenTestClient”).
Special functions / Security / Server-side Authentication
The following config entries are required for the specific machines.
Page 178 of 271

PenTestSRV01
[general]
accessControlPlugin = "AccessControlPluginUser"
[webClient]
clientSideAuth = 0
[httpServer]
uiArguments = "-p vision/login.pnl -centered -iconBar -menuBar -server https://PenTestSRV01"
PenTestSRV02
[general]
[webClient]
clientSideAuth = 0
[httpServer]
uiArguments = "-p vision/login.pnl -centered -iconBar -menuBar -server https://PenTestSRV02"
PenTestWeb:
[general]
data = “PenTestSRV01$ PenTestSRV02”
event = “PenTestSRV01$ PenTestSRV02”
[ctrl]
#configuration entry for redundant WinCC OA servers
connectToRedundantHosts = 1
[webClient]
clientSideAuth = 0
[httpServer]
uiArguments = "-p vision/login.pnl -centered -iconBar -menuBar -server https://PenTestWEB/"
Page 179 of 271

PenTestClient:
[general]
Start the UI on the client with following parameter for a Remote UI.
The –ssa parameter avoids the creation of a cache folder which is only required by a Desktop UI.
-p vision/login.pnl -server https://PenTestWEB -ssa
A login dialog will open afterwards, and the user credentials are requested. Please note that login as root
user is disabled with activated SSA feature.
6.4.6.2 Server-side Authentication for Managers with session binding

Beside Server-side Authentication for User Interfaces, it is also possible to extend this feature with session
binding for WinCC OA managers. This method stands for a higher level of security compared to the method
explained in chapter Server-Side Authentication for User Interfaces.
If manager binding is used, the Event Manager remembers the user, who initialized the connection. So, it is
not possible to exchange the user ID in the messages at the client. e.g.: user connects as user “guest”, but the
hacker changes the user ID to “root” every time before a message is sent. With message binding this is not
possible, because the Event Manager will close the connection.
To verify the usage of the correct user it is necessary to ensure that non-repudiation requirements are fulfilled.
This is achieved via usage of signatures for the specific user (see chapter: Signing). To configure the usage
of the signatures it is necessary to create own certificate files for the user which should start this process. With
this setting it is possible to start a WinCC OA Process like a CTRL Manager or an ASCII Manager with a User
with limited access permissions. This means that it is not necessary to execute all WinCC OA manager
processes as root user what may be misused for a security attack vector.
6.4.6.2.1 Example for file-based Manager SSA certificates

As an example, it is possible to generate the required certificates with the implemented certificate creation
panel from WinCC OA (see chapter: Create own openSSL certificates).
The following screenshot shows how a certificate can be created for the user “para”. As CA the certificate for
WinCC OA multiplexing proxy is used:
Page 180 of 271

Figure 72 - Create certificate for SSA with session binding
The “Rule/User” field represents the user for this certificate and the “Certificate/key Name” field defines the
name of this certificate. This example will create two files with the names:
• CertPara.key → Private Key

• CertPara.crt → Public Key
For the activation of SSA with Manager Session binding following entries should be configured in WinCC OA
config file:
[general]
#activate SSA with session binding
accessControlPlugin = "AccessControlPlugin"
#use public key for CA as chain file
ssaChainFile = "root-cert.pem"
#configure public and private key for user para
ssaPrivateKey = "file:CertPara.key"
ssaCertificate = "file:CertPara.crt"
[webClient]
clientSideAuth = 0
httpAuth = 1
Page 181 of 271

This configuration makes it mandatory to start all processes as the user para. If any process is started as a
different user (e.g.: root) it fails, and an error message is displayed.
For cases where specific manager should be started using another account it is possible to configure this in
the related section of the config file. So, it is possible to create an own certificate for the user “root” and if the
processes WinCC OA Data- and Event Manager should run as root user following config entries are necessary:
[event]
ssaPrivateKey = "file:Certroot.key"
ssaCertificate = "file:Certroot.crt"
[data]
ssaPrivateKey = "file:Certroot.key"
ssaCertificate = "file:Certroot.crt"
A remote WinCC OA host which establishes a connection to the configured WinCC OA server needs the same
entries in the related section. Following configuration is needed if a remote CTRL Manager should relate to
the WinCC OA server:
[general]
pvss_path = "C:/Siemens/Automation/WinCC_OA/3.16"
proj_path = "C:/Projects/316_Manager_SSA"
proj_version = "3.16"
langs = "en_US.uft8"
data = "pentestsrv01"
event = "pentestsrv01"
accessControlPlugin = "AccessControlPlugin"
[ctrl]
ssaChainFile = "root-cert.pem"
ssaPrivateKey = "file:CertPara.key"
ssaCertificate = "file:CertPara.crt"
[webClient]
clientSideAuth = 0
httpAuth = 1
It needs to be noted that there is no entry for the User Interface in this config file to allow a login for different
users on the same UI host.
Page 182 of 271

6.4.6.2.2 Example for Windows Certificate Store SSA certificates
Alternatively, to the usage of file-based certificates it is possible to use the Windows certificate store for
handling of the required certificates (see chapter: Windows certificate store). In a first step it is necessary to
create the certificates manually via command line or via WinCC OA panel. For the import, it is necessary to
create the certificates in a PKCS12 format which includes the public and private key.
In comparison to the certificates required by mxProxy it is also necessary to define a name for the
Cryptographic Service Provider (CSP). The selected CSP named “Microsoft Enhanced RSA and AES
Cryptographic Provider” contains algorithms for encryption and hash creation like AES256 or SHA512.
Detailed information regarding this CSP is available by Microsoft®:
https://docs.microsoft.com/en-us/windows/desktop/seccertenroll/cryptoapi-cryptographic-service-providers
Related to the example from chapter Example for file-based Manager SSA certificates a CA can be created
with following command:
openssl pkcs12 -export -in root-cert.pem -inkey root-key.pem -out CAroot.pfx -CSP "Microsoft
Enhanced RSA and AES Cryptographic Provider"
And the host key for user para can be created with following command for the users named para and root:
openssl pkcs12 -export -in SSApara.crt -inkey SSApara.key -out SSApara.pfx -CSP "Microsoft
openssl pkcs12 -export -in SSAroot.crt -inkey SSAroot.key -out SSAroot.pfx -CSP "Microsoft
The created certificate files can be imported into the Windows certificate store. CAroot.pfx needs to be
imported into the “Trusted Root Certification Authorities” and it is recommended to import SSApara.pfx into the
Personal certificates of the Local Computer store.
ATTENTION
During the import it is essential to mark the private key as exportable to make the certificate readable
by WinCC OA processes.
Page 183 of 271

Figure 73 - Windows certificate Store with SSA certificates for Manager
Page 184 of 271

The following lines show how the WinCC OA config file needs to be configured to use the root certificate for
the WinCC OA project to start core WinCC OA managers like Data- or Event Manager. For all CTRL Managers
the certificate for the para user should be used.
[general]
ssaCertCheck = "chainPrefix=CARoot"
ssaCertificate = "store:MACHINE:MY:SSAroot"
ssaPrivateKey = "store:MACHINE:MY:SSAroot"
[ctrl]
ssaCertificate = "store:MACHINE:MY:SSApara"
ssaPrivateKey = "store:MACHINE:MY:SSApara"
This example makes it necessary to start the CTRL Manager as a specific user. With this setting it is possible
to start a specific manager as a user with limited access rights. A startup of a CTRL Manager as user root or
operator will fail due to wrong configuration.
Benefit of this approach is a hardening of the entire WinCC OA system to reduce the attack vectors to a
configured system.
Special functions / Security / Authentication / Server-side Authentication for managers

ATTENTION
The creation of a signature to the messages requires the existence of private key on the remote
machines. This makes it necessary to protect this file with OS methods.
Additional it is recommended to use the OS based certificate store
(see chapter: Storage of openSSL certificates and private keys)
Page 185 of 271

6.4.7 WinCC OA Server Configuration
According to definitions in chapter Security Cells and Network Architecture it is recommended to run a
WinCC OA server only in a secure environment. Server related WinCC OA processes that runs in a secured
environment shall be protected in multiple ways:
• Protected physical access (e.g. locked room, place with additional access control device, …)
• No devices for accessing the system (e.g. USB stick, CD/DVD drive, bluetooth, …)
• Plant network access only (no access from public network)

Control- and API Managers usually have common task to fulfill and they do this as root user, in the default
configuration. With the default configuration the servers need to be secured to avoid unauthorized access.
It is possible to reduce the security risk caused by usage of the root user by using certificates for each
WinCC OA manager. This feature allows the creation of Manager Certificates for a specific user, which is
configured due to the least privilege’s requirements. Further information is available
in chapter: Server-Side Authentication for Managers with session binding
Network topology should ensure that the server for Control and Api Managers cannot be accessed from
public but only from plant network (e.g. in DIN EN 50159 named as “Category 2 network”) so that
unauthorized access via network can be excluded. For network configuration
see chapter: Administration of networks and network services.
Page 186 of 271

6.4.8 WinCC OA User Interface Configuration
This chapter describes the different and possible UI architectures of WinCC OA. In dependency of the
operational environment different security requirements must be mentioned for a secure implementation. Not
all forms of an UI are recommended to be configured in a secure environment.
Basic Information regarding UI configuration is available with WinCC OA documentation:
WinCC OA UI
WinCC OA contains the following types of User Interfaces:
• Remote UI as Engineering Station (with Vision-, GEDI- and Para module) for Desktops and
Notebooks
• Remote UI as Operator Station (with Vision module) for Desktops and Notebooks
• Desktop UI for Desktop and Notebooks
• ULC UX for Desktop and Notebooks

• Mobile UI for Android and iOS
• Operator for iOS
• Siemens ITC (Industrial thin client) for Siemens HMI

…that can be connected using one of the following network configurations:
• Local LAN (without connection to the internet)

• Local WLAN
• LAN using VPN through internet connected network

• LAN/WLAN connected to internet with own firewall and proxies
• LAN/WLAN connected to internet with external firewall and proxies

WLAN generally is a dangerous means of networking as the information is spread all over the surrounding
where an attacker can easily make trials to compromise the attached devices. Therefore, it is generally
recommended to not use a WLAN device in a secure plant operation environment.
ATTENTION
For local communication between WinCC OA UI and embedded graphic modules like WebView.ewo,
an unencrypted http communication channel is used.
The host which executes the WinCC OA User interface module needs to be protected. Target is to
prevent a situation where this unencrypted connection is harmed by malicious software which is
locally installed directly on the UI host.
See chapter Virus Scanner to find ways to avoid this threat.
Page 187 of 271

6.4.8.1 Intended operational environment (UI)
• Remote UI is applicable for clients that are physically secured: access is restricted, secure login (e.g. AD
with appropriate settings, two-factor-authentication …), plant network only and OS hardening
(see chapter: Hardening). This installation can be used for all purposes.
• Desktop UI connects via HTTPS to the WinCC OA HTTP-Server; the required data (configuration,
certificates and project files) is downloaded from server but held locally. OS must be hardened
(see chapter: Hardening), if network is connected to internet a network connection via VPN is required. This
installation should not be used for administration purposes but for operator or viewing access.
• ULC UX may be used on any kind of computer as there are no local files hosted; the network connection
is secured using HTTPS. The computer should not be a public computer (e.g. internet coffee shop) as the
device could be compromised, the connection parameter and the credentials could be stolen (e.g. SSO
and other precautions can mitigate the danger of a key logger).
• Mobile UI Application is designed to work in a WLAN, so mobiles must be avoided in secure plant operation
environment. In this context the WinCC OA Operator App is also seen as Mobile UI.
As Matrix:
physically secured Administered Client Administered Client Public WLAN host
host host in plant network host in public network
Remote UI All functions Operator functions Restricted functions Not secure
Desktop UI All functions Operator functions Restricted functions Not secure
ULC UX All functions Operator functions Operator functions Restricted functions
Mobile UI N/A Not secure (WLAN)1 Not secure (WLAN)2 Not secure (WLAN)3
Operator APP
Table 14 – Matrix for UI in intended operational environment
Legend:
1. All functions → Complete functionality is secure for operator and administrative access
2. Operator functions → Functionality is secure for operator access
3. Restricted functions → Functionality is only secure for limited operator access (e.g. only read
functionality)
4. Not secure → Usage of this UI method must be prohibited to avoid a security risk.
1 Mobile devices are designed for a WLAN environment. This field refers to a secured WLAN environment.
2Mobile devices are designed for a WLAN environment. This field refers to an unsecured public WLAN environment
with an administrated client.
3Mobile devices are designed for a WLAN environment. This field refers to an unsecured public WLAN environment
with a non-administrated client.
Page 188 of 271

6.4.8.2 Device Management
Any device with a user interface (Desktop UI, ULC UX, and Mobile UI) can only connect if it is unlocked in
the device management panel.
6.4.9 Branding of WinCC OA MSI Installation

Branding of MSI installation package allows the implementation of special optical adjustments for the WinCC
OA installation.
Installation / Windows / Branding of the WinCC OA MSI Installation
Regarding aspects of security the following points must be considered for this process:
• Use WIX software (http://wixtoolset.org/ (acc.: 27th March 2019)) >3.10.2 to avoid dll hijacking
• The new installation folder must not contain blanks in an unquoted path, this could result into a
security threat if the WinCC OA project is started as a service:
http://www.commonexploits.com/unquoted-service-paths/ (acc.: 27th March 2019)
• The integrator should digitally sign the branded installation

(see chapter: Digital signatures for binaries and libraries)
Page 189 of 271

6.4.10 Configuration Settings for WinCC OA Video (vimaccOA)
WinCC OA provides universal video management software for transmitting, displaying or archiving video
data. The required components are optionally installable via WinCC OA setup (vimaccOA). These
components are defined as external vendor parts and named as Video Management System (VMS). The
following figure shows how WinCC OA and VMS parts interacts to implement WinCC OA Video.
Figure 74 - Interaction VMS and WinCC OA (Accellence Technologies, 2018)
Visible in the legend are three different types of communication:
1. Inter-Process-Communication (IPC).
Inter-process communication in vimaccOA means the data connections between the existing
processes. These connections are used to adjust the so-called "config", which (within the VMS)
enables system-wide data exchange via data points.
If an attacker can penetrate this communication, he receives system-wide read and write access to
the data points. To avoid this threat an AES-128 encryption algorithm is implemented. The required
certificates are installed during vimacc® setup process. This setup process uses a Video Security
Page 190 of 271

Wizard to create and deploy a file-based certificate. The correct deployment is in reasonability of the
Administrator on side of the asset owner.
Figure 75 - Video Security Wizard
The file based secret key is stored in following folder and this folder needs to be protected via OS
measurements:
• VIMACC® Process host: [vimacc® install folder]/data/features

• WinCC OA Server host: [WinCCOA project folder]/data/videoOA
2. Vimacc® Control Interface (vCI).

For data synchronization with higher-level control systems, such as the SCADA system "WinCC
OA", the VMS "vimacc®" of WinCC OA Video provides a corresponding control protocol. This control
protocol not only serves to control the system but also transmits status information from the video
system to the control system.
If an attacker is able to penetrate this communication, he receives the same possibilities as when
attacking the IPC connections. To avoid this issue an encryption mechanism is implemented which
protects the communication in the same way as for the IPC configuration.
3. Video data (Streaming & Record).

In addition to the control and synchronization connections, a VMS mediates and distributes
numerous video data. This is done to display live images in the form of continuous video streams
and to play back records in the form of a dedicated transmission of data blocks - so-called GOP's
(Group of Pictures).
If an attacker succeeds in penetrating this communication, he gets access to the image material as
well as the possibility to introduce fake video data into the system. A complete encryption helps to
avoid this threat.
A solution is implemented via Crypto Tokens (CTK) consisting of a public and a private key which
uses an RSA-2048 algorithm. This token is generated via Security Wizard for a specific facility; the
deployment of this CTK is done via vimacc® system and configuration of all configuration server is in
responsibility of the asset owner. Details regarding the implementation are available in following
figure.
Page 191 of 271

Figure 76 - CTK Implementation
The AES-128 Assetkey and the Crypto Token (CTK) are created via vimacc® Security Wizard and the Token
is encrypted by the AES-128 Assetkey. This encrypted CTK is stored and distributed via vimacc® system.
Beside of WinCC OA this CTK is read via WinCC OA Video Manager API Interface and the information is
stored as an encrypted blob on a WinCC OA datapoint.
After establishing of a new streaming interface, a session related AES-128 streaming key is created. This
streaming key is only valid for the current session. This AES-128 streaming key is encrypted via RSA-2048
CTK. The created key is used to encrypt the Video Datablock (GOP) and to create a SHA-1 hash.
The WinCC OA Video UI reads the encrypted key from the datapoint element
“_VIDEO_OA_MAIN.driver.encryption”. In a first step checks the hash, decrypts the Data block and finally
decodes the GOP. This makes the Video Stream readable for a human operator. This implementation
ensures a complete encryption from Camera to the operator. As already mentioned, the information on this
datapoint was written by the CTK deployment process. An alteration of this datapoint makes the Video
Stream not readable for the operator. And so, it is recommended configuring “_auth” configs to prevent the
system from a manipulation (see chapter: Protection via authorization levels in WinCC OA).
The figure shows also that a Camera interacts to the VMS Streaming Interface before the Video data is
available within the WinCC OA system. It must be mentioned that this communication should be encrypted in
a secure environment. The implementation was tested via Cameras from Axis Communications
(https://www.axis.com acc.: 27th March 2019) where an encryption functionality can be offered.
Page 192 of 271

Detailed information is available within the WinCC OA documentation:
Add-ons / Video
ATTENTION
For usage of video cameras following recommendations must be considered:
• The viewing area of a camera must not be able to track the input of a password on any device of
the observed area.
• Default passwords of a camera should be changed directly after the commissioning of a new
camera.
• A wired connection to a camera must not be useable to start a Man in the Middle attack.
• Wireless configuration should use a secure and encrypted transfer protocol (e.g. WPA2-
Enterprise) which is in addition protected via a VPN connection. It is also recommended to use
only an encrypted and wired connection (no WLAN) for Video streams which contain sensitive
information.
• Enable encryption within the security camera administrative tools. It is essential that a camera
delivers a reliable picture which is prevented from altering. Do not use a camera in a security
relevant area if an encryption feature is not available.
• Protect the administration software for the camera with a password (see: Password strength).
• Update camera firmware frequently or whenever necessary depending on advisories given by the
camera vendor.
• Limit the exposure of a camera to the local network in a security relevant environment (make
remote access via Internet only possible by usage of a VPN connection).
Page 193 of 271

As an additional and optional security layer it is also possible to hide the WinCC OA HTTP Server behind a
Reverse-Proxy (See chapter: Hide secure network behind a Reverse Proxy).
CAUTION
The implementation of vimacc® uses the open source library OpenCV in Version 3.1. This version
may be vulnerable according to CVE vulnerability database:
https://www.cvedetails.com/vulnerability-list/vendor_id-16327/product_id-36994/Opencv-Opencv.html
Although most of the vimaccOA implementation is not affected by most of the descripted
vulnerabilities, it may be possible that the module VMS Streaming interface may be affected for USB
cameras.
In a case of a vulnerability an assertion may occur which disconnects all video streams from the
same interface-instance.
To mitigate the risk, it is possible to configure the usage of an USB camera with a separate interface-
instance. This will only affect the USB cameras but has no negative effect to the remaining system.
Page 194 of 271

6.4.11 Example configuration of TLS in WinCC OA
TLS communication is implemented in WinCC OA by usage of WinCC OA Multiplexing Proxy (mxProxy).
This manager is used as a central communication point to reduce the amount of open ports for each host
and to ensure an encrypted communication.
The following figure gives a centralized overview for a communication from an untrusted zone to a trusted
zone via a DMZ. This figure shows where a communication is encrypted and where it is not encrypted. It also
shows the places where TLS certificates are required to ensure this communication method. The name of
file-based certificates is only explained in DMZ and for the CA.
Page 195 of 271

6.4.11.1 Example with remote mxProxy
Following solution shows an example where WinCC OA httpServer and WinCC OA mxProxy are running
within the DMZ.
• Advantage: WinCC OA mxProxy as predetermined breaking point running on a separate machine

• Disadvantage: Unsecure connection must be secured via IT Infrastructure measures.
Figure 77 - Communication Methods in WinCC OA with remote mxProxy
Page 196 of 271

The example above named as Figure 77 - Communication Methods in WinCC OA with remote mxProxy
shows following content:
• A domain controller with DNS, KDC and a CA is configured. Private keys for CA remain on AD
controller.
• Three different UI’s can establish a secure communication to WinCC OA server via a DMZ
o WinCC OA ULC UX Client needs no certificate. It accepts the CA public key from httpServer
in “Trusted Root Certification authorities” to establish a connection to WinCC OA httpServer.
Port 443 is required for Front End Firewall.
o DesktopUI and MobileUI get the CA public key from httpServer during the installation of a
WinCC OA project into local user cache. This setup copies also the required certificates for
mxProxy communication (public CA certificate, public Host certificate, private Host key). A
DesktopUI and a MobileUI need to establish a connection to WinCC OA httpServer and to
mxProxy. Port 443 and 5678 are required for Front End Firewall.
o RemoteUI is installed manually on a designed client. The required certificates for mxProxy
communication need to be copied manually (public CA certificate, public Host certificate,
private Host key). A RemoteUI establishes a connection via mxProxy. This remote UI can
establish a secure connection to the Oracle Server if an Oracle Client is installed and this
client communicates to the Oracle server via a secured connection. Port 5678 is required for
Front End Firewall
• A remote WinCC OA project within an unsecured network can establish a connection to the secure
network as well.
• Communication between all UIs and WinCC OA mxProxy is completely secured.
• DMZ Zone contains a WinCC OA httpServer and a WinCC OA mxProxy host. Both are required to
establish a communication between the untrusted and the trusted zone.
• WinCC OA httpServer in DMZ communicates via secured port 443 to WinCC OA httpServer in
WinCC OA server project. Port 4897 and Port 4998 are required for Back End firewall to establish an
unsecured connection between the CTRL-Manager from httpServer in DMZ to Data- and Event
Manager from WinCC OA server in secured zone.
Port 443 needs to be configured for Back End Firewall and ULC-UX reads WinCC OA panels from
WinCC OA Server via secured port 443.
• WinCC OA mxProxy receives all communications via Port 5678. The ports 4897 (data), 4998
(event), 4777 (dist) need to be configured on Back End Firewall. This means that this communication
is unencrypted.
• Trusted Zone contains a WinCC OA server with Data- and Event Manager but not a mxProxy.
Config entry mxProxy is configured with “none”
• Oracle Server operates in the trusted zone and has a connection via WinCC OA RDB manager to
WinCC OA server project.
Oracle itself provides remote clients with data which are configured with “queryRDBDirect=1”. This is
a config entry which allows the client to query data directly from Oracle server (via VPN Tunnel) to
avoid a detour via Data-Manager on WinCC OA server.
Page 197 of 271

6.4.11.2 Example with local mxProxy
Following solution shows an example where only WinCC OA httpServer runs in a DMZ but WinCC OA
mxProxy runs local on WinCC OA Server.
• Advantage: No unsecure connection

• Disadvantage: WinCC OA server could be attacked because determined breaking point mxProxy
runs local on the same machine as Data- and Event Manager.
Figure 78 - Communication Methods in WinCC OA with local mxProxy
Page 198 of 271

The example above named as Figure 78 - Communication Methods in WinCC OA with local mxProxy shows
following content
controller.
• Three different UI’s can establish a secure communication to WinCC OA server via a DMZ
o WinCC OA ULC UX Client needs no certificate. It accepts the CA public key from httpServer
in “Trusted Root Certification authorities” to establish a connection to WinCC OA httpServer.
Port 443 is required for Front End Firewall.
o DesktopUI and MobileUI get the CA public key from httpServer during the installation of a
WinCC OA project into local user cache. This setup copies also the required certificates for
mxProxy communication (public CA certificate, public Host certificate, private Host key). A
DesktopUI and a MobileUI needs to establish a connection to WinCC OA httpServer and to
mxProxy. Port 443 and 5678 are required for Front End Firewall.
o RemoteUI is installed manually on a designed client. The required certificates for mxProxy
communication need to be copied manually (public CA certificate, public Host certificate,
private Host key). A RemoteUI establishes a connection via mxProxy. This remote UI can
establish a secure connection to the Oracle Server if an Oracle Client is installed and the
client communicates to the Oracle server via a secured connection. Port 5678 is required for
Front End Firewall
• Communication between all UIs and WinCC OA server project is completely secured.
• DMZ Zone contains a WinCC OA httpServer
• WinCC OA httpServer in DMZ communicates via secured port 443 to WinCC OA httpServer in
WinCC OA server project. This httpServer communicates via secured port 5678 to mxProxy.
Port 443 needs to be configured for Back End Firewall. ULC-UX reads panels from WinCC OA
Server via secured port 443.
• WinCC OA mxProxy receives all communications via secured port 5678.

• Trusted Zone contains a WinCC OA server with Data- and Event Manager including mxProxy in
default configuration.
• WinCC OA mxProxy runs locally on secure WinCC OA server.
Page 199 of 271

6.4.11.3 Example with local mxProxy and remote Apache Reverse-Proxy
The following example shows mostly an equal configuration compared to chapter Example with local mxProxy,
but with an Apache Reverse-Proxy as determined breaking point. This is the solution with the highest level of
security from the selected examples. (see chapter: Hide secure network behind a Reverse Proxy).
• Advantage: No unsecure connection and Apache Server as determined breaking point.

• Disadvantage: Additional Apache Reverse-Proxy Server required.
Figure 79 - Communication Methods in WinCC OA with local mxProxy and Apache Reverse-Proxy
Page 200 of 271

The example above named as Figure 79 - Communication Methods in WinCC OA with local mxProxy and
Apache Reverse-Proxy shows following content:
controller.
• All types of UI connection and the distributed WinCC OA project establish a connection via a
configured Apache Reverse-Proxy.
• Apache Reverse-Proxy forwards the incoming traffic to the required hosts:
o WinCC OA httpServer within DMZ
o WinCC OA Server in trusted network
• Apache Reverse-Proxy is configured as determined breaking point for all connections outside the
trusted network.
• Front End Firewall needs to be configured to accepts the configured ports to establish a connection to
Apache Reverse-Proxy within the DMZ.
• Back End Firewall needs to accept port 443 for http communication and port 5678 for mxProxy.
• Communication between all UIs and DIST Connections to WinCC OA server project is completely
secured.
• DMZ Zone contains a WinCC OA httpServer and an Apache Reverse-Proxy.
• WinCC OA httpServer in DMZ communicates via secured port 443 to WinCC OA httpServer on WinCC
OA server project.
• WinCC OA Control Manager for WinCC OA httpServer communicates via secured port 5678 to
mxProxy.
• Port 443 needs to be configured for Back End Firewall. ULC-UX reads panels from WinCC OA Server
via secured port 443.
• Port 5678 needs to be configured for Back End Firewall to establish a connection to mxProxy in trusted
network.
• Trusted Zone contains a WinCC OA server with Data- and Event Manager including mxProxy in default
configuration.
• WinCC OA mxProxy runs locally on secure WinCC OA server.
Page 201 of 271

Patch management and security updates
Most of the security breaches are performed via security holes that have already been patched by the
software producers. Only in rare cases a zero-day exploit is used in which a weakness is used which is not
officially known or where no patch is available. A centralized patch management aids the distribution of
patches.
Note:
In this document ETM professional control GmbH can only give a few general recommendations for
specific cases but an overall security guideline for this topic can be given by international standards.
A common standard in IACS environment is this document: IEC/TR 62443‑2‑3, Industrial

communication networks – Network and system security – Part 2-3: Patch management in the IACS
environment.
Patch management is the scheduled procedure for installing patches on plant computers. The following
issues need to be clarified at the time of planning:
• Which patches need to be installed?
• Which tests are used for the patches before installing them on the plant?
• When will these patches be installed?

• What is the sequence in which these patches are installed?
• How should these patches be installed on the plant computers?
The patch management of a system is effective only if it is a part of a comprehensive security concept. The
exclusive use of patch management and security updates cannot protect a system from security threats. As
soon as information regarding a weakness is available the relevance for the own application must be
evaluated. Depending on the evaluation it must be decided if further steps are required:
• No action, existing security measurements are enough
• Add additional external measurements to ensure the security level
• Installation of current software updates to eliminate the weakness
Page 202 of 271

6.5.1 Patches and Security Updates
Patch For OS producers all kind of updates, service packs, feature packs or
similar installations are gathered in the term „patch“. They may or may not
be security relevant.
Security updates: Security updates provided by OS producers only contain updates that are
related to security topics.
Table 15 – Types of OS related patches
WinCC OA summary patches (containing all changes for the corresponding version) for Windows and Linux
are usually published in a defined interval and can be downloaded from the SIMATIC WinCC Open
Architecture Portal (https://www.winccoa.com/) in section “Downloads”.
It is recommended to subscribe for security advisories published by Siemens CERT to get information
regarding current vulnerabilities and counter-measures:
https://www.siemens.com/global/en/home/products/services/cert.html (acc.: 27th March 2019)
Usually it is necessary to stop a running project to install the new patch and to restart it afterwards, by usage
of the redundancy and split functionality from WinCC OA it is possible to upgrade and test only one side of
the redundant system while the other side remains running with the not patched installation.
Project administration / Project administration / Update or patch project
For Siemens automation components like a PLC which does not use default PC operating systems it can be
necessary to correct security related issues through a firmware update. Corresponding information can be
found on the Siemens Industrial Security Website:
http://www.siemens.com/industrialsecurity (acc.: 27th March 2019)).
6.5.2 Use of the patch management

Patch management should not impair the process operation of a plant. To ensure this, the following
configurations are tested and recommended:
6.5.2.1 Centralized patch management

From both the administration and security points of view, patch management should be done centrally. A
central server, preferably located in the perimeter network, downloads the patches from trusted sources and
distributes them in the internal network.
In this manner, a centralized configuration and monitoring system is available to the Plant administrator. The
plant computers do not require internet access. The patch server is placed in a perimeter network isolated by
a firewall. On this server new patches are downloaded from the internet.
Page 203 of 271

6.5.2.2 Windows
It is recommended to use WSUS for centralized patch management. This is made available by Microsoft®
free of charge and provides all functions that are required for patch management. The WSUS offers a variety
of different patch classes for almost all Microsoft® products
The loaded patches can be distributed to the plant computers by using a SCCM server. Any automatic
synchronization or restart of the updated computer should be prevented due to undesired influence on the
whole plant. Instead the update should be performed manually at a predefined date.
See chapter: Procedure for Patch Management
6.5.2.2.1 Prerequisites for WSUS server

Following parts are required by a WSUS server:
• Every computer needs an Ethernet connection to the WSUS server
• Windows OS is mandatory for WSUS and SCCM

• Internet access for WSUS server required to deploy Microsoft® updates
• SCCM is necessary to deploy software like Anti-Virus software or WinCC OA Patches.
• A single SCCM server could assume the combined functionality as WSUS and as SCCM server but
it is recommended to separate those functionalities
6.5.2.2.2 Patch classifications for WSUS server

With the introduction of the WSUS and the extension of Windows Update to Microsoft Update (Patches for a
large number of Microsoft® products), new classifications have been introduced for the individual patches
(https://support.microsoft.com/en-us/kb/824684 (acc.: 27th March 2019)):
• Critical updates
• Definition Updates
• Drivers
• Feature Packs
• Security Updates
• Service Packs
• Tools
• Update
• Update Rollups
• Security-only updates
• Monthly Rollup
• Preview of Monthly Rollups
Page 204 of 271

The following update classes are particularly important for secure and stable operation of a system:
• Security Updates: A widely released fix for a product-specific, security-related vulnerability. Security
vulnerabilities are rated by their severity. The severity rating is indicated in the Microsoft® security
bulletin as critical, important, moderate, or low.
• Critical Updates: A widely released fix for a specific problem that addresses a critical, non-security-
related bug.
These two update classes must be subjected to a compatibility test with the respective WinCC OA version
and classified as compatible after a successfully conducted test executed by the Integrator or asset owner.
Patching the systems is not the only security measure used to protect a system or the entire corporate
network. By implementing an in-depth defense (use of all security techniques described in this Security
Guideline), a potential hacker must first overcome several security levels before he could exploit any
vulnerable spots of a missing security update.
This protection gives extra time for evaluating and testing the patches to be installed.
6.5.2.2.3 Procedure for Patch Management for WSUS Server

Since maintaining control over the process is the most important principle, the administrator must specifically
choose the time at which the patches are installed. To validate the integrity and functions of a patch it is
recommended to install the patch on a test system equal to the live system before installing the patch for the
live operating plant. Furthermore, plant specific adjustments can be necessary if default functions have been
changed.
In addition, groups should be formed (for example, one group with all master servers and one with all
standby servers) and install the patches group by group.
Page 205 of 271

The creation of back-ups must be considered. Every change of the configuration, e.g. installing a patch, can
create unexpected and negative impacts on the system. In such a situation the best case is to import an
existing backup to revert to the initial state.
Figure 80 - Usage of WSUS server
6.5.2.3 Linux
Due to the natural fragmentation of existing Linux OS systems different mechanisms are available to update
an existing machine. Usually at least a packet management tool like APT, APT-GET, YUM or ZYPPER
needs to be installed. This upgrade is possible by manually triggering the specific functions. Please note that
following operations need root permission for execution and therefore the following examples are triggered
with the sudo command.
• Upgrade with yum package (usually in CentOS® / RedHat® machines)

o sudo yum update
o sudo yum upgrade
• Upgrade with apt-get package (usually for SuSe Linux Enterprise Server(SLES) Linux machines)
o sudo apt-get update
o sudo apt-get upgrade
Both operations check if new updates for installed packages are available and start the installation after a
manual confirmation.
Page 206 of 271

6.5.2.3.1 Install Linux Mirror Server for Updates or Installs
Due to secure network restrictions it is recommended to install a mirror server which keeps the repository for
an update procedure within a DMZ. An update procedure for apt-get or yum should get the required files
from a dedicated server instead from the internet. Documentation regarding setup and configuration of mirror
servers are available by vendors of Linux distributions:
• CentOS®: https://wiki.centos.org/HowTos/CreateLocalMirror (acc.: 27th March 2019)
• openSUSE®: https://www.suse.com/documentation/slms1/book_slms/data/cha_updates.html
6.5.2.3.2 Activate automatic upgrades

Like for Windows it is also possible to activate the automatic upgrade procedure within a Linux system.
Automatic upgrade with yum package (usually in CentOS® machines)
• Install the required package by the following command:

o sudo yum -y install yum-cron
o Edit the configuration file to apply any specific requirements in this file:
/etc/yum/yum-cron.conf
More information:
https://linuxaria.com/howto/enabling-automatic-updates-in-centos-7-and-rhel-7 (acc.: 27th March 2019)
Automatic upgrade with apt-get package (openSUSE®)
• Install the required package by the following command:

o apt-get install unattended-upgrades apt-listchanges
o Edit the configuration file to apply any specific requirements in this file:
/etc/apt/apt.conf.d/50unattended-upgrades
More information: https://wiki.debian.org/UnattendedUpgrades (acc.: 27th March 2019)
Page 207 of 271

Virus Scanner
The use of virus scanners within a system is effective only if it is a part of a comprehensive security concept.
In general, the use of a virus scanner alone cannot protect a system from security threats.
Definitions:
• Virus scan server

A computer that administers the virus scan clients centrally loads the virus signatures and distributes
them on the virus scan clients.
• Virus scan client
A computer that is checked for viruses and is administered by the virus scan server.
6.6.1 Use of virus scanners

The use of a virus scanner should not impair the process operation of a plant. Ultimately, this leads to the
fact that a virus-inflicted computer should not be shut down automatically and immediately, if as a result,
control over the production process would be lost. Therefore, the following requirements must be met by a
virus scanner for use in industrial automation and control systems (IACS):
• If a local firewall, adapted to the process operation, is being used, it must be possible to install the
virus scanner even without its own firewall.
• The virus scan clients may be divided in (product-related and task-related) groups and configured
separately.
• It must be possible to disable the automatic distribution of the virus signatures and other updates.
• It must be possible to distribute the virus signatures and updates manually and group-wise.
• It must be possible to scan files and the system manually and group-wise.
• In case a virus is detected, if is recommended to configure a message without any file-related action
such as, for example, "Delete", "Clean" etc. being carried out automatically.
• It must be possible to log all messages on the virus scanner server.

• It must be possible to suppress the local message window on a virus scan client since it could
overlap important process control system messages.
Note:
Software installation is often a procedure that represents a serious and complicated system change
to the respective system. The files to be installed must always be virus-free (e.g. a file server with its
own virus scanner or a DVD checked for viruses). A virus scanner should not hinder the installation
unnecessarily or, in fact, corrupt it. Hence, it must be possible to disable it completely if problems
occur during installation.
Page 208 of 271

6.6.2 Principle architecture of a virus scanner
ETM professional control GmbH recommends the simplified virus scanner architecture illustrated in the
following to realize the demands mentioned in the previous section.
The virus scan server receives the virus signatures from the internet and from the update server of the
respective manufacturer or from a supervisory virus scan server and administers the virus scan clients.
Figure 81 - Virus Scan Overview (Siemens, 2019)
It is possible to use multiple virus scan servers depending on the manufacturer. These may also be arranged
hierarchically.
Page 209 of 271

After the virus scan server has received the virus signatures and they have been checked on a test system,
the virus signatures are distributed on the virus scan client’s group-wise. The manageability by groups is a
feature of the Virus Scan Software package. Many vendors which offers Virus Scanners in an Enterprise
offers this feature with their product.
An example for the usage of groups are Client machines. Some machines are fixed positioned within the
PCN and some other may be used for a mobile usage (Laptops). Another example are different kinds of
Servers like WinCC OA server or Oracle Servers.
Each option requires a different configuration of the Anti-Virus Software and this can be achieved by usage
of management groups.
Four groups have been created in the following figure. Depending on the system requirements more or fewer
groups can be created. However, there should be at least two groups present.
Figure 82 - Usage of Virus scan server
A list with the tested Anti-Virus Software for WinCC OA 3.16 FP2 (P009) is available within the
documentation.
Installation / Requirements for WinCC OA / Software requirements / Paragraph: Virus scanner
Page 210 of 271

Additional to the architecture of the Anti-Virus deployment system following steps should be considered
regarding the recommendation from ICS-cert with the “Updating Antivirus in an Industrial Control System”
document:
• Verify the source of the update.

• Download the update file(s) to a dedicated host (server or workstation).
• Scan the downloaded file(s) for malware.

• Verify the cryptographic hash of each downloaded file(s).
• Scan the removable media for malware or other unexpected data before use to verify its integrity.
The most secure options are to securely erase the removable media and reformat the drive with the
appropriate file system (for flash or magnetic media) or to use a new CD or DVD (for optical media)
for each update
• Write the file(s) to the removable media. Dedicate this media exclusively for updates.
• Lock the media so others cannot write to it.

• Load the media into the test environment and verify that it has no adverse impact to the test system.
• Re-scan the media for malware or other unexpected data to verify that nothing transferred to the re-
movable media from the test environment host.
• Install the update on a non-critical endpoint or segment of the system and verify that it has no
adverse impact to the production system.
• Install the update on the remaining hosts.

• Monitor the system for any unusual behavior and verify proper operation of the ICS.
(ICS-Cert, 2018, S. 2)
Page 211 of 271

Logging, audit, maintenance and asset management
The capability of detecting attempted and actual security threats is rapidly developing. Due to the
requirements for verification in many branches, reporting and event log evaluation must be increasingly
included in current security concepts. Runtime must continue without interference despite the added load,
however.
The following reporting can be configured and evaluated as needed, in addition to the alarm and messaging
systems of process control for example:
• Local event logs
• Event logs of the domain controller
• Event logs of the firewall(s)
• Event logs of the virus scanners
• Audit trail (e.g. configurable in Windows)
Asset management in plant technology refers to the management of equipment as well as the activities and
measures that serve to maintain or enhance the value of the plant.
Asset management is a very sensitive subject in the field of security engineering, since this data also
presents a weak point in a plant. In general, asset management and its administrative rights should be
restricted to the functional area within the plant's security cell.
The procedures described in the paragraph on Secure Access Techniques section can be used to publish
maintenance data beyond the borders of the security cell. This reliably prevents direct access from the
outside – for example, to sensors or actuators on the field level.
6.7.1 Observe audit logging and transmit information to WinCC OA

Via SNMP Agent it is recommended to define suspicious messages (e.g. Windows event log or Linux system
logs) on OS level.
The tool should mention the following messages:
• Host Log Files (Windows Event logs or Unix/Linux system logs)

• Failed authentication (log on) attempts recorded in the security log
• Successful authentication to unknown or dormant accounts or from unknown hosts recorded in the
security log
• Authentication attempts outside office hours
• Unusual high number of log entries in each time frame or many errors logged
• Execution of untypical commands or functions
• Gaps in or erasure of system logs

Occurrence of such messages in a live system should trigger an SNMP trap. This message needs to be
transmitted to WinCC OA and raise a visible Alarm for the operator in WinCC OA Alert screen. With this
information it is possible to start countermeasures to protect the system from a possible attack.
Page 212 of 271

6.7.2 Implement Intrusion detection system
A good analysis of the overall system is the implementation of an intrusion detection system (IDS). This is a
device or software application that monitors a network or systems for malicious activity or policy violations. A
detailed description including reference for available products is given by the Wikipedia article:
https://en.wikipedia.org/wiki/Intrusion_detection_system (acc.: 27th March 2019)
It is recommended to analyze the interface and to check if a transfer of an occurrence is possible via SNMP
trap or any other protocol message which is readable by WinCC OA. With this message it is possible to
trigger further activities inside WinCC OA to inform the operator about suspicious activities in the system.
List of possible several threats which may be detected by an IDS system:
• System Resources
o Usage of system resources for potential illegal/unknown actions (e.g. unknown data or data not
related to regular system operation is found on storage media/shares, high CPU usage)
o Exceptional high network load (e.g., machines on network sending data consuming resources on
other systems)
o Exceptional slow or irregular system performance
o Unexplainable system crashes
• Applications & 3rd party software

o Detection of malware on the system by antivirus software
o Host firewall blocks and reports suspicious activity
o Presence of unfamiliar software applications
o Unfamiliar processes running
o Unexplainable errors reported by 3rd party applications (e.g., by database server, Webserver)
• Network Log Files

o Network scans (connection attempts to many IP addresses or multiple ports) originating from a
single host
o Outgoing HTTP connections to suspicious Websites
o Large volume of outgoing traffic
o Connection attempts to ports blocked at the perimeter firewall
o Log entries show network traffic outside office hours
• Users
o Presence of new accounts not created by administrators
o Unexplained use of privileges at OS or application level (functions or applications running with
other privileges than normal)
o Locked user accounts not based on user’s fault
o Compromised user accounts (e.g., user account activity detected without original user presence)
Page 213 of 271

• System Changes
o Unexplainable deletion or replacement of files needed by OS or application (e.g., DLL)
o Unexplainable presence of new files
o Existence of large unknown data files
o Modifications of the hosts file %SystemRoot%\system32\drivers\etc\hosts, in particular large
number of entries pointing to the loopback address 127.0.0.1
o Suspicious active services, services with suspicious names or missing or incomplete service
description
o Terminal Services service is active
o netstat shows unknown open ports in the “Listening” state
o netstat shows a large number of outgoing connections in particular to TCP ports 22 (SSH), 139
(NetBIOS) or 445 (SMB)
The complete list is given by the Wikipedia article:
https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers (acc.: 27th March 2019)
• Others
o Unusual behavior after plugging in external media (e.g. USB stick, hard disk)
o Publication/leakage of internal system data on external Websites
Page 214 of 271

Security tests
Security measures are checked regularly, updated and supplemented, if required. This is necessary, on one
hand, since the fast-developing technology needs new security measures, and on the other hand, new
threats keep coming up.
Network administrators can perform automatic tests of the target system with the help of so-called "Security
Scanners". The security scanners are accessing special databases, e.g. those of the SANS institute
(SysAdmin, Networking and Security). Those databases hold lists of security gaps currently known and
widespread, e.g. the list of CVEs (Common Vulnerabilities and Exposures). The security scanners test if any
known vulnerable spots are present in the system being checked.
Security scans are basically divided in four categories:
• Blackbox scan
• Whitebox scan
• Penetration test
• Vulnerability Scanning (Nessus, OpenVAS)
6.8.1 Knowledge of Security Testing

The rapid digitalization of critical infrastructure poses a wealth of new security challenges, which requires
new ways of security testing. Comprehensive education and experience are essential for a Security Tester to
implement a holistic Security Testing concept for a plant or a project. Therefore, it is essential to implement a
training concept for Security Testers.
A proper education can be given by the International Software Testing Qualification Board (ISTQB):
http://www.istqb.org/certification-path-root/advanced-security-tester.html (acc.: 27th March 2019)
Another guides regarding security testing can be given by the Open Web Application Security Project
(OWASP):
https://www.owasp.org/index.php/Testing_Guide_Introduction (acc.: 27th March 2019)
6.8.2 Blackbox scan

The Blackbox scan refers to testing a target system for vulnerabilities to security, from the viewpoint of a
hacker who does not have any system-internal information. In a Blackbox scan, the system is considered as
a closed unit, i.e. neither the configuration nor the network structure of the target system is known.
In a Blackbox scan, points of attack identifiable externally are detected as vulnerable spots (e.g. open ports,
accessible services …). Other hacking options that the system offers to the hacker after exploiting these
vulnerable spots remain unidentified.
Page 215 of 271

6.8.3 Whitebox scan
In contrast to the Blackbox scan, the Whitebox scan uses system-internal information. The target system is
tested for existing vulnerable spots. In this case, it is from the viewpoint of an administrator. A Whitebox scan
(also called glass box scan) tests individual components of the system and their interactions and determines
any configurations that are critical with respect to security.
The Whitebox scan also detects hazards, which, for example, exist because of outdated versions of user
software or are attributable to negligent user account administration.
An example for a Whitebox scan is the Microsoft® Baseline Security Analyzer (MBSA).
It can be used for the following purposes in addition to other tasks:
• Searching one or more computer for vulnerabilities from poor user management, for example
• Determination of the availability of security updates for one or more computers
• Searching for vulnerability caused by misconfigured Access Control List (ACL) which may be used
for a tampering attack by a criminal attacker.
6.8.4 Penetration tests

Penetration test tools are special security scanners. Penetration tests are conducted with the resources and
methods that a hacker would use to penetrate the system without authorization.
ATTENTION
A running process control system should never be tested with penetration test tools. The use of
penetration tests tools is always associated with the risk that the system tested (or the installation or
configuration of the system) may get damaged permanently.
The use of security scanners in the Whitebox scan for the maintenance period (plant shutdown) should be
supported by the manufacturer of each product, and this must be tested in advance, if needed.
Other tools that can be used, for example, for security tests under laboratory conditions:
• Port scanner
• Network/OS vulnerability scanner
• Application/Database vulnerability scanner

• Password cracker
• File searching and analyzing tool

• Network analyzer
• Exploit protection tool
ATTENTION
Before using the tools stated above the respective and current legal situation must be checked!
Page 216 of 271

6.8.5 Vulnerability Scanning
Vulnerability scanners are used to scan computers or complete networks by usage of automated tools.
Those tools usually create reports which show common vulnerabilities to the system. Based on this report it
is possible the get a basic analysis of the vulnerabilities inside configured IT infrastructure.
6.8.5.1 Publicly available Solutions
Different options for Vulnerability scanners are available and here is a small list:
• Nessus - https://www.tenable.com/products/nessus/nessus-professional (acc.: 27th March 2019)
• openVAS - http://www.openvas.org/index.html (acc.: 27th March 2019)
6.8.5.2 Recommended Solution with SiESTA

The actual version of WinCC Open Architecture is tested with a product named Siemens Extensible Security
Testing Appliance (SiESTA).
This is a variety set of vulnerability scanners where each scanner can be configured to the required needs.
The SiESTA Toolset provides a centralized user interface for different vulnerability scanners including a
configurable method for automatic evaluation of scan results.
The following tools are - among others - integrated in SiESTA:
• Nmap Scan
• Nessus
• SSLyze
• STYX
• Kali Linux
More details regarding SiESTA are available by Siemens CT at following homepage for interested parties
within Siemens. A login with Siemens user credentials is required to access this page, those credentials
cannot be provided by ETM for interested parties outside from Siemens:
https://wiki.ct.siemens.de/display/SiESTA/SiESTA+Home (acc.: 27th March 2019).
https://new.siemens.com/global/en/company/stories/research-technologies/a-swiss-army-knife-for-digital-
security.html (acc. 10th May 2019).
WinCC OA is tested by SiESTA with the goal to identify and resolve all known vulnerabilities before the
product is released to market.
Page 217 of 271

Implement Backup and Restore concept
6.9.1 General Information
A well-defined security concept can protect the facility from a typical availability related attack scenario, but a
complete protection without any negative impact is usually not possible. A typical risk is an attack that
successfully places a lock virus which encrypts the entire file system. In this situation it is necessary to have
a reliable backup concept to successfully restore the system.
Beside the backup concept it is also essential to create an own disaster recovery concept which includes all
required steps to restore the system within a short time span. This is important because this is usually an
exceptional situation which could cause panic. That delays the restore process if an important step in the
restore procedure was forgotten. Therefore, it is recommended to create a step by step list which could be
realized within a short time span.
Besides the implemented Backup and Restore functionality within WinCC OA for historical data and the
configuration database it is also necessary to take care of the OS environment and plan a backup for
network equipment like switches.
6.9.2 OS related backup

External vendor software could be used for planning an execution of those backups. The dedicated software
should take care of the complete OS configuration including AD and network configuration. Typical backup
software contains 3 different kinds of backup procedure:
• Full-Backup: This backup mode takes most time and needs the most place on the backup medium. It
is recommended to configure this mode in larger timeslots when the load on site is reduced like
during weekends (e.g. Sunday night)
• Incremental Backup: This will backup just the changes since the last full or incremental backup. This
backup procedure can be configured in a smaller timeslot than a full backup. For restoring it is
necessary to restore the newest full backup and the incremental backup in the correct timely order. A
typical incremental backup could run on delay basis and so be scheduled for every night.
• Differential backup: It takes only the changes since the last full backup
Page 218 of 271

Sunday Full Backup
Saturday Monday Incremental

Incremental Backup Backup
Friday Incremental Tuesday Incremental

Backup Backup
Thursday Wednesday
Incremental Backup Incremental Backup
Figure 83 - Backup Schema
The noted timeslots are not a specific recommendation by ETM profession control GmbH and are used only
as examples; it is necessary to define own timeslots for every site to fulfill the specific requirements.
Beside the type of the backup it is also necessary to define a backup medium rotation for those devices. It is
good practice to use a typical and documented rotation schema for this approach. A schema following a
“Grandfather-Father-Son” principle is only one of several options. A typical rotation for a grandfather could
run on monthly basis, for the father on weekly and daily basis for the son.
Page 219 of 271

Grandfather
(monthly)
Father
(weekly)
Son
(daily)
Figure 84 - Grandfather/Father/Son backup principle
Page 220 of 271

6.9.2.1 Selection of OS related backup software
Different vendors offer special solutions for backup and recovery software. ETM professional control GmbH
cannot recommend any specific software that fulfills the requirements for every project/plant. But different
selection guidelines are available online like an article from
Gartner Inc. (https://www.gartner.com (acc.: 27th March 2019)). This is an American research and advisory
firm providing information technology related insight for IT and other business leaders located across the
world.
For backup and recovery software this firm provided a specific article and reviewed a few products from
different vendors. As a result, they published the following chart online:
Figure 85 - Magic square by Gartner for vendors of backup and restore software (Gartner, 2017)
Page 221 of 271

This chart from July 2017 shows that the products
from Commvault, IBM, Dell EMC, Veritas Maintanbility
Technologies and Veen as leaders in the market
of backup and restore software. ETM professional
control GmbH recommends checking the actual Usability Efficiency
study from Gartner and to review the articles for
those products. The selected product should fulfill
all requirements for the specific project/plant. A
good help to find a reliable backup and restore
software is given by ISO/IEC 9126
(https://en.wikipedia.org/wiki/ISO/IEC_9126 Functionality Portability
(acc.: 27th March 2019)). This standard gives a
good hand on concept to analyze and find the
correct software. Reliability
Even if IEC 9126 was already replaced by IEC

25000 the existing web pages give a good Figure 86 - IEC 9126 Schema
overview how to assess software from a 3rd party
vendor.
More datails regarding IEC 25000 are available within the standard itself which can by acquired online
(https://www.beuth.de/en/standard/iso-iec-25000/204260933 (acc.: 27th March 2019)). This analysis could
help to fulfill the requirements on site if a fulfillment of a security standard like IEC62443 3-3 is mandatory.
6.9.2.2 Configure exceptions for OS related backup

Due to multiple file access especially during a running OS backup a few unforeseen issues could occur.
To avoid bad side effects ETM professional control GmbH recommends excluding a few folders from the
online backup mechanism. The backup of those files could be done with other mechanisms
(see chapter: WinCC OA related backup).
• db folder from WinCC OA project
• log folder from WinCC OA project
• data folder from WinCC OA project

The other content of the WinCC OA project folder could be part of the OS based backup. Please note that
this delimitation is only valid for a running WinCC OA project. There is no limitation if no WinCC OA
project is running. The complete content of the machines could be part of a full backup procedure if the
WinCC OA project is stopped during this procedure but must be excluded for incremental backup while
the WinCC OA project is running.
6.9.3 Network equipment backup

Most current network equipment like switches from Cisco, Nortel or another supplier of network
equipment allows the export of the actual configuration. Those backups should be triggered each time
directly after a configuration update for the device was accomplished.
Page 222 of 271

6.9.4 DB-Server (Oracle) backup
A cyclic backup needs to be configured according to recommendations from Specialists. Following
whitepapers are provided by Oracle itself and give hints how a backup and restore process shall be
implemented.
https://www.oracle.com/technetwork/database/database-
appliance/documentation/dbappliancebackupstrategies-519664.pdf (acc.: 15th May 2019)
https://www.oracle.com/technetwork/database/features/311394-132335.pdf (acc.: 15th May 2019)
6.9.5 WinCC OA related backup

In addition to the OS specific backup a WinCC OA related backup needs to be implemented. In general, it is
possible to differ between three types of backup:
Online Backup: This triggers a backup of the actual Raima-

DB image from WinCC OA which contains the complete DP-
Type configuration, the Datapoints and the related attribute
configuration, e.g. peripheral addresses or original values. This
backup type contains the complete process image of a running
project. Also, historical data can be included in the backup
using this backup type.
Figure 87 - Online Backup
Parameterization Backup: This backup method is part of the

Online Backup panel. It allows a backup of all configuration
parts within a project. This involves all scripts and panels
including the relevant colorDB files for this project.
With the same backup method an ASCII output is triggered
which backups the complete data model configuration (DPTs,
DPs, configs) of the project into text based ascii files. A
combination of this backup method with the Online Backup
creates a complete snapshot of a project and makes it possible
to restore an entire project without historical files.
Figure 88 - Parameterization Backup
Page 223 of 271

Historical backup: This method is related to the selected
logging option for Oracle via RDB Manager, Historical DB or
Alerts Logging within the Raima DB. For every option it is
possible to configure the time when a switch of the actual file
should be applied. Typically, a switch of a file should occur on
a weekly or monthly basis, but this depends on the specific
requirement especially for Historical DB data. For all those
options it is possible to define which data should remain online
and which files shall be copied to a backup device. Typically,
those files are also stored on disk and need to be copied to a
tape in a periodic manner. This backup could be applied
together with the OS related backup. In general, it is possible
to define the same backup schema (e.g. Grandfather-Father- Figure 89 – Archives in Historical Archive
(HDB)
Son) for those files.
The two screenshots show a possible way to split the amount

of data into different groups and to define an own backup
procedure for each archive (HDB) or archive group (RDB).
Datapoints are applicable for each group and this makes it
possible to define different backup intervals for every Datapoint
in dependency of the content (e.g. for DP with fast update
intervals it is not necessary to keep them for more than 1 year
online, but a calculated average value based on this value
should stay available even after 1 year).
Figure 90 – Archive Groups in RDB

Archive
System management / Database / History DB (Database Configuration)
Page 224 of 271

6.9.6 External Data Storage
A backup to portable medium, e.g. a data tape, offers the option transfer data into another and secure
building separated from the site building (e.g. safe deposit box). In cases where the complete site building
gets destroyed including the complete hardware (e.g. Fire) it will be possible to reassemble the complete
configuration if the medium was stored safely. Those external backups could be used for yearly or monthly
backups.
6.9.7 Restore procedure

As already mentioned in the chapter above it is recommended to define a disaster recovery procedure for
the own facility. It is necessary to define each step with additional information. For example, this disaster
recovery procedure holds the following steps:
1. Inform the staff members of the ongoing restore procedure and tell them when the system is available
again
2. Get the backup tape from the external building (add here the Address and the number of the safe
deposit box)
3. Restore Backup for e.g. CISCO switches
4. Restore AD system with the last full backup
5. Restore all incremental backups created after the last full backup
6. Apply the last two steps for all other machines
7. Restore Online Backup for WinCC OA project.
8. Restore Parameterization Backup for WinCC OA project.
9. Restore Historical Data
10. Start the system
For reasons of precaution the restore procedure of an automated backup should minimum once be executed
on a test system.
Page 225 of 271

Implement Risk assessment process based on VDI/VDE 2182
6.10.1 Definition of Risk assessment process
Both the project specifications and the threat situation can change over time, so that it is necessary to repeat
the procedure at regular intervals or event-driven, to adjust the measures if necessary. This approach is
known as “Plan-Do-Check-Act” or PDCA. IEC62443 requires an execution of this guideline by all
stakeholders. The detailed approach for this guideline and dependencies are explained inside this norm
(https://www.vdi.de/uploads/tx_vdirili/pdf/1728597.pdf (acc.: 27th March 2019)).
This guideline describes how specific measures can be implemented to guarantee the IT security of
automated machines and plant; aspects of the automation devices, automation systems, and automation
applications are considered. A uniform, feasible procedure for ensuring IT security throughout the entire life
cycle of automation devices, systems, and applications is described. The lifecycle covers development,
integration, operation, migration and decommissioning phases.
This guideline defines a simple procedure for the development and description of IT security. This model
consists of eight steps. The implementation of this model from the viewpoint of vendors, integrators/machine
vendors and plant management will be described in the guidelines VDI/VDE 2182 Part2, Part3, and Part4.
Applying the methods and measures described in this guideline will allow systematic solutions to be
achieved which are appropriate to the level of protection required meaning that they are also cost effective.
1. Identify assets
8. Perform process
2. Analyze threats
audits
3. determine
7. Implements
relevant security
countermeasures
objectives
6. Select 4. Analyse and assess

countermeasures risks
5. Identify measures
and assess
effectiveness
Figure 91 - Steps of VDI/VDE 2182
Page 226 of 271

1. In the 1st step the view of the asset owner is limited to a functional related view. Specific
hardware components are not defined at this point of time. The asset owner should provide this
information in form of a tender specification. A detailed definition will be defined during this
project in corporation with the integrator in form of a performance specification.
2. The assets from the 1st step is analyzed from a functional point of view. The threat analysis is
performed in an iterative process together with the identification of the protection goals. This
step identifies the relevant threats for each asset, assigns possible causes and describes the
direct consequences.
3. In this step, the protection objectives which are relevant for the object of observation are
determined. For each asset found, it must be decided which protective aims are relevant.
4. The existing risks resulting from threats are analyzed and evaluated. From the threat potential
and the simplicity of the attack, the probabilities for the occurrence of the threats identified in the
previous step are evaluated. Thus, the potential damage to the object of observation as well as
the resulting damage was estimated. Statistical data is generally not available, so the risk
assessment is qualitative.
5. In this step, measures and their effectiveness against the relevant requirements are described.
Appropriate protection measures are selected using catalogs, experiences and other
documents. Often a necessity is countered by a few different protective measures. The
appropriate costs are allocated to each recommended protection measure to determine an
economic assessment of the total solution.
6. A reasonable (economically) total solution is selected as the best combination of measures from
the multitude of listed protective measures. In doing so, the company's aims and compliance
with company policy must be considered about IT security.
7. The individual protective measures are to be implemented in the context of the overall solution.
In this step, a business concept is created that ensures the sustainable implementation of the
solution. If the object of observation is an automation solution or a system, the operating concept
covers the entire operating phase. For a product, the operating concept relates to the marketing
phase.
8. In the audits it is checked whether all defined measures for the achievement of the defined
protection aims as well as for the protection-relevant threats are enough and successfully
implemented. The audits are to be carried out by persons who are not involved in the process.
Page 227 of 271

6.10.2 Example for VDI/VDE 2182 integration
Different examples are available within the detailed documents from VDI/VDE 2182:
• VDI/VDE 2182 Part 2.1 IT-security for industrial automation - Example of use of the general model
for device manufacturer in factory automation - Programmable logic controller (PLC),
• VDI/VDE 2182 Part 2.2 IT-security for industrial automation - Example of use of the general model in
factory automation for plant and machinery installers - Forming press,
for manufacturers in factory automation - Process control system of an LDPE plant,
for integrators in process industry - LDPE reactor,
for plant managers in process industry - LDPE plant.
Due to copyright reasons it is not possible to share the detailed knowledge from this standard within this
document and so it is recommended to get an own copy of those standards for the integrator. In this
guideline we can only point out a small example with general information to handle an issue from this norm.
As a reference the recommended structure from Highly Secure Large System is used for the next steps.
1. Identify assets
Based on the architecture the remote access from outside was defined as an asset
Figure 92 - Part from Highly Secure Large System architecture
Page 228 of 271

2. Analyze threats.
In this step the asset and possible threats are analyzed using experience and possible examples from
threat catalogues (CVE web pages) or BSI homepage. The vulnerability and the direct consequences are
mentioned.
For the remote access the following threats could be analyzed:
Asset Threat Cause Vulnerability Consequence
Remote Access Defect in data transfer Defect Hardware diversity Faults take long to be
line router eliminated
Remote Access Data Manipulation Hackers Security measures Unauthorized persons

at service provider acquire data
Table 16 - VDI/VDE Example Step 2
3. Determine relevant security objectives

Use the same table from step 2 and define which of the main protection goals availability, confidentiality
or integrity is affected.
Asset Threat Cause Vulnerability Consequence
Confidentialit
Availability
Integrity
y
Remote Access Defect in data Defect Hardware Faults take long to be
X
transfer line router diversity eliminated
Remote Access Data Hackers Security unauthorized persons

Manipulation measures at acquire data
X X X
service
provider
Table 17 - VDI/VDE Example Step 3
Page 229 of 271

4. Analyze and assess risks.
The plant manager defines a risk matrix. If the plant manager can use the standardized risk matrix of its
company for evaluating similar security scenarios, this makes it easier to make cross-project
comparisons.
The attached matrix definitions come from a good practice method known as Threat and Risk analysis
inside the Siemens Company.
Exposure Rating (of Product or Solution in Operational Environment)
First part of likelihood rating, representing the likelihood whether an attack may be attempted
Exposure Categories
Level of Access Needed Risk of Getting Caught
• Easy logical or physical access for attacker, e.g. • Low risk to be discovered / convicted
− internet access sufficient, or • No or little measures for unauthorized access detection and
2 High − public physical access, or investigation implemented
− attacker has access as part of daily work, operation, or maintenance
activities, or
Exposure Scale
− product or components can be acquired by attacker with low effort

• Restricted logical or physical access for attacker, e.g. • Medium risk to be discovered / convicted
− internal network access required, or • Some measures for unauthorized access detection and investigation
1 Medium
− restricted physical access, or implemented (e.g. surveillance, logging, monitoring)
− product or components can be acquired by attacker with medium effort
• Highly restricted logical or physical access for attacker, e.g. • High risk of being discovered / convicted
− highly restricted network and physical access, or • Good measures for unauthorized access detection and investigation
0 Low
− product or components can not be acquired by attacker or only with high implemented (e.g. surveillance, protected log files, monitoring and
effort alarming, limited no. of persons)
Figure 93 – Definition of exposure
Exploitability/Simplicity Rating (of Product or Solution)

Second part of likelihood rating, representing the likelihood whether an attempted attack is likely to succeed
Exploitability of Vulnerabilities / Simplicity to Perform a Successful Attack
• Successful attack is easy to perform, even for an unskilled attacker (little capabilities needed)
Exploitability/Simplicity Scale
2 High • Vulnerability can be exploited easily with low effort, since no tools are required or suitable attack tools freely exist.
• No or only weak security measures to counter the attack caused by the threat
• Successful attack is feasible for an attacker with average hacking skills (medium capabilities needed)
1 Medium • Vulnerability is exploitable with medium effort, requiring special technology, domain or tool knowledge
• Some security measures to counter the threat
• Successful attack is only possible for a small group of attackers with high hacking skills (high capabilities needed)
• Vulnerability is only exploitable with high effort, and if strong (huge) technical difficulties can be solved, non-public information about inner workings of
0 Low
system is required
• Strong state of the art security measures to counter the threat
Figure 94 – Define Likelihood matrix based on Exploitability and Exposure
Exposure Rating
Low Med High
Exploitability/Simplicity Rating
Very
Low Unlikely Possible
unlikely
Med Unlikely Possible Likely
Very
High Possible Likely
likely
Figure 95 – Define the risk level on site
Page 230 of 271

Risk
Risk Level Description
Risk must be treated with highest priority in terms of definition and

Major implementation of countermeasures or acceptance by senior
management.
Risk must be treated with high priority in terms of definition and

Significant implementation of countermeasures or acceptance by
product/solution/service owner.
Risk must be treated with medium priority in terms of definition and

Moderate implementation of countermeasures or acceptance by
product/solution/service owner.
Risk can be treated optionally, however definition and implementation

Minor of countermeasures is recommended if easily possible or is considered
state-of-the-art.
Figure 96 – Evaluation of risk level
Likelihood Rating
Very unlikely Unlikely Possible Likely Very likely
Negligible Minor Minor Minor Minor Moderate

Impact Rating
Moderate Minor Moderate Moderate Moderate Significant
Critical Minor Moderate Moderate Significant Major
Disastrous Moderate Moderate Significant Major Major
Figure 97 - Definition of Security threat
Page 231 of 271

Asset Threat Cause Vulnerability Consequence Identified
Confidentiality
Risk
Availability
Integrity
Remote Access Defect Defect Hardware Faults take Moderate
in data router diversity long to be
X
transfer eliminated
line
Remote Access Data Hackers Security Unauthorized Major

Manipul measures at persons X X X
ation service provider acquire data
Table 18 - VDI/VDE example step 4
5. Identify measures and assess effectiveness

In this step the asset owner describes the countermeasures that are already fulfilled or going to be
fulfilled due to the company policies. It is especially required to define countermeasures that could reduce
the available risk. Some possible definitions for remote access are:
• Establish a VPN connection
• Reduce Hardware diversity
Page 232 of 271

6. Select countermeasures
After having the available number of countermeasures they will be put into the same table:
Countermeasures
Confidentiality
Identified Risk
Consequence
Vulnerability
Availability
and costs
Integrity
Threat
Cause
Asset
Remote Defect in Defect Hardware Faults take Reduce
Moderate
Access data router diversity long to be Hardware
X
transfer eliminated diversity –
line 2000€
Remote Data Hackers Security Unauthorized Use VPN
Major
Access Manipul measures persons connection –
X X X
ation at service acquire data 200€ / month
provider
Table 19 - VDI/VDE example step 6
7. Implement countermeasures
The implementation will typically be embedded in the project schedule agreed between the integrator or
device manufacturer and the plant manager.
8. Perform process audits

Required audits for new systems are carried out between the installation and the commissioning phases.
For running systems, they are performed regularly or when change management provisions call for it.
Audits are designed for examining technical issues (vulnerabilities or security gaps) and detecting
organizational and administrative shortcomings.
As mentioned at begin of this chapter this was only a small example part from the VDI/VDE 2182 norm itself.
The existing documents can give more detailed information about a risk assessment and the possible way to
implement this into the business-related processes.
Page 233 of 271

System Decommissioning
Until this point all steps regarding a secure setup or recommendations for operation mode were considered.
At system decommissioning a system is taken out of service after the operational phase. A system
decommissioning process needs to be applied according to the policies of the enterprise, to ensure that the
confidentiality protection goal is still guaranteed.
At least it is essential that components from a plant, that potentially contain data, like hard discs of flash
memory cannot be misused for an unauthorized read. An erase of the memory in the devices is therefore
very useful. The method of a secure wipe of confidential data needs to be defined by the Integrator and
executed by the asset owner in the phase of decommissioning. (Kobes, 2016, S. 24-27).
According to IEC 62443 a disposal of all assets should be considered, and the requirement is defined in
following way:
“Policies and procedures should be developed detailing retention, physical and integrity protection,
destruction, and disposal of all assets based on their classification, including written and electronic records,
equipment and other media containing information, with consideration for legal or regulatory requirements.”
(IEC 62443-2-1, 2010, S. 35)
ATTENTION
This chapter or this document gives an overview how software can be removed from devices but not
for hardware devices itself. This exception also includes machines which were connected to a
SCADA system during operation mode (e.g. handling of fuel rods from a nuclear reactor).
Within this definition following recommendation needs to be considered:
• A wipe of hard disc by formatting is not secure and can still be used by an attacker to read
confidential data. To avoid this threat a simple delete is not enough according to information given by
BSI (BSI, 2019).
Instead it is recommended to proceed with one of the following options:
o Secure deletion of data by 3rd party tool. Enclosed a small example list of possible vendors:
▪ Kaspersky® Total Security https://support.kaspersky.com/us/11449 (acc.: 27th
March 2019)
▪ Parted-Magic https://partedmagic.com/ (acc.: 27th March 2019)
▪ DBAN https://dban.org/ (acc.: 27th March 2019)
o Shredder the hard disc physically to make it impossible to get the stored data for an
attacker. This approach destroys the hard disc by force and makes it impossible to read the
data after this procedure. Different vendors offer products or services for this requirement.
Enclosed a possible example:
https://www.recycling.com/hard-drive-shredder-destruction-service/ (acc.: 27th March 2019)
Page 234 of 271

o Usage of Hard disc encryption like BitLocker. This is a very secure and recommended option
because an attacker is not able to read the contain data if the TPM Key is not available
according to following figure.
Figure 98 - Architecture BitLocker (Microsoft, BitLocker, 2016)
• Configuration from Routers and Switches needs to be wiped before the discard of the device.
“Configuration files and log files stored on active network components contain a wealth of
information about the network, the infrastructure, the organisation and possibly also about individuals
in the organisation. When a device is passed to an outside party (for example, returned to the
manufacturer or the service company for the replacement of parts under warranty, or sold to a
possible purchaser), this information can be analysed.
For example, the following information can be extracted from configuration files:
o the protocols used (especially routing protocols), IP addresses and subnets
o VLAN configuration
o access control lists
o passwords and SNMP community strings
o name and contact data for the administrator (banner)
Due to the sensitivity of this information, care should be taken to ensure that prior to withdrawing a
device from operation or replacing defective or outdated devices, the files are deleted or rendered
unreadable. The procedure greatly depends on the manufacturer of the device. The security policy
for routers and switches should set out the responsibilities in this area.”
(BSI - IT-Grundschutz-Catalogues, 2013, S. 1842)
Some Router offers the option of the “factory reset” which deletes sensitive information from the
device. The option to shredder a device physically can also be considered.
• Ensure secure deletion of PLC program before PLC is discarded. The option to shredder a device
physically can also be considered.
• User documents which contain confided data should be destroyed or stored in a secure way if the
written information may be used for further projects.
Page 235 of 271

7 Security Checklist
The following checklist is a recommendation on how to install and configure a secure system. Details of this
checklist are available within this document. Target of this checklist is a procedure to verify if all
recommended settings are already implemented on site.
Please consider that most use cases are based on a Defense in Depth concept where security must be
applied by all stakeholders inside a project. A good description is given by IEC62443,
(see chapter: References).
Step Description Chapter Check N/A
Ensure Security Knowledge
1. Consider the strategy and the concept of a Strategy of the Security Guideline
security process in all following steps
Defense in depth concept
Preparation and Installation
2. Install a domain environment Administration of Computers
3. Protect a new installed machine from any hostile Newly installed machine
network traffic until OS system is hardened.
Different Disc Partitions
4. Implement Multitier-network architecture. Security Cells and Network

Architecture
Highly Secure Large System
Secure small system
Distributing the Tasks on several

Computers
5. Protect electricity grid Secure network cell from power

issues
6. Split network to security cells Limitation of bandwidth between

security cells
7. Deploy WinCC OA Server concept

Server Configuration
8. Deploy WinCC OA UI concept User Interface Configuration
9. Initial configuration for mobile devices Configuration settings for all

mobile devices
10. Take care of security in branding WinCC OA Branding of WinCC OA MSI

version Installation
Page 236 of 271

11. Configuration of Video cameras Configuration Settings for Video
Cameras
12. Secure configuration of Oracle server Use Oracle Server with Oracle
Database Appliance (ODA)
Service packs and Hotfixes
13. Install the latest service packs from Microsoft® Patch management and security
or Linux distribution updates
14. Activate automated notification of patch Patch management and security

availability updates
15. Install WSUS Server for Windows based system Windows
16. Install Mirror Server for Linux based system Linux
Harden OS system
17. Disable not required services Shutting down/Uninstalling

services that are not needed under
Microsoft® Windows
Shutting down/Uninstalling
services that are not needed under
Linux
18. Uninstall not required software Uninstalling not needed software
19. Disable unsecure SNMP protocols Restrict SNMP driver

communication to SNMPv3
20. Implement a secure desktop solution Secure Desktop – Kiosk Mode
21. Disable DCOM Interface if it is not required by Disable DCOM

the project or plant
22. Harden DCOM Interface if legacy technology is Hardening DCOM for OPC DA
used (e.g. OPC DA). driver
23. Configure OPC UA settings OPC UA configuration
24. Activate SMB signing Activate SMB signing
25. Create or replace default certificates for Create and deploy TLS certificates
encryptable driver via TLS
26. Enable Secure Mode of Linux Enable SELinux
Page 237 of 271

OS User Account Policies
27. Set password complexity requirements Password strength
28. Delete or disable default OS users Delete or disable unneeded default

users on OS Level
User rights assignment
29. Apply user rights assignment on folder level Definition of Access Control List
(ACL)
30. Create role-based user concept for WinCC OA Administration of Role-Based user
authorizations
31. Limitation of root user Limit usage of root user
32. Delete or disable default users Delete or disable all default users
on WinCC OA level
Security Settings
33. Configure machine inactivity limit to protect idle Automatic user logout in OS
interactive sessions.
34. Check digital signature of software packages Digital signatures for binaries and
libraries
Auditing
35. Activate OS based audit logging Logging, audit, maintenance and

asset management
36. Make suspicious logging events in WinCC OA Observe audit logging and transmit
visible information to WinCC OA
37. Implement intrusion detection system Implement Intrusion detection

system
Network Security Settings
38. Plan a network concept and network services Administration of networks and
network services
39. Limit internet access for plant computers Limitation of internet access
40. Definition of Access Points to Security Cell Definition of the Access Points to
the Security Cells
Page 238 of 271

41. Configure Firewall for required ports Usage of WinCC OA mxProxy and
restriction of open ports and
limitation of the IP access list
42. Activate Anti-Virus Software Virus Scanner
43. Ensure secure communication between security Secure security cell link via IT
cells Infrastructure
Secure security cell link via WinCC

OA Proxy
44. Activate OS based secure communication IPsec Bypass Technology

protocol
45. Move Reporting Manager into a DMZ Define Reporting Manager as

predetermined breaking point
46. Implement secure communication for unsecure Secure communication for

protocols unsecure protocols
47. Hide secure network behind Reverse-Proxy Hide secure network behind a
Reverse Proxy
Physical Security
48. Configure BIOS settings Configure BIOS Settings
49. Deactivate unused interfaces Deactivate unused interfaces
Implement security related processes
50. Ensure Security coding knowledge for project Secure coding standard for API
developers extension
51. Usage of Obfuscator tool for own API code Usage of Obfuscation tool for API
code
52. Implement Training concept for Security Testers Knowledge of Security Testing
Encrypt network communication
53. Create openSSL certificates for WinCC OA and Usage of TLS/SSL for plant
deploy it communication
Create own openSSL certificates
Create and deploy certificates
54. Consider Demo Configuration of TLS Demo configuration of TLS in

WinCC OA
Page 239 of 271

55. Store openSSL certificates in a secure way Storage of openSSL certificates
and private keys
56. Enforce usage of strong cipher suite Enforce usage of strong cipher
suite
57. Establish secure maintenance access Protected Maintenance Access
Secure Access Techniques
58. Encrypt Oracle communication Activate encryption between

Oracle Client and Oracle Server
PLC Communication
59. Activate secure communication to PLC Usage of interlocks for the

PLCError! Reference source not
found.
WinCC OA Security
60. Add authorization config for all WinCC OA Protection via authorization levels
Datapoints in WinCC OA
61. Ensure secure communication for Web clients Secure Web Publication
Communication with WinCC OA –

Desktop UI
Activate httpAuth for WinCC OA

HTTP-Server
62. Protect knowledge Script and Panel Encryption
63. Implement area authorization concept Access Control via Area

authorization
64. Remove unnecessary Datapoints Deletion of unused Datapoints
65. Reduce security privileges for WinCC OA Start a WinCC OA project as a

processes service
66. Use an authentication mechanism outside of Usage of WinCC OA external

WinCC OA authentication method
67. Usage of WinCC OA mxProxy to split network Remote access to WinCC OA

mxProxy manager via Dist
Manager
Page 240 of 271

68. Disable automatic activation for mobile devices Disable Automatic Unlock for
Mobile Devices (Android and iOS)
and Desktop UI
69. Activate Server-side authentication (SSA) Server-side Authentication
70. Activate session binding for WinCC OA Server-Side Authentication for

managers Managers with session binding
71. Define SSO for OS or external Users in WinCC Automatic User Login
OA
Single Sign On
72. Activate automatic user logout in WinCC OA Automatic user logout in WinCC
Level OA
73. Configure certification chain Usage of certification chain
74. Set secure settings in WinCC OA config file Keep secure settings in WinCC OA
config file
75. Consider security implementation of WebView Secure implementation of

EWO WebView EWO
Alternative security options to openSSL and

WinCC OA mxProxy
76. Activate Kerberos encryption Activate Kerberos encryption for

WinCC OA systems
WinCC OA Access Control Plug-In
77. Usage of WinCC OA Access Control Plug-In as Usage of WinCC OA Access

a sandbox to implement a specific security Control Plug-In
concept
Mobile Devices
78. Secure configuration of mobile devices Configuration settings for all

mobile devices
Security Testing
79. Ensure and verify actual security configuration Security tests
Whitelisting
80. Install and use whitelisting Software Whitelisting/Application Control
Page 241 of 271

Disaster Recovery (no WinCC OA DRS)
81. Implement Backup concept Implement Backup and Restore

concept
82. Define and document steps for restore Restore procedure

procedure
Process
83. Implement and maintain cyclic risk assessment Implement Risk assessment
process process based on VDI/VDE 2182
Decommissioning
84. Secure Decommissioning during abandonment Decommissioning

stage
Table 20 - Security Checklist
Page 242 of 271

8 Glossary
This chapter specifies descriptions, definitions and abbreviations as they are used in this document. Due to
the normative operations and to present this document in a consistent internationally approved terminology,
the update of some definitions is necessary.
Some descriptions, definitions and abbreviations were adopted from internationally approved standards (e.g.
ISA-95, ISA-99) or from the respectively current descriptions of the manufacturer.
8.1.1.1 Access Point Firewall

In this security concept an access point is combined with a firewall as a special case. An access point
firewall offers access to a security cell exclusively for maintenance tasks, which otherwise, would not require
any connection (e.g. to MES systems).
See chapters: Firewall

Manufacturing Execution System (MES)
8.1.1.2 Access Control List (ACL)

An access control list defines the list of permissions for objects like files or folders on OS level. This list
defines which user or system process is granted to access those objects.
8.1.1.3 Administrated Client

Client inside an operational environment where the complete security related policies from the company are
in place. Those machines are fully configured and maintained by an IT department with following
configuration:
• Firewall fully configured and activated
• Anti-Virus software active and up to date

• All mandatory OS related updates are installed
• Installed software products controlled by the IT department, no unauthorized software products are
installed
• Hard disc is encrypted
8.1.1.4 Area Authorization

Area authorizations are assigned within areas. Areas are logical or geographical regions, for example, of a
plant, and can be assigned to the various groups. The rights of an area that has been assigned to one group
are applicable to all users belonging to this group. In this manner, different rights by different groups can be
configured according to the assigned areas.
8.1.1.5 Authentication
Authentication is the ability to verify the identity of a user or a computer system on a computer network.
Page 243 of 271

8.1.1.6 Authentication Protocol
It is the protocol with which an entity establishes its identity in a network for a remote identity. Typically, the
identity is proved with a secret key, e.g. a password, or with a key that is more secure, for example, a chip
card. Certain authentication protocols also implement methods for common usage of keys between clients
and servers, to supply integrity or data security for messages.
8.1.1.7 Block Cipher

A block cipher is a deterministic encryption method which maps a clear text with a fixed length to a cipher
with a fixed length. The exact transformation is determined by a symmetric key.
Actual block ciphers are mentioned in this table - please note that the red colored ciphers are already
vulnerable for attacks and should not be used in a secure environment.
Cipher Key Length Block Length State
DES 56 64 Unsecure
3DES 112 64 Unsecure
IDEA 128 64 Unsecure
RC5 128 64 Unsecure
Blowfish < 448 64 Unsecure
AES 128 128 Secure
AES 192 128 Secure
Twofish < 256 128 Secure
AES 256 128 Secure
Table 21 – List of available cipher suites (Siemens, 2019)
8.1.1.8 Brute-force attack

A brute-force attack uses automated software to generate many guesses to evaluate a secret which is used
as a password for user credentials is or as a secret key to decrypt data. This method is based on a trial and
error mechanism and the limited factor is the consumed time. It is possible to mitigate a brute-force attack by
methods which increase the consumed time, that is required for a successful brute-force attack.
Page 244 of 271

8.1.1.9 Chain of trust (certification chain)
In computer security, digital certificates are verified using a chain of trust. The trust anchor for the digital
certificate is the root certificate authority (CA).
The certificate hierarchy is a structure of certificates that allows individuals to verify the validity of a
certificate's issuer. Certificates are issued and signed by certificates that reside higher in the certificate
hierarchy, so the validity and trustworthiness of a given certificate is determined by the corresponding validity
of the certificate that signed it.
The chain of trust of a certificate chain is an ordered list of certificates, containing an end-user subscriber
certificate and intermediate certificates (that represent the intermediate CA), that enables the receiver to
verify that the sender and all intermediate certificates are trustworthy. This process is best described in the
page Intermediate certificate authority. See also X.509 certificate chains for a description of these concepts
in a widely used standard for digital certificates.
https://en.wikipedia.org/wiki/Chain_of_trust (acc.: 27th March 2019)
8.1.1.10 Cipher suite

“A cipher suite is a set of cryptographic algorithms. The schannel (Secure channel) SSP implementation of
the TLS/SSL protocols use algorithms from a cipher suite to create keys and encrypt information. A cipher
suite specifies one algorithm for each of the following tasks:
• Key exchange
• Bulk encryption
• Message authentication
Key exchange algorithms protect information required to create shared keys. These algorithms are
asymmetric (public key algorithms) and perform well for relatively small amounts of data.
Bulk encryption algorithms encrypt messages exchanged between clients and servers. These algorithms are
symmetric and perform well for large amounts of data.
Message authentication algorithms generate message hashes and signatures that ensure the integrity of a
message.”.
(Microsoft, Cipher Suites in TLS/SSL (Schannel SSP), 2019)
The list of selectable cipher suites depends on the used openSSL version. WinCC OA uses an actual
recommended version openSSL. The list of selectable cipher suites by openSSL and the OS can be queried
by command line. Here is an example for a Windows system:
D:\Siemens\Automation\WinCC_OA\3.16\bin>openssl ciphers
8.1.1.11 CIS – Center of Internet Security

“CIS® (Center for Internet Security, Inc.) is a forward-thinking, non-profit entity that harnesses the power of a
global IT community to safeguard private and public organizations against cyber threats.
The CIS Controls™ and CIS Benchmarks™ are the global standard and recognized best practices for
securing IT systems and data against the most pervasive attacks. These proven guidelines are continuously
refined and verified by a volunteer, global community of experienced IT professionals.“
(CIS, 2018)
https://www.cisecurity.org/ (acc.: 27th March 2019)
Page 245 of 271

8.1.1.12 Component Object Model (COM)
COM is a platform developed by Microsoft® to enable inter-process communication and dynamic object
generation on the Microsoft® Windows operating system (Interface between (Microsoft®) Windows
applications). COM-enabled objects are language-independent and can be both DLLs and executable
software applications.
CAUTION
COM must not be used in an environment where the implementation of security features is
mandatory because this interface likely used for security attacks. It could only be used for
compatibility reason in old software products if they run in a complete secured environment.
8.1.1.13 Computer name

The computer name is an option for identification of a computer within a network. It is the host portion of the
FQDN (Fully Qualified Domain Name), if a host assignment has been made. The computer name may be
identical to the NetBIOS name of the computer if the computer name is less than 16 characters and both
names happen to be the same unintentionally.
8.1.1.14 Control Language (CTRL)

A Control program ("script") is used to fulfill control tasks in WinCC OA and can be programmed by a user of
the control system. The syntax of the internal controller language "Control" has a similar structure to that of
the C or C++ programming language.
Control / Introduction CONTROL
8.1.1.15 Control room

It is the control room of a control system. The definition according to ISA-99 is: "Central location where a
group of resources is being operated." A control room is the name of a technical control facility that supports
the control of processes. The control room is part of a control system.
Note:
In the industrial infrastructure there are usually one or more control centers to monitor and
coordinate the operating schedule. In complex plants, multiple control centers are usually connected
via WAN (Wide Area Network), e.g. one control center is at another location for failure safety. One
control center contains the SCADA host computers and the related display devices for the plant
operator and additional information systems like an archive server.
8.1.1.16 Control Systems Network (CSN)

It is the name for a network as part of a security cell or area of the system in which the automation plants are
located. The PCS or DCS or SCADA server systems are also linked to the CSN, to be in contact with the
automation plants. Each CSN is a so-called system network or system bus.
To avoid a negative impact caused by network traffic it is recommended to configure an own subnet for CSN
where it is ensured that this separate network is not jammed by the common traffic.
Page 246 of 271

8.1.1.17 Cryptographic Service Provider
This is an independent software module which performs cryptographic algorithms for authentication,
encoding and encryption.
WinCC OA uses the CSP named “Microsoft Enhanced RSA and AES Cryptographic Provider” to check the
SSA for managers with session binding
(see chapter: Example for Windows Certificate Store SSA certificates).
8.1.1.18 DCOM
Short for Distributed Component Object Model, an extension of the Component Object Model (COM) that
allows COM components to communicate across network boundaries. Traditional COM components can
only perform interprocess communication across process boundaries on the same machine. DCOM uses the
RPC mechanism to transparently send and receive information between COM components (i.e., clients and
servers) on the same network.
DCOM was first made available in 1995 with the initial release of Windows NT 4.
CAUTION
DCOM must not be used in an environment where the implementation of security features is
mandatory since this interface is likely used for security attacks. It may only be used for compatibility
reason in old software products if they run in a complete secured environment.
8.1.1.19 Defense in Depth

(ISA-99) Security architecture with the assumption that every point of security can and most likely will be
bypassed.
Note
The concept of a Defense in Depth contains a tiered and layered structure of security and
recognition measures and mechanisms (also on the level of single place systems). It has the
following features:
• Attackers may reckon to be detected when trying to breach or bypass the single layers.
• The weak point of a layer of this architecture can be covered in one of the other layers.
• The system security is a separate layer structure inside the whole layered structure of the
network security.
8.1.1.20 Demilitarized Zone (DMZ)

In the telecommunication field, it is the keyword for a computer, router or a small network, which is set up as
a "neutral area" between the internal network of an organization and the "external" public network. This
measure should prevent external users from having direct access to a server with corporate information.
"Perimeter Network" (Boundary network, perimeter network) is another term often used to designate the
DMZ.
Page 247 of 271

8.1.1.21 Desktop UI
The WinCC OA Desktop UI is a part of the WinCC OA installation package. It can be installed on a computer
or a portable terminal device (Desktops, Notebooks or Netbooks) that is connected to the WinCC OA Server
using a web browser. It is only intended as remote access for operators.
WinCC OA UI / Desktop UI
8.1.1.22 Device
Any item that can be connected to a network or computer is a device, such as, for example, a computer,
printer, joystick, adapter, an interface card or any other peripheral device. Generally, devices require a
device driver for the used operating system.
They include electronic devices licensed under Windows such as computers, workstations, terminals and
handheld computers, which access the services of the Windows operating system or can use them, including
file and printer sharing, remote access and authentication.
8.1.1.23 Distributed Computer Network (DCN)

Distributed computing is a field of computer science that studies distributed systems. A distributed system is
a software system in which components located on networked computers communicate and coordinate their
actions by passing messages. The components interact with each other to achieve a common goal. Three
significant characteristics of distributed systems are: concurrency of components, lack of a global clock, and
independent failure of components.
8.1.1.24 Distributed Control System (DCS)

A distributed control system (DCS) is a control system for a process or plant in which the system elements
are distributed but operated as coupled.
This contrasts with non-distributed systems, which use a single controller at a central location. In a DCS, a
hierarchy of controllers is connected by communication networks for command and monitoring. With WinCC
OA the communication between the distributed systems is realized with the WinCC OA Dist Manager
(WCCILdist)
Example scenarios where a DCS might be used include:
• Petrochemical (oil) and refineries
• Water management systems

• Chemical plants
• Traffic control systems
Note:
Decentralized process control systems are usually used in combination with continuous processes
like the generation of electric energy, oil and gas refining, chemical or pharmaceutical production
and paper manufacture. Besides that, it is also used in combination with discrete processes like
assembly, packaging and storing of automobiles and other goods.
Page 248 of 271

8.1.1.25 Domain
Environment or context that is defined by a security policy and a security model, or security architecture and
a set of system resources as well as the corresponding group of system entities comprises that have
permission to access this resource.
(Windows): Logical group of computers on which a version of the operating system Microsoft® Windows is
running and that share a central folder database (refer to AD starting with Windows 2000). The AD contains
the user accounts and security information for the resources in this domain. A unique user account or unique
user name is assigned to each person using a computer within a domain. Access rights to resources within
the domain can be assigned to this account.
(Windows): A structure for administration of local Windows networks. It corresponds to a local security
section with central administration of resources and represents an administrative limit.
8.1.1.26 Domain controller

A domain controller (DC) is a server that responds to security authentication requests within a Windows
Server domain. It is a server on a Microsoft® Windows or Windows NT network that is responsible for
allowing host access to Windows domain resources.
A domain controller is the centerpiece of the Windows AD service. It authenticates users, stores user
account information and enforces security policy for a Windows domain.
8.1.1.27 DoS- / DDoS Attack

In computing, a denial-of-service (DoS) attack is an attempt to make a machine or network resource
unavailable to its intended users, such as to temporarily or indefinitely interrupt or suspend services of a host
connected to the Internet. A distributed denial-of-service (DDoS) attack is where the attack source is more
than one and often thousands of unique IP addresses (DDoS).
(Wikipedia, 2018).
8.1.1.28 Disaster Recovery (DR)

Disaster recovery (DR) involves a set of policies, tools and procedures to enable the recovery or continuation
of vital technology infrastructure and systems following a natural or human-induced disaster. Disaster
recovery focuses on the IT or technology systems supporting critical business functions, as opposed to
business continuity, which involves keeping all essential aspects of a business functioning despite significant
disruptive events. Disaster recovery is therefore a subset of business continuity.
8.1.1.29 Disaster Recovery System (DRS)

This is a feature of WinCC OA which provides a Hot Standby Redundancy Concept with two pairs of
redundant WinCC OA servers.
Add-ons / Disaster Recovery System
8.1.1.30 Eavesdrop
This is an attack vector against the confidentiality of a system. Eavesdropping is a secretly listening of a
communication between two or more different components. Attacker can use the observed communication to
steal instinctual property or to get information to prepare an attack against the integrity of a system.
Page 249 of 271

8.1.1.31 Enterprise Resource Planning (ERP)
ERP systems should map all business processes to a large extent. A complete integration (avoid using
isolated applications) leads to a re-centralized system in which resources can be administered across the
entire organization or enterprise. The typical functional areas of ERP software are:
• Material management (Procurement, warehousing, material planning and valuation)
• Manufacturing
• Finance and accounting

• Controlling
• Personal management
• Research and development
• Sales and marketing
• Master data administration

Since different branches of management place highly varying demands on an ERP system, most providers
offer industry solutions whose sub-packages are tailored to suit specific industries
8.1.1.32 Extensible Markup Language Remote Procedure Call (XML-RPC)

This abbreviation designates an XML-based remote procedure call (Extensible Markup Language). Software
running on different operating systems can make procedure calls via network using XML-RPC. XML-RPC
uses HTTP and SSL for the encoding. It sends a procedure call to a remote server via HTTP. The call is an
XML document and it receives the response as XML.
Special Functions / XML-RPC
8.1.1.33 External user authentication

Describes a tool provided by a third-party vendor which handles user credentials including group ownership
outside from an OS environment. Those tools allow to create and configure user in a way like Windows AD
environment. WinCC OA supports a handler for those tools. This allows the customer to use a central user
management for the facility.
8.1.1.34 Food & Drug Administration FDA

US authorities; Guidelines and directives in the field of validation of processes and products have been
prepared by the Food & Drug Administration (FDA). The most important and internationally applicable
requirements of automation technology (with respect to the validation) are summarized in the GMP Acts 21
CFR Part 11.
8.1.1.35 Field Device Network (FDN)

It is the name for a network as part of a security cell or area of the system in which only automation plants
and field devices are connected.
Page 250 of 271

8.1.1.36 Firewall
A Firewall is part of the connection between networks and restricts the data traffic between connected
networks.
A firewall represents a security system which helps to protect a computer network or a single computer from
unauthorized network access. Moreover, it is a partial aspect of a security concept.
Every firewall security system is based on a software component. The firewall software is used to restrict
network access by using the sender address, destination address and services in use. It monitors the data
exchange and decides according to defined rules whether a network packet may pass or not.
Note:
A firewall is either an application which is installed on a computer for general purposes or a

dedicated platform (appliance) which forwards or discards packages within a network. The firewall is
usually used to define borders and works with restrictive rules that only allow the usage of ports.
8.1.1.37 Firewall types

Used for a better distinction regarding the tasks and areas of operation in this document.
• Front-end firewall: A front-end firewall protects the perimeter. Only clearly named users can get
access via verifiable communication (application filter). Clearly recognized and trustworthy devices
can get access via exceptions (e.g. via internet protocol security, IPsec).
• Back-end firewall: A back-end firewall protects the production network PCN against the perimeter
and other trustworthy networks (e.g. MON). The back-end firewall must be implemented as a
performance-oriented solution for unambiguously identified trustworthy devices.
• Three-Homed firewall: A Three-Homed firewall is a combined front- and back-end firewall with its
own “minimal perimeter” for scalable security solutions.
8.1.1.38 Group Authorization

Each user must belong to a group. In other words, a group is a collection of users. The groups are defined in
WinCC OA or inherited from the Windows user administration in the case of Windows user administration.
The rights for the groups must be defined in WinCC OA for this purpose. Therefore, several user groups can
be defined, and each group can have several users assigned to it. The WinCC OA user administration
provides five predefined groups. One user may also belong to more than one group. If a user belongs to
more than one group, the user rights consist of the combination of rights associated with the individual
groups.
System management / Authorizations / Groups
8.1.1.39 Host
It is a device in a TCP/IP network that has an IP (Internet Protocol) address. For example, such devices may
be servers, workstations, print devices with a network interface and routers. Sometimes, the term refers to a
certain network computer that executes a service used by the network or remote clients.
Page 251 of 271

8.1.1.40 International Electro technical Commission (IEC)
This is an international standardization organization with its headquarters in Geneva for standards in the field
of electrical engineering and electronics. Certain standards have been developed jointly with ISO.
8.1.1.41 International Organization for Standardization (ISO)

It is the international association of standards organizations and develops international standards in all fields
except electrical engineering and electronics, for which the International Electro technical Commission (IEC)
is responsible.
8.1.1.42 International Society of Automation (ISA)

It designates the independent society for standardization in automation technology.
8.1.1.43 Internet Protocol (IP)

It is a network protocol of the TCP/IP suite that needs to be routed. It is responsible for IP addressing,
routing as well as fragmenting and reassembling IP packets.
8.1.1.44 IP address
An IP address is an address in computer networks that is based on the Internet Protocol (IP) just as the
internet, for example. It is assigned to devices that are connected to the network, thus making them
addressable and accessible. The IP address may designate one single receiver or a group of receivers
(Multicast, Broadcast). Conversely, multiple IP addresses may be assigned to one computer.
The IP address is used to transport data from the sender to the designated receiver. Like the postal address
on the envelope of a letter, data packets are provided with an IP address that uniquely names the receiver.
Based on this address the "Post offices" (e.g. routers) can decide the direction in which the packet needs to
be transported. In contrast to postal addresses, IP addresses are not bound to a fixed location.
The most popular notation of the IPv4 addresses common today consists of four numbers that can have a
value from 0 to 255 and are separated with a dot, e.g. 192.0.2.42. From the technical point of view, the
address is a 32-bit (IPv4) or 128-bit (IPv6) binary number.
8.1.1.45 IPsec
The term refers to the IP Security protocols; this is architecture for supplying encryption and authentication
services. It is a series of cryptography-based security services and security protocols based on industrial
standards. All protocols of the TCP/IP protocol suite as well as internet communication using L2TP (Layer
Two Tunneling Protocol) can be protected with IPsec. Typical usage is a VPN connection.
Page 252 of 271

8.1.1.46 Kerberos
Kerberos is a distributed authentication service (Network protocol) for open and unsecured computer
networks. The current version at present is Kerberos 5. It is defined in RFC 4120 and uses ASN.1 for coding.
Kerberos offers secure and uniform authentication in an insecure TCP/IP network on secure host computers.
The authentication is handled by a trustworthy third party (also called Trusted Third Party). This third party is
a particularly secure Kerberos 5 network service. Kerberos supports SSO, that is, a user must login only
once and can then use all network services without having to reenter any password. Kerberos handles any
further authentication.
When using Kerberos (must be explicitly activated and configured) with WinCC OA it is necessary that valid
Kerberos tickets are distributed, otherwise the necessary WinCC OA manager cannot be started. As soon as
a project is running even a breakdown of the server which distributes the tickets cannot stop the started
WinCC OA project from running. However, it is not possible to start further projects or a WinCC OA manager
within a project. This action will be prompted by an error message since a valid Kerberos ticket is also
needed for the start due to security reasons.
8.1.1.47 LDAP - Lightweight Directory Access Protocol

Lightweight Directory Access Protocol (LDAP) is a set of open protocols used to access centrally stored
information over a network. It is based on the X.500 standard for directory sharing but is less complex and
resource intensive. For this reason, LDAP is known as "X.500 Lite."
8.1.1.48 Local Area Network (LAN)

It is a communication network in which a group of computers, printers and other devices that are located
within a relatively limited area (e.g. a building), are connected to each another. Data exchange can take
place between all devices connected to the network in one LAN.
8.1.1.49 Man-in-the-middle attack(MITM)

This is a scenario where an Attacker secretly intercepts the communication between two parties. Each
member guess that they are communicating together but, messages are altered by the attacker. Typically,
the victims are not aware that the communication is altered and instead they believe they are communicating
directly via a trusted connection.
8.1.1.50 Manufacturing Execution System (MES)

A name for software solutions at the operations control level. The task of MES is to capture the entire data
volume with the aim of optimizing the production processes. The MES prepares the data acquired and
makes it ready for evaluation. In the process, even real-time data from the production is processed for the
monitoring and control of production processes.
At the automation and management levels, MES facilitate effective production and operation control. They
enable fast response times to changing manufacturing conditions in conjunction with the reduction of non-
production related activities. Thus, they represent a connection between the automation level of production
processes and the systems of the management level. In this case the term "vertical integration" is used.
Page 253 of 271

8.1.1.51 Mirror Server for Linux based systems
A mirror server contains the repository for Linux based systems. For Linux systems it is possible to configure
a dedicated host inside the internal network instead of using an official host in the internet.
A mirror server is configured to receive all update packages in a controlled environment before they are
deployed within the internal network. The usage of a Mirror Server helps to keep the internal hosts secret
which may contain privacy and secure information and makes them less vulnerable for an attack.
Another benefit of a Mirror Server is the reduction of internet bandwidth because the packages are only
downloaded once for all configured clients.
8.1.1.52 Mutual authentication

Mutual authentication (also known as two-way authentication) is a security process in which both client and
server authenticates the other identity before a communication is established.
Mutual authentication is implemented in WinCC OA in following ways:
• Check of X.509 certificates

• Username and Password
8.1.1.53 MQTT protocol

Message Queueing Telemetry Transport (MQTT) protocol is a publish-subscribe based messaging protocol.
It is designed for connecting remote devices using a slow or highly delaying network. A typical use case for
this communication are IoT devices.
A MQTT system consists typically of clients communicating with a server. The server is also called a broker.
WinCC OA operates as a MQTT client which can establish a connection to a MQTT broker.
8.1.1.54 NAMUR
NAMUR is an international association of automation technology users in the process industry. The complete
original name, "Normenarbeitsgemeinschaft für Mess- und Regeltechnik in der chemischen Industrie"
(Standards workgroup for measuring and control technology in the chemical industry) is no longer used
today. Instead, the association has now adopted the name, "Interessengemeinschaft
Automatisierungstechnik der Prozessindustrie" (Community of those interested in automation technology for
the process industry). NAMUR supports exchange of engineering practices between its members and with
other associations and organizations. The working results are published in the form of NAMUR
recommendations and worksheets and, if required, incorporated by national and international standards
committees as proposals for standardization.
8.1.1.55 NT LAN Manager (NTLM)

In a Windows network, NT LAN Manager (NTLM) is a suite of Microsoft® security protocols that provides
authentication, integrity, and confidentiality to users.
Page 254 of 271

8.1.1.56 PAM - Pluggable authentication module
“One of the most common ways of implementing password complexity on a Linux system is the use of a
pluggable authentication module (PAM). A PAM allows the system administrator to choose from a wide array
of authentication systems available on the Internet or writes his/her own system, if the application is PAM-
aware. This moves the onus for authentication away from the application itself, to separate modules that get
plugged into the application. With a PAM-aware passwd utility, the administrator can simply supply the
password complexity parameters, such as minimum length, presence of numbers and punctuation
characters, or absence of dictionary words that will be imposed on the user’s password.
In Linux, PAM configuration is done either the /etc/pam.conf file or files within the /etc/pam.d directory, or
both. When both are used, pam.conf sets default values, which can then be overridden by individual
application-specific files within the /etc/pam.d directory.”
(K. K. Mookhey, Nilesh Burghate, 2005, S. 53)
8.1.1.57 Perimeter Network, Perimeter, DMZ: Demilitarized Zone

(ISA-99): „A segment of the perimeter network located logically between internal and external networks.
“Perimeter network” (border network, Perimeter network) is another frequently used description for the DMZ.
In the telecommunication field, it is the keyword for a computer, router or a small network, which is set up as
a "neutral area" between the internal network of an organization and the "external" public network. This
measure should prevent external users from having direct access to a server with corporate information.
Note:
The purpose of the so-called demilitarized zone is to enforce the guideline of the internal network for
the information exchange externally as well as to grant untrustworthy external sources only
restricted access to information that can be officially released. Thereby the internal network is
protected against attacks from the outside.
In the context of industrial automation and process control systems “internal network” normally
means the network or segment on which the security related measures primary concentrate. For
example, a process control network can be considered as an internal network when it is connected
to an external business network.
Example:
A DMZ can be implemented using the WinCC OA proxy. A WinCC OA system with Data- and Event
Managers is running in the background. A WinCC OA HTTP-Server is running separated from the
system and it provides a defined mapping of the necessary data within the DMZ. The
communication takes place through a routing firewall. Thereby, the proxy is running on the secured
system. Externally, the WinCC OA HTTP-Server communicates through a NAT firewall with
Desktop UI end devices located in a different network. In this example, the WinCC OA HTTP-Server
represents the perimeter.
See chapter: Secure Web Publication
Page 255 of 271

8.1.1.58 Plant administrator
A Plant administrator is a user in a network, who administers the plant PCs with the scope of responsibility of
the plant operator. The Plant administrator must not necessarily be the plant operator.
8.1.1.59 Plant, automation plant

It is a production or manufacturing system (including all decentralized peripherals, sensors, actuators, drives,
network and software components, buildings, switching cabinets, cabling, operation and administration
personnel) consisting of process control, process visualization, automation and engineering systems
networked with each another.
8.1.1.60 Plant operator, operator

A plant operator or operator is a real person registered with the automation plant. This person has the
training and the authority to operate this system (e.g. operator registered in the WinCC OA project).
8.1.1.61 Plant PC, plant computer

It is a computer that is specifically in the scope of responsibility of the plant operator and is administered
there.
8.1.1.62 Predetermined breaking point

Describes a specific element where the communication chain from a device to a central server must fail in
situations with unexpected high load. A DoS attack or a malfunction of the software could responsible for this
unexpected load situation. The disruption of the communication between the effected components should
ensure the stability of the remaining system.
8.1.1.63 Process Control (Systems) Network (PCN)

It is the name for a network as part of a security cell or security area of the plant, in which the PCS systems
(Process Control Systems), DCS systems (Distributed Control Systems), or SCADA systems are located
(SCADA: Supervisory Control and Data Acquisition). Each of these is respectively the so-called plant or
terminal or HMI (Human Machine Interface) network. This should be a special and separate network. In
certain cases, the maintenance staff also uses this network.
8.1.1.64 Programmable Logic Controllers (PLC)

It is a device that is used for open-loop or closed-loop control of a machine or plant and is programmed
digitally. Since a few years, it has been replacing the "hardwired" programmed controller in most segments.
8.1.1.65 Protocol
This is a group of rules and conventions that is used to send information over a network. These rules control
the format, the repeat rate, the sequence and error control of the messages exchanged between the network
devices.
8.1.1.66 Process Control Network PCN

(ISA-99): Such networks that are usually connected with time-critical mechanisms for controlling physical
processes.
Note:
The process control network can be split in different zones and a company or plant can have
multiple process control networks.
Page 256 of 271

8.1.1.67 Process Control System PCS
PCS systems are plant computers that fulfill process control tasks, e.g. WinCC OA server, WinCC OA client,
8.1.1.68 Process Control Engineering

Process control engineering designates resources and processes that are used to control, regulate and
secure process-related plants. The central resources are the process control system and the programmable
logic controller. Besides this, there is still the hardwired programmed controller, which is not suitable for
complex applications. Hence, at present, it is used only where the installation of a PLC appears to be too
expensive or there are special demands on security.
A procedural process changes material depending on the type, property and composition. Typical procedural
plants are refineries, cement plants, rolling mills or paper factories. Related areas such as discrete
manufacturing or building technology have developed processes like those for manufacturing control
technology and building control technology. The basic task of process control engineering is to control and
monitor the process. The purpose is to maintain certain set-point conditions (temperature, fill level,
atmospheric humidity, etc.) and to trigger an alarm or activate a safety function in case of large deviations.
The modules of process control engineering communicate via special data links (Profibus, Modbus and
LON). However, the lower-priced data links from the world of computers are being used increasingly even in
this field. There is almost no system today that is not provided with the (Ethernet) network prevalent in the
PC world. Modern process control systems can also send e-mails and information to cell phones via SMS.
The systems of process control engineering are programmed using pre-defined software modules. This
reduces the number of errors considerably and enhances operational security (configuring instead of
programming).
This is important since these systems sometimes also watch, and control processes associated with a
certain hazard potential. Similarly, there are pre-defined modules to configure graphic displays (process
visualization) for representing the workflows internal to the process (plant, machinery). The graphical
information can be shown on a PC that is connected to the system or directly on a monitor.
8.1.1.69 Process Control Engineering, Control Equipment

(ISA-99): A category that comprises decentralized process control systems, programmable logic controllers,
SCADA systems, consoles for user interfaces as well as sensor facilities and control devices in the field of
administration and controlling of the process.
Note
The term also covers field bus systems which contain control logic and algorithms run on intelligent
electronic devices that coordinate their actions.
Page 257 of 271

8.1.1.70 Process Control Engineering and Personnel, IACS – Industrial Automation and Control Systems
The term covers control systems for the usage in manufacture and process engineering plants and facilities,
in building automation, in plants with geographical distributed operating procedures like utility companies
(energy, gas and water companies), in production and distribution plants like pipelines for oil, as well as
other industry branches like traffic networks that have an atomized process or are managed by remote
access.
This is a combination of staff, hardware and software that can influence the reliable performance or
execution of an industrial process in a safe and secure way.
Note
These systems are:
• Industrial process control systems like e.g. Distributed Control Systems/DCSs,

Programmable Logic Controllers/PLCs, Remote Terminal Units/RTUs, intelligent electronic
devices, SCADA systems (Supervisory Control and Data Acquisition), linked electronic
sensors and controls as well as monitoring and diagnostic systems.
In this context process control systems, whether in physically distributed or integrated form,
feature the basic functions of process control systems as well as Safety Instrumented
Systems/SIS.
• Assigned information systems like systems for expanded or changeable controls,

accelerator, display for fixed installed devices, graphical user interfaces, process history,
(Manufacturing Execution Systems/MES as well as plant information management systems.
Assigned internal interfaces, network interfaces, machine interfaces or user interfaces that provide
functions for controlling, security and production operations for continuous, batch, discrete or other
processes.
8.1.1.71 Process Visualization System / SCADA

SCADA is a control system architecture that uses computers, networked data communications and graphical
user interfaces for process supervisory management.
For more information see Wikipedia: https://en.wikipedia.org/wiki/SCADA (acc.: 27th March 2019)
8.1.1.72 Program Management

According to definition given by PMI (https://www.pmi.org (acc.: 27th March 2019)) a program is a superior
collection of projects in the same environment or the same goal. In context of this guideline a security
program includes different security related projects like:
• Configuration and hardening of WinCC OA.

• Implementation and configuration of network infrastructure.
• Definition and usage of security policies on site.
In this case a program management is the process of managing several related projects with the intention of
improving organization performance.
Page 258 of 271

8.1.1.73 Remote client
Explanation according to ISA-99: "Resources external to the process control network that are connected
temporarily or permanently with a host computer in the process control network via a communication link.
These resources enable access to parts of the control devices and equipment in the process control network
directly or indirectly."
8.1.1.74 Remote access

Remote access describes the usage of systems that enable access to the resources of a security zone from
a remote location. A human, a software process or a device can perform this access.
This is part of the integrated routing and RAS (Remote Access Service), the telephone worker, external field
employees and Plant administrators. They administer the servers in various branches of an organization
enabling network access from a remote location. Users can dial up into the network from a remote location to
use certain services. These include, for example, file and printer sharing, e-mail, scheduling and SQL
databases.
8.1.1.75 Remote UI
This is the default user interface from WinCC OA which is installed via a common setup. It holds libraries and
executables which are installed on the local machine. A UI interface establishes a connection to the
associated Data- and Event manager. It is possible to execute this UI local on the same machine or on a
remote machine.
8.1.1.76 Role-Based access control

By using the permission bits, a user is assigned to a role. Based on the applied role different privileges can
be granted or revoked for the control system.
8.1.1.77 Router
This hardware enables interoperability and connectivity between local area networks (LAN) and WANs (Wide
Area Network) and the interconnection of LANs with different network topologies (such as, for example,
Ethernet and Token Ring). Routers compare the information contained in the packet header with a LAN
segment and then choose the best possible transmission path for the packet. In the process, they try to
optimize the network performance.
8.1.1.78 Samba
Samba is a free software re-implementation of the SMB/CIFS networking protocol.
Samba runs on most Unix, OpenVMS and Unix-like systems, such as Linux, Solaris, AIX and the BSD
variants, including Apple's Mac-OS Server, and Mac-OS client (Mac OS X 10.2 and greater). Samba is
standard on nearly all distributions of Linux and is commonly included as a basic system service on other
Unix-based operating systems as well. Samba is released under the terms of the GNU General Public
License. The name Samba comes from SMB (Server Message Block), the name of the standard protocol
used by the Microsoft® Windows network file system.
Samba provides file and print services for various Microsoft® Windows clients and can integrate with a
Microsoft® Windows Server domain, either as a Domain Controller (DC) or as a domain member. As of
version 4, it supports AD and Microsoft Windows NT domains.
Page 259 of 271

8.1.1.79 Samba 4 Domain Controller
Starting from version 4.0, Samba can run as Domain controller (DC). This technology allows a centralized
user and resource management for Linux based OS systems. It is a major rewrite that enables Samba to be
an AD domain controller, participating fully in a Windows AD Domain.
8.1.1.80 Security-Enhanced Linux (SELinux)

This is an enhancement inside the Linux Kernel itself which was originally developed by US National
Security Agency (NSA). It is a standard fare on some Linux distributions like CentOS and provides
mechanisms to support mandatory access control by security policies.
8.1.1.81 Service Principal Name

“Service principal names are associated with the security principal (user or groups) in whose security context
the service executes. SPNs are used to support mutual authentication between a client application and a
service. An SPN is assembled from information that a client knows about a service. Or, it can obtain
information from a trusted third party, such as Active Directory. A service principal name is associated with
an account and an account can have many service principal names.” (Microsoft, Microsoft Technet, kein
Datum)
8.1.1.82 Single Sign On

This feature is applicable to each workstation. If the feature is enabled in the WinCC OA Windows user
administration, it is not necessary to enter a password when starting the WinCC OA UI client. Windows login
takes place automatically. In addition, the authorization level 'bit 32' enables the usage of SSO feature for a
workstation.
8.1.1.83 Sudo command

This is a Linux specific command where root permission is required when executing it as common user. This
command is placed in front of the original command and the OS requests the user password at the first
execution (e.g.: sudo apt-get upgrade). After the first execution the password is cached until a configurable
timeout (default 15 minutes) is reached. A modification of this timeout is possible with the file /etc/sudoers.
Following line reduces the default timeout to two minutes:
Defaults timestamp_timeout=120
8.1.1.84 Support PC, support device

This describes a mobile or stationary PC for a support employee that has the privileges to establish a
connection to the live system. In the security concept this fact is shown by allowing this computer a
connection over the perimeter zone.
8.1.1.85 Support Station

Stationary support PC that is either physically positioned at the plant as MES in the PCN and therefore part
of the plant or positioned as a distributed MES in a perimeter network/MON and is a trustworthy distributed
plant PC.
8.1.1.86 Tampering
Within this document the term tampering refers to a modification of products in a way that would make them
harmful to the consumer. It is essential to configure the SCADA system in a way that avoids any case of
tampering. It is possible to scan the own system for vulnerability regarding tampering by usage of
vulnerability scanners like MBSA from Microsoft®.
Page 260 of 271

8.1.1.87 TCP/IP
It is a group of network protocols frequently used for connecting computers. It also enables the
communication between computers and networks having different hardware architectures and operating
systems that are connected to each other. TCP/IP encompasses standards for the communication between
computers and conventions for connecting networks as well as routing the data traffic.
8.1.1.88 Trusted - Network

This is a network of machines behind a security perimeter protected by a firewall;
see chapter: Process Control Network PCN.
All machines are completely controlled by a central mechanism like an AD controller and the machines within
this network are protected from any outside triggered impact. Every outbound communication from a trusted
network via security perimeter is controlled by defined procedures.
Machines inside of the trusted network are defined as secure machines and an unencrypted communication
between these machines is possible. Usually these machines are configured in an own security cell with
limited access to the other network controlled by a firewall and a DMZ.
With WinCC OA it is possible to set up the connection between a trusted and untrusted network via WinCC
OA mxProxy manager.
8.1.1.89 Ultralight client – User Experience (ULC UX)

Client system of WinCC OA based on HTML5 and WebSocket technology which controls the logic of a user
interface directly on a WinCC OA server. Only graphical information is transferred to the clients.
8.1.1.90 Untrusted - Network

This is the opposite of the trusted network and the configured machines are placed outside from a security
perimeter. To set up a connection between these machines and machines inside a trusted network a lot of
configuration settings must be considered. The connection of these machines to any machines inside the
trusted network must be controlled by good and defined procedures.
8.1.1.91 User
A person accessing a system with or without the necessary privileges respectively an accessing part of an
organization or automatic process.
A real or virtual person logged in (e.g. the user logged in at the desktop of the respective operating system or
even an automatic desktop login).
8.1.1.92 User rights

General: Privileges which enable the user to perform assigned tasks on a computer system or a domain.
The definition of operation authorizations for workstations is an elementary and integral part of WinCC Open
Architecture. The standardized authorizations are mapped with the help of levels (bits).
See chapter: Task-Related Operation and Access Rights.
System management / Authorization / Authorization levels
Page 261 of 271

8.1.1.93 Vimacc® System
“Vimacc® is a universal digital video management system that can be seamlessly integrated into existing
system structures. It not only integrates different peripheral video systems it can also be integrated itself into
various superior systems. Vimacc® is platform independent and has a modular structure.
• Independent from a system's design, complexity and architecture, vimacc®
• Manufacturer independent and standardized integration
• Manual and alarm-controlled surveillance

• Permanent recording in configurable ring; manually resp. alarm-controlled
• Efficient, fast, accurate, and data protection compliant investigation
• Redirecting to external systems:
• independent from manufacturer due to standard interfaces
• Data protection compliant deployment for multiple clients simultaneously “

(Accellence Technologies, 2018)
8.1.1.94 Virtual Private Network (VPN)

This is the extension of a private network that includes encapsulated, encoded and authenticated links over
commonly used or public networks. It is possible to use remote access and routing connections for private
networks via the Internet with VPN connections.
8.1.1.95 WebClient
A WebClient is any computer or software application that sets up a link with another computer with a running
Webserver to requests its service.
8.1.1.96 WebSocket and WebSocket secure (WS and WSS)

WebSocket is a computer communication protocol, supplying full-duplex communication channels over a
single TCP connection. The WebSocket protocol enables interaction between a web client (e.g. a browser)
and a web server with lower overhead and is used by ULC UX client from WinCC OA. The secure mode
supports encrypted communication.
8.1.1.97 WinCC OA HTTP-Server

This is a Webserver for static HTML files and file transfer, dynamic HTML files and scripting on the server
side using WinCC OA control script. This is a unique HTTP server technology designed for usage directly
with WinCC OA and it is recommended to run this service as predetermined breaking point and inside a DMZ
for security reasons. This service does not implant specific security technology as know by the common
Apache Server, but it is possible to use both technologies together.
Page 262 of 271

8.1.1.98 Workstation authorization
Workstation authorization may be assigned to all user groups or alternatively, to members of different
specific groups. Access rights may be specified, or, if needed, reduced with the help of workstation
authorization. For example, the rights of an administrator are not inherited by or assigned to a user who is
exclusively allowed the visualization of fixed and defined functional areas via workstation authorization.
System management / Authorization / Workstation authorization
8.1.1.99 X.500
X.500 Directory Service is a standard way to develop an electronic directory of people in an organization so
that it can be part of a global directory available to anyone in the world with Internet access.
Page 263 of 271

9 Lists
Table of figures
Figure 1 - IEC 62443 definition from 9th February 2018 (ISA99, kein Datum) ....................................................... 17
Figure 2 - Responsibilities for asset owner, Integrator and Product supplier in IEC62443 (Kobes, 2016) ..... 20
Figure 3 - Weakest point in chain (Siemens, 2019) .................................................................................................... 20
Figure 4 - Automation levels (Siemens, 2019) ............................................................................................................. 24
Figure 5 - Security Management Process (Siemens, 2019) ...................................................................................... 28
Figure 6 - Basic layers of defense in depth according to responsibility ................................................................. 29
Figure 7 - Layers of protection ........................................................................................................................................ 31
Figure 8 – Implementation of Defense in Depth concept for different Types of Access (Siemens, 2019) ..... 35
Figure 9 – Splitting of Security Cells (Siemens, 2019) .............................................................................................. 38
Figure 10 - Communication in Security Cells (Siemens, 2019) ................................................................................ 38
Figure 11 - Operation Levels (Siemens, 2019) ............................................................................................................. 40
Figure 12 - Operation levels Personal production (Siemens, 2019) ........................................................................ 41
Figure 13 - Operation levels production (Siemens, 2019) ......................................................................................... 42
Figure 14 - Operation levels Domain Production (Siemens, 2019) .......................................................................... 43
Figure 13- Usage of TLS/SSL in OSI model between Client and Server ................................................................ 46
Figure 16 - Public/Private Key encryption (Gilliam, 2018) ........................................................................................ 47
Figure 17 - Public/Private Key signature (Gilliam, 2018) .......................................................................................... 48
Figure 18 - Usage of MAC Signature ............................................................................................................................. 49
Figure 19 - TLS Handshake protocol (Zwodrei, 2015) ............................................................................................... 50
Figure 20 - Kerberos Ticket granting service ............................................................................................................... 51
Page 264 of 271

Figure 21 - Phases in Security Strategy ........................................................................................................................ 53
Figure 22 - Highly secure large system with WinCC OA DRS System .................................................................... 58
Figure 23 - Secure small system .................................................................................................................................... 62
Figure 24 - Secure security cell link ............................................................................................................................... 64
Figure 25 - Secure security cell link with security tunnel .......................................................................................... 65
Figure 26 - Sample configuration for security cell connection via a single WinCC OA mxProxy ...................... 66
Figure 27 - Digital signature signed by ETM professional control GmbH .............................................................. 82
Figure 28 - Access from malicious user via DCOM interface ................................................................................... 86
Figure 29 - Usage of DCOM Tunneling Software ........................................................................................................ 87
Figure 30 - OPC tunnel protocol from OPC Expert (https://opcexpert.com/) ...................................................... 87
Figure 31 – Reverse-Proxy schema ................................................................................................................................ 88
Figure 32 - Example for Apache configuration with Desktop UI or Remote UI ..................................................... 90
Figure 33 - Import certificate into Trusted Root Certification Authorities ............................................................. 92
Figure 34 - Start page from WinCC OA HTTP-Server with trusted certificate via Apache Server ................... 93
Figure 35 - Example for Apache configuration with ULC UX .................................................................................... 95
Figure 36 - Secure ULC UX communication via Apache Proxy ................................................................................ 97
Figure 37 - Oracle Database Appliance X7-2M ( (Oracle, 2019) ............................................................................. 98
Figure 38 - SELinux ........................................................................................................................................................... 99
Figure 39 - Schematic graphic of the communication using the WinCC OA mxProxy with a remote UI ....... 103
Figure 40 - Sample configuration for a remote WinCC OA mxProxy ..................................................................... 104
Figure 41 - SSL host certificates panel ....................................................................................................................... 110
Figure 42 - Certificates Snap-in for MMC .................................................................................................................. 115
Page 265 of 271

Figure 43 - Settings to import PKCS12 certificate .................................................................................................... 116
Figure 44 - Imported host certificate and certification chain (chain of trust) ..................................................... 117
Figure 45 - Configure Read Permission to Private Key for WinCC OA Users ...................................................... 118
Figure 46 - Certificate in store of Current User ......................................................................................................... 119
Figure 47 - Example for chainPrefix ............................................................................................................................. 120
Figure 48 - Default user role in WinCC OA ................................................................................................................. 125
Figure 49 - Datapoint with authorization config ........................................................................................................ 126
Figure 50 - Permission bits for pairs OpAll_tunnel1- tunnel1/tunnel2 ................................................................. 130
Figure 51 - Permission bits for pairs OpAll_tunnel2-tunnel2/tunnel3 .................................................................. 131
Figure 52 - Permission bits for the pair OpAll_tunnel3-tunnel3 ............................................................................. 131
Figure 53 - Effective user permissions for user tunnelOperator1 .......................................................................... 132
Figure 54 - Disable Automatic Unlock for mobile devices and WinCC OA Desktop UI ..................................... 136
Figure 55 - WinCC OA as MQTT client ........................................................................................................................ 138
Figure 56 – Protect unsecure WinCC OA driver communication with Secure Tunnel........................................ 139
Figure 57 - Compare Ethernet- to Serial protocol protection ................................................................................. 141
Figure 58 - Signature for Desktop UI installation package ..................................................................................... 143
Figure 59 - Digital signature for executable ............................................................................................................... 144
Figure 60 - Prevent DoS Attack via config settings .................................................................................................. 148
Figure 61 - Prevent DoS Attack to WinCC OA driver via config settings .............................................................. 149
Figure 62- Central user administration with Domain Controller and different permissions ............................ 155
Figure 61 - System authorization panel to set permission bit 3 ............................................................................. 156
Figure 64 - Usage WinCC OA in PAM architecture ................................................................................................... 157
Page 266 of 271

Figure 65 - Windows/Linux DC Architecture ............................................................................................................. 158
Figure 66 - User defined authentication with external tool .................................................................................... 161
Figure 65 - Increasing Password length with fixed Alphabet size of 26 ............................................................... 166
Figure 66 – Increasing Alphabet size with fixed Password length of 5 ................................................................. 166
Figure 69 - Single Sign On ............................................................................................................................................. 175
Figure 70 – Compare SSA login process with WinCC OA default mechanism .................................................... 177
Figure 71 - SSA example ................................................................................................................................................ 178
Figure 72 - Create certificate for SSA with session binding ................................................................................... 181
Figure 73 - Windows certificate Store with SSA certificates for Manager .......................................................... 184
Figure 74 - Interaction VMS and WinCC OA (Accellence Technologies, 2018) .................................................. 190
Figure 75 - Video Security Wizard ................................................................................................................................ 191
Figure 76 - CTK Implementation .................................................................................................................................. 192
Figure 77 - Communication Methods in WinCC OA with remote mxProxy .......................................................... 196
Figure 78 - Communication Methods in WinCC OA with local mxProxy .............................................................. 198
Figure 79 - Communication Methods in WinCC OA with local mxProxy and Apache Reverse-Proxy ............ 200
Figure 80 - Usage of WSUS server ............................................................................................................................... 206
Figure 81 - Virus Scan Overview (Siemens, 2019) .................................................................................................... 209
Figure 82 - Usage of Virus scan server ....................................................................................................................... 210
Figure 83 - Backup Schema ........................................................................................................................................... 219
Figure 84 - Grandfather/Father/Son backup principle ............................................................................................ 220
Figure 85 - Magic square by Gartner for vendors of backup and restore software (Gartner, 2017) .............. 221
Figure 86 - IEC 9126 Schema ........................................................................................................................................ 222
Page 267 of 271

Figure 85 - Online Backup .............................................................................................................................................. 223
Figure 88 - Parameterization Backup .......................................................................................................................... 223
Figure 89 – Archives in Historical Archive (HDB) ...................................................................................................... 224
Figure 90 – Archive Groups in RDB Archive ................................................................................................................ 224
Figure 91 - Steps of VDI/VDE 2182 .............................................................................................................................. 226
Figure 92 - Part from Highly Secure Large System architecture ........................................................................... 228
Figure 93 – Definition of exposure ................................................................................................................................ 230
Figure 94 – Define Likelihood matrix based on Exploitability and Exposure ....................................................... 230
Figure 95 – Define the risk level on site ...................................................................................................................... 230
Figure 96 – Evaluation of risk level ............................................................................................................................... 231
Figure 97 - Definition of Security threat ...................................................................................................................... 231
Figure 98 - Architecture BitLocker (Microsoft, BitLocker, 2016) ........................................................................... 235
Page 268 of 271

List of Tables
Table 1 - List of Abbreviations ........................................................................................................................................ 15
Table 2 - Norms and Standards ...................................................................................................................................... 21
Table 3 - Strategy of IT Security ..................................................................................................................................... 27
Table 4 - Security Solutions............................................................................................................................................. 54
Table 5 - Firewall Overview ............................................................................................................................................. 55
Table 6 – User authorization on folder level ................................................................................................................. 80
Table 7 – Port WinCC OA mxProxy ............................................................................................................................... 102
Table 8 - Default communication ports used for alive-message communication .............................................. 108
Table 9 - List of useable cipher suits in WinCC OA .................................................................................................. 122
Table 10 – Faults in RPM file check ............................................................................................................................. 145
Table 11 - Compare methods of user authentication ............................................................................................... 152
Table 12 – Security assessment of authentication method in WinCC OA ........................................................... 153
Table 13 - Time for brute-force attack ........................................................................................................................ 166
Table 14 – Matrix for UI in intended operational environment ............................................................................... 188
Table 15 – Types of OS related patches ..................................................................................................................... 203
Table 16 - VDI/VDE Example Step 2 ........................................................................................................................... 229
Table 17 - VDI/VDE Example Step 3 ........................................................................................................................... 229
Table 18 - VDI/VDE example step 4 ............................................................................................................................ 232
Table 19 - VDI/VDE example step 6 ............................................................................................................................ 233
Table 20 - Security Checklist......................................................................................................................................... 242
Table 21 – List of available cipher suites (Siemens, 2019) ..................................................................................... 244
Page 269 of 271

List of citations
Accellence Technologies. (2018, 09 17). https://www.accellence.de/en.
Blunden, B. (2013). Software Exorcism. New York, NY 10013: Apress.
BSI - IT-Grundschutz-Catalogues. (2013). Retrieved from https://download.gsb.bund.de/BSI/ITGSKEN/IT-GSK-13-EL-

en-all_v940.pdf
BSI. (2019, 03 26). Daten auf Festplatten richtig löschen. Retrieved from https://www.bsi-fuer-
buerger.de/BSIFB/DE/Empfehlungen/RichtigLoeschen/richtigloeschen.html
CIS. (2018, 11 29). Center of Internet Security. Retrieved from https://www.cisecurity.org/
Fernandez, I. (2015). Beginning Oracle Database 12c Administration: From Novice to Professional (2nd edition).
Apress.
Gartner. (2017, 7 31). Retrieved 09 27, 2017, from https://www.gartner.com
Gerhard Ackermann, Robert Hönl. (2006). Schutz von IT-Anlagen gegen Überspannung. Berlin: VDE Verlag.
Gilliam. (2018, 2 25). Public-key cryptography. Retrieved 3 05, 2018, from Wikipedia:
https://en.wikipedia.org/wiki/Public-key_cryptography
ICS-Cert. (2018, 1). ICS-Cert. Retrieved 1 10, 2018, from https://ics-cert.us-

cert.gov/sites/default/files/recommended_practices/RP_Updating_Antivirus_in_an_ICS_S508C.pdf
IEC 62443-2-1. (2010, 11). IEC 62443-2-1. IEC.
IEC_9126, W. (2017, 4 5). IEC_9126, Wikipedia. Retrieved 9 27, 2017, from

https://en.wikipedia.org/wiki/ISO/IEC_9126
ISA99, C. (n.d.). ISA99 Committee. Retrieved 2 28, 2018, from

http://isa99.isa.org/Public/Forms/AllItems.aspx?RootFolder=%2FPublic%2FImages
K. K. Mookhey, Nilesh Burghate. (2005). Linux - Security, Audit and Control Features. Rolling Meadows, IL 60008
USA: Information Systems Audit and Control Association.
Kobes, P. (2016). Leitfaden Industrial Security IEC 62443 einfach erklärt. Berlin: VDE VERLAG GMBH.
Microsoft. (2016, 09 08). BitLocker. Retrieved from https://docs.microsoft.com/en-us/previous-versions/technet-

magazine/cc160980(v=msdn.10)
Microsoft. (2019, 02 04). Cipher Suites in TLS/SSL (Schannel SSP). Retrieved from https://docs.microsoft.com/en-
au/windows/desktop/SecAuthN/cipher-suites-in-schannel
Microsoft. (n.d.). Microsoft Technet. Retrieved 3 6, 2018, from Service Principal Names:
https://technet.microsoft.com/en-us/library/cc961723.aspx
Microsoft. (n.d.). Require SMB Security Signatures. Retrieved 7 10, 2018, from https://docs.microsoft.com/en-
us/previous-versions/orphan-topics/ws.11/cc731957(v=ws.11)
NSA. (2019). National Security Agency / Central Security Service. Retrieved from https://www.nsa.gov/what-we-
do/research/selinux/
Page 270 of 271

Oracle. (2019). Oracle Database Appliance X7-2M. Retrieved from https://www.oracle.com/engineered-
systems/database-appliance/x7-2m/
Raina, K. (2003). PKI Security Solutions for the Enterprise. Indianapolic, Indiana: Wiley Publishing Inc.
Shaw, W. T. (2006). Cybersecurity for SCADA Systems. Tulsa, Oklahoma 74112-6600 USA: PennWell Corporation.
Siemens. (2019). Siemens PSS Network.
Smulders, P. (1990). The threat of information theft by reception of electromagnetic radiation from rs-232 cables. In
Computer & Security vol. 9 (pp. 53-58).
Stapleton & Epstein. (2016). Security without Obsurity - A Guide to PKI Operations. Boca Raton, FL 33487-2742: CRC
Press, Taylor & Francis Group.
Wikipedia. (2018, 10 9). Denial-of-service attack. Retrieved from https://en.wikipedia.org/wiki/Denial-of-service_attack
Zvarych, A.G.; Pomales, I.; Rodriguez, J.; Villasmil, D. (2014). Practical Communications Considerations for Protection
Engineers. Retrieved from https://ieeexplore.ieee.org/document/6799025
Zwodrei. (2015, 3 10). SSL handshake with two way authentication with certificates. Retrieved 3 5, 2018, from
https://commons.wikimedia.org/w/index.php?curid=9031795
Page 271 of 271

WinCC Open Architecture Security Guideline

Uploaded by

Copyright:

Available Formats

WinCC Open Architecture Security Guideline

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

WinCC Open Architecture Security Guideline

Uploaded by

Copyright:

Available Formats

Preamble 1

Targets of the Security

Security Guideline References 3

Proper Use of ETM professional control GmbH products

Please take note of the following:

SIMATIC - WinCC Open Architecture3.16 FP2 (P009)

2 TARGETS OF THE SECURITY GUIDELINE ............................................................................................................................. 16

IEC 62443/ISA99 ............................................................................................................................................................... 17

NAMING SCHEME IN FIGURES AND EXAMPLES ............................................................................................................................. 23

5 STRATEGY OF THE SECURITY GUIDELINE ........................................................................................................................... 25

SECURITY MANAGEMENT PROCESS .......................................................................................................................................... 26

6 IMPLEMENTATION OF THE SECURITY STRATEGY FOR SECURITY SOLUTIONS .................................................................... 53

SECURITY CELLS AND NETWORK ARCHITECTURE .......................................................................................................................... 55

SIMATIC - WinCC Open Architecture3.16 FP2 (P009)

SIMATIC - WinCC Open Architecture3.16 FP2 (P009)

7 SECURITY CHECKLIST....................................................................................................................................................... 236

9 LISTS ............................................................................................................................................................................... 264

TABLE OF FIGURES ............................................................................................................................................................... 264

SIMATIC - WinCC Open Architecture3.16 FP2 (P009)

Intention of this document

SIMATIC - WinCC Open Architecture3.16 FP2 (P009)

SIMATIC - WinCC Open Architecture3.16 FP2 (P009)

SIMATIC - WinCC Open Architecture3.16 FP2 (P009)

The document is structured as followed:

• Chapter 5: The security strategies and their basic principles

• Chapter 7: Security Checklist

WinCC OA Documentation reference

• Advanced knowledge about WinCC Open Architecture

• Administration of IT technologies known for the office environment

• Configuration of used third party products.

SIMATIC - WinCC Open Architecture3.16 FP2 (P009)

WinCC OA Documentation reference

Installation / Requirements for WinCC OA

SIMATIC - WinCC Open Architecture3.16 FP2 (P009)

SIMATIC - WinCC Open Architecture3.16 FP2 (P009)

SIMATIC - WinCC Open Architecture3.16 FP2 (P009)

SIMATIC - WinCC Open Architecture3.16 FP2 (P009)

SIMATIC - WinCC Open Architecture3.16 FP2 (P009)

SIMATIC - WinCC Open Architecture3.16 FP2 (P009)

See also: http://en.wikipedia.org/wiki/Cyber_security_standards (acc.: 27th March 2019)

SIMATIC - WinCC Open Architecture3.16 FP2 (P009)

SIMATIC - WinCC Open Architecture3.16 FP2 (P009)

SIMATIC - WinCC Open Architecture3.16 FP2 (P009)

Asset Owner 2-1

Automation solution 2-4

IACS environment / project specific

develops control systems Control System

Independent of IACS environment

Reason and goal of an IEC 62443

SIMATIC - WinCC Open Architecture3.16 FP2 (P009)

ISO/IEC - International Organization for Standardization / International Electro

ISO/IEC 11770 “Information technology -- Security techniques -- Key management”

ISO/IEC 15408 "Information technology - Security techniques - Evaluation criteria for IT

ISO/IEC 17799 "Code of practice for information security management""

ISO/IEC 27001 "Information security management systems – Requirements" as part of

IEC 61643 “Low-voltage surge protective devices”

IEC 61663 “Lightning protection - Telecommunication lines”

NAMUR - International User Association of Automation Technology in Process

NA 67 " Information protection for process control systems (PCS) "

NA 103 " Use of Internet technologies in process automation "