WinCC OA 资料 - Security Guideline References 3...SIMATIC - WinCC Open Architecture3.16 FP2 (P009)...

Preamble 1

Targets of the Security

Guideline 2

References 3

Definitions 4

Strategy of the Security

Guideline 5

Implementation of the

Security Strategy for

Security Solutions

6

Security Checklist 7

Glossary 8

Lists 9

Security Guideline

SIMATIC

WinCC Open Architecture

3.16 FP2 (P009)

05/2019

Legal Information

ETM professional control GmbH | A Siemens Company

A Siemens Company

Marktstraße 3

A-7000 Eisenstadt

7000 Eisenstadt

AUSTRIA

05/2019

Copyright © ETM professional control GmbH |

A Siemens Company

subject to alterations

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.

of 271

SIMATIC - WinCC Open Architecture3.16 FP2 (P009)

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.

of 271


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

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

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

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.

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)

https://www.siemens.com/industrialsecurity

https://www.siemens.com/industrialsecurity

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)


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.

https://www.winccoa.com/

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.


https://technet.microsoft.com/en-us/security

https://technet.microsoft.com/en-us/security/bulletin/dn602597

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.

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

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

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

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.

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)

http://en.wikipedia.org/wiki/Cyber_security_standards

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

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

of 271


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.

IACS environment / project specific

Independent of IACS environment

develops control systems

designs and deploys

operates and maintains

is the base for

Control System

as a combination of components

Host devices

Network components Applications

Embedded devices

4-1

3-3

4-2

develops components

Product

Supplier

System

Integrator

Asset Owner

Service Provider

Industrial Automation and Control System (IACS)

+

2-4

3-2

2-1

2-4

Operational policies and procedures

Automation solution

Basic Process Control System

(BPCS)

Safety Instrumented System (SIS)

Complementary Hardware and

Software

Maintenance policies and procedures

2-3

3-3

Figure 3 - Weakest point in chain (Siemens, 2019)

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

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


http://www.industry.siemens.com/topics/global/en/industrial-security/Pages/default.aspx

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.

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)

MES – Manufacturing Execution Systems (Level)

MCS – Manufacturing Control Systems (Level)

ECN Enterprise Control (Systems) Network

MON Manufacturing Operations Network

PCN Process Control (Systems) Network

CSN Control Systems Network

FDN Field Device Network (Field Level)

Figure 4 - Automation levels (Siemens, 2019)

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.

https://www.bsi.bund.de/EN/Topics/ITGrundschutz/ITGrundschutzCatalogues/itgrundschutzcatalogues_node.html

https://www.bsi.bund.de/EN/Topics/ITGrundschutz/ITGrundschutzCatalogues/itgrundschutzcatalogues_node.html

https://download.gsb.bund.de/BSI/ITGSKEN/IT-GSK-13-EL-en-all_v940.pdf

https://www.tenable.com/blog/cis-adapts-critical-security-controls-to-industrial-control-systems

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.

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

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.

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.

Figure 6 - Basic layers of defense in depth according to responsibility

Industrial IT Security Services

Operational Guidelines

Product Security Product Supplier

System Integrator

Asset Owner

Service Provider


https://new.siemens.com/global/en/company/topic-areas/future-of-manufacturing/industrial-security.html

https://new.siemens.com/global/en/company/topic-areas/future-of-manufacturing/industrial-security.html

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

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.

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.

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.

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.

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.

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

Realtime Data

Data

Exchange

Realtime

Controlling Maintenance Support

physical protection

single access points

perimeter zones

standardize

application layer

filtering

secure

Authentication

and SSO

perimeter zones

certificate based

authenticated

and encrypted

communication

secure

Authentication

and SSO

secure

Authentication

and SSO

secure

Authentication

and SSO

certificate based

authenticated

and encrypted

communication

certificate based

authenticated

and encrypted

communication

System hardening System hardening System hardening System hardening

Operator-Rights

Administration

Operator-Rights

Administration

Operator-Rights

Administration

Types of

Access

Layers

of

Protection

perimeter zones perimeter zones

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!

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

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.

Figure 9 – Splitting of Security Cells (Siemens, 2019)

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

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.

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)

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.

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.

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.

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.

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

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

Presentation

Session

Transport

Network

Data Link

Physical

Application

Presentation

Session

Transport

Network

Data Link

Physical

TLS/SSL

TLS/SSL

IP Sec

Figure 15- Usage of TLS/SSL in OSI model between Client and Server

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)

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)

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

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)

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

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.

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.

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.

Decommissioning

Continuous Risk Management

Backup and Restore concept

Security Tests

Logging, audit, maintenance and asset management

Virus Scanner

Patch Management and Security Updates

Administration and Configuration

Hardening

Security Cells and Network Architecture

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

according to recommendations.

Administration and Configuration of OS

Administration and Configuration of WinCC OA

A plant shall regular get updates to close newly

discovery security gaps.

Patch management and security updates

A plant shall check incoming files for harmful

content.

Virus Scanner

A plant shall record security-related and

process-specific data

Logging, audit, maintenance and asset

management

The implemented security level shall be checked

regularly for improvements.

Security Tests

A process to recover from a disaster shall be

defined.

Implement Backup and Restore concept

A continuous Risk assessment process shall be

implemented.

Implement Risk assessment process based on

VDI/VDE 2182

A plan shall be decommissioned in a secure way

after end-of-life.

System Decommissioning

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)


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:

Front-end Firewall Protects the perimeter and enables access to web publications of the

perimeter and remote dial-up options for the back-end firewall

Back-end Firewall

Protects the production control network PCN and enables the primarily

certificate-based, encoded and signed access to individual trustworthy

remote stations and networks (e.g. MON of the manufacturing execution

system, MES) and the remote and support access to the PCN.

Three homed-

Firewall

Combined front-end and back-end firewall with certain "Minimal Perimeters"

for scalable security solutions

Access point-Firewall (Special Case) Offers access to a security cell exclusively for maintenance

tasks, which otherwise, would not need any connection (e.g. to the MES).

Back-Router Enables load decoupling with high throughput, usually in combination with an

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.

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

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.

of 271


Figure 22 - Highly secure large system with WinCC OA DRS System

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.

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.

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

of 271


WinCC OA Server

WinCC OA Desktop UI

Control System Network

Process Control Network

Enterprise Control Network

S7-400H S7-400 S7-400 S7-400FH

WinCC OA Support Station

Firewall

Accesspoint

Firewall

WAN

WinCC OAWebserver

WinCC OA Support Station

Office PC

WinCC OA Client

Figure 23 - Secure small system

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)

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.

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

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.

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)

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

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.

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.

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

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.

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.

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.

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.

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.

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

https://www.bsi.bund.de/EN/Topics/ITGrundschutz/ITSecurityGuidelines/itSecurityguidelines_node.html

https://docs.vmware.com/en/VMware-vSphere/index.html

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.

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)

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc786681(v=ws.10)

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc786681(v=ws.10)

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)

All

directo

ries

Pro

ject

fold

er

<pro

j_p

ath

>/log

<pro

j_p

ath

>/d

b

<pro

j_p

ath

>/d

ata

All

directo

ries

Pro

ject

fold

er

<pro

j_p

ath

>/log

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.

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.

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)

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.

https://en.wikipedia.org/wiki/Kiosk_software

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

https://www.securecoding.cert.org/confluence/display/seccode/SEI+CERT+Coding+Standards

https://www.bsi.bund.de/EN/TheBSI/thebsi_node.html

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)

https://technet.microsoft.com/en-us/library/cc771387(v=ws.11).aspx

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.

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/)

https://opcexpert.com/

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

https://scadahacker.com/library/Documents/OPC_Security/OPC%20Security%20-%20Hardening%20Guidelines%20for%20OPC%20Hosts.pdf

https://scadahacker.com/library/Documents/OPC_Security/OPC%20Security%20-%20Hardening%20Guidelines%20for%20OPC%20Hosts.pdf

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

https://www.winccoa.com/downloads/detail/wincc-oa-secured-by-apache-en.html?tx_mddownloads_mddownloadsfe%5Baction%5D=show&cHash=517b4b9c361294c4ba4c727a319d8db3



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>

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>

https://pentestweb/

https://pentestweb/

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

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.

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.

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®):

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>

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

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.

https://www.mass.gov/equifax-data-breach

https://www.doag.org/en/home/

https://www.doag.org/formes/pubfiles/10852341/2018-Infra-Tammy_Bednar-Oracle_Database_Appliance_built-in_Security_features_-Manuskript.pdf

https://www.doag.org/formes/pubfiles/10852341/2018-Infra-Tammy_Bednar-Oracle_Database_Appliance_built-in_Security_features_-Manuskript.pdf

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.

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

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 = ""

https://www.winccoa.com/forum/

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

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

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.

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"

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.

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




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.

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.

https://www.openssl.org/

https://wiki.openssl.org/index.php/Main_Page

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

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

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.

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:


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.

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.

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:

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.

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

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.

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:

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.

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

AES256-SHA

Deprecated

These cipher suites exist for compatibility reasons and must

not be used on secure systems due to a weak MAC algorithm.

AES128-SHA256

AES256-SHA256

RSA Certificates and private keys are used for key exchange

and partner authentication. Key exchange and authentication

are done with RSA.

DHE-RSA-AES256-SHA256

DHE-RSA-AES256-GCM-SHA384

DHE-DSS-AES256-GCM-SHA384

The Diffie–Hellman key exchange method allows two parties

that have no prior knowledge of each other to jointly establish a

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

ECDHE-RSA-AES256-GCM-SHA384

Elliptic curve Diffie–Hellman (ECDH) is an anonymous key

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

https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-1.pdf?__blob=publicationFile&v=8

https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-1.pdf?__blob=publicationFile&v=8

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.

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

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.

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.

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]);

}

}

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);

}

}

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.

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

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

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

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.

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

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

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.

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

https://opcfoundation-onlineapplications.org/faq/#t=SecurityBulletins.htm

https://opcfoundation.org/security/

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:


(acc.: 27th March 2019).


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

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

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.

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

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

https://en.wikipedia.org/wiki/Extended_Validation_Certificate

https://theniceweb.com/archives/491

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.

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.

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

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

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.

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

maxRequestLineCount

maxRequestMemSize

maxValueRequestCount

maxAlertRequestCount

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

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

maxTrapsBufferSize

maxOutputQueueSize

maxRequestQueueSize


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)

https://www.us-cert.gov/ncas/tips/ST04-002

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

Requirement

WinCC OA user

authentication

Operating system

based user

authentication

User defined

authentication with a

3rd party tool

Duplicate storage of

password hash

Username and hashed

password in WinCC OA

Datapoint

Username stored in

WinCC OA Datapoint

Username stored in

WinCC OA Datapoint

Password hash

algorithm

conform to PKCS #5 State of the art and OS

related.

Depends on the

authentication tool but

should be able to handle

an IEC62443 compliant

algorithm (see chapter:

Block Cipher)

Financial Costs Intergraded in WinCC

OA

no additional cost

Handled with OS license

Depends on the license

costs of the 3rd party tool

Additional costs for

implementation and

maintenance may occur.

Mandatory usage of

strong password

Not implemented,

password strength

depends on the user

Configurable Must be configurable for

full standard (IEC62443)

compliance with the

selected tool.

Cyclic change of a

password

Not implemented, user

must change the

password in own

responsibility

Configurable Should be configurable

with the selected tool.

Easy start of

configuration and

tailoring

WinCC OA has own

users to start with

implementation

User and groups must

be created in OS level.

Permission bits must be

configured in WinCC OA

User, Groups and

maybe also permission

bits must be configured

in the external tool

Centralized user

administration

Not existing, user must

be synchronized

manually (Sync tool

inside from WinCC OA

available)

User Administration is

centralized but OU

(Organization units) do

not exist in WinCC OA

User Administration may

be centralized in

dependency of the tool.

Disabling of a user User can be disabled

but can easily be

restored

Restore of a disabled or

deleted user will need

Domain Administrator

privileges

Depends on the external

Tool but should provide

this functionality

of 271


Security Feature or

Requirement

WinCC OA user

authentication

Operating system

based user

authentication

User defined

authentication with a

3rd party tool

Usage of SSO Not possible Optional configurable

but mandatory if

Kerberos security is

active in WinCC OA.

Not possible, at least

own OS user

authentication required

Combination with

hardware related login

mechanism (fingerprint,

smartcard, …)

Not existing Login to WinCC OA with

SSO activated

Depends on the

authentication tool

Effort in creating users

and groups


and groups on WinCC

OA level

Effort in creating OS

users and assignment to

a group with WinCC OA

related permission.

Additional effort in

assignment of

permission bits in

WinCC OA to imported

groups from OS


and maybe permissions

inside the ext. auth. tool.

No additional effort in

WinCC OA necessary.

Conform to

IEC62443 4-2 and

IEC62443 3-3

requirements

Not conform Conform if configured

on OS level

Conform if requirements

regarding user

authentication are

supported by the

system.

Notification of failed

login procedures

Only as entry in local

text-based log file but no

automated mechanism

exists to handle this

event.

Configurable on OS

level (Group policy for

Windows) with option to

lock the affected user.

Depends on the

authentication tool

Support of password

expiration

Not existing Configurable on OS

level (Group policy for

Windows)

Depends on the

authentication tool

Storage of password

hash

Encrypted password

hash stored on _Users

Datapoint.

Secure password

storage by the OS. No

valid password hash will

be transmitted to an UI

client.

Password storage by

the authentication tool.

The security level

depends on the tool. No

valid password hash will

be transmitted to an UI

client.

Table 11 - Compare methods of user authentication

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.

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.

of 271


Figure 62- Central user administration with Domain Controller and different permissions

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

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

Figure 63 - System authorization panel to set permission bit 3

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.

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.

WinCC OA (Service application with

LDAP, Winbind, ...)

Configuration file (etc/pam.d)

PAM Library

Low level modules (pam_unix)

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

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.

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)

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.

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.

https://jscrambler.com/

https://code.tutsplus.com/articles/client-side-security-best-practices--net-35677

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.

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.

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)

https://www.bleepingcomputer.com/news/security/hacker-steals-military-docs-because-someone-didn-t-change-a-default-ftp-password/

https://www.bleepingcomputer.com/news/security/hacker-steals-military-docs-because-someone-didn-t-change-a-default-ftp-password/

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

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.

0

50000

100000

150000

200000

250000

5 6 7 8

amo

un

t o

f co

mb

inat

ion

s in

Mio

.

Password length

impact of Password length

increase of combinations

Figure 67 - Increasing Password length with fixed Alphabet size of 26

0

20

40

60

80

100

120

10 20 30 40

amo

un

t o

f co

mb

inat

ion

s in

Mio

.

size of Alphabet

impact of Alphabet size

increase of combinations

Figure 68 – Increasing Alphabet size with fixed Password length of 5

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

https://www.digitalocean.com/community/tutorials/how-to-set-password-policy-on-a-centos-6-vps

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.

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)

https://www.allianz-fuer-cybersicherheit.de/ACS/DE/_/downloads/BSI-CS_074E.pdf?__blob=publicationFile&v=2

https://www.allianz-fuer-cybersicherheit.de/ACS/DE/_/downloads/BSI-CS_074E.pdf?__blob=publicationFile&v=2

https://www.allianz-fuer-cybersicherheit.de/ACS/DE/_/downloads/BSI-CS_109.pdf?__blob=publicationFile&v=8

https://www.allianz-fuer-cybersicherheit.de/ACS/DE/_/downloads/BSI-CS_109.pdf?__blob=publicationFile&v=8

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)

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.

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!

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

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.

of 271


Figure 69 - Single Sign On

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

of 271


Figure 70 – Compare SSA login process with WinCC OA default mechanism

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.

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/"

https://pentestsrv01/

https://pentestsrv01/

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 certif icate for

WinCC OA multiplexing proxy is used:

https://pentestweb/

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

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.

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.

https://docs.microsoft.com/en-us/windows/desktop/seccertenroll/cryptoapi-cryptographic-service-providers

of 271


Figure 73 - Windows certificate Store with SSA certificates for Manager

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)

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.

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.

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

host

Administered Client

host in plant network

Administered Client

host in public network

Public WLAN host

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

Operator APP

N/A Not secure (WLAN)1 Not secure (WLAN)2 Not secure (WLAN)3

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.

2 Mobile devices are designed for a WLAN environment. This field refers to an unsecured public WLAN environment

with an administrated client.

3 Mobile devices are designed for a WLAN environment. This field refers to an unsecured public WLAN environment

with a non-administrated client.

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)

http://wixtoolset.org/

http://www.commonexploits.com/unquoted-service-paths/

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

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.

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.

https://www.axis.com/

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

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.

https://www.cvedetails.com/vulnerability-list/vendor_id-16327/product_id-36994/Opencv-Opencv.html

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.

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

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.

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

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.

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

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.

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

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.


https://www.siemens.com/global/en/home/products/services/cert.html

http://www.siemens.com/industrialsecurity

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

https://support.microsoft.com/en-us/kb/824684

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.

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.

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)

https://wiki.centos.org/HowTos/CreateLocalMirror

https://www.suse.com/documentation/slms1/book_slms/data/cha_updates.html

https://linuxaria.com/howto/enabling-automatic-updates-in-centos-7-and-rhel-7

https://wiki.debian.org/UnattendedUpgrades

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.

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.

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

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)

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.

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)

https://en.wikipedia.org/wiki/Intrusion_detection_system

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

https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers

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.

http://www.istqb.org/certification-path-root/advanced-security-tester.html

https://www.owasp.org/index.php/Testing_Guide_Introduction

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!

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.

https://www.tenable.com/products/nessus/nessus-professional

http://www.openvas.org/index.html

https://wiki.ct.siemens.de/display/SiESTA/SiESTA+Home

https://new.siemens.com/global/en/company/stories/research-technologies/a-swiss-army-knife-for-digital-security.html

https://new.siemens.com/global/en/company/stories/research-technologies/a-swiss-army-knife-for-digital-security.html

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

of 271


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.

Sunday Full Backup

Monday Incremental Backup

Tuesday Incremental Backup

Wednesday Incremental Backup

Thursday Incremental Backup

Friday Incremental Backup

Saturday Incremental Backup

of 271


Figure 84 - Grandfather/Father/Son backup principle

Grandfather(monthly)

Father(weekly)

Son(daily)

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)

https://www.gartner.com/

of 271


This chart from July 2017 shows that the products

from Commvault, IBM, Dell EMC, Veritas

Technologies and Veen as leaders in the market

of backup and restore software. ETM professional

control GmbH recommends checking the actual

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

(acc.: 27th March 2019)). This standard gives a

good hand on concept to analyze and find the

correct software.

Even if IEC 9126 was already replaced by IEC

25000 the existing web pages give a good

overview how to assess software from a 3rd party

vendor.

Figure 86 - IEC 9126 Schema

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.

Maintanbility

Efficiency

Portability

Reliability

Functionality

Usability

https://en.wikipedia.org/wiki/ISO/IEC_9126

https://www.beuth.de/en/standard/iso-iec-25000/204260933

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.

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

Figure 87 - Online Backup

https://www.oracle.com/technetwork/database/database-appliance/documentation/dbappliancebackupstrategies-519664.pdf

https://www.oracle.com/technetwork/database/database-appliance/documentation/dbappliancebackupstrategies-519664.pdf

https://www.oracle.com/technetwork/database/features/311394-132335.pdf

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-

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 89 – Archives in Historical Archive

(HDB)

Figure 90 – Archive Groups in RDB

Archive


System management / Database / History DB (Database Configuration)

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.

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.

Figure 91 - Steps of VDI/VDE 2182

1. Identify assets

2. Analyze threats

3. determine relevant security

objectives

4. Analyse and assess risks

5. Identify measures and assess

effectiveness

6. Select countermeasures

7. Implements countermeasures

8. Perform process audits

https://www.vdi.de/uploads/tx_vdirili/pdf/1728597.pdf

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.

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

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

line

Defect

router

Hardware diversity Faults take long to be

eliminated

Remote Access Data Manipulation Hackers Security measures

at service provider

Unauthorized persons

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.


Avail

ab

ilit

y

Co

nfi

den

tialit

y

Inte

gri

ty

Remote Access Defect in data

transfer line

Defect

router

Hardware

diversity

Faults take long to be

eliminated X

Remote Access Data

Manipulation

Hackers Security

measures at

service

provider

unauthorized persons

acquire data X X X

Table 17 - VDI/VDE Example Step 3

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.

Figure 93 – Definition of exposure

Figure 94 – Define Likelihood matrix based on Exploitability and Exposure

Exposure Rating

Low Med High

Exp

loit

ab

ilit

y/S

imp

licit

y R

ati

ng

Low Very

unlikely Unlikely Possible

Med Unlikely Possible Likely

High Possible Likely Very

likely

Figure 95 – Define the risk level on site

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

Ex

po

su

re S

ca

le

2 High

• Easy logical or physical access for attacker, e.g.− internet access sufficient, or

− public physical access, or− attacker has access as part of daily work, operation, or maintenance

activities, or− product or components can be acquired by attacker with low effort

• Low risk to be discovered / convicted• No or little measures for unauthorized access detection and

investigation implemented

1 Medium

• Restricted logical or physical access for attacker, e.g. − internal network access required, or

− restricted physical access, or− product or components can be acquired by attacker with medium effort

• Medium risk to be discovered / convicted• Some measures for unauthorized access detection and investigation

implemented (e.g. surveillance, logging, monitoring)

0 Low

• Highly restricted logical or physical access for attacker, e.g.− highly restricted network and physical access, or

− product or components can not be acquired by attacker or only with higheffort

• High risk of being discovered / convicted• Good measures for unauthorized access detection and investigation

implemented (e.g. surveillance, protected log files,monitoring and alarming, limited no. of persons)

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

Ex

plo

ita

bilit

y/S

imp

lic

ity

Sc

ale

2 High• Successful attack is easy to perform, even for an unskilled attacker (little capabilities needed)• 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

1 Medium• Successful attack is feasible for an attacker with average hacking skills (medium capabilities needed)• Vulnerability is exploitable with medium effort, requiring special technology, domain or tool knowledge

• Some security measures to counter the threat

0 Low

• 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

system is required• Strong state of the art security measures to counter the threat

of 271


Risk

Risk Level Description

Major

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

implementation of countermeasures or acceptance by senior

management.

Significant

Risk must be treated with high priority in terms of definition and

implementation of countermeasures or acceptance by

product/solution/service owner.

Moderate

Risk must be treated with medium priority in terms of definition and

implementation of countermeasures or acceptance by

product/solution/service owner.

Minor

Risk can be treated optionally, however definition and implementation

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

Imp

act

Rati

ng

Negligible Minor Minor Minor Minor Moderate

Moderate Minor Moderate Moderate Moderate Significant

Critical Minor Moderate Moderate Significant Major

Disastrous Moderate Moderate Significant Major Major

Figure 97 - Definition of Security threat

of 271



Avail

ab

ilit

y

Co

nfi

den

tiality

Inte

gri

ty

Identified

Risk

Remote Access Defect

in data

transfer

line

Defect

router

Hardware

diversity

Faults take

long to be

eliminated X

Moderate

Remote Access Data

Manipul

ation

Hackers Security

measures at

service provider

Unauthorized

persons

acquire data

X X X

Major

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

of 271


6. Select countermeasures

After having the available number of countermeasures they will be put into the same table:

Asset

Thre

at

Cause

Vuln

era

bili

ty

Conseq

uence

Availa

bili

ty

Confide

ntialit

y

Inte

gri

ty

Identified R

isk

Counte

rme

asure

s

and c

osts

Remote

Access

Defect in

data

transfer

line

Defect

router

Hardware

diversity

Faults take

long to be

eliminated X

Modera

te

Reduce

Hardware

diversity –

2000€

Remote

Access

Data

Manipul

ation

Hackers Security

measures

at service

provider

Unauthorized

persons

acquire data X X X

Majo

r

Use VPN

connection –

200€ / month

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.

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)

https://support.kaspersky.com/us/11449

https://partedmagic.com/

https://dban.org/

https://www.recycling.com/hard-drive-shredder-destruction-service/

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.

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

security process in all following steps

Strategy of the Security Guideline

Defense in depth concept

Preparation and Installation

2. Install a domain environment Administration of Computers

3. Protect a new installed machine from any hostile

network traffic until OS system is hardened.

Newly installed machine

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

version

Branding of WinCC OA MSI

Installation

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®

or Linux distribution

Patch management and security

updates

14. Activate automated notification of patch

availability

Patch management and security

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

the project or plant

Disable DCOM

22. Harden DCOM Interface if legacy technology is

used (e.g. OPC DA).

Hardening DCOM for 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

encryptable driver via TLS

Create and deploy TLS certificates

26. Enable Secure Mode of Linux Enable SELinux

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

interactive sessions.

Automatic user logout in OS

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

visible

Observe audit logging and transmit

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

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

cells

Secure security cell link via IT

Infrastructure

Secure security cell link via WinCC

OA Proxy

44. Activate OS based secure communication

protocol

IPsec Bypass Technology

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

predetermined breaking point

46. Implement secure communication for unsecure

protocols

Secure communication for

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

developers

Secure coding standard for API

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

deploy it

Usage of TLS/SSL for plant

communication

Create own openSSL certificates

Create and deploy certificates

54. Consider Demo Configuration of TLS Demo configuration of TLS in

WinCC OA

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

Datapoints

Protection via authorization levels

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

processes

Start a WinCC OA project as a

service

66. Use an authentication mechanism outside of

WinCC OA

Usage of WinCC OA external

authentication method

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

mxProxy manager via Dist

Manager

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

managers

Server-Side Authentication for

Managers with session binding

71. Define SSO for OS or external Users in WinCC

OA

Automatic User Login

Single Sign On

72. Activate automatic user logout in WinCC OA

Level

Automatic user logout in WinCC

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

EWO

Secure implementation of

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

a sandbox to implement a specific security

concept

Usage of WinCC OA Access

Control Plug-In

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

of 271


Disaster Recovery (no WinCC OA DRS)

81. Implement Backup concept Implement Backup and Restore

concept

82. Define and document steps for restore

procedure

Restore procedure

Process

83. Implement and maintain cyclic risk assessment

process

Implement Risk assessment

process based on VDI/VDE 2182

Decommissioning

84. Secure Decommissioning during abandonment

stage

Decommissioning

Table 20 - Security Checklist

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.

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.

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)

https://en.wikipedia.org/wiki/Chain_of_trust

https://www.cisecurity.org/

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.

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.

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.

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.

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.

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.

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.

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.

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.

https://en.wikipedia.org/wiki/Microsoft_Windows

https://en.wikipedia.org/wiki/Microsoft

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

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.

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.

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.

https://en.wikipedia.org/wiki/SCADA

https://www.pmi.org/

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.

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

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

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.

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.

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

http://sharepoint.etm.at/rd/01/0002/Security/SecurityConcept/V3.16/3.16_FP2/SIMATIC_WinCC_OA_Security_Guideline_v316-FP2.docx#_Toc9854020



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

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


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



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


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

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/

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

WinCC OA 资料 - Security Guideline References 3...SIMATIC - WinCC Open Architecture3.16 FP2 (P009)...

Documents

Transcript of WinCC OA 资料 - Security Guideline References 3...SIMATIC - WinCC Open Architecture3.16 FP2 (P009)...