Preamble 1
Targets of the Security
Guideline 2
Security Guideline References 3
SIMATIC WinCC Open Architecture Definitions 4
3.16 FP2 (P009) Strategy of the Security
Guideline 5
Implementation of the Security Strategy for 6 Security Solutions
Security Checklist 7
Glossary 8
Lists 9
05/2019 Legal Information
Warning Concept
This manual contains notes that need to be considered, to heed the secure configuration of a plant and to prevent damage to property. The notes on security impacts are shown by a warning triangle in different colors or a warning light. Notes referring to a minor or an improbably security issue have no symbols.
The alerts and warnings are illustrated here in descending order of its level. DANGER
Means that death or severe security issues will occur, if the corresponding precautions are not taken.
WARNING
Means that death or severe security issues may occur, if the corresponding precautions are not taken.
CAUTION
With a warning triangle means that moderate security issues may occur, if the corresponding precautions are not taken.
ATTENTION
With a grey warning triangle means that an undesirable event or condition may occur if the corresponding note is not heeded.
CAUTION
Without a warning triangle means that damage to property may occur, if the corresponding precautions are not taken.
With the occurrence of multiple hazardous levels, the warning for the highest level is used. If a caution with the warning triangle warns of personal injury, it may also have a warning of damage to property.
ETM professional control GmbH | A Siemens Company 05/2019 Copyright © ETM professional control GmbH | A Siemens Company A Siemens Company Marktstraße 3 A-7000 Eisenstadt subject to alterations
7000 Eisenstadt
AUSTRIA
Qualified Staff
The product/system associated with this documentation should be handled only by personnel qualified for the task. They should handle the tasks assigned to them and paying attention to the associated documentation, like this document. Qualified persons, based on their training and experience, can detect risks and avoid possible hazards when handling these products/systems.
Proper Use of ETM professional control GmbH products
Please take note of the following:
WARNING
ETM professional control GmbH products should be used only for the application areas foreseen in the associated technical documentation. If third party products and components are used, they must be recommended and/or approved by ETM professional control GmbH. The fault-free and secure operation of the products assumes proper transport and storage, assembly, installation, commissioning, operation and maintenance. The permissible ambient conditions must be followed. Notes (Instructions) in the associated documentation must be seen and followed.
Brands
All names and designations marked with the registered trademark ® are registered brands of the Siemens AG or affiliated companies like e.g. ETM professional control GmbH. The use of the registered brands by a third party for their own purposes may infringe the rights of the owner.
Disclaimer
We have checked the contents of the documentation to ensure that they match the hardware and software described. Nevertheless, deviations cannot be entirely excluded, and we cannot, therefore, guarantee complete agreement. The information in this documentation is, however, reviewed regularly and any corrections necessary are incorporated in later editions. Information about the current version can be found in the page footer.
Page 3 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
Table of Content
1 PREAMBLE ...... 7
SCOPE ...... 7 INTENTION OF THIS DOCUMENT ...... 7 DISCLAIMER ...... 8 1.3.1 License ...... 8 STRUCTURE AND ORGANIZATION OF THIS DOCUMENT ...... 10 REQUIRED KNOWLEDGE...... 10 1.5.1 Training center ...... 11 PRODUCTS USED ...... 11 ABBREVIATIONS ...... 13 2 TARGETS OF THE SECURITY GUIDELINE ...... 16 3 REFERENCES ...... 17
IEC 62443/ISA99 ...... 17 OTHER STANDARDS AND RULES ...... 21 OPERATIONAL GUIDELINES FOR INDUSTRIAL SECURITY ...... 22 4 DEFINITIONS ...... 23
NAMING SCHEME IN FIGURES AND EXAMPLES ...... 23 NAMES OF THE NETWORKS IN THE “SECURITY GUIDELINE WINCC OPEN ARCHITECTURE" ...... 24 5 STRATEGY OF THE SECURITY GUIDELINE ...... 25
SECURITY MANAGEMENT PROCESS ...... 26 DEFENSE IN DEPTH ...... 29 5.2.1 Defense in Depth concept ...... 30 5.2.2 Layers of protection ...... 31 5.2.3 Implement Defense in Depth for different Types of Access ...... 34 DIVISION IN SECURITY CELLS ...... 37 5.3.1 Process cells and security cells ...... 37 TASK-RELATED OPERATION AND ACCESS RIGHTS ...... 39 TASK-BASED GROUPING, CENTRAL ADMINISTRATION AND LOCAL CONFIGURATION ...... 44 5.5.1 Requirements ...... 44 5.5.2 Tasks ...... 44 5.5.3 Workstation authorization in WinCC OA ...... 45 USAGE OF ENCRYPTED COMMUNICATION PROTOCOLS ...... 46 5.6.1 Usage of TLS protocol ...... 46 5.6.2 Usage of Kerberos...... 51 6 IMPLEMENTATION OF THE SECURITY STRATEGY FOR SECURITY SOLUTIONS ...... 53
SECURITY CELLS AND NETWORK ARCHITECTURE ...... 55 6.1.1 Definition of the Access Points to the Security Cells ...... 55 6.1.2 Newly installed machine ...... 56 6.1.3 Highly Secure Large System ...... 56 6.1.4 Secure small system ...... 61
Page 4 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
6.1.5 Secure security cell link via IT Infrastructure ...... 63 6.1.6 Secure security cell link via WinCC OA Proxy ...... 66 6.1.7 Secure network cell from power issues ...... 67 6.1.8 Secure Access Techniques ...... 68 HARDENING ...... 77 6.2.1 Hardening IT-Infrastructure ...... 77 6.2.2 Hardening WinCC OA ...... 101 ADMINISTRATION AND CONFIGURATION OF OS ...... 163 6.3.1 Administration of Computers ...... 163 6.3.2 Administration of networks and network services ...... 168 6.3.3 Configuration settings for all mobile devices ...... 169 6.3.4 Automatic user logout in OS...... 170 ADMINISTRATION AND CONFIGURATION OF WINCC OA ...... 171 6.4.1 Administration of Role-Based user authorizations ...... 171 6.4.2 Automatic User Login ...... 172 6.4.3 Automatic User Logout in WinCC OA ...... 173 6.4.4 Administering user rights ...... 173 6.4.5 Single Sign On ...... 174 6.4.6 Server-side Authentication ...... 176 6.4.7 WinCC OA Server Configuration ...... 186 6.4.8 WinCC OA User Interface Configuration...... 187 6.4.9 Branding of WinCC OA MSI Installation ...... 189 6.4.10 Configuration Settings for WinCC OA Video (vimaccOA) ...... 190 6.4.11 Example configuration of TLS in WinCC OA ...... 195 PATCH MANAGEMENT AND SECURITY UPDATES ...... 202 6.5.1 Patches and Security Updates ...... 203 6.5.2 Use of the patch management ...... 203 VIRUS SCANNER ...... 208 6.6.1 Use of virus scanners ...... 208 6.6.2 Principle architecture of a virus scanner ...... 209 LOGGING, AUDIT, MAINTENANCE AND ASSET MANAGEMENT ...... 212 6.7.1 Observe audit logging and transmit information to WinCC OA ...... 212 6.7.2 Implement Intrusion detection system ...... 213 SECURITY TESTS ...... 215 6.8.1 Knowledge of Security Testing ...... 215 6.8.2 Blackbox scan ...... 215 6.8.3 Whitebox scan ...... 216 6.8.4 Penetration tests ...... 216 6.8.5 Vulnerability Scanning ...... 217 IMPLEMENT BACKUP AND RESTORE CONCEPT ...... 218 6.9.1 General Information ...... 218 6.9.2 OS related backup ...... 218 6.9.3 Network equipment backup ...... 222 6.9.4 DB-Server (Oracle) backup ...... 223 6.9.5 WinCC OA related backup ...... 223 6.9.6 External Data Storage ...... 225
Page 5 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
6.9.7 Restore procedure ...... 225 IMPLEMENT RISK ASSESSMENT PROCESS BASED ON VDI/VDE 2182 ...... 226 6.10.1 Definition of Risk assessment process ...... 226 6.10.2 Example for VDI/VDE 2182 integration ...... 228 SYSTEM DECOMMISSIONING ...... 234 7 SECURITY CHECKLIST...... 236 8 GLOSSARY...... 243 9 LISTS ...... 264
TABLE OF FIGURES ...... 264 LIST OF TABLES ...... 269 LIST OF CITATIONS ...... 270
Page 6 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
1 Preamble
Scope This „SIMATIC WinCC Open Architecture Security Guideline” is valid for WinCC Open Architecture 3.16 FP2 (P009) and newer for the usage of process control systems. This version stays valid until recalled. For older versions of WinCC OA the corresponding security guidelines are valid.
The "WinCC Open Architecture Security Guideline" merely has the character of recommendations and is meant to support SIMATIC WinCC OA customers in secure operations of their production systems. The recommendations are based on state-of-the-art technology, current standards and the characteristics of the products used.
Due to the continuously advancing threat level, a hundred percent/complete permanent protection cannot be guaranteed even in case of full implementation. A regular validation of the implemented measures within the scope of the security guideline is recommended.
Registered Brands
SIMATIC WinCC Open Architecture is a registered brand name of ETM professional control GmbH, a subsidiary of Siemens AG. The use of product names and designations in this documentation by a third party for their own purposes may infringe the right of the registered brands owner.
Copyright© ETM professional control GmbH | A Siemens Company 2019 All Rights Reserved Marktstraße 3 7000 Eisenstadt Austria
Intention of this document This guideline serves as a supporting document for design, implementation and maintenance of a State-of-the-Art SCADA system at customer’s site. It is necessary to cover as many of the security goals expected by the customer. This guideline is intended to provide ideas on available security concepts that customer-side security concept may follow to achieve the targeted goals.
The proposed parameters for WinCC OA and settings for the operating system are derived from the knowledge and experiences made at Siemens AG and ETM professional control GmbH but must be adapted to match the requirements of the plant.
Page 7 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
Disclaimer
1.3.1 License “The following notes and conditions shall apply for Software provided by Siemens by installing on your system, by filing a copy on your system during the installation or by making available the Software in any other way. Please note: This Software is protected under German and/or foreign copyright laws and provisions in international treaties. Unauthorized reproduction and distribution of this Software or parts of it is liable to prosecution. It will be prosecuted according to criminal as well as civil law and may result in severe punishment and/or damage claims. Please read all license provisions applicable to this Software before installing and/or using this Software. You will find them after this note. If you received this Software as "Trial-Version" this Software may only be used for test and validation purposes according to the provisions of this Trial License stated after this note. TO USE THE SOFTWARE IN PRODUCTION PROCESSES IS NOT ALLOWED. BECAUSE IT IS A TRIAL VERSION WE CANNOT EXCLUDE THAT EXISTING DATA WILL BE MODIFIED OR OVERWRITTEN OR WILL GET LOST. THEREFORE, WE WILL NOT BE LIABLE FOR ANY DAMAGES RESULTING FROM THIS INSTALLATION OR FROM IGNORING THIS LEGAL NOTICE AND/OR FOR LOSS OF DATA. ANY OTHER TYPE OF USAGE OF THIS SOFTWARE IS ONLY ADMISSIBLE IF YOU HAVE A VALID LICENSE FROM US. IF YOU DO NOT HAVE A VALID LICENSE (WHICH HAS TO BE ESTABLISHED BY SUBMITTING A CORRESPONDING CERTIFICATE OF LICENSE, YOU HAVE TO INTERRUPT THE INSTALLATION PROCESS IMMEDIATELY. DON’T USE THE INSTALLED SIEMENS SOFTWARE AND CONTACT OUR NEAREST OFFICE TO AVOID ANY DAMAGE CLAIMS. Security information Siemens provides products and solutions with industrial security functions that support the secure operation of plants, systems, machines and networks. In order to protect plants, systems, machines and networks against cyber threats, it is necessary to implement - and continuously maintain - a holistic, state-of-the-art industrial security concept. Siemens’ products and solutions constitute one element of such a concept. Customers are responsible for preventing unauthorized access to their plants, systems, machines and networks. Such systems, machines and components should only be connected to an enterprise network or the internet if and to the extent such a connection is necessary and only when appropriate security measures (e.g. firewalls and/or network segmentation) are in place. For additional information on industrial security measures that may be implemented, please visit https://www.siemens.com/industrialsecurity. Siemens’ products and solutions undergo continuous development to make them more secure. Siemens strongly recommends that product updates are applied as soon as they are available and that the latest product versions are used. Use of product versions that are no longer supported, and failure to apply the latest updates may increase customer’s exposure to cyber threats. To stay informed about product updates, subscribe to the Siemens Industrial Security RSS Feed under https://www.siemens.com/industrialsecurity. General License Conditions for Software Products for Automation and Drives (Status: January 31, 2019)” Siemens Setup Information with integrated Security Disclaimer V5.2 (Siemens, 2019)
Page 8 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
Note:
To stay informed about WinCC OA product updates and security notifications such as detected security holes and recommendations, sign up for our product-specific ETM-Newsletter. More information is available under: http://www.etm.at/index_e.asp?id=16&sb1=&sb2=&sb3=&sname=&sid=&seite_id=151 (acc.: 27th March 2019)
Page 9 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
Structure and organization of this document The "WinCC Open Architecture Security Guideline" has various requirements and recommendations and consists of multiple parts: This document is the base document. It describes the general basic principles for a site-specific adjusted security concept and the various approaches for possible solutions.
The document is structured as followed:
• Chapters 1-4: Information necessary to understand the security guideline • Chapter 5: The security strategies and their basic principles • Chapter 6: The implementation of the security strategies for security solutions • Chapter 7: Security Checklist • Chapter 8: Glossary of the document-specific terminology • Chapter 9: List of figures and references Further information about the "WinCC Open Architecture Security Guideline" can be found in the download section of the SIMATIC WinCC Open Architecture Portal at: https://www.winccoa.com/. ETM professional control GmbH suggests registering there to get the latest news for WinCC Open Architecture. The target audience of this document are people responsible for designing, developing, installing and supplying services for automation systems based on the SCADA software WinCC Open Architecture developed by ETM professional control GmbH. This document can be used as an overview for decision-makers or as a basic introduction to the topic.
WinCC OA Documentation reference
This symbol refers to more information in the WinCC OA Documentation. The description points to the specific information. Further details or configuration suggestions can also be provided by WinCC OA Documentation.
Required knowledge
The following knowledge is assumed for understanding and implementing the concepts introduced in this document:
• Advanced knowledge about WinCC Open Architecture • Advanced knowledge about the project to be protected.
• Administration of IT technologies known for the office environment • Configuration of the PLC hardware in use for communication via specific drivers (S7, IEC, Modbus…)
• Configuration of used third party products.
Page 10 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
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®).
WinCC OA Documentation reference
Installation / Requirements for WinCC OA Installation / Requirements for WinCC OA / Software requirements
Updates for operating systems are in the responsibility of the OS producers. Please get more information from the producers’ Website.
ATTENTION
For using WinCC Open Architecture on a Windows operating system the following information must be considered: When WinCC Open Architecture runs on a Microsoft® Windows operating system, Microsoft handles updates of the operating system. ETM professional control GmbH will not explicitly test any Windows patches or give any recommendation for the usage of those patches. For information on the updates of the operating system see: https://technet.microsoft.com/en-us/security (acc.: 27th March 2019) https://technet.microsoft.com/en-us/security/bulletin/dn602597 (acc.: 27th March 2019)
Administration rights may be needed for the WinCC Open Architecture installation and for creating WinCC Open Architecture project instances, depending on the rights that were set for the folder structure.
Page 11 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
Note:
The TCP/IP protocol must be installed on the platforms since the WinCC Open Architecture processes communicate through TCP. Either TCP/IP v4 or v6 can be set active. Both protocols should never be set active simultaneously. When both protocols are used simultaneously, the faultless communication between the WinCC Open Architecture systems cannot be guaranteed. ETM professional control GmbH recommends restricting the communication within the plant to TCP/IP v4 and deactivating v6 to avoid issues caused by incompatibilities.
Page 12 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
Abbreviations
Abbreviation Explanation ACC Access on – This is the date when an external Web reference was accessed ACL Access Control List AD Active Directory AES Alert & Event Screen of WinCC OA AS Authentication Server BCC Backup Control Center (2nd node for WinCC OA DRS System) BSI Bundesamt für Sicherheit in der Informationstechnik (Federal Office for Information Security [Germany]) CA Certification Authority CBC Cipher Block Chaining Mode CIS Center for Internet Security COM Component Object Model CRL Certificate Revocation List CSN Control Systems Network CSP Cryptographic Service Provider CTK Crypto Token CTRL Control Scripting Language DATA WinCC OA Data-Manager DC Domain Controller DCN Distributed Computer Network DCOM Distributed Component Object Model DCS Distributed Control System DDoS Distributed Denial of Service DIST DISTributed system, DISTribution-Manager (DIST-System, Dist Manager) DMZ Demilitarized Zone DoS Denial of Service DP Datapoint DPE Datapoint Element DPL Datapoint List, typical usage as file extension e.g. export.dpl or dpl-file DPT Datapoint Type
Page 13 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
Abbreviation Explanation DRS WinCC OA Disaster Recovery System feature, not a disaster recovery concept ECDHE Elliptic-curve Diffie–Hellman protocol ECN Enterprise Control Network ERP Enterprise Resource Planning ETM Company name of ETM professional control GmbH EVENT WinCC OA EVENT-Manager FR (IEC) Foundational Requirement GEDI Graphical EDItor of WinCC OA HDB History Database Manager of WinCC OA IACS Industrial Automation and Control Systems ICS Industrial Control System IEFT The Internet Engineering Task Force IPC Inter-Process-Communication ISA International Society of Automation ISO International Organization for Standardization KDC Key Distribution Center LDAP Lightweight Directory Access Protocol MAC Message Authentication Code MCC Master Control Center (2nd node for WinCC OA DRS System) MCS Manufacturing Control Systems MES Manufacturing Execution Systems MQTT Message Queue Telemetry Transport MMC Microsoft Management Console MXPROXY WinCC OA Multiplexing Proxy NSA US National Security Agency NTLM NT LAN Manager ODA Oracle Database Appliance OS Operating System PARA PARAmeterization Tool of WinCC OA (Data model configuration tool) PAM Pluggable Authentication Modules PCN Process Control Network PLC Programmable Logic Controller
Page 14 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
Abbreviation Explanation PMON Process Monitor of WinCC OA RAIMA Configuration Database of WinCC OA with last values and alerts (also historical) RDB Relational Database Manager of WinCC OA REDU Redundancy (e.g. REDU-Manager) RSA Rivest–Shamir–Adelman cryptosystem RPC Remote Procedure Call SAN Storage Area Network SCCM System Center Configuration Manager SELinux Security-Enhanced Linux SiESTA Siemens Extensible Security Testing Appliance SL Security Level based on IEC 62443 SR (IEC) System Requirement SSA Server-side Authentication SSL Secure Socket Layer SSO Single Sign On TGS Ticket Granting Service TGT Ticket Granting Ticket TLS Transport Layer Security ULC UX WinCC OA Ultralight Client – User Experience UI User Interface UUID Universally Unique Identifier VA WinCC OA database to store historical data for HDB VCI VIMACC Control Interface VMS Video Management System WinCC OA SIMATIC WinCC Open Architecture WSS WebSocket Secure XML-RPC Extensible Markup Language Remote Procedure Call Table 1 - List of Abbreviations
Page 15 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
2 Targets of the Security Guideline
Maintaining the control over production and the processes in the application has the highest priority in automation. Even measures to prevent security threats must not affect this. The "Security Guideline WinCC Open Architecture" should ensure that only authenticated users execute authorized (permitted) operations on authenticated devices based on utilization features assigned to them. This solution should take place only via unique and planned access routes. This is to ensure secure production or coordination without hazards for human beings, environment, product, goods to be coordinated and the business of the organization during a task.
The "Security Guideline WinCC Open Architecture" recommends the use of security mechanisms available currently for this purpose. This means the system operator uses all available security mechanisms from Siemens AG, ETM professional control GmbH or third-party providers, to ensure the maximum possible level of security.
The configurations illustrated in this document may also be implemented and scaled with modifications. This depends on the level of protection needed by the system operator; the responsibilities present or security mechanisms that have already been implemented. However, this should be planned diligently and carefully by all technicians, specialists, administrators and others responsible in each case. To achieve the maximum level of security, the modified configurations should not contradict the basic principles of this security concept.
The “Security Guideline WinCC Open Architecture” should facilitate the cooperation and interaction between network administrators of organizations (IT administrators) and automation networks (automation engineers). Thus, the benefits of networking process control technology with data processing of the other production levels may be used without increasing the security risks on either side.
Note:
It must be taken into consideration that not all common and existing security concepts from vendor products of the IT environment can be implemented 1:1 in process automation. The focus of the IT lies in global accessibility coupled with the maximum possible level of security.
ATTENTION
Any deviations from the recommended security guideline for WinCC OA may cause security gaps with undesirable or adverse consequences. Ensure that the considered system is always updated in such a manner that no security gaps may occur. This document holds the security guideline for SIMATIC - WinCC Open Architecture 3.16 FP2 (P009). Please get in touch with your contact person at ETM professional control GmbH | A Siemens Company, regarding the related version of this security guideline if a document for a different WinCC OA version is needed.
Page 16 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
3 References
To ensure a long-time validity of this document and to allow the involvement of third-party manufacturers and their products in the security concepts, the following internationally approved standards and rules are considered:
IEC 62443/ISA99 ISA/IEC-62443 is a series of standards, technical reports, and related information that define procedures for implementing electronically secure Industrial Automation and Control Systems (IACS). This guidance applies to end-users (i.e. asset owner), system integrators, security practitioners, and control systems manufacturers responsible for manufacturing, designing, implementing, or managing IACS systems.
Figure 1 - IEC 62443 definition from 9th February 2018 (ISA99, kein Datum)
See also: http://en.wikipedia.org/wiki/Cyber_security_standards (acc.: 27th March 2019)
Page 17 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
This standard has 4 different parts:
• Part 1 (General) deals with general aspects and security standards. It defines a common basis in the form of terminology, concepts and models for the electronic security in the fields’ industrial automation and process control system. Following aspects are covered: o Terminology o Concepts o Models o Compliance metrics o Security Levels (SL): ▪ SL 1 - Protection against casual or coincidental violation ▪ SL 2 - Protection against intentional violation using simple means ▪ SL 3 - Protection against intentional violation using sophisticated means ▪ SL 4 - Protection against intentional violation using sophisticated means with extended resources
• Part 2 (Policies and Procedures) deals with implemented policies and procedures on site and must be considered by the asset owner (see document 2-1, 2-2 and 2-3). It supports the development of a program for the security of industrial automation and control systems. In addition, this part supplies detailed support related to process activities and key elements when developing a management system for the cyber security. The following aspects are covered by this norm: o Organization o Training / awareness o Continuity plan o Policies, procedures o Personnel security o Physical security o Network segmentation o Account administration o Authentication o Authorization o Risk management and implementation o Solution development and maintenance o Incident planning and response
Page 18 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
• 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. The following aspects are covered by this norm: 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. The following aspects are covered by this norm: o Product development process o PLCs o HMI devices o PC stations o Firewalls o Gateways o Switches o Functions o Applications o Data
Page 19 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
Industrial Automation and Control System (IACS)
Asset Owner 2-1 operates and maintains Operational policies and procedures 2-3 Service Provider 2-4 Maintenance policies and procedures +
Automation solution 2-4 System designs and deploys 3-2 Integrator Basic Process Safety Complementary Control System Instrumented Hardware and 3-3 (BPCS) System (SIS) Software IACS environment / project specific is the base for
develops control systems Control System Product as a combination of components 3-3 Supplier develops components 4-1 Embedded Network Host 4-2 devices components devices Applications
Independent of IACS environment Figure 2 - Responsibilities for asset owner, Integrator and Product supplier in IEC62443 (Kobes, 2016)
Reason and goal of an IEC 62443 implementation is to implement an overall concept which affects all stakeholders within a project. This is important because the overall protection is as weak as the weakest part. All parts of a chain of protections measure must be assessed by this norm because all stakeholders can create weaknesses along this protection chain. Therefore, an assessment of one single stakeholder is not enough to protect the system. Figure 3 - Weakest point in chain (Siemens, 2019)
Page 20 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
Other standards and rules The table below gives information regarding other Security standards that can be applied to an IT infrastructure by an asset owner or an Integrator.
ISO/IEC - International Organization for Standardization / International Electro technical Commission
ISO/IEC 11770 “Information technology -- Security techniques -- Key management”
ISO/IEC 15408 "Information technology - Security techniques - Evaluation criteria for IT security"
ISO/IEC 17799 "Code of practice for information security management""
ISO/IEC 27001 "Information security management systems – Requirements" as part of IEC62443
IEC 61643 “Low-voltage surge protective devices”
IEC 61663 “Lightning protection - Telecommunication lines”
NAMUR - International User Association of Automation Technology in Process Industries
NA 67 " Information protection for process control systems (PCS) "
NA 103 " Use of Internet technologies in process automation "
NA 115 " IT security for automation technology systems "
FDA - Food Drug Administration
FDA 21 CFR 11 " Electronic records and signatures "
Table 2 - Norms and Standards
Page 21 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
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 (acc.: 27th March 2019)
Page 22 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
4 Definitions This document follows internationally recognized expressions:
“shall”: Indicates a requirement
“should”: Indicates a recommendation
“may”: Is used to indicate that something is permitted
“can”: Is used to indicate that something is possible (e.g. an organization or individual can do something).
Naming scheme in figures and examples Names, terms and icons which are used in the figures and examples shall simplify the handling of this document.
Page 23 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
Names of the networks in the “Security Guideline WinCC Open Architecture" The following network names are used in this security concept and the illustrated figures. If there is no standardization available, the most common international network names are used in this security concept and the illustrated figures to satisfy the current requirements of a uniform naming scheme for the different networks.
The network names and the primary colors used (red, yellow, green) in the following figure show the networks depending on production level according to ISA-S95 as well as on security area according to ISA- S99. The automation level (MCS according to ISA-S95) is divided in further task-specific networks (green, blue, violet) in this security concept. This distinction is needed to consider the different requirements of bandwidth, availability, response times and climatic resistance.
ERP – Enterprise Resource Planning (Level)
ECN Enterprise Control (Systems) Network
MES – Manufacturing Execution Systems (Level)
MON Manufacturing Operations Network
MCS – Manufacturing Control Systems (Level)
PCN Process Control (Systems) Network
CSN Control Systems Network
FDN Field Device Network (Field Level)
Figure 4 - Automation levels (Siemens, 2019)
Page 24 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
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 (acc.: 27th March 2019)
A list of recommendations, on Security Management, is provided by specialized companies. This referred list has solutions about CIS vulnerabilities and is kept by the company Tenable. https://www.tenable.com/blog/cis-adapts-critical-security-controls-to-industrial-control-systems (acc.: 27th. March 2019). The following defense strategies serve as an overall approach to supplement the required and desired access types and operator control options with most available security mechanisms in a multi-level defense (Defense in Depth) with many security layers and serve as an overview for SIMATIC WinCC OA customers and are explained in detail.
Page 25 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
Security Management Process An implementation of a Security Management Process needs a holistic approach where different targets and ways needs to be considered.
• Security management is a significant part of any industrial security concept
• Definition of the security measures proper for the individual plant depending on found dangers and risks
• Reaching and keeping the necessary security level needs a continuous security management process
o Risk analysis with evaluation of current dangers and definition of counter measures to reduce the risk to an acceptable level
o Adjusted organizational / technical measures
o Regular / event-driven repeats
• Products, plants and processes must follow standards of care, based on laws, standards, internal guidelines and state of the art solutions.
The following defense strategies serve as an overall approach to supplement the required and desired access types and operator control options with most available security mechanisms in a multi-level defense (Defense in Depth) with numerous security layers and serve as an overview for WinCC OA customers and are explained in more detail.
Page 26 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
Target and strategy Security Guideline chapter
Comprehensive protection against security threats by access-based Defense in Depth.
Defense in Depth
Enhancing the availability and preventing the spread of security threats by division in task- oriented security cells.
Division in Security Cells
Preventing misuse by task-related control and access rights for the user, software components and devices.
Task-Related Operation and Access Rights
Response to future and current security threats by centralized group-based maintenance, service, update and distributed security of the products used with defined distribution paths.
Task-based grouping, central administration and local configuration
Encrypted and signed communication ensures that integrity and non-repudiation requirements are fulfilled. Usage of encrypted communication protocols
Table 3 - Strategy of IT Security
Page 27 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
A one-time implementation of security functionalities to achieve the targets from the table above is not enough. The implemented recommendations must be checked and maintained continuously to ensure an adequate protection. The following figure shows that implementation of security is a cyclic process. A detailed description of the involved steps is available in chapter: Implement Risk assessment process based on VDI/VDE 2182.
Figure 5 - Security Management Process (Siemens, 2019)
Individual security measures (e.g. IP security or VPN) may be used multiple times or meet different requirements simultaneously. These security measures are centrally described once and provided with notes on this central description along with the respective security solution.
The different security measures and strategies can either supplement themselves favorably or affect themselves unfavorably. In each case, it must be strived to achieve a reasonable balance between availability, security, comfort and performance. If one of the security solutions described has such a problem, attention is drawn towards this.
The main aim of the following description of the individual security strategies and their system implementation is to support the system planner and operator with the composition of the current security measures. In this manner, security measures in future can be supplemented efficiently and in a targeted manner.
Page 28 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
Defense in Depth Regarding WinCC OA, the IACS security competence covers three basic layers to support implementation of holistic “Defense in Depth”
Product Security: Defines the security mechanism implemented into a product itself. The company ETM professional control GmbH, as product supplier is responsible for the implemented features. WinCC OA operational Guidelines defines how an Integrator, Service Provider or asset owner should handle a product. In case of WinCC OA this information is provided by means of following list. o This Security Guideline document o WinCC OA Documentation o Different trainings offered by ETM professional control GmbH (e.g. CSW workshop) o White papers accessible via SIMATIC WinCC Open Architecture portal (https://www.winccoa.com/) o Consulting services Industrial IT Security Services supports an asset owner (and system integrator as a contractor of asset owner) in achievement and maintaining of a desired security level of an IACS in total. Different vendors offer services to achieve a desired security level. A possible vendor of Industrial IT Security Services is Siemens AG. The Siemens AG security services portfolio covers security audits, SOC services, vulnerability management services etc. More detailed information about Industrial Security from Siemens AG is available at the following page: https://new.siemens.com/global/en/company/topic-areas/future-of-manufacturing/industrial- security.html (acc. 01st February 2019). The following figure shows which layer needs to be covered for a defined responsibility. While Product Security and Operational Guidelines are covered by WinCC OA security competence, Industrial IT Security Services should be covered from a vendor company.
Industrial IT Asset Owner Security Services Service Provider
Operational System Integrator Guidelines
Product Security Product Supplier
Figure 6 - Basic layers of defense in depth according to responsibility
Page 29 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
5.2.1 Defense in Depth concept A typical Defense in Depth concept based on three different methods of protections and each method holds layers of protection.
1. Plant Security
o Physical Security
o Policies and procedures
2. Network security
o Security cells and DMZ
o Firewall and VPN
3. System Integrity
o System hardening
o User Account Management
o Patch Management
o Malware detection and prevention
Page 30 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
5.2.2 Layers of protection The figure below shows how a Core system is protected via different layer of protection. A typical attacker or a threat must defeat all existing layers until the Core system become vulnerable. This method ensures a good level of security even in cases when the attacker found a way to overcome a few layers of protection. This figure shows also how a potential threat may affect less likely the core of the system in dependency of the configured layers of security.
Figure 7 - Layers of protection
While planning the systems or system migration, a decision must be taken, based on the types of access needed. In cooperation with the asset owner following mechanism could by implemented for the described layers of security.
Page 31 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
1. Physical security a. Control physical access to various areas, buildings or individual rooms. b. Lock cabinets, devices and equipment like cables and wires.
2. Policies and Procedures a. Enforce usage of strong passwords b. Implement a Security Awareness concept on side c. Prepare a backup and restore concept to recover from a disaster (see chapter: Implement Backup and Restore concept). 3. Security Cells and DMZ a. A single access point for each security cell (should be a firewall system) for authenticating users, devices and applications used, for the directional access control and assignment of access authorizations and for detecting any hacking attempts. It acts as the main entry point to the network of a security cell and serves as the first point of control for access rights at the network level. b. Perimeter area techniques should be used. In this case, it means the use of exported data not serving the process control directly, which is available on one system (data storage, database). It is found between the main access point for the data entry (the so-called frontend firewall) and the deeply embedded access point for the data entry (the so-called backend firewall) or in the third network segment of a Three-Homed (found in three networks) firewall. 4. Firewall and VPN a. Firewall configuration means the protection by the local firewall against access from any location outside its own security cell. Additional it is necessary to configure all access points on the level of an Operation System (Microsoft® Windows , Linux) very carefully. As a result, all objects that can be reached via remote access such as files, registry entries and application (DCOM) are protected and all systems are restricted to the tasks to be executed by them, e.g. operating system in kiosk mode (see chapter: Secure Desktop – Kiosk Mode). b. Application layer filtering should be applied as standard technique, i.e. an access mechanism, in which every individual command can be checked at a high level. It can be checked with respect to access rights available as well as malicious or criminal intent (in most cases, realized in standard Webservers, published by the front-end firewall), where a possible failure of the access does not impair the process control. Scanning of incoming viruses means that all files and readable data, which are received on all systems, are scanned on the first system that allows access and allows reading the file/data.
Page 32 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
5. System hardening a. Disable all unused OS functionalities. This layer ensures that only the required OS functions are enabled. b. Certificate-based authenticated and encrypted communication should always be used when possible. This can be done using tunnel protocols such as PPTP (point-to-point tunneling protocol), L2TP (layer two tunneling protocol) or the IPsec (IP security) filtering. It can also be done via channels that are secured by server-based certificates, such as, for example: o RDP (Remote Desktop Protocol) o Windows server 2012/2016 terminal server published securely via HTTPS o Windows server 2012/2016 Webserver via the firewall using the TLS (transport layer security) technology. o Active Directory using Kerberos Tickets c. Certificate based manager communication in WinCC OA can be done by using the supplied WinCC OA proxy, whose communication is based on TLS protocol. WinCC OA uses openSSL for this layer, please consider WinCC OA Documentation or Readme files from actual WinCC OA patches about the required openSSL version (see chapter: Usage of TLS protocol). d. Usage of State-of-the-art encryption methods Additional it is recommended to use a tool with configurable block ciphers which allows increasing the encryption to a higher level if required.
In general it is recommended to use an actual block cipher like AES256, please mind that old ciphers like DES or 3DES are already deprecated and should not be used anymore. For recommended block ciphers, see Appendix chapter: Block Cipher.
It is not possible to recommend a specific authentication tool at this time but ETM customer support can help in such cases. e. Network administration has the choice of centralized, time-related and task-specific password guidelines as well as group-related access rights administration which are applied in WinCC OA and a standardized audit trail. Using an OS based user authentication would also be possible under Linux with Samba 4. However, the configurations which are used there cannot be applied to WinCC OA automatically. An implementation on site without an AD on Windows or on Linux via Samba 4 may be less secure compared to the given recommendation but depending on the desired requirements of the plant operator it might be enough. f. Need to connect. A project solution must only allow the connection of required devices or interfaces.
Page 33 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
6. User Account Management a. Operation authorization. The administration of these authorization levels within WinCC OA shall be done wherever this is necessary. This is the "last line of defense", also called "access control". It should be implemented or practiced by the Plant administrator and his operations personnel. Further restriction could be implemented by running a remote user interface on a workstation where every operation is limited to the WinCC OA application itself and the operator is not able to change the focus to a different application, this restriction is also known as Kiosk-Mode (see chapter: Secure Desktop – Kiosk Mode). b. Single Sign On (SSO). Secure authentication and one-time login can be used if possible. At this point an Active Directory (AD) system is mentioned as method of choice to inquire the user data from OS. In cases where Kerberos authentication is used, a Login via SSO is mandatory. Beside an AD environment it is also possible to use an external authentication tool instead of a complete AD environment. This tool could work on LDAP basis but for security reasons it is essential to select the tool wisely (see chapter: Single Sign On). Although SSO gives some level of comfort it does not work together with Server-side Authentication (SSA) (see chapter: Server-Side Authentication) 7. Patch Management a. Security updates (primarily equivalent to this technique or a part of this technique) means having the system security updates and virus signature updates available and installing them as soon as possible. To exclude any impairment of the processes running currently by the security updates, certain procedures must be kept in mind. These are described in the section: Patch management and security updates b. Automatic Updates should be implemented with prior careful analysis of possible risks.
8. Malware detection and prevention a. Anti-Virus Software needs to be configured on side b. Network specific intrusion detection and prevention systems needs to be configured
5.2.3 Implement Defense in Depth for different Types of Access From the point of view of the plant operator, it should be possible to have secure access to the components of the plant for the execution of regularly recurring tasks. The access is implemented by various components and mechanisms of the process control and visualization system. Therefore, the possible risks for unauthorized access are diverse. Subsequently, the access is classified more accurately from the customer's point of view as types of access.
The strategy of the Defense in Depth in this documentation is not a simple list of the security measures that can be used in process control technology such as, e.g. encoding, authentication, authorization etc. It is a description of the meaningful use of these security measures in different layers of protection, customized precisely to the types of access from the customer's point of view. Within this example, four different types of access where used: • Data exchange/Information exchange: Data and information exchange between different production levels, neighboring systems, onshore/offshore components, automation/security and cells.
• Real-time Controlling/Remote Controlling: The control or remote support of onshore to offshore or different systems or between the remote-control center and the system.
Page 34 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
• Maintenance: The normal monitoring and archiving of diagnostics information, data backups, updates or even the fine adjustment of configurations.
• Support: All Engineering activities, upgrades or modifications of the process control system, as well as error diagnostics and correction.
Types of Data Realtime Maintenance Support Access Exchange Controlling
Realtime Data
Layers physical protection
of single access points Protection perimeter zones perimeter zones perimeter zones perimeter zones
certificate based certificate based certificate based standardize authenticated authenticated authenticated application layer and encrypted and encrypted and encrypted filtering communication communication communication
secure secure secure secure Authentication Authentication Authentication Authentication and SSO and SSO and SSO and SSO
System hardening System hardening System hardening System hardening
Operator-Rights Operator-Rights Operator-Rights Administration Administration Administration
Figure 8 – Implementation of Defense in Depth concept for different Types of Access (Siemens, 2019)
Every access should take place only via clearly authenticated network devices and by authorized users. „Data Exchange“ and “Real-time Controlling“ in this overview represent the information-related connections of the Enterprise Resource Planning (ERP) systems for the business level, the Manufacturing
Page 35 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
Execution Systems (MES) for production planning and the Manufacturing Control Systems (MCS) for the automation level. “Maintenance” refers to the maintenance and service of the various systems. It includes regular security updates or the collection and evaluation of diagnostics and log files. “Support” stands for the remote access necessary to update, upgrade to fix errors and rectify faults in the systems used.
Moreover, there is a reference in the overview to an access type called "Real-time Data". This stands for a mixture of "Data Exchange" and "Real-time Controlling". In most cases, this mixed type of access results from the access technique used or it is the result of bundling of multiple tasks by the system operator. However, this mixed type of access should be avoided, since the security measures that can be used are very diverse and compromise solutions often are an enhanced level of risk.
Note:
User permissions should be limited to a minimum for the required type of access. Do not use administrator permissions if this is not necessary!
Page 36 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
Division in security cells
The strategy for dividing plants and connected plants into security cells increases the availability of the overall system, if failures or security threats that result in failure can thereby be restricted to the immediate vicinity. Because this strategy results in the setup of a modern and securely networked process automation plant, the planning of the security cells for this plant must be very thorough. The plant is first divided into process cells for this purpose and then into security cells based on the security measures.
5.3.1 Process cells and security cells Process cells are certain production-related areas, sections, sub-areas or sub-systems and they must meet the following conditions:
• A process cell must be an independent "functional system or sub-system", which can be run for a certain period without connection to the remaining systems or parts of the systems. In other words, a process cell must be and remain autonomously functional for a certain period.
• All associated elements of a process cell must be connected directly (e.g. not over leased lines). From the network point of view, it must be a LAN (Local Area Network).
• Parts of the system that could cause a high load on the network and processor, e.g. when they need to connect via complex security mechanisms from the outside, should necessarily be integrated directly in the process cell. One or more process cells become one security cell when the following conditions are met:
• Only trustworthy and authorized persons having proper training should get entry to a security cell. The following entries, among others, must be checked stringently: o Physical entry to the production areas and rooms of the process control system o Operation of the process control system and manual production sections o Access to the file system and configuration of the process control stations o Access to computer and controller networks, their power supplies and infrastructure (e.g. network services, domain controller)
• Any access to a security cell should take place only after checking the legitimacy. For this purpose, for example, persons and devices must be authenticated and authorized.
• Any access must be capable of being logged or must take place under supervision by authorized persons, e.g. entry of persons, file access, use of support etc.
• Devices that often must communicate with each other shall be placed within one security cell to avoid an impact caused by a slow bandwidth. A slow bandwidth could be caused by network limitations on site or it could be configured to reduce the overall network load (see chapter: Limitation of bandwidth between security cells).
Page 37 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
The planning of security cells is based on the actual areas of responsibility, the separable automation cells, the physical entry options and the network design and access protection implemented on this basis.
As a result, the operation of the individual security cells or segments is still ensured even in case of a temporary loss of parts of the infrastructure (e.g. network, displayed in red). For this purpose, information and services needed within the security cell, which are generated externally, must be saved intermediately or provided as a substitute (e.g. formulations and material data, network services such as name resolution, IP address assignment and user authentication). Suitable measures must be adopted for this purpose within the security cell.
Figure 9 – Splitting of Security Cells (Siemens, 2019)
Furthermore, in case of the occurrence of a security threat within a security cell (e.g. virus, displayed in red), the other cells or their members can be protected. Therefore, it is possible to continue running the entire system while the security threat is eliminated.
Figure 10 - Communication in Security Cells (Siemens, 2019)
Page 38 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
Task-Related Operation and Access Rights
The strategy of the task-related operation and access rights includes restricting the rights and functions of the user, system operator, devices, network and software components to the minimum needed.
To achieve effective protection without restricting the normal activities, it is necessary to coordinate the following aspects:
• Operation and access rights to the respective system and its area of protection • Purpose of use of individual devices and software components • Organization of the production and its areas of responsibility • Administration of the system • Tasks of the plant operator This means that the task-related operating and access rights are differentiated based on roles. This depends on the competence and area of responsibility of the respective operators or plant operator. The control within the different network types, thus, is defined in a far more structured and secure manner.
This coordination can be executed on basis of the production levels and the production process and is described in the following.
Note:
In smaller plants, the access is only divided in local or remote access and therefore no MES/ERP connection is used.
Securing a simple remote access is described in the section: Secure Access Techniques
The organization of the production process is based on three levels, ERP (Enterprise Resource Planning), MES (Manufacturing Execution Systems) and MCS (Manufacturing Control Systems). These are defined in the ISA-95.
Page 39 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
ERP – Enterprise Resource Planning
MES – Manufacturing Execution Systems
MCS – Manufacturing Control Systems
Figure 11 - Operation Levels (Siemens, 2019)
The areas of responsibility for resources (e.g. personnel, material and systems) within an organization are oriented at the production process. These areas of responsibility must be reflected in the assignment to the structures and system components respectively:
• Permission management of users and computers (e.g. by administration in domains) • Assignments of the plant operators (e.g. by the operator administration in the software of the process control systems)
• Software components (e.g. by local access rights of the software on the computer) • Devices • Networking (e.g. also the administration of the network and the network access)
Page 40 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
In general, there is already an administration for the IT infrastructure and the office computer. The administration of the production related computer systems must also take over the separate and specialized administration for the automation devices and process control systems (marked as "responsible MCS administrator"). The reason for this is that the responsibility for the entire production (MCS level) is up to the production manager and his personnel.
Figure 12 - Operation levels Personal production (Siemens, 2019)
To avoid security gaps, the exact demarcation of the areas of responsibility must also be done at the network and administration level. This must be done in coordination with the other production levels.
Page 41 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
Figure 13 - Operation levels production (Siemens, 2019)
To implement the areas of responsibility, the network structure and the technical options for controlling the network traffic of individual networks (illustrated by way of an example with firewalls and perimeter) must match these areas of responsibility.
The administration of the users and computers in the AD Domain or in a Samba 4 configuration on a Linux system must be adapted to these areas of responsibility. The next figure illustrates the connection via different types of trusted relationships between administrative domains (Microsoft® Windows ) for the office IT (ERP level) and the production IT (MCS level). In the figure, the production planning area (MES level) does not have its own IT administration. Instead, it is administered by the office IT and production IT areas respectively, depending on where the associated users and computers of an organization are usually found.
Page 42 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
Figure 14 - Operation levels Domain Production (Siemens, 2019)
The trusted relationships between the domains simplify the secure and mutual identification of users of the respective domain. The trustworthy users may get access to the domain at the other end. The responsibility for meaningful restriction of the process operation authorizations for individual operators needs to be defined by the plant operator (production manager). The settings are configured in the process control system or process visualization applications (in case of WinCC OA via the WinCC OA user administration).
Note:
With incorrect administrative rights for the plant operator at the operating system level, an unauthorized user can change settings. Each process control station, software part or network hardware should be able to execute only those tasks locally or in the network that are assigned to them by the manufacturer. This limitation reduces the possible potential of damage by a "security credential taken over" (e.g. password) for a user or a device. The example described above can only be implemented if there is an AD within a Microsoft® environment. If that is not the case, the trusted relationship cannot be set up as described.
ETM professional control GmbH does not supply any generally valid and usable alternative at this point.
Page 43 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
Task-based grouping, central administration and local configuration This section describes the administrative tasks for maintenance, service and update of a system, which must be planned and secured specifically because of its strategic significance. The requirements for carrying out the work of maintenance, service and update of a system are very similar with respect to the security solutions. The described information in this chapter is related to the operating system and third-party components.
5.5.1 Requirements • All tasks are implemented and administered respectively via a central storage location (e.g. backup server, Windows update service server etc.).
• All tasks must have distribution and security paths (e.g. network connection, unlocks at firewalls etc.) customized to the respective system.
• The grouping of systems with the same settings or purpose of use (e.g. in Windows software update service) reduces the incidence of errors in individual local configurations.
• Important parts of the system must be defined and grouped in such a manner that these groups can be processed independently of one another. This must also be possible without having to shut down plant operation completely. The following groups could be created, for example: o Grouping the WinCC OA servers to defined classes according to their purpose. o All WinCC OA UI clients in one “Client group “.
5.5.2 Tasks 1. Software updates: Planning and execution of the central distribution of software updates like security updates, hot fixes, installations, virus signature updates, upgrades, project updates, certificates etc. from one centralized storage location to the
individual components needed to be updated.
2. Software configuration: Planning and execution of the central configuration of systems such as operating system, virus scanner, Windows update etc. from one central configuration server to the individual systems needed to be configured.
3. Backup and restore: Planning and execution of the local and central backup of data, software applications, operating systems, firmware etc. on a central storage location and restoring the same.
4. Logging and diagnostics: Planning and execution of the centralized backup of local diagnostics, log files, logs etc. for centralized logging of the local events.
Deviations, if any, must be discussed and coordinated with the system operator. An example of this is the exclusive local storage of data/backup data, which, in case of data loss on the local storage locations can no longer supply the data needed.
Page 44 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
5.5.3 Workstation authorization in WinCC OA Workstation authorization may have all permission bits or only some specific bits. Thus, permission bits can be even further reduced. This means that an administrator user which has the permission bit 4 would not have this right on the workstation if it is revoked for this workstation.
Therefore, it is possible to realize that tasks which need the permission bit 4 can only be done via a special workstation (e.g. a locked-up office).
Page 45 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
Usage of encrypted communication protocols WinCC OA uses two different technologies for encrypted communication between distributed and remote parts of a project. 1. TLS communication 2. Kerberos communication
5.6.1 Usage of TLS protocol
5.6.1.1 TLS Basic communication In order of Stapleton and Epstein description of TLS/SSL is defined as follows:
“Secure Socket Layer (SSL) and Transport Layer Security (TLS) are cryptographic protocols designed to provide secure communications on the Internet. This protocol provided endpoint authentication and communication privacy over the Internet using cryptography. Both SSL and TLS provide for server and client side authentication. However, in typical use, usually just the server is authenticated (i.e., its identity is ensured), while the client remains unauthenticated. To provide for mutual authentication requires a PKI deployment of certificates to the clients. The protocol allows client/server applications to communicate in a way designed to prevent eavesdropping, message tampering, and message forgery.
Jointly developed by Netscape and Microsoft, SSL version 3.0 was released in 1996, which later served as a basis to develop Transport Layer Security (TLS), an IETF standard protocol.” (Stapleton & Epstein, 2016, S. 84)
Based on the OSI model TLS uses the layers Transport and Session for communication to the other host, in contrast to IPsec which uses the Network Layer.
Application Application
Presentation Presentation
TLS/SSL Session Session
TLS/SSL Transport Transport
IP Sec Network Network
Data Link Data Link
Physical Physical
Figure 15- Usage of TLS/SSL in OSI model between Client and Server
Page 46 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
TLS communication is based on an asynchronous mechanism to send a message between a sender and a receiver.
The secure dispatch of a message needs three methods, which must be used together:
1. Encryption: The content of a message must not be readable for an unauthorized user. 2. Signing: The message needs a digital signature to prove the identity of the sender. 3. Integrity: The receiver needs verification that the message was not altered.
5.6.1.1.1 Encryption Firstly, the receiver Alice shares her public key with the sender Bob. Next Bob encrypts the message based on this public key from Alice. The encrypted message is transmitted to the receiver Alice.
Finally, Alice receives the message from Bob and can decrypt the content with her private key. This key must be kept secret by user Alice. A theft of this Private Key could cause a threat, where the transmitted messages may be sniffed and decrypted by a malicious user.
Figure 16 - Public/Private Key encryption (Gilliam, 2018)
Page 47 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
5.6.1.1.2 Signing Signing of a message needs the private key of the sender. In this case Alice is signing her message with her private key before the transmission to Bob. Bob can ensure that his received message was send by Alice with Alice’s public key.
Figure 17 - Public/Private Key signature (Gilliam, 2018)
Page 48 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
5.6.1.1.3 Integrity with MAC To prevent a message from altered during the transmission, a hash function is needed. This function creates one-way cipher text which cannot be decrypted. The verification of an unaltered message is possible by usage of a Message-Authentication-Code (MAC). This MAC is added as last block to an encrypted message, with a Block-Cipher running in CBC mode.
The following picture shows how Alice adds a MAC to her message before Bob receives it. Firstly the received message is split by the algorithm running on Bob’s side into the original message and the transferred MAC. Next this algorithm uses the “Master-secret” key (see chapter: TLS Handshake) to generate an own MAC, based on the original message. Finally, verification is done, to ensure that Bob’s MAC is equal with the original MAC created by Alice.
Figure 18 - Usage of MAC Signature
Page 49 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
5.6.1.2 TLS Handshake WinCC OA uses the TLS-Handshake method to set up a protected stable communication between two different endpoints. During the TLS-Handshake procedure the encryption method is changed from an asymmetrical to a symmetrical one. The usage of a symmetric encryption increases the transfer performance between both hosts compared to an asymmetric encryption. Since a symmetric encryption requires a secret key known by both communicating parties, a generation of such a shared secret key and its distribution between both endpoints is also a part of the TLS-Handshake procedure. The figure below explains TLS-Handshake procedure in detail.
Figure 19 - TLS Handshake protocol (Zwodrei, 2015)
Page 50 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
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.
WinCC OA Documentation reference
Special functions / Kerberos Authentication
Following example shows how an authorized user can access a service from a WinCC OA server host. The AD controller holds the KEY Distribution Center (KDC) with Authentication Server (AS) and Ticket Granting Service (TGS).
Figure 20 - Kerberos Ticket granting service
Page 51 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
The Kerberos Ticket granting process works a follow:
1. User from client (Remote UI) wants to access a service from a WinCC OA server. In a first step the user sends a message (as_request) with login name and name of the requested service to AS (Authentication Server) in KDC (Key Distribution Center), to get a Ticket Granting Ticket (TGT). This ticket is required to request a service ticket for WinCC OA server. 2. AS from KDC sends encrypted TGT to WinCC OA user (as_reply). 3. User sends encrypted TGT to TGS in KDC to request an application ticket for WinCC OA server (tgs_request). 4. TGS sends encrypted session key with service ticket to access WinCC OA server, based on full service principal name (tgs_replay). 5. User sends encrypted service ticket with timestamp to WinCC OA Server (ap_request). 6. WinCC OA server accepts request and grants service for WinCC OA user (ap_replay). Interesting points in usage of Kerberos:
• Kerberos does not protect the installed software from altering. • All configured services (WinCC OA server) need to be configured in Active Directory and Service Principal Names (SPN) need to be configured.
• Kerberos must run always: A redundant concept must be implemented via IT infrastructure measurements to avoid a single point of failure.
• All passwords are encrypted with the same key (Kerberos master key). • Lifetime of a TGT is configurable; the default value is eight hours. A system could be vulnerable if a TGT is stolen during this period.
• AS needs physical protection. • Based on time stamp a system is considerably well protected against attacks. A dictionary attack needs a time less than five minutes to be successful. In general Kerberos and especially the Kerberos 5 implementation is a common network protection mechanism. This stands for the actual State of the Art in Security measurements. Kerberos is used in many systems that need a holistic security implementation.
Page 52 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
6 Implementation of the Security Strategy for
Security Solutions
Successful implementation of the security strategies for security solutions in automation plants realized with WinCC OA can be achieved only with the awareness of responsibility and cooperation of all those involved. This includes particularly:
• Manufacturer (development, system test and security test) • Project manager and integrator (planning, setup and factory acceptance test) • Operator (operation and administration) The strategies and their implementation must be checked and updated over the entire life cycle of a system and are described in this chapter, from the beginning of offer preparation, planning and design to migration and right up to disassembly of the system.
Security Cells and Network Architecture Hardening Administration and Configuration Patch Management and Security Updates Virus Scanner Logging, audit, maintenance and asset management Security Tests Backup and Restore concept Continuous Risk Management Decommissioning
Figure 21 - Phases in Security Strategy
The following aspects enable the security concept in automation plants described here to become effective: • The use of robust and system-tested products having a high degree of availability, a basic hardening (e.g. IP hardening) and predefined security settings.
• Customization that uses current techniques and standards facilitates system design adapted to the security needs.
• The effectiveness of the security solutions is achieved only with diligent and responsible operation of the systems and components. In addition, they must be used following the typical application specified by the manufacturer.
Page 53 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
The following table gives an overview of exemplary security solutions that are recommended here for the implementation of the security strategies mentioned above. These security solutions are counted in the following sections and dealt with in greater depth in the detailed documents (configuration of a Kerberos domain) respectively. They are aimed at supporting the system operator, aware of his responsibility, with discharging his tasks for improving the security of the automation plant.
Security Requirements Chapter in the Security Guideline
A plant shall be split into different Security Cells. Security Cells and Network Architecture
The surface for vulnerabilities shall be limited. Hardening
OS and WinCC OA shall be configured Administration and Configuration of OS according to recommendations. Administration and Configuration of WinCC OA
A plant shall regular get updates to close newly Patch management and security updates discovery security gaps.
A plant shall check incoming files for harmful Virus Scanner content.
A plant shall record security-related and Logging, audit, maintenance and asset process-specific data management
The implemented security level shall be checked Security Tests regularly for improvements.
A process to recover from a disaster shall be Implement Backup and Restore concept defined.
A continuous Risk assessment process shall be Implement Risk assessment process based on implemented. VDI/VDE 2182
A plan shall be decommissioned in a secure way System Decommissioning after end-of-life.
Table 4 - Security Solutions
Important for every security solution is the usage of highly available network periphery that is provided by various manufacturers. The corresponding manufacturers must clarify the reliability of the components. ETM professional control GmbH cannot give a binding statement to the compatibility between WinCC OA and the components of special manufacturers.
Siemens for example supplies components of the SCALANCE product family from SIMATIC NET. Detailed information on SIMATIC NET as network periphery can be found on the Siemens Website: http://w3.siemens.com/mcms/industrial-communication/en/scalance/Pages/default.aspx (acc.: 27h March 2019)
Page 54 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
Security Cells and Network Architecture
6.1.1 Definition of the Access Points to the Security Cells Network access points should
• Prevent the impermissible data traffic to the process control and visualization systems • Enable permitted data traffic and thus the normal operation of the process control and visualization systems Access points can be:
Protects the perimeter and enables access to web publications of the Front-end Firewall perimeter and remote dial-up options for the back-end firewall
Protects the production control network PCN and enables the primarily certificate-based, encoded and signed access to individual trustworthy Back-end Firewall remote stations and networks (e.g. MON of the manufacturing execution system, MES) and the remote and support access to the PCN.
Three homed- Combined front-end and back-end firewall with certain "Minimal Perimeters" Firewall for scalable security solutions
(Special Case) Offers access to a security cell exclusively for maintenance Access point-Firewall tasks, which otherwise, would not need any connection (e.g. to the MES).
Enables load decoupling with high throughput, usually in combination with an Back-Router upstream Three-Homed firewall
Table 5 - Firewall Overview
The design of the security cells and networks should also limit the scope of responsibility of the system operator precisely (e.g. with respect to the IT administrators of the ECN and office networks). This means that the system operator must clearly have the administrative rights and obligations in his security cell. It needs to be decided which security cells and network design should be implemented. This decision, in general, is influenced by the significance and size of a system, its spatial division, the risk obtained and the budget available.
CAUTION
It is essential to use and configure reliable network equipment (e.g. Switches) with hardened configuration to avoid negative impact caused by an attack. The documentations of the network equipment can give enough help to protect the network against DOS and other attacks to the network.
Page 55 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
The examples in the following paragraphs supply an overview about the implementation of a security level on site. Generally, the following criteria have been used for the choice and names of the sample plants:
• A plant is called "highly secure" if it has a high amount of possible number of security layers (e.g. the combination of front-end and back-end firewalls is more secure than a single firewall). This is because in case the front-end suffers from a hostile take-over, the production-related network is still protected by the back-end firewall.
• A plant is called "secure" if it has the basic security mechanisms (e.g. the perimeter technique of web publication instead of direct access to the Webserver).
• A plant is called "large" if it has its own infrastructure (e.g. domain controller) or it is connected to the information processing system of the organization.
• A plant is called "normal" (and thus, not given a special name) when it is configured as a classical multi-user DCS process control system (without special infrastructure) and holds only rudimentary connections or its own MES.
• A plant is called "small" if it is primarily a single-user or small multi-user system without connection to other systems or to the information processing system of the organization.
6.1.2 Newly installed machine A newly installed and not yet hardened Microsoft® Windows or Linux machine is vulnerable for attacks. An attacker could place any harmful tool on the machine without detection by the operator. The attacker could place sleeping processes on the machine and activate them during a later phase when the machine is in production and holds sensible information.
To avoid this situation, it is recommended to run a machine within an own Security cell until the OS is hardened with all available patches and prepared to run in an operative environment.
6.1.3 Highly Secure Large System The highly secure large system has its own perimeter and infrastructure, its own network services and administration, protected maintenance access, protected remote control, secure web publication and protected production planning connection.
The following figure gives a simple illustration of a possible sample for the structure of a large and highly secure production plant. This example shows only a possible solution and it does not show the mandatory configuration for secure systems.
Following areas are marked in color:
• The Process Control Network PCN (green network). • The Control System Network CSN (blue network).
• The upstream perimeter network belonging to the plant's scope of responsibility (orange network), protected by one front-end and one back-end firewall.
• The office and business network office LAN (red network) is secured by its own firewall All three production-related areas (marked in red, orange and light blue) are secure network systems, secured as security cells, and can work independently for a specific period. They have their own domain controller
Page 56 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
The web-based access from the ECN to a Webserver of the plant in the perimeter takes place via a web publication of the front-end firewall. The user activities can be checked and logged there via application filters. The process control system Webserver in the perimeter retrieves its data from the process control servers in the PCN via a certificate-based connection (TLS) through the back-end firewall. The back-end firewall checks whether this connection can be authenticated and set up mutually by both subscribers. This ensures a high-performance level and the security that only known and trustworthy systems from the perimeter get specific access via the back-end firewall to certain systems of the PCN.
The support and remote access may take place using multiple access types and paths. The access is authenticated, authorized and logged centrally in the back-end firewall. More information on this is given in the section Protected Maintenance Access.
Page 57 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
Figure 22 - Highly secure large system with WinCC OA DRS System
Page 58 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
Detailed System Description:
• The system operation is maintained by two redundant WinCC OA servers as a WinCC OA DRS system in the PCN. The PCN is separated into two different locations. Visualization is performed by two distributed clients who are also configured inside the PCN.
• Archiving of historical data in the database is done in an Oracle–RAC where the archived data is written to a SAN system. Data replication is configured via WinCC OA DRS System.
• Administration and authentication within the PCN via Active Directory using its own and independent PCN domain (production domain) with primary domain controller (PDC) and backup domain controller (BDC). Important network services are provided within the PCN, for example: o Name resolution (IP address, host) o Address allocation (IP address) o System clock synchronization (NTP, SNTP): In WinCC OA the data transmission uses time stamps. Depending on the time stamps logical decisions are made for the processing. Therefore, it must synchronize the system time on all clients, PLCs, RTUS and modules. The system time progress must be constant.
• Inside the perimeter network (PN) the application gateway is used for publishing the process control data. In this example following services are used o WinCC OA HTTP-Server (WinCC OA Webserver) with the complete process diagram for the visualization on the WinCC OA Desktop UI inside the Enterprise Control Network o WinCC OA OPC server for transmitting selected data (OPC items) to other OPC clients. o The virus scan server inside the PN o WSUS server to deploy Microsoft® Windows updates to receive updates from Microsoft® o Linux Mirror Server to receive CentOS® packages and make them deployable for all Clients on a CentOS® based platform. o SCCM Server to deploy updates within the system.
• Remote trustworthy clients and servers of the process control system (e.g. Webserver, MES server), without direct process data link, are integrated via encoded SSL/TLS communication in the PCN security cell. The authentication takes place mutually via certificates; the back-end firewall allows IPsec traffic that has been set up.
• Non-trustworthy devices in the ECN office network receive user-dependent access to web publications of the production system in the perimeter via the front-end firewall. The authentication takes place via an encoded connection on the server side with a username and password.
• Trustworthy users of the MES production planning area, who work in the ECN office network, may be granted access to data for selected applications via firewall client software of the front-end firewall. The use of these applications depends on whether the application can take over the function of the firewall client
• The access of the external support stations is performed over specific nodes inside the back and front firewall. The required ports for communications between the zones need to be configured on these firewalls.
Page 59 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
• SSA is activated in WinCC OA (see chapter: Server-Side authentication). The verification of user credentials is done by the WinCC OA Webserver. This Webserver needs to be part of the PCN domain or a trust to the PCN domain needs to be configured.
• The router for external access should only be activated if needed. This means if a remote controller should access the site the local available operator on site activates this access point. This helps to reduce the amount of access points to the plant or the project to a very small period.
• Network equipment (Routers, Switches) are hardened against DOS attacks. • Domain Controllers run in redundant mode to avoid a single point of failure scenario.
Page 60 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
6.1.4 Secure small system A secure small plant is a sample system of a security cell, which is connected to an external unprotected network via an access point firewall. However, all process control system functions are implemented within the security cell. This includes both multi-user systems and any number of WinCC OA single-user systems.
The following figure gives a simple illustration of the structure of a secure and small production plant with the following areas marked in color:
• The PCN (green network). • The CSN (blue network). • The entire security cell is protected by one access point firewall belonging to its own scope of responsibility.
• The office and business network, ECN (Enterprise Control Network: red network) secures itself optionally via its own firewall. This assumes that the access of non-trustworthy computers to the WAN/Intranet will not always be controllable.
• The WAN/Intranet stands here as an example of the organization's own network that is configured to allow remote access. The production-related area, that is the application area of the WinCC OA ULC UX / WinCC OA HTTP-Server, is secured as a security cell.
In general, the system structure of small security-relevant systems consists of multiple WinCC OA workstations with remote user interfaces and a WinCC OA server. Active authentication method is SSA (see chapter: Server-Side authentication)
Note:
Systems that are used exclusively within a security cell should not be connected to an external unprotected network unless there is a compulsive need to do so. The only exception is access for maintenance. The following is applicable, in principle: One or more single user systems with direct connection to the process operation should not be run in an unprotected network (that is, beyond a security cell). The reason for this is that in case of just one possible threat to the security, the process control is endangered (too few security layers).
The support and remote access for maintenance may take place via multiple access types and paths. However, it must always be authenticated and authorized for this security cell centrally at the added firewall (access point firewall).
Page 61 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
Enterprise Control Network
WinCC OA Firewall Support Station Office PC
WAN
WinCC OA Support Station
Firewall
Accesspoint
WinCC OA WinCC OA Desktop UI Client
Process Control Network
WinCC OA WinCC OA Server Webserver
Control System Network
S7-400H S7-400 S7-400 S7-400FH
Figure 23 - Secure small system
Page 62 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
6.1.5 Secure security cell link via IT Infrastructure The connections between mutually trusting security cells must be provided via encoded tunnel communication, for example, IPsec or SSL/VPN tunnel. These security mechanisms have no effect on the communication within the security cell. The communication that the security cell abandons is encoded and hence, limited in its performance.
ATTENTION
All tunnel mechanisms and firewalls are potential "predetermined breaking points" of the network.
If a DoS attack is recognized the firewall is put into a safe state resulting in a heavily reduced data transmission. All plant sections must be designed to be able to continue operation in case of a security cell failure.
Security cell links are implemented between the following components:
• At all access points (back-end firewall, Three-Homed firewall and access point firewall)
• At the security cell subscribers (local IPsec filter rules of the individual operating systems)
• At the security control devices (SIMATIC SCALANCE S, product series of the security modules)
Page 63 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
The following diagram illustrates two security cells protected by access point firewalls as an example (production sub-systems, plant1A and plant1B). They use a common MES part in the sub-system plant1A. Both firewalls allow established IPsec communication between the MES components and the stations of the process control system of the second sub-system, plant1B. The MES part and the process control stations involved have been configured for IPsec communication.
The communication is set up if one of the participating target IP addresses is addressed
Figure 24 - Secure security cell link
The figure shows a security cell link of the CSN implemented for "Industrial Ethernet" (WinCC OA S7 driver) with security modules.
Page 64 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
The communication between automation plants, developed particularly for industrial use, cannot be tunneled via a conventional IT firewall. The increased computing power of an end-to-end encoding of automation plants would lead to overall performance degradation. An IT firewall cannot protect this communication adequately, since there are no filter rules available for this purpose. The security modules especially developed for this purpose, hence, take over the task of protecting the communication. This enables protected data exchange between the automation and process control systems between the sub-systems, plant1A and plant1B.
Figure 25 - Secure security cell link with security tunnel
Page 65 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
6.1.6 Secure security cell link via WinCC OA Proxy Beside the common solution to set up a connection between security cells via IT Infrastructure it is also possible to design this in a logical way via WinCC OA mxProxy manager. It must be noted that this service supports only a connection between WinCC OA systems and has no direct effect to the selected network and will also not affect any external vendor software.
The provided example shows three different security cells realized by usage of the WinCC OA mxProxy. In this case the WinCC OA mxProxy runs on a dedicated machine inside from Security Cell one which is defined as Master Cell. Each other WinCC OA server runs without a WinCC OA mxProxy manager.
The two other security cells set up a connection to the dedicated machine (WinCC OA mxProxy) inside security cell one. This machine is also defined as predetermined breaking point. It is necessary that this host can establish a connection to the WinCC OA hosts running in security cell two and three.
An attack could result into a fail of the WinCC OA mxProxy machine which disables the communication between the security cells but keeps the internal communication active.
Figure 26 - Sample configuration for security cell connection via a single WinCC OA mxProxy
This figure above shows only a possible way to implement a security cell architecture based on WinCC OA mxProxy manger.
Page 66 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
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.
WinCC OA Documentation reference
Special functions / Security / Multiplexing Proxy / Configuration of Multiplexing Proxy
ATTENTION
There is no mandatory recommendation about the split of security cells provided by ETM professional control GmbH. Every implementation on site needs to fulfill special requirements from a security point of view. This means the security design for each site typically has a unique architecture.
Also consider chapter: “Usage of mxProxy and restriction of open ports and limitation of the IP access list” inside this document.
6.1.7 Secure network cell from power issues Beside the protection from a hacker, it is also recommended to protect the system from natural disasters, like lightning or power failures inside the internal network. Both scenarios could result in a situation where the SCADA system is partly or completely not available. This may result in bad and unforeseen side effects.
To protect the overall system from this negative impact it is recommended to protected electricity grid based on following standards:
• IEC 61643 - Low-voltage surge protective devices • IEC 61663 - Lightning protection - Telecommunication lines (Gerhard Ackermann, Robert Hönl, 2006)
Page 67 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
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 o Secure Web Publication
• 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 Web Publication o Secure integration of manufacturing control o Secure data exchange
Page 68 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
6.1.8.1 Secure Web Publication Web publication is one of the most modern and secure access techniques. In the process, the web pages of the Webserver to be published are protected from external attacks in the perimeter at the front-end firewall. The protection is possible by switching the identity. The name and IP address of the respective Webserver are thus not subjected to any direct access. The front-end firewall acts as the "authorized representative" of the Webserver. The network topology and IP addresses of the perimeter are not visible to the external network.
Webservers can be provided by various third-party suppliers, e.g. the Apache Webserver from the “Apache Software Foundation” or the Microsoft® Forefront Threat Management Gateway Server (TMG) server from Microsoft®. For these Webservers various security solutions, e.g. in combination with OpenVPN are available. Further details can be found on the homepages of the Webserver provider.
An example of a configuration with WinCC OA is given with the Hide secure network behind a Reverse Proxy chapter.
Page 69 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
6.1.8.1.1 WinCC OA HTTP-Server For quickly displaying plant data an integrated Webserver, which communicates via HTTPS and HTTP, is part of the software WinCC OA. The WinCC OA HTTP-Server is used to read and publish data. The responsible integrators must define individually which data is available over the intranet or internet. This service from WinCC OA can be activated using the httpServer CTRL function. With this function it is possible to activate a mandatory authorization via existing user credentials.
ETM provides a default configuration for this service with the CTRL script webclient_http.ctl. It is recommended to run this service as predetermined breaking point with an own CTRL Manager running within a DMZ (see chapter: Highly Secure Large System). The start mode for this CTRL Manager needs to be set to “automatic” to ensure that it is started and running while the project is in run mode.
Usage of WinCC OA HTTP-Server feature allows the automatic deployment of scripts, panels or configuration files to the requesting client machines. This feature enables a kind of comfort but to avoid a negative security impact; following recommendations need to be considered:
1. Encrypted panels and scripts need to be used for security relevant tasks, see chapter: Script and Panel Encryption. 2. A Desktop-UI needs a local cache of all project related files including the required certificates, to establish a connection to the WinCC OA server. A WinCC OA HTTP-Server automatically deploys the required certificates for the WinCC OA mxProxy to the requesting client:
a. Public Key for the root certification authority (root-cert.pem)
b. Public Key of the WinCC OA mxProxy (host-cert.pem)
c. Private Key of the WinCC OA mxProxy (host-key.pem)
This means a client can use the same certificates as the WinCC OA HTTP-Server host for the WinCC OA mxProxy communication. To avoid a negative security impact one of the following recommendations, need to be considered:
a) Usage of Microsoft® Windows Certificate Store (see chapter: Windows certificate store). With this feature enabled it is necessary to create and import the client certificate for the client machine. This disables the functionality of the default certificates inside the config folder from the WinCC OA HTTP-Server project. Although the three mentioned files are still deployed by this server to the client. They will have no functionality and are useless for an attacker. Another benefit is that the certificates inside the store are protected via OS based mechanism.
Although this is the recommended configuration for all Windows based system, this is not applicable for a Linux or Mobile OS (Android, iOS). With the actual version from SIMATIC - WinCC Open Architecture 3.16 FP2 (P009) only the Windows certificate store is supported.
Page 70 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
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.
WinCC OA Documentation reference
Reference tables / Configuration file / Possible config entries in WinCC OA → sslCertificate
Page 71 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
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 Documentation reference
WinCC OA UI / ULC UX / Architecture
A configurable load balancing function will help to distribute the load between the different Webservers.
WinCC OA Documentation reference
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 Documentation reference
WinCC OA UI / ULC UX / Architecture
6.1.8.2 Secure integration of manufacturing control Trusted clients or servers of manufacturing control system (MES or IMS), without a direct process interface, are integrated via encrypted communication (e.g. TLS) in the security cell in the following cases:
• When protocols and mechanisms are used for internal data exchange, which was developed for operation within local networks and domains (e.g. OPC / SQL / ODBC).
• The mutual authentication of encrypted communication is made via X.509 based certificates. • The authorization is made with OS-based and application-specific access rights.
Page 72 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
6.1.8.3 Secure data exchange It is often necessary that plant data must be made available to or from the plant without using any functions of the process control system or 3rd party tools (e.g. Apache Web server, Microsoft WSUS Server).
A distinction is made between the following application scenarios:
• Data made available for the plant (e.g. documentation, PCS updates, device descriptions) • Data made available for external networks (e.g. reports) These two application scenarios should not be implemented on the same computer. Both scenarios have different security requirements and should therefore be separated. Further it is recommended to install the required servers in the perimeter network.
During the installation following requirements need to be considered:
• A virus scanner must be installed to scan reading and writing operations. • All options of a virus scanner (e.g. heuristics) should be set to maximum. • Viruses must be removed at once. • Connection via trusted network o Authentication and authorization should be needed. o Encryption should be used.
• Connection via external Network o Authentication and authorization must be needed. o Encryption must be used.
Page 73 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
6.1.8.4 Protected Maintenance Access Very high requirements about the security concept are caused by the need for remote access and remote engineering for a site because every misusage could harm the system. Fundamentally the devices differ between reliable devices (they are in control and administrated by the facility operator) and devices that are only used for these activities by a reliable person (therefore called as non-reliable devices).
To ensure the maximum possible security for the system to be kept, every access must be authenticated and authorized. This can be done centrally at the access point firewall using a combination of multiple techniques and security mechanisms. A "direct dial-up" to the device supplies too weak testing options and hence, it is not recommended.
Depending on the type of the dial-up planned – whether local or via remote – and the maintenance access, there are different requirements and solutions depending on the risk level expected.
6.1.8.4.1 Reliable devices Remote but reliable devices without direct process interface will be integrated into the security cell via encrypted communication.
• Mutual authentication of the encrypted communication via certificates • Authentication and application specific access privileges.
6.1.8.4.2 Non-reliable devices Non-reliable devices get via remote dial-up a user specific access to the process control engineering system via Access Point firewall.
6.1.8.4.3 Remote Dial-up In case of remote dial-up, the security techniques used depend on the specific risks. They need the release by the system operator and the encoding of the information transfer.
A secure or protected network connection, a connection via a VPN client, is used as the basis for maintenance access.
Compared to local dial-up, the following other factors must be taken into consideration:
• Type of the dial-up medium • Type of the dial-up device • Purpose of the access
6.1.8.4.3.1 Dial-up Medium • Point-to-point connections on layers 1-2 (e.g. ISDN, modem, serial). Lower risk, since only specific devices can dial up (depending on the technology)
• Point-to-point connections on layers 3-4: (e.g. VPN, PPTP and L2TP). Higher level of risk for the access point, since every (device or user) could try to dial up to set up a connection.
Page 74 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
6.1.8.4.3.2 Dial-up Device • Specific support PC used only for this purpose This is a situation where the asset owner maintains the plant itself. The risk level is low since the support PC, its configuration and its security level are known and under control.
• Specific support PC used but not under own control This is a situation where the Integrator maintain the plant. The risk level is medium, but it is possible to reduce them by a mandatory usage of a VPN software which ensures mandatory security level for the remote PC.
• Any support PC not known Very high level of risk with unknown security level and not recommended
6.1.8.4.3.3 Purpose of the Access • Support of the process control system software Lower risk level since access needs to be granted only to software that is largely proprietary
• Support for the customization of the process control system Lower risk level since access needs to be granted only to proprietary customization data.
• Administrative access High risk level since full access is available to the complete systems
• Access to devices in the Control Systems Network (CSN) Very high-risk level since the access to the plant process cannot be fully restricted
6.1.8.4.4 Remote access Remote access devices get the web-based user specific access to the process control system via Access Point firewall.
• Authentication ensued via server-sided encryption (for example: HTTPS) via username, password and certificates.
• Authentication is OS based and specific for a web application. It is necessary to adjust the hostname/IP addresses with the local OS system to access the connected WinCC OA system.
6.1.8.4.5 Remote engineering Maintenance access takes place after the dial-up to the process control site. Based on the task, the following options are recommended:
• Remote maintenance, remote engineering (VPN client with maintenance application) • Remote desktop (VPN client with remote desktop for MES, OS or any but uniquely defined target system)
• Remote terminal (VPN client with access to the terminal server and the applications released for this purpose in the terminal client) The authorization for the maintenance tasks takes place via username and password at the maintenance software or at the terminal.
Page 75 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
6.1.8.4.6 Summary To sum it up, these results in the following requirements being made on the access techniques and ensuring their security:
• A protected maintenance access should be performed by using a VPN connection to the firewall. The security for the connection (e.g. encryption level) must be selected depending on the level of risk.
• The VPN dial-up is authenticated with the help of username and password at the firewall. The firewall verifies this login.
• If the access to the software of the process control system takes place with a specific support PC, the support PC connected via VPN can be secured like a remote process control computer.
• If administrative access or, in fact, access to the CSN is necessary, this should be done only via remote desktop, net meeting or remote support to selected plant PCs and the stationary MES.
• The Administrator from asset owner must approve administrative access.
Page 76 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
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 (acc.: 27th March 2019)
Although a virtual environment (e.g. running on an ESXI server) extends the configured environment, additional security requirements need to be considered. An own catalogue of security settings are usually published by vendors of the chosen virtual infrastructure, e.g. VM-Ware offers a few suggestions regarding the configuration on their Web-page. https://docs.vmware.com/en/VMware-vSphere/index.html (acc.: 27th March 2019).
Furthermore, recommendations from the following chapters must be considered.
6.2.1.1 Shutting down/Uninstalling services that are not needed under Microsoft® Windows A general list of not needed services cannot be given for a WinCC OA project due to the dependencies of the plant configuration of the customers. It is to consider if a service is needed. Examples for services that can be disabled in most of the cases: 1. “Wireless Zero Configuration” Service for the configuration of wireless services to Windows 2. “Domain Time” or “Windows Time” If a custom tool is used for the synchronization of the system clock 3. “CD/DVD-Autorun” Automatic start of auto run files of inserted CD/DVDs 4. “SNMP Service” SNMP poses a security threat on network level and should only be activated if it is needed for the project solution. If SNMP is needed following chapter should be considered: Restrict SNMP driver communication to SNMPv3
Page 77 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
6.2.1.2 Shutting down/Uninstalling services that are not needed under Linux Disable all unnecessary services and daemons (services that run in the background). All unwanted services need to be disabled. Attached a few command line parameters which works on a CentOS based Linux machine. For command which fits to other Linux distribution the man pages can be consulted.
Type the following command to list all services which are started at boot time in run level # 3 on a CentOS machine:
chkconfig --list | grep '3:on'
To disable a service currently running the following command can be used on CentOS:
service serviceName stop
If a service should not be started during an OS startup procedure, following command needs to be executed on CentOS: chkconfig serviceName off
It is recommended to disable the SSH Daemon and the Bluetooth service if none of that is needed. Both services could be disabled in following way, on CentOS:
systemctl stop sshd; systemctl disable sshd systemctl stop bluetooth; systemctl disable bluetooth
6.2.1.3 Configure BIOS Settings Configure BIOS to disable booting from CD/DVD and external devices in BIOS. Also define a BIOS password.
6.2.1.4 Different Disc Partitions A configuration of different disc partitions helps to prevent important data if any disaster happens. By creating different partitions, data can be separated and grouped. When an unexpected software accident occurs, only data of that partition will be damaged, while the data on other partitions is not affected (but consider that this suggestion beware only from software accident not for hardware accident where the complete hard disc including all configured partitions fails).
6.2.1.5 Deactivate unused interfaces Deactivate all interfaces that are not needed. Following interfaces can be deactivated as an example:
• WLAN, Bluetooth • USB, Firewire, etc.
• Turn Off IPv6 This list is not complete! A complete list can only be defined and applied for each plant separately.
6.2.1.6 Delete or disable unneeded default users on OS Level Every installed OS system has predefined users (e.g. guest user) and some of them are not needed. These users should be disabled for security reasons to prevent a security problem caused by a login try with one of these users.
Page 78 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
6.2.1.7 Limitation of internet access It is recommended to strictly limit the internet access of a live system. This also applies to the accessibility of a server for installing patches and security updates. It is recommended to restrict access to certain elements in the system, see chapter: Patch management and security updates for further details.
6.2.1.8 Uninstalling not needed software In most cases a newly delivered computer has software that is not needed for the plant operation and poses a potential risk. Therefore, it is recommended to remove all unnecessary software and only keep the required software packages on the computer.
6.2.1.9 Activate SMB signing According to Microsoft® TechNet the SMB protocol is defined in following way. “The SMB protocol provides the basis for Microsoft file and print sharing and many other networking operations, such as remote Windows administration. To help prevent attacks that modify SMB packets in transit, the SMB protocol supports the digital signing of SMB packets. This policy setting determines whether SMB packet signing must be negotiated before further communication with an SMB client is permitted.” (Microsoft, Require SMB Security Signatures, kein Datum)
It is possible to activate SMB signing for Windows and for Linux systems:
• Microsoft® Windows: Local Security Policy: Security Settings → Local Policies → Security Options → Microsoft network server: Digitally sign communications (always) --> Enabled
• Linux CentOS: Configuration is possible by changing the file: /etc/samba/smb.conf with following line: server signing = mandatory
Note:
According to Microsoft® an activation of SMB packet signing can degrade the performance up to 15 percent. https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server- 2003/cc786681(v=ws.10) (acc.: 27th March 2019)
Page 79 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
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)
folder
folder
Project Project
All directories All directories All
Project execution account X X W W W X X W
Plant administrator WX WX W WX WX WX WX W
Operator R R W Table 6 – User authorization on folder level
Legend:
• W → Write access • R → Read access • X → Execute access • Project execution account: User which executes the project on site. This user may also be a machine account like “NETWORK SERVICE” if the project runs as service (see chapter: Start a WinCC OA project as a service).
• Plant administrator: Administrator on site which is in responsibility of the deployment and maintenance of the project.
• Operator: Operator on site which operates the system, usually running in kiosk mode with limited privileges.
Page 80 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
Secure handling of configuration data (e.g. export configuration data from TIA Portal to the “data” folder of the WinCC OA project) is mandatory for security reasons. It is necessary to protect the folders with limited access privileges to avoid a negative impact caused by a theft of configuration data. It must be ensured that the configuration data is protected if this file is transferred to another device like an USB-stick or a different machine. The originator of this file (e.g. configuration file by TIA portal) handles the secure transport to the target host. On the target host this file is usually placed in a specific folder (e.g. “data” folder) of the WinCC OA project. This folder needs to be protected as well.
Page 81 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
6.2.1.11 Whitelisting/Application Control Whitelisting and Application Control are techniques that allow running only trustworthy applications respectively only allow defined file operations. Different to blacklisting software (virus scanner) that only protect from known threats, the Whitelisting allows blocking all unknown or not trustworthy applications. It is possible to distinguish between two different solutions:
• Whitelisting, list based: A list with trustworthy applications is used to decide whether the application can be started or not.
• Whitelisting, rule based (Application Control): A few rules decide whether an application can be started, and which file operations are allowed for the application. A strict distinction between these solutions is not always possible; often a mixed version is used. List based whitelisting Software is easier to configure. The list can be created automatically and if there are no changes to the installed software no further administrative tasks are needed. Therefore, this method is suited for smaller plants or plants with non-permanent IT administrator. Rule based Application Control may need more effort for configuration and maintenance but supplies more possibilities and allows a more detailed configuration of applications and file operations. This method is better suited for large plants with an own IT administration. Whitelisting and Application Control is no substitution for classic blacklisting software. Instead it is a further part in a whole Defense in Depth concept. Due to less resource demand of Whitelisting and Application Control software compared to black listing software it is to be favored on time critical systems and systems with fewer resources. It is to consider that every computer with access to the internet or a web-based intranet should have an up-to-date virus scanner. A typical Application Control allows verification of digitally signed files like libraries and executables. This functionality allows a configuration, where all files with a digital signature signed by ETM professional control GmbH are marked as secure files. (see chapter: Digital signatures for binaries and libraries).
Figure 27 - Digital signature signed by ETM professional control GmbH
This functionality may be extendable by usage of digital signs, implemented by an integrator or asset owner on site. An approach is applicable for all files like panels, scripts, compiled libraries or executables created by API interface. Finally, all used files on site should have a digital signature. To sum it up it is recommended to use Application Control software which allows the verification of signed files. SIMATIC - WinCC Open Architecture 3.16 FP2 (P009) has been tested with the following Whitelisting software:
• McAfee® Application Control (AC), formerly known as Solidcore • Kaspersky® Industrial Cyber Security Suite (KICS)
Page 82 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
6.2.1.12 IPsec Bypass Technology The use of the "IPsec Bypass Technology" stands for a special measure. By using local IPsec filter rules, it is possible to set up IPsec protected communication with another computer without any specific configuration of the local personal firewall. This communication setup needs either a Kerberos authentication, or Active Directory domain membership of the relevant computer.
6.2.1.13 Usage of interlocks for the PLC Some PLCs allow the usage of interlocks. This allows preventing wrong commands from the UI to the PLC. Further details can be acquired from the developers of the PLC software project.
6.2.1.14 Secure Desktop – Kiosk Mode Multiple options are available to restrict the desktop of an operator so that only the UI for the WinCC OA system can be used and no other software applications can be started.
The following options can be used for the configuration:
• Configuration of GPO settings on AD server for Microsoft® Windows systems • Configuration of system settings for Linux based systems • Usage of third-party tools Details about configuration settings for Kiosk Mode are available for different OS installations: https://en.wikipedia.org/wiki/Kiosk_software (acc.: 27th March 2019). The detailed configuration and recommendations for Kiosk Mode differs between Linux distributions as well as between different Windows versions. ETM recommends the reading of actual suggestions for the chosen OS. Within the chosen possibility to implement Kiosk Mode, it is recommended to avoid the execution typical shortcuts, which may be used to escape the Kiosk Mode: • ALT + F4 → Close the actual application window • ALT + TAB → Switch to the next application-level window • CTRL + ALT + TAB → Opens Dialog to lock machine, shutdown machine, etc. • Windows Key → Open Start menu A complete list of shortcuts which can be used to escape the Kiosk Mode can be given by OS manual.
6.2.1.15 Limitation of bandwidth between security cells The security cell can be protected from external network overload by limiting the bandwidth between security cells and therefore enabling an uninterrupted data flow inside the cell. The time critical communication inside the cell is not affected.
Page 83 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
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 (acc.: 27th March 2019)
Another source of useful information is also available by the BSI (Bundesamt für Sicherheit in der Informationstechnik). Here is a start link to the provided service: https://www.bsi.bund.de/EN/TheBSI/thebsi_node.html (acc.: 27th March 2019)
6.2.1.17 Usage of Obfuscation tool for API code Besides secure coding it is also recommended to protect a system from reverse engineering caused by Decompilers. The generation of a build without debug symbols is often the justification for requirements which may protect the intellectual property. For instance, there are tools called Decompilers that can take the debug build of a program and re-create the application’s source code. (Blunden, 2013).
A process for decompiling delivers following data:
• Control flow • Fix coded values for first values or keys • Processing inputs (e.g. hidden functions, options) • Existing test code (without security check) • Existing mechanism (to disguise data or check of licenses) All this information could be used for the preparation of further attacks. To reduce the threat, caused by this situation, it is recommended to use an Obfuscation tool. Such a tool cannot completely avoid the threat, but it can increase the effort of an attacker and reduces the attractiveness for an attack. This is possible as an obfuscation tool renames the identifiers like the names of variables and methods and it removes the debugging information. In general, these tools also change the program sequence which makes it very hard to understand the logic of a script.
Different obfuscation tools from different vendors can offer divergent functionalities. Here is a small choice:
• 2LKit Obfuscator • Cloakware
• ConfuserEx • The Marvin Obfuscator • Zelix KalssMaster
Page 84 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
6.2.1.18 DCOM Settings The DCOM interface is infamous and can be used by attackers to gain access to an OS with only one exploit. This treat is caused by remote procedure calls (RPC) which gives a program on computer A the ability to call a software function on computer B. Although this capability stands for a very powerful mechanism for distributed computing architecture, it is significant security vulnerability. (Shaw, 2006, S. 411)
Due to historical reasons some features from WinCC OA like the OPC DA driver needs DCOM to set up a connection between the different parts of a plant. Based on this information it is recommended to select one of the following options.
1. Disable DCOM: This is the recommended way if DCOM is not used at all in the entire system 2. Hardening DCOM: If DCOM is needed it is suggested to implement hardening to reduce the threat caused by this vulnerability.
6.2.1.18.1 Disable DCOM The DCOM protocol is infamous for some security leaks and needs a special hardening to avoid a threat scenario. If DCOM interface is not needed inside the project or plant, it is recommended to disable this functionality. The required information is available by Microsoft®: https://technet.microsoft.com/en-us/library/cc771387(v=ws.11).aspx (acc.: 27th March 2019)
Page 85 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
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.
WinCC OA Documentation reference
Drivers / OPC Data Access / Initial setup of OPC communication / DCOM settings for Remote Servers
The negative effect of the described configuration is that it weakens the security configuration on OS level and allows remote access of users without privileges like anonymous or everyone. This approach allows a remote attack from malicious users via this open interface and therefore this setting is only recommended in a full secured environment where an access from a malicious user is not possible. The following figure shows a possible attack scenario via this open interface.
Figure 28 - Access from malicious user via DCOM interface
The following description in chapters Usage of secure tunnel to avoid remote DCOM communication and Usage of hardening guideline for OPC DCOM can give a hint to avoid or reduce this attack scenario.
Page 86 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
6.2.1.18.2.1 Usage of secure tunnel to avoid remote DCOM communication A DCOM tunneling tool allows the elimination of an open DCOM interface by replacing the DCOM network protocol with TCP. Instead of connecting the OPC DA client to a networked OPC DA server, the client program connects to a local OPC tunneling application, which acts as a local OPC DA server. The tunneling software accepts messages from a local OPC DA client and converts them into a TCP messages. These messages are sent to the remote OPC Tunneling software and are converted back into the OPC protocol for the OPC server. The described communication works for both sides and simulates a local OPC DA server/client connection. The following graphic shows how an attack could be prevented via IT-Infrastructure with a typical action like the implementation of a firewall.
Figure 29 - Usage of DCOM Tunneling Software
Different vendors offer options for OPC tunneling, the integrator or the asset owner must choose which solutions can fulfill the requirements on site. A possible solution is offered by the OPC Training institute with OPC Expert.
Figure 30 - OPC tunnel protocol from OPC Expert (https://opcexpert.com/)
Page 87 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
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:
WinCC OA Documentation reference
Drivers / OPC Data Access / Initial setup of OPC communication / DCOM settings for Remote Servers
6.2.1.19 Hide secure network behind a Reverse-Proxy A WinCC OA HTTP-Server, which can hold sensitive information, should be protected behind a Reverse-Proxy, to control and limit the access points to this Web server. In computer networks, a Reverse-Proxy is a type of proxy server that retrieves resources on behalf of a client from one or more servers. These resources are then returned to the client as if they originated from the Web server itself.
This figure shows a symbolic implementation of a Reverse-Proxy which controls the communication between a Web Server from a secure network with the internet.
Figure 31 – Reverse-Proxy schema
Page 88 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
6.2.1.19.1 Example for Basic configuration with Apache Reverse-Proxy A possible way to implement a Reverse-Proxy is the usage of the Apache Server software. More information is available within a whitepaper (login required): https://www.winccoa.com/downloads/detail/wincc-oa-secured-by-apache- en.html?tx_mddownloads_mddownloadsfe%5Baction%5D=show&cHash=517b4b9c361294c4ba4c727a319 d8db3 (acc.: 27th March 2019).
Based on this whitepaper it is possible to suggest a configuration for the usage of an Apache Reverse-Proxy, which holds following parts:
• WinCC OA project runs on two redundant WinCC OA server controllers inside the PCN. Data- and Event manager accepts WinCC OA messages without SSL-encryption (config entry: mxProxy = “none”).
• WinCC OA HTTP-Server runs on a separate host in PCN. • Apache Server runs with a connection to PCN and PN on a Linux based OS. • WinCC OA mxProxy on “PenTestProxy” communicates with both WinCC OA server projects. The configuration of a remote WinCC OA mxProxy is essential for the communication between the UI on the client and WinCC OA Data- and Event manager on WinCC OA server hosts due the configuration of different networks. With this design the WinCC OA server hosts cannot be directly accessed by the client machine.
• Client Machine with Desktop UI or Remote UI, running on a Microsoft® Windows 10 OS is connected to PN. It is possible to configure this machine without access to any IP address inside PCN.
• Certificates for WinCC OA mxProxy, WinCC OA HTTP-Server and WinCC OA Servers are deployed. • Root certificates are imported in “Trusted Root Certification Authorities” on client machine. • Client device is unlocked in WinCC OA Device Management panel
Page 89 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
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
# Listen to port 443 for https communication Listen 443
Page 90 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
##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
## reverse proxy setting for http communication
ProxyPass / http://PenTestWEB/ ProxyPassReverse / http://PenTestWEB/
## reverse proxy setting for https communication AllowCONNECT 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
Page 91 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
This suggested configuration reads all requests to the root path for the Apache Proxy and transfers them to the WinCC OA HTTP-Server running on the PenTestWEB machine. For the Client machine it is necessary to import the created root certificate in to the „Trusted Root Certification Authorities“ store.
Figure 33 - Import certificate into Trusted Root Certification Authorities
Page 92 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
The navigation to the URL of the Apache Server sends the request to the internal WinCC OA HTTP-Server from WinCC OA and the certificate is marked as trusted like this screenshot explains:
Figure 34 - Start page from WinCC OA HTTP-Server with trusted certificate via Apache Server
Client to Data/Event communication via Apache proxy With this configuration it is possible to install the Desktop UI via a secured communication channel (https) and configure the project. As a parameter for the hostname it is necessary to use the name of the Apache and WinCC OA mxProxy (PenTestProxy in the given example) instead of the DNS name of the WinCC OA server. The WinCC OA mxProxy will get the connection request and set up a connection to the WinCC OA servers inside the PCN network. This means that the entire communication between the internal WinCC OA servers and the external WinCC OA client are handled with this Apache Reverse-Proxy. This makes it possible to trace suspicious activities and implement more security layers, to fulfill given security requirements based on an Apache Reverse-Proxy configuration. This solution is applicable for Desktop UI and Remote UI.
Page 93 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
6.2.1.19.2 Apache Configuration for ULC-UX The example from chapter Example for Basic configuration with Apache Reverse Proxy shows a possible configuration between a Desktop UI or Remote UI client to WinCC OA server host via Apache proxy server. But the explained scenario contains a possible threat caused by an unsecured client (see chapter: Intended operational environment (UI)) or an unsecured communication between WinCC OA mxProxy and WinCC OA server hosts.
This situation can be avoided by usage of the ULC UX as a client solution via Apache proxy with a complete end to end encryption. In this case the WinCC OA mxProxy applies on both WinCC OA server hosts and the communication is completely encrypted. This is possible due the behavior of the https communication between ULC UX client and WinCC OA HTTP-Server. The ULC UX features uses WebSocket technology to upgrade https communication from the initial connect to a secured web socket communication. And this needs to be configured on the Apache proxy server. The suggested configuration is based on this architecture:
• Two WinCC OA redundant hosts are connected to PCN • One remote WinCC OA HTTP-Server is connected to both WinCC OA server hosts • Apache Reverse-Proxy is configured to send and upgrade the https communication to web socket secured (wss).
• Certificate files are deployed on all server machines including Apache server • Host with ULC UX client has imported the root certificate into the “Trusted Root Certification Authorities” store.
Page 94 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
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 Documentation reference
WinCC OA UI / ULC UX
To ensure a working communication via Apache proxy following settings needs to be configured for the Apache configuration file (/etc/httpd/conf/httpd.conf for CentOS®):
Page 95 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
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:
This section configures the message transfer via incoming port 443:
AllowCONNECT 443
##### 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/
Page 96 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
A successfully configured architecture results into a full encrypted communication between Client and Server ensured by https certificates:
Figure 36 - Secure ULC UX communication via Apache Proxy
Page 97 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
6.2.1.20 Secure Oracle connection
6.2.1.20.1 Use Oracle Server with Oracle Database Appliance (ODA) Beside a secure connection between different nodes it is also recommended to ensure a good and secured storage. WinCC OA allows reading and writing to an Oracle DB via WinCC OA RDB-Manager.
Since security incidents, like the Equifax-Data-Breach (https://www.mass.gov/equifax-data-breach acc.: 08th May 2019), are becoming bigger and occurs more frequently, it is necessary to secure the centralized logging system as well. Oracle itself provides a few general recommendations but especially a configuration for an ODA (Oracle Database Appliance) should be considered.
ODA is available up to a two-node plug-and-play RAC cluster. Oracle Standard Edition 2 (within Oracle VM) and Oracle Enterprise Edition are fully supported and certified to run on every ODA; it reduces typical deployment times from weeks to less than a day. ODA uses also best practices for operating system and database security to fulfill the given security requirements. (Fernandez, 2015, S. 69)
Figure 37 - Oracle Database Appliance X7-2M ( (Oracle, 2019)
For a secure configuration of an ODA different configuration attempts are possible. Different suggestions regarding hardening are available by different vendors. One example vendor is the DOAG group (https://www.doag.org/en/home/ (acc.: 05th February 2019), which has published following document during an exhibition from 20th to 23th November 2018: https://www.doag.org/formes/pubfiles/10852341/2018-Infra-Tammy_Bednar- Oracle_Database_Appliance_built-in_Security_features_-Manuskript.pdf (acc.: 05th February 2019).
Methods for improving the security maturity for the selected Oracle solution needs to be provided by an Oracle specialist. This is part of “Industrial IT Security Services” from a Defense in Depth concept (see chapter: Defense in Depth).
6.2.1.20.2 Activate encryption between Oracle Client and Oracle Server The WinCC OA RDB manager communicates with the Oracle client and sends the data to the Oracle server. To prevent the communication from being intercepted and used for the harm of the company, the activation of the Oracle encryption is recommended. It is also recommended to activate SSO login for the Oracle connection.
Different Hardening Guideline are also provided by Oracle itself. Due to the situation that this document cannot give specific recommendation regarding hardening of Oracle it is recommended to consult an Oracle specialist to implement specific security requirements.
Page 98 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
6.2.1.21 Enable SELinux Security-Enhanced Linux (SELinux) is usually activated by default on supported Linux systems like CentOS to implement mandatory authentication mechanisms. This feature is usually activated by default and must not be disabled for security reasons.
Figure 38 - SELinux
The figure above shows how a process tries to request an action from an object (e.g. manipulation of a file). The request is checked inside the Linux Kernel by SELinux Modules. After a successful check, the access to an object is granted and the activities are performed. A denied access is logged as a security relevant event and can be analyzed. It is recommended to keep the default setting with the enforced mode of SELinux. In some special cases it may be necessary to change the mode to permissive, but this could reduce the overall level of security at the configured system.
Page 99 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
The configuration can be applied in the file:
/etc/selinux/config
Following configuration is recommended for this file:
# This file controls the state of SELinux on the system. # SELINUX= can take one of these three values: # enforcing - SELinux security policy is enforced. # permissive - SELinux prints warnings instead of enforcing. # disabled - No SELinux policy is loaded. SELINUX=enforcing # SELINUXTYPE= can take one of these three values: # targeted - Targeted processes are protected, # minimum - Modification of targeted policy. Only selected processes are protected. # mls - Multi Level Security protection. SELINUXTYPE=targeted
According to NSA it is essential that end systems (with a running WinCC OA application) can separate information based on confidentiality and integrity requirements to provide a secure system. Security mechanism which are implemented into an OS are the foundation of this separation (NSA, 2019).
CAUTION
A disabled SELinux layer could result into a Security threat because unfortunately, existing mainstream operating systems (without SELinux layer) lack the critical security feature required for enforcing separation: mandatory access control. Therefore, application security mechanisms are vulnerable to tampering and bypass, and malicious or flawed applications can easily cause failures in system security (NSA, 2019).
Page 100 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
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.
WinCC OA Documentation reference
Special functions / Encryption of Panels and CTRL Scripts / Encryption of Panels and Encryption of CONTROL scripts/Libraries
6.2.2.3 Local access to the Process-Monitor of WinCC OA The manager for the Process-Monitor (PMON) in WinCC OA has a HTTP server which allows remote access for the configured project.
Due to security reasons the default settings for the Process-Monitor (WCCILpmon) limit the access (HTTP, TCP) only to the local machine.
For detailed information please have a look in the SIMATIC WinCC Open Architecture Portal: https://www.winccoa.com/forum/ (Section Security/TOPIC: Security Advisory Report)
To re-enable the access from any computer following config entry is needed:
[pmon] localAddress = ""
Page 101 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
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.
WinCC OA Documentation reference
System management / Settings / IP access list for TCP server sockets ATTENTION
Configuration setting for remote PMON access needs to be designed very carefully because http- Server from PMON communicates only via http protocol and not via https. A secure configuration on IT-Infrastructure level is mandatory to prevent the system from a security threat.
6.2.2.4 Usage of WinCC OA mxProxy and restriction of open ports and limitation of the IP access list Restrict the external accessibility of services to known devices or external applications by a local firewall via specified network addresses and protocols or an access authority. The list of the open ports can be checked with the “netstat” command within a command shell on Windows and Linux systems. Using the port security allows to limit the access via the network by using IP access lists. The restriction of access should be configured in the firewall settings. All ports should be closed except the port for the WinCC OA mxProxy which is necessary for the WinCC OA manager communication. This port is configurable. Port Protocol Description 5678 TLS/SSL WinCC OA mxProxy
Table 7 – Port WinCC OA mxProxy
Page 102 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
The WinCC OA mxProxy is used as port concentrator and uses following protocols for the communication.
• TLS/SSL: Secure communication between devices. This communication is encrypted to prevent unauthorized reading data on the communication line. It is recommended to set up a secure communication between different security cells where a sniffing of network data would be possible (see chapter: Usage of TLS protocol).
• TCP: TCP is used for the communication inside the secured network or inside a security cell.
Figure 39 - Schematic graphic of the communication using the WinCC OA mxProxy with a remote UI
The advantage of using the proxy is that only a single port must be opened inside the firewall. More ports must be opened when using following functions from WinCC OA:
• Port 443 for https Is used by WinCC OA httpServer to establish a Desktop UI or an ULC UX connection. This port is configurable via config entry “httpPort” inside the “[webClient ]” section (default port: 443).
• Port 1521 for Oracle WinCC OA RDB Manager – The RDB Manager communicates directly with the local installed Oracle client. Therefore, the corresponding port must be opened on Oracle server side to allow the communication between Oracle server and client. The information about the defined ports can be found in the tnsname.ora file which is found inside the Oracle client installation folder in the subfolder “\network\admin” after the Oracle connection between server and client has been configured (default port 1521).
Page 103 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
• Port for Driver communication The communication to external devices (via API or driver) is not handled via WinCC OA mxProxy and therefore it is mandatory to open the specific ports as well to set up a working communication. It is recommended to encrypt this communication as well if possible and supported.
• Port 9370 for Video The Video Feature from WinCC OA uses an own Software component named “vimacc®” from Accellence Technologies which is optionally installable via WinCC OA setup. This part uses port 9370 in the default configuration. This port needs to be opened as well if Video functionality is needed.
6.2.2.5 Remote access to WinCC OA mxProxy manager via Dist Manager
Following example configuration shows the usage of a distributed communication between different WinCC OA systems via a WinCC OA mxProxy manager.
Figure 40 - Sample configuration for a remote WinCC OA mxProxy
The architecture above shows a possible example for communication between 3 different WinCC OA systems via Dist Manager and a single WinCC OA mxProxy. In this example the machine Server1 inside from security cell 1 sets up an SSL connection to Server2 and Server3 inside security cell2. Server 3 sets up a direct and unencrypted communication to server2 inside the same security cell.
A failure of the WinCC OA mxProxy will disconnect the Dist Manager communication between Server1 to Server2 and Server3 and the communication between Server2 and Server3 still is active.
Page 104 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
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.
WinCC OA Documentation reference
Reference tables / Configuration file / Possible config entries in WinCC OA
ServerSystem1: No WinCC OA mxProxy running on this machine. The necessary entries for the config file are: [general] distributed = 1 mxProxy = "none" [dist] mxProxy = "192.168.107.200 192.168.107.105:5678 cert" mxProxy = "192.168.107.202 192.168.107.105:5678 cert" distPeer = "192.168.107.200" 2 distPeer = "192.168.107.202" 3
ServerSystem2: No WinCC OA mxProxy running on this machine. The necessary entries for the config file are:
[general] distributed = 1 mxProxy = "none"
ServerSystem3: No WinCC OA mxProxy running on this machine. This machine sets up also a dist connection to ServerSystem2 and therefore an added distPeer entry is necessary in comparison to config file from ServerSystem2. The necessary entries for the config file are:
[general] distributed = 1 mxProxy = "none" [dist] distPeer = "192.168.107.200" 2
mxProxySystem: This machine has only a WinCC OA mxProxy manager from WinCC OA and nothing else. Needed config entries for the suggested configuration are:
[proxy] server = "192.168.107.200:4777" server = "192.168.107.202:4777"
Page 105 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
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.
WinCC OA Documentation reference
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 Documentation reference
WinCC OA UI / Desktop UI WinCC OA UI / Mobile UI Application / Device Management It is possible to access the WinCC OA Desktop UI via Apache proxy redirection and in this case the correct configuration for visible IP addresses from outside of the trusted network must be mentioned. This feature will increase the security level of the site since the real IP addresses are not visible from outside the secure MCS network.
Page 106 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
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.
WinCC OA Documentation reference
Special functions / Security / Multiplexing Proxy
Page 107 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
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.
WinCC OA Documentation reference
Special functions / Security / Multiplexing Proxy / MultiplexingProxy,Basics
The usage of the WinCC OA proxy is the default way for secure communication in WinCC OA. It is automatically activated with every fresh installed WinCC OA project. Another way is the usage of the Kerberos authentication method instead. This functionality can be configured and detailed information is available in chapter: Activate encryption for WinCC OA for Kerberos authentication and Usage of Kerberos.
6.2.2.8.1 Alternative communication without WinCC OA mxProxy Usage of the WinCC OA mxProxy is not mandatory for WinCC OA communication. Inside a secure network or in a network with active Kerberos communication (Activate encryption for WinCC OA for Kerberos authentication) it is possible to use TCP communication with signed and encrypted messages by Kerberos. When firewalls are configured inside this internal and secure network it is essential to open the required ports to allow a WinCC OA communication. A list of all necessary open ports when not using the WinCC OA proxy is shown in the following table: Port Protocol Description 4776 TCP WinCC OA Redundancy Manager 4777 TCP WinCC OA Distribution Manager 4778 TCP WinCC OA Split Manager 4897 TCP WinCC OA Database Manager 4998 TCP WinCC OA Event Manager 4999 TCP WinCC OA Process Monitoring
Table 8 - Default communication ports used for alive-message communication
The ports can be configured in the config file for the WinCC OA project. This can be necessary if specific ports are used by other applications or due to plant specific guidelines about the usage of ports.
Page 108 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
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).
WinCC OA Documentation reference
CONTROL / Control functions / Functions S / system()
The openSSL webpage (https://www.openssl.org/ (acc.: 27th March 2019)) show the complete list of available options to create own certificates. More information can be given by openSSL wiki (https://wiki.openssl.org/index.php/Main_Page) (acc.: 27th March 2019).
Due to the different options and opportunities of openSSL a deep knowledge of that library is essential for the creation of specific certificates. This makes it necessary that the implemented command line interface should only be used by experienced users. At this position ETM professional control GmbH cannot give a mandatory configuration for the creation of those specific certificates. For all users without this deep knowledge of openSSL ETM professional control GmbH suggests using the given WinCC OA panel for the creation of own certificates. This will fulfill the majority part of all security requirements.
Page 109 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
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.
WinCC OA Documentation reference
Special functions /Security / Create SSL Certificates
Figure 41 - SSL host certificates panel
Page 110 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
Following example shows a way how certificates can be created and deployed by usage of this panel.
1. Open the SSL Certificates panel on WinCC OA server machine via SysMgm → Communication a. Create HTTP root certificate In Frame Root certificate click: “Create” and enter following data: Certificate Type: “Certificate for WinCC OA HTTP-Server” Destination Path: Select config folder from the actual project Root keyfile password: Type a password, e.g.: “MakeYourProjectC4secure.KeepItSave!” Expiration in: Select the lifespan of this certificate. The default value is approximate 3 years. According to the given security requirements by the asset owner a correct lifetime needs to be configured. It is suggested to give the CA a longer lifetime than the created host certificates. This allows a defined process to renew the deployed certificates if required. Country Code: e.g.: “AT” Province: e.g.: “Burgenland” City: e.g.: “Eisenstadt” Organization: e.g. “ETM CA” Department : e.g. “RD01” CN Name : This is the Common name used in the certificate, e.g. select a hostname: “example.server.com”
b. A click on “Create” button creates two new files, inside the config folder: root-certificate.pem → this is the public root certificate file root-privkey.key → this is the private root key and keeps the secret for SSL encryption. These CA-files are used to sign host certificates and should be kept in a secured place. It is important to keep the passphrase. Without that it is not possible to renew, revoke or create new host certificates. The root-certificate creation panel can be closed afterwards.
2. Create WinCC OA HTTP-Server host certificate a. It needs to be ensured that the input fields in the “Root certificate” frame are filled with the correct files and the correct password b. Certificate Type: Select “Certificate for WinCC OA HTTP-Server c. Destination path: Select config folder from WinCC OA project d. Expiration in, Country Code, Province, City, Department, and CN Name: The same data as in the creation of the root certificate can be used. e. Organization: This value needs to differ from the value in the creation of the root certificate. This example suggested “ETM CA” as a value for the root certificate and for the host certificate the value “ETM” can be used. This is essential due SSL standards otherwise the host certificate is assessed as altered or corrupted. f. Click “Create Button” g. Two new files are created:
• certificate.pem • privkey.pem
Page 111 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
3. Create certificates for WinCC OA mxProxy a. For creation of WCCILproxy certificate the steps from the HTTP root and host certificates can be repeated after “Certificate for WCCILproxy” was selected for Certificate Type. It is necessary to select the correct root certificate files because they are different to the http certificates. This procedure creates following files in config folder: root-cert.pem → WinCC OA mxProxy certificate root-key.pem → root key for the proxy communication who keeps the secret for SSL communication host-cert.pem → host certificate for the WinCC OA mxProxy manager host-key.pem → key file for the WinCC OA mxProxy
4. The entire project with these created certificates needs to be restarted without issuing any error in this regard. 5. Establish Desktop UI communication a. Start the “webclient_http.ctl” CTRL script on WinCC OA server machine b. From client navigate to address to WinCC OA server via Internet Browser (Chrome, IE or Firefox) and install the application, if necessary. ETM recommends loading of the root CA certificates into the “Trusted Root Certification Authorities” store of the browser. This makes the browser aware of any available certificates for the project. This drops the certificate error from the URL where it is possible to download the setup for Desktop UI. c. A creation of a new project (default folder: [User folder]\.wincc_oa-cache) transfers the following certificates from WinCC OA Webserver to the client machine host-cert.pem, host-key.pem, root-cert.pem A repeat of the descripted steps is necessary for every WinCC OA host. The other hosts can use the same Root CA for their host certificates. It is strongly recommended to create all required host certificates on a centralized machine with the Root CA and to copy them manually to the WinCC OA hosts.
Note:
It is noted that an open connection between WinCC OA managers (e.g. EVENT to UI, EVENT to CTRL, REDU to REDU) is not closed, even if the certificate becomes outdated. The next connection attempt will be denied.
Although an open UI connection stays open after a certificate expired, this cannot be behaved as a security issue due following reason:
• A theft expired certificate is not usable • An active connection stays open because of the usage of a session key created during the initialization event. This session key allows a symmetric encryption between server and client which allows a higher data transfer performance compared to an asymmetric encryption mechanism.
This session key was created by the client with the public key of the server. And the private key of the server started the symmetric encryption.
Page 112 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
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: WinCC OA HTTP-Server.
Page 113 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
• Protection of certificates on Mobile Devices Please note that Mobile Devices uses the same mechanism to deploy certificates into a local cache. In a default configuration those certificates are not protectable and such devices must not be used in an operation environment that needs a high level of security (see chapter: Intended operational environment (UI).
• Protection of certificates for WinCC OA video Certificates which are used to implement a secure Video stream can be created, details are explained in chapter: Configuration Settings for WinCC OA Video (vimaccOA).
• Protection of TLS certificates for encryptable driver communication WinCC OA uses drivers which uses the TLS method to encrypt the message between driver and PLC, see chapter: Create and deploy certificates. The required certificates need to be created and deployed according to WinCC OA documentation.
Page 114 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
6.2.2.8.4.2 Windows certificate store Beside the file-based certificates it is also possible to store certificates for mxProxy with OS mechanism. A possible way is offered by Microsoft® Windows.
The Microsoft Management Console (MMC) Snap in “Certificates” offers a way to store and distribute certificates inside a Windows Platform. This system needs own certificates which combines the certificate with the private key in a PKCS12 format.
Here is an example how those certificates can be created:
With existing certificates already created using the WinCC OA certificate panel the following openSSL commands will convert the required certificates:
• RootCA: openssl pkcs12 -export -in root-cert.pem -inkey root-key.pem -out rootCert.pfx
• HostCerticate: openssl pkcs12 -export -in host-cert.pem -inkey host-key.pem -out hostCert.pfx
The created certificate files are importable into the Certification MMC from Microsoft® Windows. The given example uses the Computer Certificate store. To access this store, it is recommended to open the MMC console as an administrator and select the “Computer account” for “Certificates” Snap-in. Usage of “Computer account” is recommended to bind the certificate to a computer instead of a user.
Figure 42 - Certificates Snap-in for MMC
To allow reading it is important to check the “Mark this key as exportable…” checkbox for the host certificate.
Page 115 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
Figure 43 - Settings to import PKCS12 certificate
The root certificate must be part of the Trusted Root Certification Authorities and the Host Certificate should be stored into the Personal Certificates. A successfully imported certificate will show the reference to the private key and a verified certification path including a certification chain host to the certification authority:
Page 116 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
Figure 44 - Imported host certificate and certification chain (chain of trust)
To complete this example the following line needs to be added to the config file from the WinCC OA project:
[general] securityMode = "winCert" winCert = "MACHINE:MY:W2012_RCC_WEST" winRootCA = "MACHINE:ROOT:RootCA"
This configuration reads the certificates from the Windows certificate store instead of directly from the file and former activities about deployment could be applied.
Page 117 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
6.2.2.8.4.2.1 Configure Read Permission for Private Key to WinCC OA Users Although the created certificates by this configuration are readable by the local machine account, (see chapter: Start a WinCC OA project as a service) it may be possible that the logged in user is not able to read the private key, if a UI is required. In those cases, it is necessary to apply read permission to the private key for the group of configured WinCC OA users.
The following screenshot shows how this configuration can be applied inside an MMC. Within the popup menu, from the required certificate, it is possible to manage the privileges of private keys. The permission settings of the required certificate show that a Read-Permission was granted to the group of WinCCOAUsers.
Figure 45 - Configure Read Permission to Private Key for WinCC OA Users
Page 118 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
6.2.2.8.4.2.2 Install certificates into User Account instead Machine account Alternatively, it is also possible to install the certificates for the “Current Users” instead “Local Computer” as explained in this screenshot:
Figure 46 - Certificate in store of Current User
If this way is chosen it is necessary to adapt the configuration and to read the certificate from the “USER” store instead the “MACHINE” store.
[general] securityMode = "winCert" winCert = "USER:MY:W2012_RCC_WEST" winRootCA = "USER:ROOT:RootCA"
ATTENTION
Those certificates are exportable and could be used by an attacker if he was able to hijack a machine with valid certificates. The attacker could export the valid certificates and use them with a different machine for an attack. Therefore, it is essential to consider the Defense in Depth approach and to secure all machines to protect them from any theft or misusage. A theft device with a stolen certificate should result into an intermediate task where all certificates need to be replaced to keep the level of security and to prevent the hacker from doing any harm to the site facility.
Page 119 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
6.2.2.8.5 Usage of certification chain The WinCC OA client config entry chainPrefix allows the client to connect only to hosts via mxProxy that have specific named certificates or certificates from a certain CA/Sub-CA with a configured content. It is recommended to configure this setting to avoid a Man in the Middle attack scenario in an environment with unsecure clients.
Example based on this configuration:
Figure 47 - Example for chainPrefix
Description: PenTestSRV01 runs with WinCC OA Data- and Event Manager including WinCC OA mxProxy, PenTestWEB runs with a WinCC OA HTTP-Server and PenTestClient is a simple Windows 10 client.
This means that the client can assure that the client is connecting to the correct server by usage of the chainPrefix, only if the Server uses the certificates which the client chainPrefix config specifies the connection is set up. To make this useable the certification Path of the server certificates and the client certificates needs to be different. It increases the protection from a stolen certificate from a client where it could be possible to use this certificate to decelerate the own machine as a server project to start a Man in the Middle attack.
The config file configuration shown below is an example for the usage, the name of the RootCA is the 1st position, the 2nd position gives the name of the certificate where a wildcard is automatically added, and therefore a client certificate could also be named PenTestFirst or PenTestSecond but not PenMachine.
The following configurations apply to configure a certification chain:
1. PenTestClient runs with a Remote UI Enter following line into the config file from the UI project:
[general] chainPrefix = "RootCA;PenTest"
2. PenTestClient run as Desktop UI. Enter following line into the config.webclient file from PenTestWEB:
Page 120 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
[general] chainPrefix = "RootCA;PenTest"
3. PenTestClient runs as ULC UX Enter following line into the config file from PenTestWEB:
[general] chainPrefix = "RootCA;PenTest"
All those configurations will harden the system to allow only certificates that fit to the configured CN- Name. All other names or contents are interpreted invalid and the connection is denied.
For security reasons it is important to protect the config folder to prevent them from altering by an unauthorized user. This must be configured on OS level, see chapter: Access control.
Page 121 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
6.2.2.8.6 Enforce usage of strong cipher suite To ensure a good and secure connection between two nodes of a WinCC OA project the usage of a strong cipher is recommended. This is also recommended by BSI in following document. https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR- 02102-1.pdf?__blob=publicationFile&v=8 (acc.: 04th Feb. 2019).
A WinCC OA project can enforce the usage of a strong cipher with the config entry: “cipherSuiteList”. This list contains a comma separated list of all cipher suites which can be used for communication. The server chooses the first cipher suite of his list which is also offered by the client.
Although openSSL understands many different cipher suites, the list of useable cipher suites in WinCC OA is limited, according to following table.
Cipher Suite Description
AES128-SHA Deprecated AES256-SHA These cipher suites exist for compatibility reasons and must not be used on secure systems due to a weak MAC algorithm.
AES128-SHA256 RSA Certificates and private keys are used for key exchange AES256-SHA256 and partner authentication. Key exchange and authentication are done with RSA. DHE-RSA-AES256-SHA256 The Diffie–Hellman key exchange method allows two parties DHE-RSA-AES256-GCM-SHA384 that have no prior knowledge of each other to jointly establish a DHE-DSS-AES256-GCM-SHA384 shared secret key over an insecure communications channel. Key exchange is done with DHE, while authentication is done with RSA certificates.
ECDHE-RSA-AES128-GCM-SHA256 Elliptic curve Diffie–Hellman (ECDH) is an anonymous key ECDHE-RSA-AES256-GCM-SHA384 agreement protocol that allows two parties, each having an elliptic curve public–private key pair, to establish a shared secret over an insecure channel. Key exchange is done with ECDHE, while authentication is done with RSA certificates.
Attention These ciphers suites supports only communication via WinCC OA mxProxy and not http communication via WinCC OA httpServer.
Table 9 - List of useable cipher suits in WinCC OA
Page 122 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
Following example shows a secure example to configure this config entry. If both ciphers are existing on WinCC OA server and WinCC OA UI the cipher “ECDHE-RSA-AES256-GCM-SHA384” will be used for mxProxy communication. The second cipher will be selected by WinCC OA httpServer because an ECDHE key exchange mechanisms is not supported by this service. This cipher uses RSA for key exchange instead.
cipherSuiteList = "ECDHE-RSA-AES256-GCM-SHA384,ECDHE-RSA-AES128-GCM-SHA256,AES256- SHA256"
WARNING
The usage of cipher suite “AES256-SHA” with this config entry on a WinCC OA server will allow an attacker to enforce the usage of a weak cipher. The following line gives an example for a weak configuration of this config entry:
cipherSuiteList = "ECDHE-RSA-AES256-GCM-SHA384,AES256-SHA256,AES256-SHA”
An attacker has only to add following line on a client machine to enforce the usage of a weak cipher:
cipherSuiteList = "AES256-SHA”
This attack is possible because the client informs WinCC OA server that a communication via “AES256-SHA” protocol is requested and WinCC OA server accepts it because it is inside the list of valid and accepted cipher suits. This attack scenario can be prevented by removing the weak cipher from the list of acceptable ciphers on the WinCC OA server. In this case the WinCC OA server denies the connection, when a client understands only a weak cipher.
Page 123 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
6.2.2.9 Protection via authorization levels in WinCC OA The definition of operation authorizations for workstations is an elementary and integral part of WinCC OA. The standardized authorizations are mapped with the help of levels (bits).
A set of authorization levels are predefined in WinCC OA and used in some panel for a client-side authentication check by usage of the CTRL function getUserPermission(). Among other things those permission bits are used to check if a user has the permission to open a specific panel (e.g.: SysMgm).
Beside the client-side panel check it is also possible to implement a server-side authorization check by adding _auth configs to datapoints (see chapter: Add authorization config to Datapoint).
The predefined set of authorization levels is defined as follows:
1. Visualization: This permission bit allows the reading of panels. This authorization level is declared as 'bit 1'.
2. Operating authorization: This permission bit allows to open detail panels. This authorization level is declared as 'bit 2'.
3. Extended operating authorization: The user can execute commands, set substitute and correction values and change ranges of values.
4. Administration: The user can use the module 'PARA' (for the configuration of the data model). Further the WinCC OA System Management can be used for the configuration of the plant.
5. Acknowledgement: This level authorizes the acknowledgement of alerts.
Those authorization levels can be altered, or additional levels can be configured during the development of a WinCC OA project by the Integrator. This approach offers a way to implement a tailored authorization check.
Note:
The operation authorization "authorization level 2" as 'bit 2' is linked to the "authorization level 1", the 'bit 1'. The level 'bit 2' for opening panels can be assigned only if the authorization level 'bit 1' (Visualization) has already been defined as the operation authorization. Bit32 has a special meaning and is used to configure the Single Sign On functionality (SSO) for workstation hosts (see chapter: Single Sign On).
Page 124 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
Assigning this principle of bit-based operation authorizations is displayed in the following screenshot.
Figure 48 - Default user role in WinCC OA
This permission bit can be evaluated within WinCC OA in the following way.
Page 125 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
6.2.2.9.1 Add authorization config to Datapoint It is possible to add an authorization (_auth) config to a Datapoint which needs protection. This allows deciding which config is worth being protected. So, it is possible to define a user which has permission bit 3 that is needed to set an original value or to manipulate an existing alert handling config. A few Datapoints within a newly created WinCC OA project are already protected by this mechanism.
Figure 49 - Datapoint with authorization config
CTRL function getUserPermission() with a permission bit as parameter checks if the actual user has the required permission bit. With this function it is possible to create a project specific CTRL code to limit the navigation and control permission to a limited number of authorized users.
Due to compatibility reasons it is not possible to provide a configuration database with fully configured _auth config settings. It is recommended by ETM professional control GmbH to protect system essential Datapoints with an authorization config to make a Server-side authorization check possible and to avoid the risk that unauthorized users gain control of the client. Most of the internal WinCC OA Datapoints are protectable via an authorization (_auth) config.
Although this configuration is possible by project specific tailoring, some DPE must not be protected with an _auth config. Reasons are special circumstances where a DP update is needed, even if no user is currently logged in (e.g. The login panel needs the _Ui DP to open a module to ask for user credentials).
6.2.2.9.2 Example for protection of internal WinCC OA Datapoints The following lines show a way how the internal WinCC OA Datapoints could be protected with “_auth” configs for special Datapoints where an own configuration is needed.
In this example most of the Datapoints are protected with “_auth” config level 4 where at least the para user must update those Datapoints. The following lines show a CTRL code to configure all internal Datapoints in 3 steps.
Page 126 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
Please keep in mind that new versions or patches of WinCC OA may have more Datapoints and they must be configured separately if needed. These three steps describe only the required steps to configure the internal Datapoints from WinCC OA. The project and tailored specific Datapoints from a WinCC OA project must be configured in a similar way. Security awareness on the Datapoints with outgoing address config (e.g. switches) is strongly recommended. Only an authorized user should be allowed to trigger specific switches.
It is recommended to repeat these steps on a regular basis. Some Datapoints (e.g. _AESProperties) are created dynamically by the system and they will be created without an existing authorization config.
1. First step: Protect all Datapoints with _auth config level four. The following lines get all internal Datapoints even those without a leading prefix and add an auth config with level four to each of them. This script also ignores all Master Datapoints.
dyn_string allVal;
//general setting for all internal Datapoints
//get list for all Datapoints with leading _ allVal = dpNames( "_**" );
//append Datapoint list with internal Datapoints without leading _ dynAppend( allVal, dpNames( "*", "_AlertClass" )); dynAppend( allVal, dpNames( "*", "_AlertHorn" )); dynAppend( allVal, dpNames( "*", "_CommCenterDomains" )); dynAppend( allVal, dpNames( "*", "_HistSynch" )); dynAppend( allVal, dpNames( "*", "_IS_TableType" ));
// this loop will configure all internal Datapoints where a permission bit 4 could be placed. for(int i=1; i<=dynlen(allVal); i++) { //check and ignore MasterDP if(strpos(dpSubStr(allVal[i], DPSUB_DP), "_mp_") != 0) { dpSetWait(allVal[i] + ".:_auth.._type", 62, allVal[i] + ".:_auth._original._write", 4, allVal[i] + ".:_auth._dp_fct._write", 4, allVal[i] + ".:_auth._address._write", 4, allVal[i] + ".:_auth._default._write", 4, allVal[i] + ".:_auth._u_range._write", 4, allVal[i] + ".:_auth._pv_range._write", 4, allVal[i] + ".:_auth._alert_hdl._write", 4, allVal[i] + ".:_auth._alert_class._write", 4);
} else { DebugTN("ignore MasterDP: ", allVal[i]); } }
Page 127 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
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" ));
for(int i=1; i<=dynlen(allVal); i++) { 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 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); } }
Page 128 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
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"));
for(int i=1; i<=dynlen(allVal); i++) { if (strpos(allVal[i], ".") > 0) { dpSetWait(allVal[i] + ":_auth.._type", 62, allVal[i] + ":_auth._original._write", 0); } else { dpSetWait(allVal[i] + ".:_auth.._type", 62, allVal[i] + ".:_auth._original._write", 0); } }
ATTENTION
Some DPEs like “_Users.Password” are only protectable in cases where other features like external authentication (see chapter: Usage of WinCC OA external authentication method) or SSA (see chapter: Server-Side Authentication) is configured. The WinCC OA Standard authentication method needs write permission for a user who wants to change his own password, even in case where this user possesses only reading permission. An external authentication method or SSO are using a different method to update the password. Please check also warning phrase in chapter Usage of Operating system (Windows or Linux) based user management.
Page 129 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
6.2.2.10 Access Control via Area authorization Areas are logical or geographical zones of e.g. a tunnel or a plant. As an example, let’s assume a tunnel that is divided into different areas and run by users assigned to different groups. Users of these groups can have different rights for different areas (parts of the tunnel) depending on permission bits set for a combination Group-Area. The pairs Group-Area are defined with User administration panels through definition of the group membership in the areas. The permission bits that were set for a pair Group-Area can be further evaluated within Control scripts for example in a panel with functions described below and processed in needed way (by means of e.g. “IF” instructions).
Please consider following demo configuration for a detailed explanation:
• There are three different areas tunnel1, tunnel2 and tunnel3
• There are three user groups OpAll_tunnel1, OpAll_tunnel2 and OpAll_tunnel3
• There are following pairs Group-Area (memberships of groups in areas)
o OpAll_tunnel1: Member of areas: tunnel1 and tunnel2
o OpAll_tunnel2: Member of areas: tunnel2 and tunnel3
o OpAll_tunnel3: Member of area: tunnel3
• Permissions for pairs OP_All_tunnel1-tunnel1 and OP_All_tunnel1-tunnel2 configured as:
Figure 50 - Permission bits for pairs OpAll_tunnel1- tunnel1/tunnel2
Page 130 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
• OP_All_tunnel2-tunnel2/tunnel3 :
Figure 51 - Permission bits for pairs OpAll_tunnel2-tunnel2/tunnel3
• Op_All_tunnel3:
Figure 52 - Permission bits for the pair OpAll_tunnel3-tunnel3
Page 131 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
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.
WinCC OA Documentation reference
System management / Authorizations / Areas
Page 132 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
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”
WinCC OA Documentation reference
Special functions / Kerberos Authentication
6.2.2.12 Restrict SNMP driver communication to SNMPv3 WinCC OA is designed as open system and therefore SNMPv1 and SNMPv2 can be used even though no security features are available. If the plant has a high demand of security it is recommended to restrict the configuration to SNMPv3.
Page 133 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
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.
WinCC OA Documentation reference
Installation / Windows / WinCC OA as service Installation / Linux / WinCC OA as service
Page 134 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
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).
WinCC OA Documentation reference
Add-Ons / API / Access Control Plug-in
More details about ways for implementation are available within Doxygen-help from the API installation ([WinCC OA Setup Folder\api\doc\index.html: WinCC OA API\Classes\Class List\SecurityPlugin
or via direct link: [WinCC OA Setup folder] \api\docu\class_security_plugin.html
Page 135 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
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).
WinCC OA Documentation reference
WinCC OA UI / Mobile UI Application / Device Management
Figure 54 - Disable Automatic Unlock for mobile devices and WinCC OA Desktop UI
6.2.2.17 Define Reporting Manager as predetermined breaking point To avoid a negative impact like a DoS attack to the productive system via reporting interface it is recommend placing that Reporting Manager in a DMZ. This should help to protect the WinCC OA system inside the trusted network zone. With a correct configuration a DoS attack will not cause any negative CPU and Memory load impact to the WinCC OA servers.
Additionally, it is recommended to store created reports on a network share. This allows a configuration, where an allowed but unsecured client can read data without query them from a running WinCC OA system.
Page 136 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
6.2.2.18 Secure driver communication WinCC OA offers different protocols for communication between WinCC OA drivers and periphery devices like a PLC. In dependency of the implementation different methods needs to be considered.
6.2.2.18.1 Recommendations for encryptable protocols
6.2.2.18.1.1 Create and deploy TLS certificates Following WinCC OA drivers use TLS technology and certificates to ensure an encrypted communication between driver and PLC.
• WinCC OA S7Plus driver • OPC Unified Architecture driver • TLS Gateway driver
• IEC 60870-5-104 driver • MQTT client It is recommended to read the manuals of those drivers carefully in WinCC OA documentation. Some of the described drivers are provided with default certificates to ensure a fast deployment on site. But those certificates must not be used in live operation due to security reasons. A default certificate is comparable with a default password of a device and this means everybody may be able to get the secret very easily and may start a threat with this knowledge.
6.2.2.18.1.2 OPC UA configuration The OPC UA protocol could be vulnerable for attacks and different security bullets are collected by the OPC foundation. Information regarding these bullets is available with following webpage: https://opcfoundation-onlineapplications.org/faq/#t=SecurityBulletins.htm (acc.: 27th March 2019).
To reduce the level of attack a few recommendations for configurations are given by the OPC foundation. Detailed information is available here: https://opcfoundation.org/security/ (acc.: 27th March 2019).
Page 137 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
6.2.2.18.1.3 Definition of MQTT broker The WinCC OA MQTT driver operates as a client in a MQTT system. It reads and provides data from and to a centralized MQTT broker. The figure below shows a typical implementation.
Figure 55 - WinCC OA as MQTT client
WinCC OA provides the MQTT client as a driver which can establish a connection to an MQTT broker. Different vendors do provide MQTT brokers and ETM cannot give a specific recommendation for a special vendor. The vendor of the MQTT broker must be chosen very carefully by asset owner or the Integrator. Following points must be considered in the selection process of a MQTT broker:
• Communication between MQTT client and MQTT broker must be encrypted with a state-of-the-art protocol like TLS.
• Hardening Guide for the selected MQTT broker is available and implemented.
6.2.2.18.1.4 Usage of encrypted communication between Driver and PLC like S7-1500 Controllers Even if WinCC OA offers different security functions for a plant system, no 100% security for false signals sent to the PLC can be granted. Siemens recommends the usage of Scalance S-Modules or the usage of S7-1500 controllers with integrated security features for plants with higher security demands. Especially newer configuration protocols like the S7+ driver support the encrypted communication to an S7-1500 PLC.
Details and contact information concerning these Siemens modules can be found on following Website: http://w3.siemens.com/mcms/industrial-communication/en/scalance/Pages/default.aspx (acc.: 27th March 2019).
Page 138 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
6.2.2.18.2 Recommendations for unencrypted protocols
6.2.2.18.2.1 Drivers with Ethernet connection Some older driver protocols do not support a secure communication between a PLC and the WinCC OA driver running on a dedicated machine. This also applies to secure driver-based communication between two WinCC OA nodes running on different hosts.
For those protocols it is essential to implement more security configurations if the nodes are not running within the same security cell and are vulnerable for Man in the Middle attacks. In those cases, it is essential, for security reasons, to handle those nodes as 2 different security cells to prevent such attacks on the IT- infrastructure level. Some authorities recommend different ways to set up a security communication for an unsecure protocol. Usually a VPN communication is recommended between those nodes, to prevent any observation or manipulation of the transmitted messages. See chapter: Secure security cell link via IT Infrastructure.
The following figure shows a possible implementation by usage of a remote WinCC OA driver host which delivers the received data to a redundant pair of WinCC OA hosts. It is also possible to execute the remote drivers directly on the redundant pair of WinCC OA server, but this example gives a possible solution to reduce the scaling workload by usage of a specific architecture. It is also possible to extend this architecture by usage of a distributed WinCC OA system.
Figure 56 – Protect unsecure WinCC OA driver communication with Secure Tunnel
Page 139 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
The figure above gives only a possible example to set up a connection between different security cells which use an unsecure protocol for communication. In that case it is essential to implement security measurements via IT infrastructure.
This recommendation is valid for all unsecure protocols, it is essential to harden the environment if any of these functionalities is used.
ATTENTION
Although usage of a fully encrypted protocol is recommended the majority of WinCC OA driver uses an unsecured communication protocol. This leads to the recommendation that most of the communication between driver and device must be done in a secure environment. It must be mentioned that only following protocols use a secure communication between WinCC OA and the device: • WinCC OA S7Plus driver • OPC Unified Architecture driver • SNMPv3 driver • TLS Gateway driver • IEC 60870-5-104 driver • MQTT driver
Page 140 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
6.2.2.18.2.2 Drivers with serial connection (RS232, V.24, COM) Some WinCC OA drivers use a serial interface to set up a connection between WinCC OA and the PLC or periphery device. Although other protocols like Ethernet connections are standard for this connection, some technical facilities use a serial protocol.
Following WinCC OA drivers use this method:
• DNP3 • IEC60870-5-101 • RK512 A mixed communication mode is supported by protocols like IEC60870-5-101. This mode allows an RTU 101 device to communicate to a V.24 converter with a serial connection. The converter translates the serial communication into an ethernet protocol, which can be protected with a secure tunnel.
Following figure shows a comparison of both options. In this case the Ethernet connection between WinCC OA driver and V.24 converter is protected via VPN encryption.
Figure 57 - Compare Ethernet- to Serial protocol protection
This figure shows a WinCC OA server project which establish a connection to an RTU 101 device. Each device is running as a security cell. For configuration of a connection two options are possible:
1. IEC101 is connected via an Ethernet protocol and the connection is protected with a VPN tunnel. Inside the security cell the ethernet protocol is translated to a V.24 protocol. This scenario avoids a MITM attack threat. IEC 101 is directly connected via serial cable to an RTU 101 device. Although this connection method ensures a point to point connection it may be possible that the message traffic could be vulnerable to an eavesdropping attack. A standard radio receiver may be able to pick-up the transmitted signals (Smulders, 1990). To avoid an attack scenario the usage of a shielded RS232 cable should be mandatory to reduce the risk of a MITM attack for this connection.
Page 141 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
“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.
WinCC OA Documentation reference
Special functions / XML-RPC
Page 142 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
6.2.2.19 Digital signatures for binaries and libraries
6.2.2.19.1 Check digital signatures for Windows systems Installation packages from WinCC Open Architecture uses the extended validation technology for digital signing of all installation packages. https://en.wikipedia.org/wiki/Extended_Validation_Certificate (acc.: 27th March 2019).
The packages are signed with a timestamp as a best practice method, this ensures that the digital signature will not expire even when the certificate is expired (https://theniceweb.com/archives/491 acc: 09th May 2019).
Based on this mechanism a SHA256 hash is created to prevent installation packages from manipulation. Every manipulation will result into a loss of the digital signature and the setup package becomes corrupt. Consequently, an installation attempt is denied by OS settings.
Figure 58 - Signature for Desktop UI installation package
Page 143 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
Beside the installation packages WinCC Open Architecture specific executables and libraries are also protected by a SHA-256 hash algorithm verified by VeriSign.
Figure 59 - Digital signature for executable
This mechanism works automatically for every installation package within a Microsoft® Windows OS system; there are no further steps for verification necessary. In detail it is possible to adjust the GPO settings of the Windows system to configure the validation settings if needed.
In the case of self-developed API manager, drivers or control extensions these binaries should be also signed with the customers certificates.
Page 144 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
6.2.2.19.2 Linux This mechanism works on a private key handled inside the workspace from ETM professional control GmbH. A check of the digital signature is possible in combination with the public key which is available inside the RPM installation package of ETM professional control GmbH. This mechanism protects every RPM package from manipulation.
A check of installed files from an RPM-package is possible with the rpm command with the –V flag. For example, an “rpm -V WinCC_OA_3.16-base-sles” or “rpm -V WinCC_OA_3.16-base-rhel” checks all installed files, from this package and generates a list with detected manipulations.
Code Meaning
S File size differs
M File mode differs
5 The MD5 checksum differs
D The major and minor version numbers differ on a device file
L A mismatch occurs in a link
U The file ownership differs
G The file group owner differs
T The file time (mtime) differs
Table 10 – Faults in RPM file check
To implement a periodic check of the installation it is necessary to generate a script-based environment which checks periodically the installation and warns the user if a manipulation is detected.
As an example, a check was implemented into the start_pvss2 script from the WinCC OA installation on Linux systems. Here is a snippet from the manipulated Shell script file. The modifications began in line #143 from the original script. The manipulated content is marked with a yellow back color.
Within this script package verification is triggered every time when start_pvss2 is executed. It writes the result to a temporary file, checks for a MD5 checksum and denies the startup if an alteration was detected. The yellow highlighted lines where manipulated compared to the original start_pvss2 file which comes with the default setup of WinCC OA.
Page 145 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
…… HP-UX) if [ "x${SHLIB_PATH}" = "x" ] ; then SHLIB_PATH=${SHLIB} elif [ `expr "${SHLIB_PATH}___EOL___" : "${SHLIB}___EOL___"` = 0 -a `expr "${SHLIB_PATH}" : "${SHLIB}:"` = 0 ] ; then SHLIB_PATH=${SHLIB}:${SHLIB_PATH} fi export SHLIB_PATH ;; esac
#create text file with verification details rpm -V WinCC_OA_3.16-base-sles > /tmp/verifyWinCCOA
#remove altered config file from check sed -i '/config\/config/d' /tmp/verifyWinCCOA
#check for MD5 checksum failed flag cut -d " " -f 1 /tmp/verifyWinCCOA | grep 5 > /dev/null
if [ "$?" == 0 ] then echo 'MD5 checksum verification failed. Details:' cat /tmp/verifyWinCCOA exit 1 else echo 'Everything OK start WinCC OA' fi
if [ "$stopOpt" != "" ] then ( set -x; cd $PVSS_PATH/bin; ./WCCILpmon $stopOpt -PROJ ${PROJ} ) else ( set -x; cd $PVSS_PATH/bin; ./WCCILpmon -PROJ ${PROJ} -config $PVSS_II $* ) & fiecho ""
Page 146 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
6.2.2.20 Limit usage of root user Since the “root” user of a WinCC OA project has all permission bits, it is a special case for the user administration. In many cases there is no authorization check if this user executes tasks or programs. During the creation of a new project a dialog will be opened to enter a password for the root user. It is possible to set an empty password to simplify the project engineering, but this is not the recommended solution. ETM professional control GmbH | A Siemens Company recommends assigning a secure password for this user during the project design. Only the PKCS#5 hash of the password will be stored in the database. It shall not be defined in the config file of the project; otherwise the root password is visible in plain text. The config file can be opened with any text editor. Further tasks of the project planning shall be done by newly created users with suitable right permission bits so that the ”root” user is only needed in exceptional cases.
6.2.2.21 Deletion of unused Datapoints A default WinCC OA installation comes with some example and pattern Datapoints like “ExampleDP_Arg1”. In addition, WinCC OA holds a few empty Datapoint types like “LABOR_ANALOG” or “WH_SC1”. In some situations, those Datapoints may not be needed within a WinCC OA project. A typical example are the Datapoints and Datapoint types for the WinCC OA S7 driver, because they are only needed if this driver is configured and active.
Although a deletion of those Datapoints and Datapoint types may reduce the size of the Raima database, it may result into unforeseen and irreproducible behaviors in WinCC OA. Another key point would be the later usage of WinCC OA features like “WinCC OA S7 driver”, “Maintenance counter” or “Labor value” if the required datapoints and types where deleted. Even as it is possible to import the missing data with WinCC OA standard mechanism like the WinCC OA ASCII manager and existing data files it could result in a situation where existing configurations may be overwritten. A manual redesign of the existing data files will be necessary by the integrator to avoid a situation which could harm the existing configuration. To sum it up a default configuration to fix a created problem by deletion cannot be given by ETM.
Therefore neither datapoints nor datapoint types that are part of the WinCC OA installation shall be deleted. A much better approach to avoid any unwanted usage is to protect all Datapoints with an authorization config (see chapter: Protection via authorization levels in WinCC OA).
Page 147 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
6.2.2.22 Keep secure settings in WinCC OA config file The default values in the WinCC OA config file were defined to protect the entire WinCC OA project from an overload scenario, as a predetermined breaking point. A reliable configuration must reduce the risk of a complete failure of a WinCC OA project. Following settings are used and activated by default to configure a scenario where Data- and Event Manager are protected from an overload:
• Definition of input and output buffer size • Definition of maximum response time It is possible to disable or modify the configured limits to fulfill the project specific requirements.
The following chapters explain possible attack scenarios and give recommendations how the risk for an attack may be reduced.
6.2.2.22.1 Possible Attack via WinCC OA UI The following figure shows a possible DoS attack via a WinCC OA UI. During an attack, the configured limit is exceeded, and the WinCC OA Event Manager closes the connection to the causing UI Manager, to protect the overall system against this attack.
Figure 60 - Prevent DoS Attack via config settings
In this scenario the Attacker compromises an UI but due to correct settings in WinCC OA config file (“maxBcmBufferSize” is configured correctly according to the WinCC OA project requirements) the overload is recognized by WinCC OA Event Manager and the remaining system is protected. The Event Manager closes the connection to the compromised UI manager and the Attacker loses his attack vector.
Page 148 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
ATTENTION
Be aware that a configuration with a big value (e.g. 300MB for “maxBcmBufferSize”) makes this security layer useless and an attacker may easily harm the entire system.
Following config entries may be of interest to configure a secure environment. This list is not complete and shows only a few basic example options:
maxBcmBufferSize maxRequestMemSize maxAlertRequestCount maxRequestLineCount maxValueRequestCount maxLinesInQuery
WinCC OA Documentation reference
Reference tables / Configuration file / Possible config entries Error tolerance and stability (accessible via search tab)
6.2.2.22.2 Possible attack via WinCC OA driver through Man in the Middle Beside a possible attack via WinCC OA UI it may be possible, for an attacker, to get an attack vector via WinCC OA driver. In case of a Man in the Middle attack, countermeasure needs to be configured, to reduce the risk of the overall system.
The following figure shows how an attacker compromised the internal network and sets up an attack vector between PLC and WinCC OA driver, through a Man in the Middle which triggers a DoS attack.
Figure 61 - Prevent DoS Attack to WinCC OA driver via config settings
Page 149 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
WinCC OA documentation gives possible options how WinCC OA can be hardened to reduce the risk of this attack to the remaining system. The according settings for the used WinCC OA driver should be configured carefully, to reduce the negative effect of an attack.
A few possible drivers related config entries to implement an overload control are following examples:
maxTrapsPerSecond maxOutputQueueSize maxRequestQueueSize maxTrapsBufferSize
WinCC OA Documentation reference
Reference tables / Configuration file / Possible config entries
6.2.2.23 Usage of WinCC OA external authentication method WinCC OA uses a dedicated integrated user authentication mechanism. This supports the creation and maintenance of project specific user groups including the definition of roles based on permission bits. It is possible to use the build in user management during development process (e.g. creating Testcase users).
Therefore, ETM professional control GmbH recommends using an external User authentication Mechanism like the user management shipped with the operating system or another third-party tool like LDAP. This enforces the usage of strong passwords.
A weak password can easily be decrypted by an attacker and therefore it is mandatory that a password has to fulfill a few minimum requirements (see chapter: Password strength or https://www.us-cert.gov/ncas/tips/ST04-002 (acc.: 27th March 2019)). It is possible to define such rules within a site-specific process, but it is not possible to control the strength of a password with default WinCC OA mechanisms.
ATTENTION
Some sites may have specific security requirements, regarding user authentication, where a mandatory password length or a cyclic password switch is necessary. For those sites following options are applicable: • Operating system based User administration (with or without SSO and Kerberos) • User defined authentication (must be implemented as customer side solution)
Page 150 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
The following table should provide a help to select the correct method to handle the user credentials. It lists different features or requirements and informs how this is applied with each authentication method.
Security Feature or WinCC OA user Operating system User defined Requirement authentication based user authentication with a authentication 3rd party tool
Duplicate storage of Username and hashed Username stored in Username stored in password hash password in WinCC OA WinCC OA Datapoint WinCC OA Datapoint Datapoint
Password hash conform to PKCS #5 State of the art and OS Depends on the algorithm related. authentication tool but should be able to handle an IEC62443 compliant algorithm (see chapter: Block Cipher)
Financial Costs Intergraded in WinCC Handled with OS license Depends on the license OA costs of the 3rd party tool no additional cost Additional costs for implementation and maintenance may occur.
Mandatory usage of Not implemented, Configurable Must be configurable for strong password password strength full standard (IEC62443) depends on the user compliance with the selected tool.
Cyclic change of a Not implemented, user Configurable Should be configurable password must change the with the selected tool. password in own responsibility
Easy start of WinCC OA has own User and groups must User, Groups and configuration and users to start with be created in OS level. maybe also permission tailoring implementation Permission bits must be bits must be configured configured in WinCC OA in the external tool
Centralized user Not existing, user must User Administration is User Administration may administration be synchronized centralized but OU be centralized in manually (Sync tool (Organization units) do dependency of the tool. inside from WinCC OA not exist in WinCC OA available)
Disabling of a user User can be disabled Restore of a disabled or Depends on the external but can easily be deleted user will need Tool but should provide restored Domain Administrator this functionality privileges
Page 151 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
Security Feature or WinCC OA user Operating system User defined Requirement authentication based user authentication with a authentication 3rd party tool
Usage of SSO Not possible Optional configurable Not possible, at least but mandatory if own OS user Kerberos security is authentication required active in WinCC OA.
Combination with Not existing Login to WinCC OA with Depends on the hardware related login SSO activated authentication tool mechanism (fingerprint, smartcard, …)
Effort in creating users Effort in creating users Effort in creating OS Effort in creating users and groups and groups on WinCC users and assignment to and maybe permissions OA level a group with WinCC OA inside the ext. auth. tool. related permission. No additional effort in Additional effort in WinCC OA necessary. assignment of permission bits in WinCC OA to imported groups from OS
Conform to Not conform Conform if configured Conform if requirements IEC62443 4-2 and on OS level regarding user IEC62443 3-3 authentication are requirements supported by the system.
Notification of failed Only as entry in local Configurable on OS Depends on the login procedures text-based log file but no level (Group policy for authentication tool automated mechanism Windows) with option to exists to handle this lock the affected user. event.
Support of password Not existing Configurable on OS Depends on the expiration level (Group policy for authentication tool Windows)
Storage of password Encrypted password Secure password Password storage by hash hash stored on _Users storage by the OS. No the authentication tool. Datapoint. valid password hash will The security level be transmitted to an UI depends on the tool. No client. valid password hash will be transmitted to an UI client.
Table 11 - Compare methods of user authentication
Page 152 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
In Summary the usage of an Operating system based user authentication gives a best practice procedure to implement a secure system. It combines the existence of a good and reliable authentication tool with the permission bits mechanism inside WinCC OA. In addition, an OS system should always stay up to date (see chapter: Patch management and security updates). Security issues will be corrected automatically via OS security updates. This helps to fulfill the user specific requirements in IEC 624443 3-3 and IEC 62443 4-2. This combination gives the best achievable level regarding security requirements.
In addition, an OS with activated Kerberos increases the security maturity of the overall system. By this consideration it is possible to rate the authentication methods in an order, with begins with the highest level of security.
1. Operating system based user management with Kerberos enabled SSO. Windows and Linux are supported.
2. Operating system based user management. Windows and Linux are supported.
3. User defined authentication with a 3rd party tool
4. WinCC OA internal authentication
Table 12 – Security assessment of authentication method in WinCC OA
The referenced list from Table 12 shows the highest maturity for the Operating system based authentication methods, but that configuration needs a fully configured domain concept. If this complete domain concept is missing, then the following points show the advantages of an external authentication tool against the WinCC OA method:
• Allows WinCC OA to support environments with mixed operating systems, where all users are not authenticated by a Windows or Linux domain.
• Allows users to connect from unknown or untrusted domains. For instance, an application where an established user connects with WinCC OA HTTP-Server (ULC UX). (See chapter: User Interface Configuration)
• Allows WinCC OA to support web-based applications were users create their own identities, based on API managers
• Allows software developers to test applications by using a complex permission hierarchy based on temporary logins. Following chapters shows the possible options to implement an external authentication concept based on the operating system of a 3rd party vendor tool.
Page 153 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
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 WinCC OA documentation:
WinCC OA Documentation reference
System management / Authorization / Windows user administration System management / Authorization / OS Auth. user administration
An Active Directory system allows the usage of mandatory requirements regarding the password strength which can be configured via group policy editor. With enforced settings it is possible to ensure good and strong passwords for user credentials which protect the project or plant from jeopardizing by the usage of weak passwords.
Beside a strong password, an OS based user authentication mechanism allows the synchronization of users and groups inside a domain. This makes it easier to trigger a login to a WinCC OA project running on a host within the same domain. For a more granular permission design it is possible to define different permission bits (authorization level) for every role (group membership) of a user. With this configuration it is possible that the same user can perform administration activities on a WinCC OA project but only reading activities on another WinCC OA project.
The following example shows a central user administration based on an AD/LDAP system. The user with the name “siteadmin” exists on the Domain controller and this user is member of specific groups. The 1st login of a user on a WinCC OA host will create this user inside the local configuration database and the assigned groups are created automatically. In the default configuration the permission bits must be applied manually to each group and this means that members of the same group can have different permission levels for each WinCC OA host. This example shows that the user siteadmin has only full permissions on WinCC OA system 1 and 2 but can only acknowledge alarms on system 3. On System 4 the same user is only able to visualize the system and he will not have the option to configure these systems if all authorization configs are configured correctly.
Page 154 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
Figure 62- Central user administration with Domain Controller and different permissions
Page 155 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
WARNING
WinCC OA uses a datapoint of DP-Type _CtrlCommandInferface to create new users for an internal algorithm. The required DP is created automatically with the first switch to OS based authentication method. The new generated DP is protected with permission bit three for _dp_fct, _original, _address and _default in a default installation. This DP is used to create users, add users to groups and change user passwords.
Although a switch to OS based authentication mechanism increases the level of security of the system it could be harmed directly after the switch due to a temporary situation where those permission bits are set to zero. This is essential to establish the login of new users.
1. Firstly, it is necessary to import the required groups from OS Level. When the user logs in, the appropriate groups are created in WinCC OA on the server. To create all necessary groups in WinCC OA, we recommend that the user who switches to the OS Auth User Administration, must possess Active Directory Administrator rights. Note also that the server must be started with Active Directory Administrator rights. This means that the user who logs on to the server must possess Active Directory Administrator rights. 2. Secondly it is also essential to activate SSA, see chapter: Server-Side Authentication for User Interfaces. 3. Thirdly it is important to protect the _CtrlCommandInterface_2 DP with the same or more restrictive settings via _auth configs. At least the datapoint attributes _dp_fct, _original, _address and _default must to be protected with permission bit 3.
This configuration could also be applied via WinCC OA configuration panel from System Management: SysMgm → Permission → System Permissions
Figure 63 - System authorization panel to set permission bit 3 4. Finally, the level of security was increased due the realization of the given recommendations.
Keep in mind A login of new OS users - without activated SSA - in WinCC OA is only possible, when “CommandInterface permission” is set to 0. Every different configuration result into errors during the creation of new users! WinCC OA Documentation reference
System Management / Authorizations / System authorizations
Page 156 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
6.2.2.23.1.1 Windows A Windows system requires a configured AD running on a dedicated Domain Controller. A switch from WinCC OA user administration to OS based administration requires a user with administrative privileges. After a switch, a login from any configured user in AD is possible, the assigned groups are created automatically in WinCC OA, but the permission bits must be set manually, for the required AD groups. This also affect an update of the group relations from an existing user, the new groups will be created automatically after the next login of this user.
To ensure a good functionality without permission issues it is recommended to use the same user which is currently used in the actual Windows session. This is necessary to avoid problems caused by configured permission settings on Windows level. For example, if the actual Windows user tries to trigger a login with a different user, it could be possible that the Windows user does not have the permission to read the assigned groups of that user that is created in WinCC OA. This situation results in a scenario where the user is created in WinCC OA but has no groups assigned.
6.2.2.23.1.2 Linux For OS authentication on a Linux system WinCC OA uses the Pluggable authentication module (PAM) interface. This interface supports the login of local users from the Linux system as well as configured users from an AD domain. The benefit of the PAM API is the usage of an independent user authentication mechanism (e.g. LDAP, Winbind). Following drawing shows the overall implementation of the PAM library model. This model is configured via a configuration file and runs on the low-level modules implemented into the operating system. The Service application in this case WinCC OA uses the PAM library for the authentication mechanism.
Configuration file PAM Library (etc/pam.d)
WinCC OA (Service application with LDAP, Winbind, ...) Low level modules (pam_unix)
Figure 64 - Usage WinCC OA in PAM architecture
This PAM mechanism was tested with a Windows DC and a Linux DC implemented via Samba 4. A user replication was configured, and a Linux Client was integrated via LDAP to this test environment. This means that a login to GNOME UI was possible with a user existing in AD.
Page 157 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
The following picture shows an example how the system was configured. The domain user exists inside the AD.
Figure 65 - Windows/Linux DC Architecture
The Linux WinCC OA Host was integrated into the Domain by usage of following configuration. Attached is the content of the required configuration files for a CentOS® system as an example. For other systems refer to the OS Manual for the correct configuration.
# # /etc/nsswitch.conf # # An example Name Service Switch config file. This file should be # sorted with the most-used services at the beginning. # # The entry '[NOTFOUND=return]' means that the search for an entry # should stop if the search in the previous entry turned # up nothing. Note that if the search failed due to some other reason # (like no NIS server responding) then the search continues with the # next entry. # # Valid entries include: # # nisplus Use NIS+ (NIS version 3) # nis Use NIS (NIS version 2), also called YP # dns Use DNS (Domain Name Service) # files Use the local files # db Use the local database (.db) files # compat Use NIS on compat mode # hesiod Use Hesiod for user lookups # [NOTFOUND=return] Stop searching if not found so far # # To use db, put the "db" in front of "files" for entries you want to be # looked up first in the databases # # Example: passwd: sss files shadow: sss files group: sss files
Page 158 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
#initgroups: files
#hosts: db files nisplus nis dns hosts: files dns nis myhostname
# Example - obey only what nisplus tells us... #services: nisplus [NOTFOUND=return] files #networks: nisplus [NOTFOUND=return] files #protocols: nisplus [NOTFOUND=return] files #rpc: nisplus [NOTFOUND=return] files #ethers: nisplus [NOTFOUND=return] files #netmasks: nisplus [NOTFOUND=return] files
bootparams: nisplus [NOTFOUND=return] files ethers: files netmasks: files networks: files protocols: files rpc: files services: files sss netgroup: files nis sss publickey: nisplus automount: files nis sss aliases: files nisplus
The file /etc/pam.d/other was used with following content:
#%PAM-1.0 auth [user_unknown=ignore success=ok ignore=ignore default=bad] pam_securetty.so auth substack system-auth auth include postlogin account required pam_nologin.so account include system-auth password include system-auth # pam_selinux.so close should be the first session rule session required pam_selinux.so close session required pam_loginuid.so session optional pam_console.so # pam_selinux.so open should only be followed by sessions to be executed in the user context session required pam_selinux.so open session required pam_namespace.so session optional pam_keyinit.so force revoke session include system-auth session include postlogin -session optional pam_ck_connector.so
With this configuration it is possible to change to the OS based authentication method inside from WinCC OA user administration panel.
Page 159 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
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 WinCC OA documentation:
WinCC OA Documentation reference
CONTROL / Control classes / Authentication
Like an integrated OS based authentication mechanism for an AD system it must be possible to set policies within an external authentication tool. ETM professional control GmbH cannot recommend any specific tool but during the analysis it is important to define the following as must have criteria:
• The evaluated authentication tool should be able to enforce the usage of good passwords. • It should be robust against Denial of Service attacks. • It should use a state-of-the-art hash algorithm for user passwords. • Support of encrypted user credentials transfer. The external tool should be available via VPN connection to make a secure remote connection possible. Beside an OS integrated user authentication based on an Active Directory concept it is also possible to use an external tool from a vendor to check the user credentials. This user authentication can be activated by configuring the required service using config file entries.
Depending on the integration of the external authentication tool it is also possible to configure the permission bits directly within this tool and the user in WinCC OA will be created automatically with the centralized configured permission bits. Both options have their advantages and disadvantages, in coordination with the integrator and the asset owner it is necessary to find the correct method to implement a solution which fulfills all requirements regarding user role security.
The following figure shows a handling of a user if the authentication bits are also handled inside the centralized system. With this configuration an own and different configuration of permission bits for a user to different systems is not possible on this level. Every user will get the same permission bits in the overall system. But if a more granular configuration is required it can be implemented with the area concept (see chapter: Access Control via Area authorization)
Page 160 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
Figure 66 - User defined authentication with external tool
ATTENTION
It is essential to implement a secure interface for the external user authentication tool. The integrator of the site must do this task directly. This interface should be robust against Man in the Middle attacks to prohibit a confidentiality related attack scenario.
Page 161 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
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.
WinCC OA Documentation reference
Graphic editor (GEDI) / Complex graphic objects / EWO (External Widget Object) / WebView EWO
To apply state-of-the-art security requirements, it is necessary to follow regulations during the implementation of a JavaScript interface. Although ETM offers an option to implement a JavaScript, the implementation itself is in responsibility of the integrator or the asset owner. Beside the functional requirements of the interface it is essential to consider following points.
• Ensure secure coding practice. During the implementation it is essential to consider and verify all output and input activities. It is possible to reduce a security risk by following common coding practice which consider security requirements. With a good implementation, it should be possible to consider following points: o Avoid common mistakes in JavaScript coding o Avoid implementation of vulnerabilities to keep the application secure. o Implement a way to recover from error Whitepapers and Guidelines regarding a secure implementation are available from different sources and some are also available via internet. (e.g. https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Security_best_practices/ or: https://code.tutsplus.com/articles/client-side-security-best-practices--net-35677 acc.: 27th March 2019)
• Implement Server-side security With JavaScript interface it is possible to read and write datapoints by usage of JavaScript function. To avoid a possible altering of a system it is essential to protect the datapoints with an authorization config. This implements a Server-side security layer and avoids a possible situation where a system may be harmed, see chapter: Protection via authorization levels in WinCC OA.
• Use obfuscation methods and avoid default names With a JavaScript interface it is possible to manipulate shapes and widgets from WinCC OA directly but only for the own interface. An attacker may be able to overfill a table object, but this will only affect the already hijacked interface of an attacker itself. To execute this attack it is necessary to know the shape name from an object to trigger a possible overload scenario. To reduce the risk and to delay the attempts from an attack it is recommended to use own names and not the default names for the shapes (e.g. TABLE1). Even if this step does not implement a high level of security it may weaken the attack vector because an attacker must guess the name of a shape before he is able to execute a script.
Page 162 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
Administration and Configuration of OS
6.3.1 Administration of Computers The administration of computers and users, of a production plant, can be organized centrally by a Domain (AD domain) or decentralized.
One benefit of centralized administration is the significant reduction of maintenance effort and the considerable enhancement of security. For example, this can be achieved using the Kerberos authentication in an AD domain. If usage of Kerberos authentication is not utilizable, the common authentication method of NT LAN Manager (NTLM) can help for a Windows based OS.
The decision about centralized or decentralized should be taken based on the number of systems to be supported or the necessity (e.g. organization's own security guidelines) of using an AD domain. Due to the operation of a machine / plant by different persons the usage of a central user administration is recommended.
The following situations require an AD domain:
• Highly available user administration by usage of multiple AD controllers. • Use of the Kerberos authentication • Public key infrastructure (can also be used for IPsec) • Centralized SSO user login and verification • The centralized user login and verification from an "external" domain (e.g. via a "one-sided trusted" to another network with its own Active Directory administration)
• The centralized, group guideline-based configuration Regardless of the type of the administration (centralized or decentralized), it is necessary to ensure careful separation of the areas of responsibility and administration of the IT department for the office networks and the operations personnel.
The following examples clarify and illustrate the meaning of separating the areas of responsibility and administration:
• An administrator of the IT department cannot reboot or incorrectly configure a plant PC inadvertently. • An administrator of the plant operations personnel cannot make changes to the domain settings of an external domain inadvertently. An administration concept must always be prepared if administration needs to be done by a domain. The infrastructure design with respect to the name space, domain structure, overall structure and trusted relationship to other domains, e.g. the domain for an office, must be specified in the administration concept. The decision regarding the infrastructure design depends to a large extent on the number of systems, the size of the systems and the associated effort and cost. The organizations own guidelines need to be followed and implemented in the same way.
Page 163 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
In principle, it is recommended that separate structures are used for the office networks and the production networks. The reason for this is that data security, authorizations and rights take place for both overall structures separately including the folder replication. Even changes in the scheme and configuration and adding a new domain to an overall structure have an effect only across the entire structure. Access to resources is enabled via single or mutual overall structure trusted relationships. Since each overall structure (office and production) is administered separately, the administrative effort increases by adding to the overall structure.
Trusted relationships of the overall structure simplify the administration of a segmented Active Directory infrastructure within an organization. This happens since they support access to overall structure- independent resources and other objects. As an example, it is possible to configure a one-way Trust from ECN to PCN. This allows the operators to use resources from the Enterprise network (e.g. printer), while Enterprise users are not able to login to a WinCC OA project for security reasons.
The rules for the necessary password complexity can be defined on the layer of organizational units (OU). An increased complexity (number of special characters, length,) increases the effort for cracking the password. A cyclic change of the password also adds additional security.
Page 164 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
6.3.1.1 Password strength Many applications are provided with a default password to ensure an easy startup, directly after installation. This default password needs to be changed as soon as possible because an unchanged default password may be used by attackers to cause a threat and harm a CIS system. The article in this reference shows how an attacker was able to steal military data because the default password was not changed: https://www.bleepingcomputer.com/news/security/hacker-steals-military-docs-because-someone-didn-t- change-a-default-ftp-password/ (acc.: 27th March 2019).
Beside the change of the default password a good password should fulfill these requirements:
• Use a minimum password length of 12 to 14 characters.
• Include lowercase and uppercase alphabetic characters, numbers and symbols to increase the alphabet size.
• Avoid using the same password twice (e.g., across multiple user accounts and/or software systems).
• Avoid character repetition, keyboard patterns, dictionary words, letter or number sequences, usernames, relative or pet names, romantic links (current or past) and biographical information (e.g., ID numbers, ancestors' names or dates).
• Avoid using information that is or might become publicly associated with the user or the account.
• Avoid using information that the user's colleagues and/or acquaintances might know to be associated with the user.
• Change the password periodically
• Change password only on secure hosts (especially for users with administrator permission)
Page 165 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
The listed requirements help to reduce a risk caused by a brute-force attack. Following two charts give an example how password length and alphabet size effects the time for a successful brute-force attack. Both charts show the maximum amount of possible combinations. The first chart shows the effect of increasing Password length while the alphabet size remains stable. The second chart shows the opposite solution with a stable password length of 5 while the Alphabet size was increased (e.g. by usage of special characters).
impact of Password length impact of Alphabet size
250000 120
200000 100
80 150000 60 100000 40
50000 20 amount combinations of Mio. in amount combinations of Mio. in 0 0 5 6 7 8 10 20 30 40
Password length size of Alphabet
increase of combinations increase of combinations
Figure 67 - Increasing Password length with Figure 68 – Increasing Alphabet size with fixed Alphabet size of 26 fixed Password length of 5
The amount of possible combinations is calculated with the power function. Alphabet size is used as base parameter while Password length is used the exponent:
Possible combinations = Alphabet size Password length
Due to mathematical reasons an increase of Password length is more important than an increase of Alphabet size to prevent a system from a brute-force attack.
Following table shows examples for the required time of a brute force attack with the assumption that this attack can generate 2 billion keys per second. These values assume that 52 letters (lower/upper case), 10 numbers and 32 special characters are used to increase the Alphabet size to 94.
Alphabet size Password length Amount of combinations Time for brute-force attack 94 5 7339040224 3,67 seconds 94 8 6,09569E+15 ~ 35 days 94 12 4,7592E+23 ~ 7,5 Mio. years
Table 13 - Time for brute-force attack
This table also shows the importance of Password length to prevent the configured system from a brute- force attack. It also shows the mathematical proved reason why a minimum password length of 12 is recommended in this chapter.
Page 166 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
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 (acc.: 27th March 2019).
Note:
Every active user account allows access to the system and is therefore a potential security threat. Following steps are recommended: • Reduction of configured / active user accounts to the necessary minimum • Periodic verification of the configured user accounts • Usage of secure access data for the available accounts • Important: Change system default passwords as well as the “root” password of the WinCC OA project before setting the system active • System access only for users that are necessary for the plant operation
Page 167 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
6.3.2 Administration of networks and network services Network services of a production system can be organized in a centralized or decentralized manner. In principle, it is also possible to have mixed configurations of centralized and decentralized administration. Mixed configurations should be adapted specifically for each system. Incorrect configurations occur more frequently in the case of components configured in a decentralized manner based on experience. In addition, conflicting settings are difficult to find.
One benefit of the centralized administration is the significant reduction of the maintenance effort and the considerably higher level of security, for example, by the following options:
• Using the Kerberos authentication within the domain in place of the NTLM authentication within a workgroup.
• Adding the host names/IP addresses in the hosts files to access the WinCC OA servers connected. The decision regarding centralized or decentralized should be taken on the basis of the number of systems to be maintained or the necessity of using centralized administration. The need for an AD domain is explained in detail in chapter: “Administration of Computers”.
6.3.2.1 Centralized administration (primarily of the domains) All information and settings required can be configured centrally:
• IP address • Name resolution of the IP address → host (automatic, central name registration, can finally be inquired by other network subscribers)
• Time synchronization (NTP, SNTP)
6.3.2.2 Decentralized administration (mostly workgroups) • All information and settings required must be configured locally. The IP address is used for unique identification of a network subscriber in a network.
• The computer name and NetBIOS computer name are used for unique identification of a computer for persons and applications in the network.
• The name resolution is used to convert the computer name (FQDN) and the NetBIOS computer name of a computer to an IP address.
ATTENTION
These numerated settings are the most frequent sources of errors, since typos or duplicate usage can occur easily.
Page 168 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
6.3.3 Configuration settings for all mobile devices Since all mobile devices, like tablets or Smartphones, have become more popular over the last years, these devices became also more vulnerable from a security perspective. These devices and laptops are vulnerable for thefts and this makes it easier for an attacker to get valid user credentials or to login to a protected network, because the attackers could enter with a valid UUID number of the device. To reduce that risk following recommendations must be considered:
• All devices must be protected by a password and or a PIN code. • A screen timeout and an automatic screen logout must be configured • Device must be encrypted • Password must not be stored on a mobile device
• Confidential data must not be stored unencrypted • Boot loader must not be unlocked • Do not root an Android or Apple device and do not install apps requiring root privileges • Always keep the system up to date • Do not install apps from untrusted sources • Only activate debug mode when necessary • Process confidential data only with secure applications • Do not install third party software keyboards requiring internet access • Every user must report a stolen device at once to the responsible administrator of the site facility. The administrator must remove stolen devices from the list of the accepted machines in the Active Directory.
• There is also an additional configuration part inside WinCC OA for mobile devices accessible via SysMgm panel. The stolen devices must be removed manually from the list of accepted devices. See chapter: Disable Automatic Unlock for Mobile Devices (Android and iOS) and Desktop UI and User Interface Configuration
• Please consider also information given by the BSI: o iOS System: https://www.allianz-fuer-cybersicherheit.de/ACS/DE/_/downloads/BSI- CS_074E.pdf?__blob=publicationFile&v=2 (acc.: 27th March 2019) o Android System (only available in German): https://www.allianz-fuer-cybersicherheit.de/ACS/DE/_/downloads/BSI- CS_109.pdf?__blob=publicationFile&v=8 (acc.: 27th March 2019)
Page 169 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
CAUTION
WinCC OA offers the option to locally store the password on the mobile device for comfortability reasons. Although this password storage uses an encryption mechanism, it was designed for environments with low security requirements. This feature offers a possible threat in case the device was stolen.
To avoid a negative impact, usage of this functionality is prohibited, in endowments with high security requirements!
6.3.4 Automatic user logout in OS An unattended operating station with logged in user is a security threat and could be used by attackers. It is mandatory to deploy a process which ensures that a user’s workplace is locked when the user leaves it for a couple of minutes. This process can be enforced by usage of the automatic logout feature after a time of inactivity.
Within a Microsoft® Windows OS it is recommended to configure this inactivity with a GPO. Within a Linux system it is possible to configure a bash logout inside the /etc/profile.d/timeout-settings.sh file:
#!/bin/bash TMOUT=300 readonly TMOUT export TMOUT
Alternatively, it is possible to configure this setting by a graphical interface. This configuration is usually possible within the settings menu; please consult the documentation for the Linux distribution for additional help. (e.g. for a CentOS® system this option is available within: Applications → System tools → Settings → Privacy)
Page 170 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
Administration and Configuration of WinCC OA
6.4.1 Administration of Role-Based user authorizations One of the most important security measures for any organization is the unique identification of persons and assignment of authorizations to them.
It is necessary to consider the characteristics of automation with respect to the administration of Role-Based user authorizations and their integration in the WinCC OA Security Guideline.
6.4.1.1 Difference between users and plant operators When logging in to a process control computer, a differentiation is made between logging in by the user to the operating system and logging in by the system operator or operator to the process control system.
The principle of minimum is applied when assigning all rights and authorizations. In the process, each of the users is assigned exactly those rights that he requires to fulfill his duties.
6.4.1.2 Deletion of User Accounts in WinCC OA To secure the traceability of historical data the deletion of an existing WinCC OA user is prohibited. Every operation is logged in the history with the changed values, a time stamp and the user ID of the operator. If the user is deleted the logged information with the user information will be lost. The usage of the panels for the user administration in a WinCC OA system prevents the deletion of users. There is only the way to deactivate and reactive users in WinCC OA. By deactivating a user, the user information is not removed, and the consistency is granted. A log-in attempt of a deactivated user will be blocked until the account has been reactivated.
Note:
Every active user account allows access to the system and is therefore a potential security threat. The following steps are recommended: • Reduction of configured / active user accounts to the necessary minimum • Regular verification of the configured user accounts • Usage of secure access data for the available accounts • Important: Change system default passwords as well as the “root” password of the WinCC OA project before setting the system active • Define user roles and differ between administrators and operators. A typical operator must not be able to change the system configuration.
Page 171 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
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.
WinCC OA Documentation reference
Special functions / Kerberos Authentication
As alternative the WinCC OA config entry “username” and “password” in the [general] section of the project’s config file can be used but these settings should only be used for testing purposes during the project development due to the user name and password being unencrypted inside the config file. For security reasons these config entries must be removed before deployment of the system.
CAUTION
A password for a user (especially for „root“) must not be part of the config file nor be part of a start option for a manager! The config file and the start options are plain text and the password is therefore not secure!
Page 172 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
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
WinCC OA Documentation reference
System management / Settings / Inactivity management
ATTENTION
Please consider that this functionality is not available for an ULC UX user interface.
6.4.4 Administering user rights The general principle of the user rights administration is that each WinCC OA user belongs to one or several WinCC OA groups.
The members of a WinCC OA group then inherit the rights assigned to this group. The user rights for a group are defined via permission bits. WinCC OA users and groups can be either directly created on WinCC OA level or inherited from the AD or external authentication tool (see chapter Usage of WinCC OA external authentication method). In case users and groups are created directly on WinCC OA level or inherited from the AD, the permission bits are set always on the WinCC OA level. In case users and groups are inherited from the external authentication tool, the permission bits could be set either on WinCC OA level or can be set on the external authentication tool level (depending on possibilities of external authentication tool).
Page 173 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
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.
WinCC OA Documentation reference
System management / Authorizations / Login
The best combination for security and Single Sign On comes with active Kerberos security. With the usage of Kerberos SSO is mandatory. The entire system will benefit from this higher level of security.
More extensions regarding this authorization levels can be defined with the Access Control Plug-In for WinCC OA (see chapter: Usage of WinCC OA Access Control Plug-In).
Note:
A joint configuration of SSA (see chapter: Server-Side Authentication) and SSO is not supported by WinCC OA.
The purpose of WinCC OA Single Sign On is to provide centralized sign on information (SSO principle) to the operator. A well-engineered security mechanism, by usage of the Operating system login (see chapter: Usage of Operating system (Windows or Linux) based user management) is used for this purpose. Operator’s username and password (identity) are saved as user accounts within the domain by the Operating system. They are used to authenticate an operator in a WinCC OA server project. The Role-Based operator authorizations are configured via group membership of the user/operator.
Page 174 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
Figure 69 - Single Sign On
Page 175 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
6.4.6 Server-side Authentication The feature SSA stands for a method where the user credentials are verified on server side instead of client side. Although WinCC OA uses client-side authentication in the default configuration to increase the speed of deployment and development it is strongly recommended to activate SSA for the life operation of a site. A default client-side authentication is vulnerable to an attacker because this attacker may be able to manipulate the authentication process directly and trigger a login without knowledge of correct user credentials.
Following list represents the security related ranking on usable authentication methods with WinCC OA. It starts with the most recommended authentication process and ends with the default rollout of WinCC OA. The default rollout of WinCC OA is defined to offer a maximum level of compatibility. It is in responsibility of the Integrator or the Asset-Owner to implement a suitable solution for each plant.
1. SSA for Managers with session binding with AD integration 2. SSA for User Interfaces with AD integration 3. SSA for Managers with session binding 4. SSA for User Interfaces 5. Client-Side Authentication (Default Rollout from WinCC OA) Each step of the most recommended authentication processes requires additional configuration tasks which are explained in this chapter. The suggested top two methods which represent the highest level of security maturity also require knowledge regarding the Active Directory implementation (see chapter: Usage of Operating system (Windows or Linux) based user management).
6.4.6.1 Server-side Authentication for User Interfaces Although the default login mechanism offers a practical security implementation it is possible to increase the level of security by usage of the SSA feature. The reason for the improvement is that the password check is done on the client in the default configuration after a creation of a new WinCC OA project. An attacker - with development knowledge - could hack the default and client-side login mechanism to set up a connection with any user (privilege escalation) and without knowledge of a correct password.
This threat can be avoided with SSA feature which needs a running WinCC OA HTTP-Server and specific config entries on client and server side. For a logon, the WinCC OA HTTP-Server provides a dialog where the user credentials need to be entered in a form. Those credentials are used to save a token in the database and to check the user credential directly on the server. The following picture shows an explanation of the login process and compares it with the default WinCC OA user authentication.
It should be considered that a successful Login is only possible for unlocked devices, see chapter: Disable Automatic Unlock for Mobile Devices (Android and iOS) and Desktop UI
Page 176 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
Figure 70 – Compare SSA login process with WinCC OA default mechanism
Page 177 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
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
WinCC OA Documentation reference
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”).
WinCC OA Documentation reference
Special functions / Security / Server-side Authentication
The following config entries are required for the specific machines.
Page 178 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
PenTestSRV01
[general] accessControlPlugin = "AccessControlPluginUser"
[webClient] clientSideAuth = 0
[httpServer] uiArguments = "-p vision/login.pnl -centered -iconBar -menuBar -server https://PenTestSRV01"
PenTestSRV02
[general] accessControlPlugin = "AccessControlPluginUser"
[webClient] clientSideAuth = 0
[httpServer] uiArguments = "-p vision/login.pnl -centered -iconBar -menuBar -server https://PenTestSRV02"
PenTestWeb:
[general] accessControlPlugin = "AccessControlPluginUser" data = “PenTestSRV01$ PenTestSRV02” event = “PenTestSRV01$ PenTestSRV02”
[ctrl] #configuration entry for redundant WinCC OA servers connectToRedundantHosts = 1
[webClient] clientSideAuth = 0
[httpServer] uiArguments = "-p vision/login.pnl -centered -iconBar -menuBar -server https://PenTestWEB/"
Page 179 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
PenTestClient:
[general] accessControlPlugin = "AccessControlPluginUser"
Start the UI on the client with following parameter for a Remote UI. The –ssa parameter avoids the creation of a cache folder which is only required by a Desktop UI.
-p vision/login.pnl -server https://PenTestWEB -ssa
A login dialog will open afterwards, and the user credentials are requested. Please note that login as root user is disabled with activated SSA feature.
6.4.6.2 Server-side Authentication for Managers with session binding Beside Server-side Authentication for User Interfaces, it is also possible to extend this feature with session binding for WinCC OA managers. This method stands for a higher level of security compared to the method explained in chapter Server-Side Authentication for User Interfaces. If manager binding is used, the Event Manager remembers the user, who initialized the connection. So, it is not possible to exchange the user ID in the messages at the client. e.g.: user connects as user “guest”, but the hacker changes the user ID to “root” every time before a message is sent. With message binding this is not possible, because the Event Manager will close the connection. To verify the usage of the correct user it is necessary to ensure that non-repudiation requirements are fulfilled. This is achieved via usage of signatures for the specific user (see chapter: Signing). To configure the usage of the signatures it is necessary to create own certificate files for the user which should start this process. With this setting it is possible to start a WinCC OA Process like a CTRL Manager or an ASCII Manager with a User with limited access permissions. This means that it is not necessary to execute all WinCC OA manager processes as root user what may be misused for a security attack vector.
6.4.6.2.1 Example for file-based Manager SSA certificates As an example, it is possible to generate the required certificates with the implemented certificate creation panel from WinCC OA (see chapter: Create own openSSL certificates). The following screenshot shows how a certificate can be created for the user “para”. As CA the certificate for WinCC OA multiplexing proxy is used:
Page 180 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
Figure 72 - Create certificate for SSA with session binding
The “Rule/User” field represents the user for this certificate and the “Certificate/key Name” field defines the name of this certificate. This example will create two files with the names:
• CertPara.key → Private Key • CertPara.crt → Public Key For the activation of SSA with Manager Session binding following entries should be configured in WinCC OA config file:
[general] #activate SSA with session binding accessControlPlugin = "AccessControlPlugin" #use public key for CA as chain file ssaChainFile = "root-cert.pem" #configure public and private key for user para ssaPrivateKey = "file:CertPara.key" ssaCertificate = "file:CertPara.crt"
[webClient] clientSideAuth = 0 httpAuth = 1
Page 181 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
This configuration makes it mandatory to start all processes as the user para. If any process is started as a different user (e.g.: root) it fails, and an error message is displayed. For cases where specific manager should be started using another account it is possible to configure this in the related section of the config file. So, it is possible to create an own certificate for the user “root” and if the processes WinCC OA Data- and Event Manager should run as root user following config entries are necessary:
[event] ssaPrivateKey = "file:Certroot.key" ssaCertificate = "file:Certroot.crt"
[data] ssaPrivateKey = "file:Certroot.key" ssaCertificate = "file:Certroot.crt" A remote WinCC OA host which establishes a connection to the configured WinCC OA server needs the same entries in the related section. Following configuration is needed if a remote CTRL Manager should relate to the WinCC OA server:
[general] pvss_path = "C:/Siemens/Automation/WinCC_OA/3.16" proj_path = "C:/Projects/316_Manager_SSA" proj_version = "3.16" langs = "en_US.uft8" data = "pentestsrv01" event = "pentestsrv01" accessControlPlugin = "AccessControlPlugin"
[ctrl] ssaChainFile = "root-cert.pem" ssaPrivateKey = "file:CertPara.key" ssaCertificate = "file:CertPara.crt"
[webClient] clientSideAuth = 0 httpAuth = 1 It needs to be noted that there is no entry for the User Interface in this config file to allow a login for different users on the same UI host.
Page 182 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
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 (acc.: 27th March 2019). 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 Enhanced RSA and AES Cryptographic Provider" openssl pkcs12 -export -in SSAroot.crt -inkey SSAroot.key -out SSAroot.pfx -CSP "Microsoft Enhanced RSA and AES Cryptographic Provider" The created certificate files can be imported into the Windows certificate store. CAroot.pfx needs to be imported into the “Trusted Root Certification Authorities” and it is recommended to import SSApara.pfx into the Personal certificates of the Local Computer store.
ATTENTION
During the import it is essential to mark the private key as exportable to make the certificate readable by WinCC OA processes.
Page 183 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
Figure 73 - Windows certificate Store with SSA certificates for Manager
Page 184 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
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.
WinCC OA Documentation reference
Special functions / Security / Authentication / Server-side Authentication for managers ATTENTION
The creation of a signature to the messages requires the existence of private key on the remote machines. This makes it necessary to protect this file with OS methods. Additional it is recommended to use the OS based certificate store (see chapter: Storage of openSSL certificates and private keys)
Page 185 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
6.4.7 WinCC OA Server Configuration According to definitions in chapter Security Cells and Network Architecture it is recommended to run a WinCC OA server only in a secure environment. Server related WinCC OA processes that runs in a secured environment shall be protected in multiple ways:
• Protected physical access (e.g. locked room, place with additional access control device, …) • No devices for accessing the system (e.g. USB stick, CD/DVD drive, bluetooth, …) • Plant network access only (no access from public network) Control- and API Managers usually have common task to fulfill and they do this as root user, in the default configuration. With the default configuration the servers need to be secured to avoid unauthorized access.
It is possible to reduce the security risk caused by usage of the root user by using certificates for each WinCC OA manager. This feature allows the creation of Manager Certificates for a specific user, which is configured due to the least privilege’s requirements. Further information is available in chapter: Server-Side Authentication for Managers with session binding
Network topology should ensure that the server for Control and Api Managers cannot be accessed from public but only from plant network (e.g. in DIN EN 50159 named as “Category 2 network”) so that unauthorized access via network can be excluded. For network configuration see chapter: Administration of networks and network services.
Page 186 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
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 Documentation reference
WinCC OA UI
WinCC OA contains the following types of User Interfaces:
• Remote UI as Engineering Station (with Vision-, GEDI- and Para module) for Desktops and Notebooks
• Remote UI as Operator Station (with Vision module) for Desktops and Notebooks • Desktop UI for Desktop and Notebooks • ULC UX for Desktop and Notebooks • Mobile UI for Android and iOS • Operator for iOS • Siemens ITC (Industrial thin client) for Siemens HMI …that can be connected using one of the following network configurations:
• Local LAN (without connection to the internet) • Local WLAN • LAN using VPN through internet connected network • LAN/WLAN connected to internet with own firewall and proxies • LAN/WLAN connected to internet with external firewall and proxies WLAN generally is a dangerous means of networking as the information is spread all over the surrounding where an attacker can easily make trials to compromise the attached devices. Therefore, it is generally recommended to not use a WLAN device in a secure plant operation environment.
ATTENTION
For local communication between WinCC OA UI and embedded graphic modules like WebView.ewo, an unencrypted http communication channel is used. The host which executes the WinCC OA User interface module needs to be protected. Target is to prevent a situation where this unencrypted connection is harmed by malicious software which is locally installed directly on the UI host.
See chapter Virus Scanner to find ways to avoid this threat.
Page 187 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
6.4.8.1 Intended operational environment (UI)
• Remote UI is applicable for clients that are physically secured: access is restricted, secure login (e.g. AD with appropriate settings, two-factor-authentication …), plant network only and OS hardening (see chapter: Hardening). This installation can be used for all purposes.
• Desktop UI connects via HTTPS to the WinCC OA HTTP-Server; the required data (configuration, certificates and project files) is downloaded from server but held locally. OS must be hardened (see chapter: Hardening), if network is connected to internet a network connection via VPN is required. This installation should not be used for administration purposes but for operator or viewing access.
• ULC UX may be used on any kind of computer as there are no local files hosted; the network connection is secured using HTTPS. The computer should not be a public computer (e.g. internet coffee shop) as the device could be compromised, the connection parameter and the credentials could be stolen (e.g. SSO and other precautions can mitigate the danger of a key logger).
• Mobile UI Application is designed to work in a WLAN, so mobiles must be avoided in secure plant operation environment. In this context the WinCC OA Operator App is also seen as Mobile UI.
As Matrix: physically secured Administered Client Administered Client Public WLAN host host host in plant network host in public network Remote UI All functions Operator functions Restricted functions Not secure Desktop UI All functions Operator functions Restricted functions Not secure ULC UX All functions Operator functions Operator functions Restricted functions Mobile UI N/A Not secure (WLAN)1 Not secure (WLAN)2 Not secure (WLAN)3 Operator APP Table 14 – Matrix for UI in intended operational environment
Legend:
1. All functions → Complete functionality is secure for operator and administrative access 2. Operator functions → Functionality is secure for operator access 3. Restricted functions → Functionality is only secure for limited operator access (e.g. only read functionality) 4. Not secure → Usage of this UI method must be prohibited to avoid a security risk.
1 Mobile devices are designed for a WLAN environment. This field refers to a secured WLAN environment.
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.
Page 188 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
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.
WinCC OA Documentation reference
WinCC OA UI / Mobile UI Application / Device Management
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.
WinCC OA Documentation reference
Installation / Windows / Branding of the WinCC OA MSI Installation
Regarding aspects of security the following points must be considered for this process:
• Use WIX software (http://wixtoolset.org/ (acc.: 27th March 2019)) >3.10.2 to avoid dll hijacking • The new installation folder must not contain blanks in an unquoted path, this could result into a security threat if the WinCC OA project is started as a service: http://www.commonexploits.com/unquoted-service-paths/ (acc.: 27th March 2019)
• The integrator should digitally sign the branded installation (see chapter: Digital signatures for binaries and libraries)
Page 189 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
6.4.10 Configuration Settings for WinCC OA Video (vimaccOA) WinCC OA provides universal video management software for transmitting, displaying or archiving video data. The required components are optionally installable via WinCC OA setup (vimaccOA). These components are defined as external vendor parts and named as Video Management System (VMS). The following figure shows how WinCC OA and VMS parts interacts to implement WinCC OA Video.
Figure 74 - Interaction VMS and WinCC OA (Accellence Technologies, 2018)
Visible in the legend are three different types of communication:
1. Inter-Process-Communication (IPC). Inter-process communication in vimaccOA means the data connections between the existing processes. These connections are used to adjust the so-called "config", which (within the VMS) enables system-wide data exchange via data points. If an attacker can penetrate this communication, he receives system-wide read and write access to the data points. To avoid this threat an AES-128 encryption algorithm is implemented. The required certificates are installed during vimacc® setup process. This setup process uses a Video Security
Page 190 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
Wizard to create and deploy a file-based certificate. The correct deployment is in reasonability of the Administrator on side of the asset owner.
Figure 75 - Video Security Wizard
The file based secret key is stored in following folder and this folder needs to be protected via OS measurements:
• VIMACC® Process host: [vimacc® install folder]/data/features • WinCC OA Server host: [WinCCOA project folder]/data/videoOA
2. Vimacc® Control Interface (vCI). For data synchronization with higher-level control systems, such as the SCADA system "WinCC OA", the VMS "vimacc®" of WinCC OA Video provides a corresponding control protocol. This control protocol not only serves to control the system but also transmits status information from the video system to the control system. If an attacker is able to penetrate this communication, he receives the same possibilities as when attacking the IPC connections. To avoid this issue an encryption mechanism is implemented which protects the communication in the same way as for the IPC configuration.
3. Video data (Streaming & Record). In addition to the control and synchronization connections, a VMS mediates and distributes numerous video data. This is done to display live images in the form of continuous video streams and to play back records in the form of a dedicated transmission of data blocks - so-called GOP's (Group of Pictures). If an attacker succeeds in penetrating this communication, he gets access to the image material as well as the possibility to introduce fake video data into the system. A complete encryption helps to avoid this threat. A solution is implemented via Crypto Tokens (CTK) consisting of a public and a private key which uses an RSA-2048 algorithm. This token is generated via Security Wizard for a specific facility; the deployment of this CTK is done via vimacc® system and configuration of all configuration server is in responsibility of the asset owner. Details regarding the implementation are available in following figure.
Page 191 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
Figure 76 - CTK Implementation
The AES-128 Assetkey and the Crypto Token (CTK) are created via vimacc® Security Wizard and the Token is encrypted by the AES-128 Assetkey. This encrypted CTK is stored and distributed via vimacc® system. Beside of WinCC OA this CTK is read via WinCC OA Video Manager API Interface and the information is stored as an encrypted blob on a WinCC OA datapoint.
After establishing of a new streaming interface, a session related AES-128 streaming key is created. This streaming key is only valid for the current session. This AES-128 streaming key is encrypted via RSA-2048 CTK. The created key is used to encrypt the Video Datablock (GOP) and to create a SHA-1 hash.
The WinCC OA Video UI reads the encrypted key from the datapoint element “_VIDEO_OA_MAIN.driver.encryption”. In a first step checks the hash, decrypts the Data block and finally decodes the GOP. This makes the Video Stream readable for a human operator. This implementation ensures a complete encryption from Camera to the operator. As already mentioned, the information on this datapoint was written by the CTK deployment process. An alteration of this datapoint makes the Video Stream not readable for the operator. And so, it is recommended configuring “_auth” configs to prevent the system from a manipulation (see chapter: Protection via authorization levels in WinCC OA).
The figure shows also that a Camera interacts to the VMS Streaming Interface before the Video data is available within the WinCC OA system. It must be mentioned that this communication should be encrypted in a secure environment. The implementation was tested via Cameras from Axis Communications (https://www.axis.com acc.: 27th March 2019) where an encryption functionality can be offered.
Page 192 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
Detailed information is available within the WinCC OA documentation:
WinCC OA Documentation reference
Add-ons / Video
ATTENTION
For usage of video cameras following recommendations must be considered:
• The viewing area of a camera must not be able to track the input of a password on any device of the observed area.
• Default passwords of a camera should be changed directly after the commissioning of a new camera.
• A wired connection to a camera must not be useable to start a Man in the Middle attack. • Wireless configuration should use a secure and encrypted transfer protocol (e.g. WPA2- Enterprise) which is in addition protected via a VPN connection. It is also recommended to use only an encrypted and wired connection (no WLAN) for Video streams which contain sensitive information.
• Enable encryption within the security camera administrative tools. It is essential that a camera delivers a reliable picture which is prevented from altering. Do not use a camera in a security relevant area if an encryption feature is not available.
• Protect the administration software for the camera with a password (see: Password strength). • Update camera firmware frequently or whenever necessary depending on advisories given by the camera vendor.
• Limit the exposure of a camera to the local network in a security relevant environment (make remote access via Internet only possible by usage of a VPN connection).
Page 193 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
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 (acc.: 27th March 2019). Although most of the vimaccOA implementation is not affected by most of the descripted vulnerabilities, it may be possible that the module VMS Streaming interface may be affected for USB cameras. In a case of a vulnerability an assertion may occur which disconnects all video streams from the same interface-instance. To mitigate the risk, it is possible to configure the usage of an USB camera with a separate interface- instance. This will only affect the USB cameras but has no negative effect to the remaining system.
Page 194 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
6.4.11 Example configuration of TLS in WinCC OA TLS communication is implemented in WinCC OA by usage of WinCC OA Multiplexing Proxy (mxProxy). This manager is used as a central communication point to reduce the amount of open ports for each host and to ensure an encrypted communication.
The following figure gives a centralized overview for a communication from an untrusted zone to a trusted zone via a DMZ. This figure shows where a communication is encrypted and where it is not encrypted. It also shows the places where TLS certificates are required to ensure this communication method. The name of file-based certificates is only explained in DMZ and for the CA.
Page 195 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
6.4.11.1 Example with remote mxProxy Following solution shows an example where WinCC OA httpServer and WinCC OA mxProxy are running within the DMZ.
• Advantage: WinCC OA mxProxy as predetermined breaking point running on a separate machine • Disadvantage: Unsecure connection must be secured via IT Infrastructure measures.
Figure 77 - Communication Methods in WinCC OA with remote mxProxy
Page 196 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
The example above named as Figure 77 - Communication Methods in WinCC OA with remote mxProxy shows following content:
• A domain controller with DNS, KDC and a CA is configured. Private keys for CA remain on AD controller.
• Three different UI’s can establish a secure communication to WinCC OA server via a DMZ o WinCC OA ULC UX Client needs no certificate. It accepts the CA public key from httpServer in “Trusted Root Certification authorities” to establish a connection to WinCC OA httpServer. Port 443 is required for Front End Firewall. o DesktopUI and MobileUI get the CA public key from httpServer during the installation of a WinCC OA project into local user cache. This setup copies also the required certificates for mxProxy communication (public CA certificate, public Host certificate, private Host key). A DesktopUI and a MobileUI need to establish a connection to WinCC OA httpServer and to mxProxy. Port 443 and 5678 are required for Front End Firewall. o RemoteUI is installed manually on a designed client. The required certificates for mxProxy communication need to be copied manually (public CA certificate, public Host certificate, private Host key). A RemoteUI establishes a connection via mxProxy. This remote UI can establish a secure connection to the Oracle Server if an Oracle Client is installed and this client communicates to the Oracle server via a secured connection. Port 5678 is required for Front End Firewall
• A remote WinCC OA project within an unsecured network can establish a connection to the secure network as well.
• Communication between all UIs and WinCC OA mxProxy is completely secured.
• DMZ Zone contains a WinCC OA httpServer and a WinCC OA mxProxy host. Both are required to establish a communication between the untrusted and the trusted zone.
• WinCC OA httpServer in DMZ communicates via secured port 443 to WinCC OA httpServer in WinCC OA server project. Port 4897 and Port 4998 are required for Back End firewall to establish an unsecured connection between the CTRL-Manager from httpServer in DMZ to Data- and Event Manager from WinCC OA server in secured zone. Port 443 needs to be configured for Back End Firewall and ULC-UX reads WinCC OA panels from WinCC OA Server via secured port 443.
• WinCC OA mxProxy receives all communications via Port 5678. The ports 4897 (data), 4998 (event), 4777 (dist) need to be configured on Back End Firewall. This means that this communication is unencrypted.
• Trusted Zone contains a WinCC OA server with Data- and Event Manager but not a mxProxy. Config entry mxProxy is configured with “none”
• Oracle Server operates in the trusted zone and has a connection via WinCC OA RDB manager to WinCC OA server project. Oracle itself provides remote clients with data which are configured with “queryRDBDirect=1”. This is a config entry which allows the client to query data directly from Oracle server (via VPN Tunnel) to avoid a detour via Data-Manager on WinCC OA server.
Page 197 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
6.4.11.2 Example with local mxProxy Following solution shows an example where only WinCC OA httpServer runs in a DMZ but WinCC OA mxProxy runs local on WinCC OA Server.
• Advantage: No unsecure connection • Disadvantage: WinCC OA server could be attacked because determined breaking point mxProxy runs local on the same machine as Data- and Event Manager.
Figure 78 - Communication Methods in WinCC OA with local mxProxy
Page 198 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
The example above named as Figure 78 - Communication Methods in WinCC OA with local 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 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.
• 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.
• WinCC OA mxProxy runs locally on secure WinCC OA server.
Page 199 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
6.4.11.3 Example with local mxProxy and remote Apache Reverse-Proxy The following example shows mostly an equal configuration compared to chapter Example with local mxProxy, but with an Apache Reverse-Proxy as determined breaking point. This is the solution with the highest level of security from the selected examples. (see chapter: Hide secure network behind a Reverse Proxy).
• Advantage: No unsecure connection and Apache Server as determined breaking point. • Disadvantage: Additional Apache Reverse-Proxy Server required.
Figure 79 - Communication Methods in WinCC OA with local mxProxy and Apache Reverse-Proxy
Page 200 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
The example above named as Figure 79 - Communication Methods in WinCC OA with local mxProxy and Apache Reverse-Proxy shows following content:
• A domain controller with DNS, KDC and a CA is configured. Private keys for CA remain on AD 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. • 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.
• WinCC OA mxProxy runs locally on secure WinCC OA server.
Page 201 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
Patch management and security updates Most of the security breaches are performed via security holes that have already been patched by the software producers. Only in rare cases a zero-day exploit is used in which a weakness is used which is not officially known or where no patch is available. A centralized patch management aids the distribution of patches.
Note:
In this document ETM professional control GmbH can only give a few general recommendations for specific cases but an overall security guideline for this topic can be given by international standards.
A common standard in IACS environment is this document: IEC/TR 62443‑2‑3, Industrial communication networks – Network and system security – Part 2-3: Patch management in the IACS environment.
Patch management is the scheduled procedure for installing patches on plant computers. The following issues need to be clarified at the time of planning:
• Which patches need to be installed? • Which tests are used for the patches before installing them on the plant? • When will these patches be installed? • What is the sequence in which these patches are installed? • How should these patches be installed on the plant computers? The patch management of a system is effective only if it is a part of a comprehensive security concept. The exclusive use of patch management and security updates cannot protect a system from security threats. As soon as information regarding a weakness is available the relevance for the own application must be evaluated. Depending on the evaluation it must be decided if further steps are required:
• No action, existing security measurements are enough
• Add additional external measurements to ensure the security level
• Installation of current software updates to eliminate the weakness
Page 202 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
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.
WinCC OA Documentation reference
Project administration / Project administration / Update or patch project
For Siemens automation components like a PLC which does not use default PC operating systems it can be necessary to correct security related issues through a firmware update. Corresponding information can be found on the Siemens Industrial Security Website: http://www.siemens.com/industrialsecurity (acc.: 27th March 2019)).
6.5.2 Use of the patch management Patch management should not impair the process operation of a plant. To ensure this, the following configurations are tested and recommended:
6.5.2.1 Centralized patch management From both the administration and security points of view, patch management should be done centrally. A central server, preferably located in the perimeter network, downloads the patches from trusted sources and distributes them in the internal network. In this manner, a centralized configuration and monitoring system is available to the Plant administrator. The plant computers do not require internet access. The patch server is placed in a perimeter network isolated by a firewall. On this server new patches are downloaded from the internet.
Page 203 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
6.5.2.2 Windows It is recommended to use WSUS for centralized patch management. This is made available by Microsoft® free of charge and provides all functions that are required for patch management. The WSUS offers a variety of different patch classes for almost all Microsoft® products The loaded patches can be distributed to the plant computers by using a SCCM server. Any automatic synchronization or restart of the updated computer should be prevented due to undesired influence on the whole plant. Instead the update should be performed manually at a predefined date. See chapter: Procedure for Patch Management
6.5.2.2.1 Prerequisites for WSUS server Following parts are required by a WSUS server:
• Every computer needs an Ethernet connection to the WSUS server
• Windows OS is mandatory for WSUS and SCCM • Internet access for WSUS server required to deploy Microsoft® updates • SCCM is necessary to deploy software like Anti-Virus software or WinCC OA Patches. • A single SCCM server could assume the combined functionality as WSUS and as SCCM server but it is recommended to separate those functionalities
6.5.2.2.2 Patch classifications for WSUS server With the introduction of the WSUS and the extension of Windows Update to Microsoft Update (Patches for a large number of Microsoft® products), new classifications have been introduced for the individual patches (https://support.microsoft.com/en-us/kb/824684 (acc.: 27th March 2019)):
• Critical updates • Definition Updates • Drivers • Feature Packs • Security Updates • Service Packs • Tools • Update • Update Rollups • Security-only updates • Monthly Rollup • Preview of Monthly Rollups
Page 204 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
The following update classes are particularly important for secure and stable operation of a system:
• Security Updates: A widely released fix for a product-specific, security-related vulnerability. Security vulnerabilities are rated by their severity. The severity rating is indicated in the Microsoft® security bulletin as critical, important, moderate, or low.
• Critical Updates: A widely released fix for a specific problem that addresses a critical, non-security- related bug. These two update classes must be subjected to a compatibility test with the respective WinCC OA version and classified as compatible after a successfully conducted test executed by the Integrator or asset owner.
Patching the systems is not the only security measure used to protect a system or the entire corporate network. By implementing an in-depth defense (use of all security techniques described in this Security Guideline), a potential hacker must first overcome several security levels before he could exploit any vulnerable spots of a missing security update. This protection gives extra time for evaluating and testing the patches to be installed.
6.5.2.2.3 Procedure for Patch Management for WSUS Server Since maintaining control over the process is the most important principle, the administrator must specifically choose the time at which the patches are installed. To validate the integrity and functions of a patch it is recommended to install the patch on a test system equal to the live system before installing the patch for the live operating plant. Furthermore, plant specific adjustments can be necessary if default functions have been changed.
In addition, groups should be formed (for example, one group with all master servers and one with all standby servers) and install the patches group by group.
Page 205 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
The creation of back-ups must be considered. Every change of the configuration, e.g. installing a patch, can create unexpected and negative impacts on the system. In such a situation the best case is to import an existing backup to revert to the initial state.
Figure 80 - Usage of WSUS server
6.5.2.3 Linux Due to the natural fragmentation of existing Linux OS systems different mechanisms are available to update an existing machine. Usually at least a packet management tool like APT, APT-GET, YUM or ZYPPER needs to be installed. This upgrade is possible by manually triggering the specific functions. Please note that following operations need root permission for execution and therefore the following examples are triggered with the sudo command.
• Upgrade with yum package (usually in CentOS® / RedHat® machines) o sudo yum update o sudo yum upgrade
• Upgrade with apt-get package (usually for SuSe Linux Enterprise Server(SLES) Linux machines) o sudo apt-get update o sudo apt-get upgrade Both operations check if new updates for installed packages are available and start the installation after a manual confirmation.
Page 206 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
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 (acc.: 27th March 2019)
6.5.2.3.2 Activate automatic upgrades Like for Windows it is also possible to activate the automatic upgrade procedure within a Linux system.
Automatic upgrade with yum package (usually in CentOS® machines)
• Install the required package by the following command: o sudo yum -y install yum-cron o Edit the configuration file to apply any specific requirements in this file: /etc/yum/yum-cron.conf More information: https://linuxaria.com/howto/enabling-automatic-updates-in-centos-7-and-rhel-7 (acc.: 27th March 2019) Automatic upgrade with apt-get package (openSUSE®)
• Install the required package by the following command: o apt-get install unattended-upgrades apt-listchanges o Edit the configuration file to apply any specific requirements in this file: /etc/apt/apt.conf.d/50unattended-upgrades More information: https://wiki.debian.org/UnattendedUpgrades (acc.: 27th March 2019)
Page 207 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
Virus Scanner The use of virus scanners within a system is effective only if it is a part of a comprehensive security concept. In general, the use of a virus scanner alone cannot protect a system from security threats.
Definitions:
• Virus scan server A computer that administers the virus scan clients centrally loads the virus signatures and distributes them on the virus scan clients.
• Virus scan client A computer that is checked for viruses and is administered by the virus scan server.
6.6.1 Use of virus scanners The use of a virus scanner should not impair the process operation of a plant. Ultimately, this leads to the fact that a virus-inflicted computer should not be shut down automatically and immediately, if as a result, control over the production process would be lost. Therefore, the following requirements must be met by a virus scanner for use in industrial automation and control systems (IACS):
• If a local firewall, adapted to the process operation, is being used, it must be possible to install the virus scanner even without its own firewall.
• The virus scan clients may be divided in (product-related and task-related) groups and configured separately.
• It must be possible to disable the automatic distribution of the virus signatures and other updates.
• It must be possible to distribute the virus signatures and updates manually and group-wise. • It must be possible to scan files and the system manually and group-wise. • In case a virus is detected, if is recommended to configure a message without any file-related action such as, for example, "Delete", "Clean" etc. being carried out automatically.
• It must be possible to log all messages on the virus scanner server. • It must be possible to suppress the local message window on a virus scan client since it could overlap important process control system messages.
Note:
Software installation is often a procedure that represents a serious and complicated system change to the respective system. The files to be installed must always be virus-free (e.g. a file server with its own virus scanner or a DVD checked for viruses). A virus scanner should not hinder the installation unnecessarily or, in fact, corrupt it. Hence, it must be possible to disable it completely if problems occur during installation.
Page 208 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
6.6.2 Principle architecture of a virus scanner ETM professional control GmbH recommends the simplified virus scanner architecture illustrated in the following to realize the demands mentioned in the previous section.
The virus scan server receives the virus signatures from the internet and from the update server of the respective manufacturer or from a supervisory virus scan server and administers the virus scan clients.
Figure 81 - Virus Scan Overview (Siemens, 2019)
It is possible to use multiple virus scan servers depending on the manufacturer. These may also be arranged hierarchically.
Page 209 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
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.
WinCC OA Documentation reference
Installation / Requirements for WinCC OA / Software requirements / Paragraph: Virus scanner
Page 210 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
Additional to the architecture of the Anti-Virus deployment system following steps should be considered regarding the recommendation from ICS-cert with the “Updating Antivirus in an Industrial Control System” document:
• Verify the source of the update. • Download the update file(s) to a dedicated host (server or workstation). • Scan the downloaded file(s) for malware. • Verify the cryptographic hash of each downloaded file(s). • Scan the removable media for malware or other unexpected data before use to verify its integrity. The most secure options are to securely erase the removable media and reformat the drive with the appropriate file system (for flash or magnetic media) or to use a new CD or DVD (for optical media) for each update
• Write the file(s) to the removable media. Dedicate this media exclusively for updates. • Lock the media so others cannot write to it. • Load the media into the test environment and verify that it has no adverse impact to the test system. • Re-scan the media for malware or other unexpected data to verify that nothing transferred to the re- movable media from the test environment host.
• Install the update on a non-critical endpoint or segment of the system and verify that it has no adverse impact to the production system.
• Install the update on the remaining hosts. • Monitor the system for any unusual behavior and verify proper operation of the ICS. (ICS-Cert, 2018, S. 2)
Page 211 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
Logging, audit, maintenance and asset management The capability of detecting attempted and actual security threats is rapidly developing. Due to the requirements for verification in many branches, reporting and event log evaluation must be increasingly included in current security concepts. Runtime must continue without interference despite the added load, however.
The following reporting can be configured and evaluated as needed, in addition to the alarm and messaging systems of process control for example:
• Local event logs
• Event logs of the domain controller
• Event logs of the firewall(s)
• Event logs of the virus scanners
• Audit trail (e.g. configurable in Windows)
Asset management in plant technology refers to the management of equipment as well as the activities and measures that serve to maintain or enhance the value of the plant.
Asset management is a very sensitive subject in the field of security engineering, since this data also presents a weak point in a plant. In general, asset management and its administrative rights should be restricted to the functional area within the plant's security cell.
The procedures described in the paragraph on Secure Access Techniques section can be used to publish maintenance data beyond the borders of the security cell. This reliably prevents direct access from the outside – for example, to sensors or actuators on the field level.
6.7.1 Observe audit logging and transmit information to WinCC OA Via SNMP Agent it is recommended to define suspicious messages (e.g. Windows event log or Linux system logs) on OS level.
The tool should mention the following messages:
• Host Log Files (Windows Event logs or Unix/Linux system logs) • Failed authentication (log on) attempts recorded in the security log • Successful authentication to unknown or dormant accounts or from unknown hosts recorded in the security log
• Authentication attempts outside office hours • Unusual high number of log entries in each time frame or many errors logged • Execution of untypical commands or functions • Gaps in or erasure of system logs Occurrence of such messages in a live system should trigger an SNMP trap. This message needs to be transmitted to WinCC OA and raise a visible Alarm for the operator in WinCC OA Alert screen. With this information it is possible to start countermeasures to protect the system from a possible attack.
Page 212 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
6.7.2 Implement Intrusion detection system A good analysis of the overall system is the implementation of an intrusion detection system (IDS). This is a device or software application that monitors a network or systems for malicious activity or policy violations. A detailed description including reference for available products is given by the Wikipedia article: https://en.wikipedia.org/wiki/Intrusion_detection_system (acc.: 27th March 2019)
It is recommended to analyze the interface and to check if a transfer of an occurrence is possible via SNMP trap or any other protocol message which is readable by WinCC OA. With this message it is possible to trigger further activities inside WinCC OA to inform the operator about suspicious activities in the system.
List of possible several threats which may be detected by an IDS system:
• System Resources o Usage of system resources for potential illegal/unknown actions (e.g. unknown data or data not related to regular system operation is found on storage media/shares, high CPU usage) o Exceptional high network load (e.g., machines on network sending data consuming resources on other systems) o Exceptional slow or irregular system performance o Unexplainable system crashes
• Applications & 3rd party software o Detection of malware on the system by antivirus software o Host firewall blocks and reports suspicious activity o Presence of unfamiliar software applications o Unfamiliar processes running o Unexplainable errors reported by 3rd party applications (e.g., by database server, Webserver)
• Network Log Files o Network scans (connection attempts to many IP addresses or multiple ports) originating from a single host o Outgoing HTTP connections to suspicious Websites o Large volume of outgoing traffic o Connection attempts to ports blocked at the perimeter firewall o Log entries show network traffic outside office hours
• Users o Presence of new accounts not created by administrators o Unexplained use of privileges at OS or application level (functions or applications running with other privileges than normal) o Locked user accounts not based on user’s fault o Compromised user accounts (e.g., user account activity detected without original user presence)
Page 213 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
• System Changes o Unexplainable deletion or replacement of files needed by OS or application (e.g., DLL) o Unexplainable presence of new files o Existence of large unknown data files o Modifications of the hosts file %SystemRoot%\system32\drivers\etc\hosts, in particular large number of entries pointing to the loopback address 127.0.0.1 o Suspicious active services, services with suspicious names or missing or incomplete service description o Terminal Services service is active o netstat shows unknown open ports in the “Listening” state o netstat shows a large number of outgoing connections in particular to TCP ports 22 (SSH), 139 (NetBIOS) or 445 (SMB) The complete list is given by the Wikipedia article: https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers (acc.: 27th March 2019)
• Others o Unusual behavior after plugging in external media (e.g. USB stick, hard disk) o Publication/leakage of internal system data on external Websites
Page 214 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
Security tests Security measures are checked regularly, updated and supplemented, if required. This is necessary, on one hand, since the fast-developing technology needs new security measures, and on the other hand, new threats keep coming up.
Network administrators can perform automatic tests of the target system with the help of so-called "Security Scanners". The security scanners are accessing special databases, e.g. those of the SANS institute (SysAdmin, Networking and Security). Those databases hold lists of security gaps currently known and widespread, e.g. the list of CVEs (Common Vulnerabilities and Exposures). The security scanners test if any known vulnerable spots are present in the system being checked.
Security scans are basically divided in four categories:
• Blackbox scan • Whitebox scan • Penetration test • Vulnerability Scanning (Nessus, OpenVAS)
6.8.1 Knowledge of Security Testing The rapid digitalization of critical infrastructure poses a wealth of new security challenges, which requires new ways of security testing. Comprehensive education and experience are essential for a Security Tester to implement a holistic Security Testing concept for a plant or a project. Therefore, it is essential to implement a training concept for Security Testers.
A proper education can be given by the International Software Testing Qualification Board (ISTQB): http://www.istqb.org/certification-path-root/advanced-security-tester.html (acc.: 27th March 2019)
Another guides regarding security testing can be given by the Open Web Application Security Project (OWASP): https://www.owasp.org/index.php/Testing_Guide_Introduction (acc.: 27th March 2019)
6.8.2 Blackbox scan The Blackbox scan refers to testing a target system for vulnerabilities to security, from the viewpoint of a hacker who does not have any system-internal information. In a Blackbox scan, the system is considered as a closed unit, i.e. neither the configuration nor the network structure of the target system is known.
In a Blackbox scan, points of attack identifiable externally are detected as vulnerable spots (e.g. open ports, accessible services …). Other hacking options that the system offers to the hacker after exploiting these vulnerable spots remain unidentified.
Page 215 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
6.8.3 Whitebox scan In contrast to the Blackbox scan, the Whitebox scan uses system-internal information. The target system is tested for existing vulnerable spots. In this case, it is from the viewpoint of an administrator. A Whitebox scan (also called glass box scan) tests individual components of the system and their interactions and determines any configurations that are critical with respect to security. The Whitebox scan also detects hazards, which, for example, exist because of outdated versions of user software or are attributable to negligent user account administration.
An example for a Whitebox scan is the Microsoft® Baseline Security Analyzer (MBSA). It can be used for the following purposes in addition to other tasks:
• Searching one or more computer for vulnerabilities from poor user management, for example
• Determination of the availability of security updates for one or more computers
• Searching for vulnerability caused by misconfigured Access Control List (ACL) which may be used for a tampering attack by a criminal attacker.
6.8.4 Penetration tests Penetration test tools are special security scanners. Penetration tests are conducted with the resources and methods that a hacker would use to penetrate the system without authorization.
ATTENTION
A running process control system should never be tested with penetration test tools. The use of penetration tests tools is always associated with the risk that the system tested (or the installation or configuration of the system) may get damaged permanently.
The use of security scanners in the Whitebox scan for the maintenance period (plant shutdown) should be supported by the manufacturer of each product, and this must be tested in advance, if needed.
Other tools that can be used, for example, for security tests under laboratory conditions:
• Port scanner • Network/OS vulnerability scanner • Application/Database vulnerability scanner • Password cracker
• File searching and analyzing tool • Network analyzer • Exploit protection tool
ATTENTION
Before using the tools stated above the respective and current legal situation must be checked!
Page 216 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
6.8.5 Vulnerability Scanning Vulnerability scanners are used to scan computers or complete networks by usage of automated tools. Those tools usually create reports which show common vulnerabilities to the system. Based on this report it is possible the get a basic analysis of the vulnerabilities inside configured IT infrastructure.
6.8.5.1 Publicly available Solutions
Different options for Vulnerability scanners are available and here is a small list: • Nessus - https://www.tenable.com/products/nessus/nessus-professional (acc.: 27th March 2019) • openVAS - http://www.openvas.org/index.html (acc.: 27th March 2019)
6.8.5.2 Recommended Solution with SiESTA The actual version of WinCC Open Architecture is tested with a product named Siemens Extensible Security Testing Appliance (SiESTA).
This is a variety set of vulnerability scanners where each scanner can be configured to the required needs. The SiESTA Toolset provides a centralized user interface for different vulnerability scanners including a configurable method for automatic evaluation of scan results.
The following tools are - among others - integrated in SiESTA:
• Nmap Scan • Nessus • SSLyze • STYX
• Kali Linux More details regarding SiESTA are available by Siemens CT at following homepage for interested parties within Siemens. A login with Siemens user credentials is required to access this page, those credentials cannot be provided by ETM for interested parties outside from Siemens: https://wiki.ct.siemens.de/display/SiESTA/SiESTA+Home (acc.: 27th March 2019).
https://new.siemens.com/global/en/company/stories/research-technologies/a-swiss-army-knife-for-digital- security.html (acc. 10th May 2019).
WinCC OA is tested by SiESTA with the goal to identify and resolve all known vulnerabilities before the product is released to market.
Page 217 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
Implement Backup and Restore concept
6.9.1 General Information A well-defined security concept can protect the facility from a typical availability related attack scenario, but a complete protection without any negative impact is usually not possible. A typical risk is an attack that successfully places a lock virus which encrypts the entire file system. In this situation it is necessary to have a reliable backup concept to successfully restore the system.
Beside the backup concept it is also essential to create an own disaster recovery concept which includes all required steps to restore the system within a short time span. This is important because this is usually an exceptional situation which could cause panic. That delays the restore process if an important step in the restore procedure was forgotten. Therefore, it is recommended to create a step by step list which could be realized within a short time span.
Besides the implemented Backup and Restore functionality within WinCC OA for historical data and the configuration database it is also necessary to take care of the OS environment and plan a backup for network equipment like switches.
6.9.2 OS related backup External vendor software could be used for planning an execution of those backups. The dedicated software should take care of the complete OS configuration including AD and network configuration. Typical backup software contains 3 different kinds of backup procedure:
• Full-Backup: This backup mode takes most time and needs the most place on the backup medium. It is recommended to configure this mode in larger timeslots when the load on site is reduced like during weekends (e.g. Sunday night)
• Incremental Backup: This will backup just the changes since the last full or incremental backup. This backup procedure can be configured in a smaller timeslot than a full backup. For restoring it is necessary to restore the newest full backup and the incremental backup in the correct timely order. A typical incremental backup could run on delay basis and so be scheduled for every night.
• Differential backup: It takes only the changes since the last full backup
Page 218 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
Sunday Full Backup
Saturday Monday Incremental Incremental Backup Backup
Friday Incremental Tuesday Incremental Backup Backup
Thursday Wednesday Incremental Backup Incremental Backup
Figure 83 - Backup Schema
The noted timeslots are not a specific recommendation by ETM profession control GmbH and are used only as examples; it is necessary to define own timeslots for every site to fulfill the specific requirements.
Beside the type of the backup it is also necessary to define a backup medium rotation for those devices. It is good practice to use a typical and documented rotation schema for this approach. A schema following a “Grandfather-Father-Son” principle is only one of several options. A typical rotation for a grandfather could run on monthly basis, for the father on weekly and daily basis for the son.
Page 219 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
Grandfather (monthly)
Father (weekly)
Son (daily)
Figure 84 - Grandfather/Father/Son backup principle
Page 220 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
6.9.2.1 Selection of OS related backup software Different vendors offer special solutions for backup and recovery software. ETM professional control GmbH cannot recommend any specific software that fulfills the requirements for every project/plant. But different selection guidelines are available online like an article from Gartner Inc. (https://www.gartner.com (acc.: 27th March 2019)). This is an American research and advisory firm providing information technology related insight for IT and other business leaders located across the world.
For backup and recovery software this firm provided a specific article and reviewed a few products from different vendors. As a result, they published the following chart online:
Figure 85 - Magic square by Gartner for vendors of backup and restore software (Gartner, 2017)
Page 221 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
This chart from July 2017 shows that the products from Commvault, IBM, Dell EMC, Veritas Maintanbility Technologies and Veen as leaders in the market of backup and restore software. ETM professional control GmbH recommends checking the actual Usability Efficiency study from Gartner and to review the articles for those products. The selected product should fulfill all requirements for the specific project/plant. A good help to find a reliable backup and restore software is given by ISO/IEC 9126 (https://en.wikipedia.org/wiki/ISO/IEC_9126 Functionality Portability (acc.: 27th March 2019)). This standard gives a good hand on concept to analyze and find the correct software. Reliability
Even if IEC 9126 was already replaced by IEC 25000 the existing web pages give a good Figure 86 - IEC 9126 Schema overview how to assess software from a 3rd party vendor.
More datails regarding IEC 25000 are available within the standard itself which can by acquired online (https://www.beuth.de/en/standard/iso-iec-25000/204260933 (acc.: 27th March 2019)). This analysis could help to fulfill the requirements on site if a fulfillment of a security standard like IEC62443 3-3 is mandatory.
6.9.2.2 Configure exceptions for OS related backup Due to multiple file access especially during a running OS backup a few unforeseen issues could occur. To avoid bad side effects ETM professional control GmbH recommends excluding a few folders from the online backup mechanism. The backup of those files could be done with other mechanisms (see chapter: WinCC OA related backup).
• db folder from WinCC OA project • log folder from WinCC OA project • data folder from WinCC OA project The other content of the WinCC OA project folder could be part of the OS based backup. Please note that this delimitation is only valid for a running WinCC OA project. There is no limitation if no WinCC OA project is running. The complete content of the machines could be part of a full backup procedure if the WinCC OA project is stopped during this procedure but must be excluded for incremental backup while the WinCC OA project is running.
6.9.3 Network equipment backup Most current network equipment like switches from Cisco, Nortel or another supplier of network equipment allows the export of the actual configuration. Those backups should be triggered each time directly after a configuration update for the device was accomplished.
Page 222 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
6.9.4 DB-Server (Oracle) backup A cyclic backup needs to be configured according to recommendations from Specialists. Following whitepapers are provided by Oracle itself and give hints how a backup and restore process shall be implemented. https://www.oracle.com/technetwork/database/database- appliance/documentation/dbappliancebackupstrategies-519664.pdf (acc.: 15th May 2019) https://www.oracle.com/technetwork/database/features/311394-132335.pdf (acc.: 15th May 2019)
6.9.5 WinCC OA related backup In addition to the OS specific backup a WinCC OA related backup needs to be implemented. In general, it is possible to differ between three types of backup:
Online Backup: This triggers a backup of the actual Raima- DB image from WinCC OA which contains the complete DP- Type configuration, the Datapoints and the related attribute configuration, e.g. peripheral addresses or original values. This backup type contains the complete process image of a running project. Also, historical data can be included in the backup using this backup type.
Figure 87 - Online Backup
Parameterization Backup: This backup method is part of the Online Backup panel. It allows a backup of all configuration parts within a project. This involves all scripts and panels including the relevant colorDB files for this project. With the same backup method an ASCII output is triggered which backups the complete data model configuration (DPTs, DPs, configs) of the project into text based ascii files. A combination of this backup method with the Online Backup creates a complete snapshot of a project and makes it possible to restore an entire project without historical files.
Figure 88 - Parameterization Backup
Page 223 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
Historical backup: This method is related to the selected logging option for Oracle via RDB Manager, Historical DB or Alerts Logging within the Raima DB. For every option it is possible to configure the time when a switch of the actual file should be applied. Typically, a switch of a file should occur on a weekly or monthly basis, but this depends on the specific requirement especially for Historical DB data. For all those options it is possible to define which data should remain online and which files shall be copied to a backup device. Typically, those files are also stored on disk and need to be copied to a tape in a periodic manner. This backup could be applied together with the OS related backup. In general, it is possible to define the same backup schema (e.g. Grandfather-Father- Figure 89 – Archives in Historical Archive Son) for those files. (HDB)
The two screenshots show a possible way to split the amount of data into different groups and to define an own backup procedure for each archive (HDB) or archive group (RDB). Datapoints are applicable for each group and this makes it possible to define different backup intervals for every Datapoint in dependency of the content (e.g. for DP with fast update intervals it is not necessary to keep them for more than 1 year online, but a calculated average value based on this value should stay available even after 1 year).
Figure 90 – Archive Groups in RDB Archive
WinCC OA Documentation reference
System management / Database / History DB (Database Configuration)
Page 224 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
6.9.6 External Data Storage A backup to portable medium, e.g. a data tape, offers the option transfer data into another and secure building separated from the site building (e.g. safe deposit box). In cases where the complete site building gets destroyed including the complete hardware (e.g. Fire) it will be possible to reassemble the complete configuration if the medium was stored safely. Those external backups could be used for yearly or monthly backups.
6.9.7 Restore procedure As already mentioned in the chapter above it is recommended to define a disaster recovery procedure for the own facility. It is necessary to define each step with additional information. For example, this disaster recovery procedure holds the following steps:
1. Inform the staff members of the ongoing restore procedure and tell them when the system is available again 2. Get the backup tape from the external building (add here the Address and the number of the safe deposit box) 3. Restore Backup for e.g. CISCO switches 4. Restore AD system with the last full backup 5. Restore all incremental backups created after the last full backup 6. Apply the last two steps for all other machines 7. Restore Online Backup for WinCC OA project. 8. Restore Parameterization Backup for WinCC OA project. 9. Restore Historical Data 10. Start the system For reasons of precaution the restore procedure of an automated backup should minimum once be executed on a test system.
Page 225 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
Implement Risk assessment process based on VDI/VDE 2182
6.10.1 Definition of Risk assessment process Both the project specifications and the threat situation can change over time, so that it is necessary to repeat the procedure at regular intervals or event-driven, to adjust the measures if necessary. This approach is known as “Plan-Do-Check-Act” or PDCA. IEC62443 requires an execution of this guideline by all stakeholders. The detailed approach for this guideline and dependencies are explained inside this norm (https://www.vdi.de/uploads/tx_vdirili/pdf/1728597.pdf (acc.: 27th March 2019)).
This guideline describes how specific measures can be implemented to guarantee the IT security of automated machines and plant; aspects of the automation devices, automation systems, and automation applications are considered. A uniform, feasible procedure for ensuring IT security throughout the entire life cycle of automation devices, systems, and applications is described. The lifecycle covers development, integration, operation, migration and decommissioning phases.
This guideline defines a simple procedure for the development and description of IT security. This model consists of eight steps. The implementation of this model from the viewpoint of vendors, integrators/machine vendors and plant management will be described in the guidelines VDI/VDE 2182 Part2, Part3, and Part4.
Applying the methods and measures described in this guideline will allow systematic solutions to be achieved which are appropriate to the level of protection required meaning that they are also cost effective.
1. Identify assets
8. Perform process 2. Analyze threats audits
3. determine 7. Implements relevant security countermeasures objectives
6. Select 4. Analyse and assess countermeasures risks
5. Identify measures and assess effectiveness
Figure 91 - Steps of VDI/VDE 2182
Page 226 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
1. In the 1st step the view of the asset owner is limited to a functional related view. Specific hardware components are not defined at this point of time. The asset owner should provide this information in form of a tender specification. A detailed definition will be defined during this project in corporation with the integrator in form of a performance specification. 2. The assets from the 1st step is analyzed from a functional point of view. The threat analysis is performed in an iterative process together with the identification of the protection goals. This step identifies the relevant threats for each asset, assigns possible causes and describes the direct consequences. 3. In this step, the protection objectives which are relevant for the object of observation are determined. For each asset found, it must be decided which protective aims are relevant. 4. The existing risks resulting from threats are analyzed and evaluated. From the threat potential and the simplicity of the attack, the probabilities for the occurrence of the threats identified in the previous step are evaluated. Thus, the potential damage to the object of observation as well as the resulting damage was estimated. Statistical data is generally not available, so the risk assessment is qualitative. 5. In this step, measures and their effectiveness against the relevant requirements are described. Appropriate protection measures are selected using catalogs, experiences and other documents. Often a necessity is countered by a few different protective measures. The appropriate costs are allocated to each recommended protection measure to determine an economic assessment of the total solution. 6. A reasonable (economically) total solution is selected as the best combination of measures from the multitude of listed protective measures. In doing so, the company's aims and compliance with company policy must be considered about IT security. 7. The individual protective measures are to be implemented in the context of the overall solution. In this step, a business concept is created that ensures the sustainable implementation of the solution. If the object of observation is an automation solution or a system, the operating concept covers the entire operating phase. For a product, the operating concept relates to the marketing phase. 8. In the audits it is checked whether all defined measures for the achievement of the defined protection aims as well as for the protection-relevant threats are enough and successfully implemented. The audits are to be carried out by persons who are not involved in the process.
Page 227 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
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,
• VDI/VDE 2182 Part 3.1 IT-security for industrial automation - Example of use of the general model for manufacturers in factory automation - Process control system of an LDPE plant,
• VDI/VDE 2182 Part 3.2 IT-security for industrial automation - Example of use of the general model for integrators in process industry - LDPE reactor,
• VDI/VDE 2182 Part 3.3 IT-security for industrial automation - Example of use of the general model for plant managers in process industry - LDPE plant. Due to copyright reasons it is not possible to share the detailed knowledge from this standard within this document and so it is recommended to get an own copy of those standards for the integrator. In this guideline we can only point out a small example with general information to handle an issue from this norm.
As a reference the recommended structure from Highly Secure Large System is used for the next steps.
1. Identify assets Based on the architecture the remote access from outside was defined as an asset
Figure 92 - Part from Highly Secure Large System architecture
Page 228 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
2. Analyze threats. In this step the asset and possible threats are analyzed using experience and possible examples from threat catalogues (CVE web pages) or BSI homepage. The vulnerability and the direct consequences are mentioned. For the remote access the following threats could be analyzed: Asset Threat Cause Vulnerability Consequence
Remote Access Defect in data transfer Defect Hardware diversity Faults take long to be line router eliminated
Remote Access Data Manipulation Hackers Security measures Unauthorized persons at service provider acquire data
Table 16 - VDI/VDE Example Step 2
3. Determine relevant security objectives Use the same table from step 2 and define which of the main protection goals availability, confidentiality or integrity is affected.
Asset Threat Cause Vulnerability Consequence
bility
a
Avail Confidentialit y Integrity
Remote Access Defect in data Defect Hardware Faults take long to be X transfer line router diversity eliminated
Remote Access Data Hackers Security unauthorized persons Manipulation measures at acquire data X X X service provider
Table 17 - VDI/VDE Example Step 3
Page 229 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
4. Analyze and assess risks. The plant manager defines a risk matrix. If the plant manager can use the standardized risk matrix of its company for evaluating similar security scenarios, this makes it easier to make cross-project comparisons. The attached matrix definitions come from a good practice method known as Threat and Risk analysis inside the Siemens Company.
Exposure Rating (of Product or Solution in Operational Environment) First part of likelihood rating, representing the likelihood whether an attack may be attempted Exposure Categories
Level of Access Needed Risk of Getting Caught • Easy logical or physical access for attacker, e.g. • Low risk to be discovered / convicted − internet access sufficient, or • No or little measures for unauthorized access detection and 2 High − public physical access, or investigation implemented − attacker has access as part of daily work, operation, or maintenance activities, or − product or components can be acquired by attacker with low effort • Restricted logical or physical access for attacker, e.g. • Medium risk to be discovered / convicted − internal network access required, or • Some measures for unauthorized access detection and investigation 1 Medium − restricted physical access, or implemented (e.g. surveillance, logging, monitoring)
− product or components can be acquired by attacker with medium effort Exposure Scale Exposure • Highly restricted logical or physical access for attacker, e.g. • High risk of being discovered / convicted − highly restricted network and physical access, or • Good measures for unauthorized access detection and investigation 0 Low − product or components can not be acquired by attacker or only with high implemented (e.g. surveillance, protected log files, monitoring and effort alarming, limited no. of persons)
Figure 93 – Definition of exposure
Exploitability/Simplicity Rating (of Product or Solution) Second part of likelihood rating, representing the likelihood whether an attempted attack is likely to succeed Exploitability of Vulnerabilities / Simplicity to Perform a Successful Attack
• Successful attack is easy to perform, even for an unskilled attacker (little capabilities needed) 2 High • Vulnerability can be exploited easily with low effort, since no tools are required or suitable attack tools freely exist. Scale • No or only weak security measures to counter the attack caused by the threat
• Successful attack is feasible for an attacker with average hacking skills (medium capabilities needed) 1 Medium • Vulnerability is exploitable with medium effort, requiring special technology, domain or tool knowledge • Some security measures to counter the threat
• Successful attack is only possible for a small group of attackers with high hacking skills (high capabilities needed) • Vulnerability is only exploitable with high effort, and if strong (huge) technical difficulties can be solved, non-public information about inner workings of 0 Low system is required
Exploitability/Simplicity Exploitability/Simplicity • Strong state of the art security measures to counter the threat
Figure 94 – Define Likelihood matrix based on Exploitability and Exposure
Exposure Rating
Low Med High
Very Low Unlikely Possible unlikely
Med Unlikely Possible Likely
Very High Possible Likely
likely Exploitability/SimplicityRating
Figure 95 – Define the risk level on site
Page 230 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
Risk
Risk Level Description
Risk must be treated with highest priority in terms of definition and Major implementation of countermeasures or acceptance by senior management.
Risk must be treated with high priority in terms of definition and Significant implementation of countermeasures or acceptance by product/solution/service owner.
Risk must be treated with medium priority in terms of definition and Moderate implementation of countermeasures or acceptance by product/solution/service owner.
Risk can be treated optionally, however definition and implementation Minor of countermeasures is recommended if easily possible or is considered state-of-the-art. Figure 96 – Evaluation of risk level
Likelihood Rating Very unlikely Unlikely Possible Likely Very likely
Negligible Minor Minor Minor Minor Moderate
Moderate Minor Moderate Moderate Moderate Significant
Critical Minor Moderate Moderate Significant Major ImpactRating
Disastrous Moderate Moderate Significant Major Major
Figure 97 - Definition of Security threat
Page 231 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
Asset Threat Cause Vulnerability Consequence Identified
Risk
bility
a
Avail Confidentiality Integrity
Remote Access Defect Defect Hardware Faults take Moderate in data router diversity long to be X transfer eliminated line
Remote Access Data Hackers Security Unauthorized Major Manipul measures at persons X X X ation service provider acquire data
Table 18 - VDI/VDE example step 4
5. Identify measures and assess effectiveness In this step the asset owner describes the countermeasures that are already fulfilled or going to be fulfilled due to the company policies. It is especially required to define countermeasures that could reduce the available risk. Some possible definitions for remote access are:
• Establish a VPN connection • Reduce Hardware diversity
Page 232 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
6. Select countermeasures After having the available number of countermeasures they will be put into the same table:
bility
osts
a
c
Asset Threat Cause Vulnerability Consequence Avail Confidentiality Integrity Identified Risk Countermeasures and
Remote Defect in Defect Hardware Faults take Reduce Access data router diversity long to be Hardware X transfer eliminated diversity –
line Moderate 2000€
Remote Data Hackers Security Unauthorized Use VPN
Access Manipul measures persons connection – X X X
ation at service acquire data Major 200€ / month provider
Table 19 - VDI/VDE example step 6
7. Implement countermeasures The implementation will typically be embedded in the project schedule agreed between the integrator or device manufacturer and the plant manager.
8. Perform process audits Required audits for new systems are carried out between the installation and the commissioning phases. For running systems, they are performed regularly or when change management provisions call for it. Audits are designed for examining technical issues (vulnerabilities or security gaps) and detecting organizational and administrative shortcomings. As mentioned at begin of this chapter this was only a small example part from the VDI/VDE 2182 norm itself. The existing documents can give more detailed information about a risk assessment and the possible way to implement this into the business-related processes.
Page 233 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
System Decommissioning Until this point all steps regarding a secure setup or recommendations for operation mode were considered. At system decommissioning a system is taken out of service after the operational phase. A system decommissioning process needs to be applied according to the policies of the enterprise, to ensure that the confidentiality protection goal is still guaranteed.
At least it is essential that components from a plant, that potentially contain data, like hard discs of flash memory cannot be misused for an unauthorized read. An erase of the memory in the devices is therefore very useful. The method of a secure wipe of confidential data needs to be defined by the Integrator and executed by the asset owner in the phase of decommissioning. (Kobes, 2016, S. 24-27).
According to IEC 62443 a disposal of all assets should be considered, and the requirement is defined in following way: “Policies and procedures should be developed detailing retention, physical and integrity protection, destruction, and disposal of all assets based on their classification, including written and electronic records, equipment and other media containing information, with consideration for legal or regulatory requirements.” (IEC 62443-2-1, 2010, S. 35)
ATTENTION
This chapter or this document gives an overview how software can be removed from devices but not for hardware devices itself. This exception also includes machines which were connected to a SCADA system during operation mode (e.g. handling of fuel rods from a nuclear reactor).
Within this definition following recommendation needs to be considered:
• A wipe of hard disc by formatting is not secure and can still be used by an attacker to read confidential data. To avoid this threat a simple delete is not enough according to information given by BSI (BSI, 2019). Instead it is recommended to proceed with one of the following options: o Secure deletion of data by 3rd party tool. Enclosed a small example list of possible vendors: ▪ Kaspersky® Total Security https://support.kaspersky.com/us/11449 (acc.: 27th March 2019) ▪ Parted-Magic https://partedmagic.com/ (acc.: 27th March 2019) ▪ DBAN https://dban.org/ (acc.: 27th March 2019) o Shredder the hard disc physically to make it impossible to get the stored data for an attacker. This approach destroys the hard disc by force and makes it impossible to read the data after this procedure. Different vendors offer products or services for this requirement. Enclosed a possible example: https://www.recycling.com/hard-drive-shredder-destruction-service/ (acc.: 27th March 2019)
Page 234 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
o Usage of Hard disc encryption like BitLocker. This is a very secure and recommended option because an attacker is not able to read the contain data if the TPM Key is not available according to following figure.
Figure 98 - Architecture BitLocker (Microsoft, BitLocker, 2016)
• Configuration from Routers and Switches needs to be wiped before the discard of the device. “Configuration files and log files stored on active network components contain a wealth of information about the network, the infrastructure, the organisation and possibly also about individuals in the organisation. When a device is passed to an outside party (for example, returned to the manufacturer or the service company for the replacement of parts under warranty, or sold to a possible purchaser), this information can be analysed. For example, the following information can be extracted from configuration files: o the protocols used (especially routing protocols), IP addresses and subnets o VLAN configuration o access control lists o passwords and SNMP community strings o name and contact data for the administrator (banner) Due to the sensitivity of this information, care should be taken to ensure that prior to withdrawing a device from operation or replacing defective or outdated devices, the files are deleted or rendered unreadable. The procedure greatly depends on the manufacturer of the device. The security policy for routers and switches should set out the responsibilities in this area.” (BSI - IT-Grundschutz-Catalogues, 2013, S. 1842)
Some Router offers the option of the “factory reset” which deletes sensitive information from the device. The option to shredder a device physically can also be considered.
• Ensure secure deletion of PLC program before PLC is discarded. The option to shredder a device physically can also be considered.
• User documents which contain confided data should be destroyed or stored in a secure way if the written information may be used for further projects.
Page 235 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
7 Security Checklist The following checklist is a recommendation on how to install and configure a secure system. Details of this checklist are available within this document. Target of this checklist is a procedure to verify if all recommended settings are already implemented on site.
Please consider that most use cases are based on a Defense in Depth concept where security must be applied by all stakeholders inside a project. A good description is given by IEC62443, (see chapter: References).
Step Description Chapter Check N/A
Ensure Security Knowledge
1. Consider the strategy and the concept of a Strategy of the Security Guideline security process in all following steps Defense in depth concept
Preparation and Installation
2. Install a domain environment Administration of Computers
3. Protect a new installed machine from any hostile Newly installed machine network traffic until OS system is hardened. Different Disc Partitions
4. Implement Multitier-network architecture. Security Cells and Network Architecture
Highly Secure Large System
Secure small system
Distributing the Tasks on several Computers
5. Protect electricity grid Secure network cell from power
issues
6. Split network to security cells Limitation of bandwidth between
security cells
7. Deploy WinCC OA Server concept Server Configuration 8. Deploy WinCC OA UI concept User Interface Configuration
9. Initial configuration for mobile devices Configuration settings for all
mobile devices
10. Take care of security in branding WinCC OA Branding of WinCC OA MSI
version Installation
Page 236 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
11. Configuration of Video cameras Configuration Settings for Video
Cameras
12. Secure configuration of Oracle server Use Oracle Server with Oracle
Database Appliance (ODA)
Service packs and Hotfixes
13. Install the latest service packs from Microsoft® Patch management and security
or Linux distribution updates
14. Activate automated notification of patch Patch management and security
availability updates
15. Install WSUS Server for Windows based system Windows
16. Install Mirror Server for Linux based system Linux
Harden OS system
17. Disable not required services Shutting down/Uninstalling services that are not needed under Microsoft® Windows
Shutting down/Uninstalling services that are not needed under Linux
18. Uninstall not required software Uninstalling not needed software
19. Disable unsecure SNMP protocols Restrict SNMP driver
communication to SNMPv3
20. Implement a secure desktop solution Secure Desktop – Kiosk Mode
21. Disable DCOM Interface if it is not required by Disable DCOM
the project or plant
22. Harden DCOM Interface if legacy technology is Hardening DCOM for OPC DA
used (e.g. OPC DA). driver
23. Configure OPC UA settings OPC UA configuration
24. Activate SMB signing Activate SMB signing
25. Create or replace default certificates for Create and deploy TLS certificates
encryptable driver via TLS
26. Enable Secure Mode of Linux Enable SELinux
Page 237 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
OS User Account Policies
27. Set password complexity requirements Password strength
28. Delete or disable default OS users Delete or disable unneeded default
users on OS Level
User rights assignment
29. Apply user rights assignment on folder level Definition of Access Control List
(ACL)
30. Create role-based user concept for WinCC OA Administration of Role-Based user
authorizations
31. Limitation of root user Limit usage of root user
32. Delete or disable default users Delete or disable all default users
on WinCC OA level
Security Settings
33. Configure machine inactivity limit to protect idle Automatic user logout in OS
interactive sessions.
34. Check digital signature of software packages Digital signatures for binaries and
libraries
Auditing
35. Activate OS based audit logging Logging, audit, maintenance and
asset management
36. Make suspicious logging events in WinCC OA Observe audit logging and transmit
visible information to WinCC OA
37. Implement intrusion detection system Implement Intrusion detection
system
Network Security Settings
38. Plan a network concept and network services Administration of networks and
network services
39. Limit internet access for plant computers Limitation of internet access
40. Definition of Access Points to Security Cell Definition of the Access Points to
the Security Cells
Page 238 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
41. Configure Firewall for required ports Usage of WinCC OA mxProxy and restriction of open ports and limitation of the IP access list
42. Activate Anti-Virus Software Virus Scanner
43. Ensure secure communication between security Secure security cell link via IT cells Infrastructure
Secure security cell link via WinCC OA Proxy
44. Activate OS based secure communication IPsec Bypass Technology
protocol
45. Move Reporting Manager into a DMZ Define Reporting Manager as
predetermined breaking point
46. Implement secure communication for unsecure Secure communication for
protocols unsecure protocols
47. Hide secure network behind Reverse-Proxy Hide secure network behind a
Reverse Proxy
Physical Security
48. Configure BIOS settings Configure BIOS Settings
49. Deactivate unused interfaces Deactivate unused interfaces
Implement security related processes
50. Ensure Security coding knowledge for project Secure coding standard for API
developers extension
51. Usage of Obfuscator tool for own API code Usage of Obfuscation tool for API
code
52. Implement Training concept for Security Testers Knowledge of Security Testing
Encrypt network communication
53. Create openSSL certificates for WinCC OA and Usage of TLS/SSL for plant deploy it communication
Create own openSSL certificates
Create and deploy certificates
54. Consider Demo Configuration of TLS Demo configuration of TLS in
WinCC OA
Page 239 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
55. Store openSSL certificates in a secure way Storage of openSSL certificates
and private keys
56. Enforce usage of strong cipher suite Enforce usage of strong cipher
suite
57. Establish secure maintenance access Protected Maintenance Access
Secure Access Techniques
58. Encrypt Oracle communication Activate encryption between
Oracle Client and Oracle Server
PLC Communication
59. Activate secure communication to PLC Usage of interlocks for the PLCError! Reference source not found.
WinCC OA Security
60. Add authorization config for all WinCC OA Protection via authorization levels
Datapoints in WinCC OA
61. Ensure secure communication for Web clients Secure Web Publication
Communication with WinCC OA – Desktop UI
Activate httpAuth for WinCC OA HTTP-Server
62. Protect knowledge Script and Panel Encryption
63. Implement area authorization concept Access Control via Area
authorization
64. Remove unnecessary Datapoints Deletion of unused Datapoints
65. Reduce security privileges for WinCC OA Start a WinCC OA project as a
processes service
66. Use an authentication mechanism outside of Usage of WinCC OA external
WinCC OA authentication method
67. Usage of WinCC OA mxProxy to split network Remote access to WinCC OA mxProxy manager via Dist Manager
Page 240 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
68. Disable automatic activation for mobile devices Disable Automatic Unlock for Mobile Devices (Android and iOS) and Desktop UI
69. Activate Server-side authentication (SSA) Server-side Authentication
70. Activate session binding for WinCC OA Server-Side Authentication for
managers Managers with session binding
71. Define SSO for OS or external Users in WinCC Automatic User Login OA Single Sign On
72. Activate automatic user logout in WinCC OA Automatic user logout in WinCC
Level OA
73. Configure certification chain Usage of certification chain
74. Set secure settings in WinCC OA config file Keep secure settings in WinCC OA
config file
75. Consider security implementation of WebView Secure implementation of
EWO WebView EWO
Alternative security options to openSSL and
WinCC OA mxProxy
76. Activate Kerberos encryption Activate Kerberos encryption for
WinCC OA systems
WinCC OA Access Control Plug-In
77. Usage of WinCC OA Access Control Plug-In as Usage of WinCC OA Access a sandbox to implement a specific security Control Plug-In concept
Mobile Devices
78. Secure configuration of mobile devices Configuration settings for all
mobile devices
Security Testing
79. Ensure and verify actual security configuration Security tests
Whitelisting
80. Install and use whitelisting Software Whitelisting/Application Control
Page 241 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
Disaster Recovery (no WinCC OA DRS)
81. Implement Backup concept Implement Backup and Restore
concept
82. Define and document steps for restore Restore procedure
procedure
Process
83. Implement and maintain cyclic risk assessment Implement Risk assessment
process process based on VDI/VDE 2182
Decommissioning
84. Secure Decommissioning during abandonment Decommissioning
stage
Table 20 - Security Checklist
Page 242 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
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) Security Cells and Network Architecture
8.1.1.2 Access Control List (ACL) An access control list defines the list of permissions for objects like files or folders on OS level. This list defines which user or system process is granted to access those objects.
8.1.1.3 Administrated Client Client inside an operational environment where the complete security related policies from the company are in place. Those machines are fully configured and maintained by an IT department with following configuration:
• Firewall fully configured and activated • Anti-Virus software active and up to date • All mandatory OS related updates are installed • Installed software products controlled by the IT department, no unauthorized software products are installed
• Hard disc is encrypted
8.1.1.4 Area Authorization Area authorizations are assigned within areas. Areas are logical or geographical regions, for example, of a plant, and can be assigned to the various groups. The rights of an area that has been assigned to one group are applicable to all users belonging to this group. In this manner, different rights by different groups can be configured according to the assigned areas.
8.1.1.5 Authentication Authentication is the ability to verify the identity of a user or a computer system on a computer network.
Page 243 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
8.1.1.6 Authentication Protocol It is the protocol with which an entity establishes its identity in a network for a remote identity. Typically, the identity is proved with a secret key, e.g. a password, or with a key that is more secure, for example, a chip card. Certain authentication protocols also implement methods for common usage of keys between clients and servers, to supply integrity or data security for messages.
8.1.1.7 Block Cipher A block cipher is a deterministic encryption method which maps a clear text with a fixed length to a cipher with a fixed length. The exact transformation is determined by a symmetric key.
Actual block ciphers are mentioned in this table - please note that the red colored ciphers are already vulnerable for attacks and should not be used in a secure environment.
Cipher Key Length Block Length State
DES 56 64 Unsecure
3DES 112 64 Unsecure
IDEA 128 64 Unsecure
RC5 128 64 Unsecure
Blowfish < 448 64 Unsecure
AES 128 128 Secure
AES 192 128 Secure
Twofish < 256 128 Secure
AES 256 128 Secure
Table 21 – List of available cipher suites (Siemens, 2019)
8.1.1.8 Brute-force attack A brute-force attack uses automated software to generate many guesses to evaluate a secret which is used as a password for user credentials is or as a secret key to decrypt data. This method is based on a trial and error mechanism and the limited factor is the consumed time. It is possible to mitigate a brute-force attack by methods which increase the consumed time, that is required for a successful brute-force attack.
Page 244 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
8.1.1.9 Chain of trust (certification chain) In computer security, digital certificates are verified using a chain of trust. The trust anchor for the digital certificate is the root certificate authority (CA). The certificate hierarchy is a structure of certificates that allows individuals to verify the validity of a certificate's issuer. Certificates are issued and signed by certificates that reside higher in the certificate hierarchy, so the validity and trustworthiness of a given certificate is determined by the corresponding validity of the certificate that signed it.
The chain of trust of a certificate chain is an ordered list of certificates, containing an end-user subscriber certificate and intermediate certificates (that represent the intermediate CA), that enables the receiver to verify that the sender and all intermediate certificates are trustworthy. This process is best described in the page Intermediate certificate authority. See also X.509 certificate chains for a description of these concepts in a widely used standard for digital certificates. https://en.wikipedia.org/wiki/Chain_of_trust (acc.: 27th March 2019)
8.1.1.10 Cipher suite “A cipher suite is a set of cryptographic algorithms. The schannel (Secure channel) SSP implementation of the TLS/SSL protocols use algorithms from a cipher suite to create keys and encrypt information. A cipher suite specifies one algorithm for each of the following tasks:
• Key exchange • Bulk encryption • Message authentication Key exchange algorithms protect information required to create shared keys. These algorithms are asymmetric (public key algorithms) and perform well for relatively small amounts of data.
Bulk encryption algorithms encrypt messages exchanged between clients and servers. These algorithms are symmetric and perform well for large amounts of data.
Message authentication algorithms generate message hashes and signatures that ensure the integrity of a message.”.
(Microsoft, Cipher Suites in TLS/SSL (Schannel SSP), 2019)
The list of selectable cipher suites depends on the used openSSL version. WinCC OA uses an actual recommended version openSSL. The list of selectable cipher suites by openSSL and the OS can be queried by command line. Here is an example for a Windows system:
D:\Siemens\Automation\WinCC_OA\3.16\bin>openssl ciphers
8.1.1.11 CIS – Center of Internet Security “CIS® (Center for Internet Security, Inc.) is a forward-thinking, non-profit entity that harnesses the power of a global IT community to safeguard private and public organizations against cyber threats.
The CIS Controls™ and CIS Benchmarks™ are the global standard and recognized best practices for securing IT systems and data against the most pervasive attacks. These proven guidelines are continuously refined and verified by a volunteer, global community of experienced IT professionals.“ (CIS, 2018) https://www.cisecurity.org/ (acc.: 27th March 2019)
Page 245 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
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.
WinCC OA Documentation reference
Control / Introduction CONTROL
8.1.1.15 Control room It is the control room of a control system. The definition according to ISA-99 is: "Central location where a group of resources is being operated." A control room is the name of a technical control facility that supports the control of processes. The control room is part of a control system.
Note:
In the industrial infrastructure there are usually one or more control centers to monitor and coordinate the operating schedule. In complex plants, multiple control centers are usually connected via WAN (Wide Area Network), e.g. one control center is at another location for failure safety. One control center contains the SCADA host computers and the related display devices for the plant operator and additional information systems like an archive server.
8.1.1.16 Control Systems Network (CSN) It is the name for a network as part of a security cell or area of the system in which the automation plants are located. The PCS or DCS or SCADA server systems are also linked to the CSN, to be in contact with the automation plants. Each CSN is a so-called system network or system bus.
To avoid a negative impact caused by network traffic it is recommended to configure an own subnet for CSN where it is ensured that this separate network is not jammed by the common traffic.
Page 246 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
8.1.1.17 Cryptographic Service Provider This is an independent software module which performs cryptographic algorithms for authentication, encoding and encryption.
WinCC OA uses the CSP named “Microsoft Enhanced RSA and AES Cryptographic Provider” to check the SSA for managers with session binding (see chapter: Example for Windows Certificate Store SSA certificates).
8.1.1.18 DCOM Short for Distributed Component Object Model, an extension of the Component Object Model (COM) that allows COM components to communicate across network boundaries. Traditional COM components can only perform interprocess communication across process boundaries on the same machine. DCOM uses the RPC mechanism to transparently send and receive information between COM components (i.e., clients and servers) on the same network. DCOM was first made available in 1995 with the initial release of Windows NT 4.
CAUTION
DCOM must not be used in an environment where the implementation of security features is mandatory since this interface is likely used for security attacks. It may only be used for compatibility reason in old software products if they run in a complete secured environment.
8.1.1.19 Defense in Depth (ISA-99) Security architecture with the assumption that every point of security can and most likely will be bypassed.
Note
The concept of a Defense in Depth contains a tiered and layered structure of security and recognition measures and mechanisms (also on the level of single place systems). It has the following features:
• Attackers may reckon to be detected when trying to breach or bypass the single layers. • The weak point of a layer of this architecture can be covered in one of the other layers. • The system security is a separate layer structure inside the whole layered structure of the network security.
8.1.1.20 Demilitarized Zone (DMZ) In the telecommunication field, it is the keyword for a computer, router or a small network, which is set up as a "neutral area" between the internal network of an organization and the "external" public network. This measure should prevent external users from having direct access to a server with corporate information. "Perimeter Network" (Boundary network, perimeter network) is another term often used to designate the DMZ.
Page 247 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
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 Documentation reference
WinCC OA UI / Desktop UI
8.1.1.22 Device Any item that can be connected to a network or computer is a device, such as, for example, a computer, printer, joystick, adapter, an interface card or any other peripheral device. Generally, devices require a device driver for the used operating system.
They include electronic devices licensed under Windows such as computers, workstations, terminals and handheld computers, which access the services of the Windows operating system or can use them, including file and printer sharing, remote access and authentication.
8.1.1.23 Distributed Computer Network (DCN) Distributed computing is a field of computer science that studies distributed systems. A distributed system is a software system in which components located on networked computers communicate and coordinate their actions by passing messages. The components interact with each other to achieve a common goal. Three significant characteristics of distributed systems are: concurrency of components, lack of a global clock, and independent failure of components.
8.1.1.24 Distributed Control System (DCS) A distributed control system (DCS) is a control system for a process or plant in which the system elements are distributed but operated as coupled. This contrasts with non-distributed systems, which use a single controller at a central location. In a DCS, a hierarchy of controllers is connected by communication networks for command and monitoring. With WinCC OA the communication between the distributed systems is realized with the WinCC OA Dist Manager (WCCILdist)
Example scenarios where a DCS might be used include:
• Petrochemical (oil) and refineries • Water management systems • Chemical plants
• Traffic control systems
Note:
Decentralized process control systems are usually used in combination with continuous processes like the generation of electric energy, oil and gas refining, chemical or pharmaceutical production and paper manufacture. Besides that, it is also used in combination with discrete processes like assembly, packaging and storing of automobiles and other goods.
Page 248 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
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.
WinCC OA Documentation reference
Add-ons / Disaster Recovery System
8.1.1.30 Eavesdrop This is an attack vector against the confidentiality of a system. Eavesdropping is a secretly listening of a communication between two or more different components. Attacker can use the observed communication to steal instinctual property or to get information to prepare an attack against the integrity of a system.
Page 249 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
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.
WinCC OA Documentation reference
Special Functions / XML-RPC
8.1.1.33 External user authentication Describes a tool provided by a third-party vendor which handles user credentials including group ownership outside from an OS environment. Those tools allow to create and configure user in a way like Windows AD environment. WinCC OA supports a handler for those tools. This allows the customer to use a central user management for the facility.
8.1.1.34 Food & Drug Administration FDA US authorities; Guidelines and directives in the field of validation of processes and products have been prepared by the Food & Drug Administration (FDA). The most important and internationally applicable requirements of automation technology (with respect to the validation) are summarized in the GMP Acts 21 CFR Part 11.
8.1.1.35 Field Device Network (FDN) It is the name for a network as part of a security cell or area of the system in which only automation plants and field devices are connected.
Page 250 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
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.
WinCC OA Documentation reference
System management / Authorizations / Groups
8.1.1.39 Host It is a device in a TCP/IP network that has an IP (Internet Protocol) address. For example, such devices may be servers, workstations, print devices with a network interface and routers. Sometimes, the term refers to a certain network computer that executes a service used by the network or remote clients.
Page 251 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
8.1.1.40 International Electro technical Commission (IEC) This is an international standardization organization with its headquarters in Geneva for standards in the field of electrical engineering and electronics. Certain standards have been developed jointly with ISO.
8.1.1.41 International Organization for Standardization (ISO) It is the international association of standards organizations and develops international standards in all fields except electrical engineering and electronics, for which the International Electro technical Commission (IEC) is responsible.
8.1.1.42 International Society of Automation (ISA) It designates the independent society for standardization in automation technology.
8.1.1.43 Internet Protocol (IP) It is a network protocol of the TCP/IP suite that needs to be routed. It is responsible for IP addressing, routing as well as fragmenting and reassembling IP packets.
8.1.1.44 IP address An IP address is an address in computer networks that is based on the Internet Protocol (IP) just as the internet, for example. It is assigned to devices that are connected to the network, thus making them addressable and accessible. The IP address may designate one single receiver or a group of receivers (Multicast, Broadcast). Conversely, multiple IP addresses may be assigned to one computer.
The IP address is used to transport data from the sender to the designated receiver. Like the postal address on the envelope of a letter, data packets are provided with an IP address that uniquely names the receiver. Based on this address the "Post offices" (e.g. routers) can decide the direction in which the packet needs to be transported. In contrast to postal addresses, IP addresses are not bound to a fixed location.
The most popular notation of the IPv4 addresses common today consists of four numbers that can have a value from 0 to 255 and are separated with a dot, e.g. 192.0.2.42. From the technical point of view, the address is a 32-bit (IPv4) or 128-bit (IPv6) binary number.
8.1.1.45 IPsec The term refers to the IP Security protocols; this is architecture for supplying encryption and authentication services. It is a series of cryptography-based security services and security protocols based on industrial standards. All protocols of the TCP/IP protocol suite as well as internet communication using L2TP (Layer Two Tunneling Protocol) can be protected with IPsec. Typical usage is a VPN connection.
Page 252 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
8.1.1.46 Kerberos Kerberos is a distributed authentication service (Network protocol) for open and unsecured computer networks. The current version at present is Kerberos 5. It is defined in RFC 4120 and uses ASN.1 for coding. Kerberos offers secure and uniform authentication in an insecure TCP/IP network on secure host computers. The authentication is handled by a trustworthy third party (also called Trusted Third Party). This third party is a particularly secure Kerberos 5 network service. Kerberos supports SSO, that is, a user must login only once and can then use all network services without having to reenter any password. Kerberos handles any further authentication.
When using Kerberos (must be explicitly activated and configured) with WinCC OA it is necessary that valid Kerberos tickets are distributed, otherwise the necessary WinCC OA manager cannot be started. As soon as a project is running even a breakdown of the server which distributes the tickets cannot stop the started WinCC OA project from running. However, it is not possible to start further projects or a WinCC OA manager within a project. This action will be prompted by an error message since a valid Kerberos ticket is also needed for the start due to security reasons.
8.1.1.47 LDAP - Lightweight Directory Access Protocol Lightweight Directory Access Protocol (LDAP) is a set of open protocols used to access centrally stored information over a network. It is based on the X.500 standard for directory sharing but is less complex and resource intensive. For this reason, LDAP is known as "X.500 Lite."
8.1.1.48 Local Area Network (LAN) It is a communication network in which a group of computers, printers and other devices that are located within a relatively limited area (e.g. a building), are connected to each another. Data exchange can take place between all devices connected to the network in one LAN.
8.1.1.49 Man-in-the-middle attack(MITM) This is a scenario where an Attacker secretly intercepts the communication between two parties. Each member guess that they are communicating together but, messages are altered by the attacker. Typically, the victims are not aware that the communication is altered and instead they believe they are communicating directly via a trusted connection.
8.1.1.50 Manufacturing Execution System (MES) A name for software solutions at the operations control level. The task of MES is to capture the entire data volume with the aim of optimizing the production processes. The MES prepares the data acquired and makes it ready for evaluation. In the process, even real-time data from the production is processed for the monitoring and control of production processes.
At the automation and management levels, MES facilitate effective production and operation control. They enable fast response times to changing manufacturing conditions in conjunction with the reduction of non- production related activities. Thus, they represent a connection between the automation level of production processes and the systems of the management level. In this case the term "vertical integration" is used.
Page 253 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
8.1.1.51 Mirror Server for Linux based systems A mirror server contains the repository for Linux based systems. For Linux systems it is possible to configure a dedicated host inside the internal network instead of using an official host in the internet.
A mirror server is configured to receive all update packages in a controlled environment before they are deployed within the internal network. The usage of a Mirror Server helps to keep the internal hosts secret which may contain privacy and secure information and makes them less vulnerable for an attack. Another benefit of a Mirror Server is the reduction of internet bandwidth because the packages are only downloaded once for all configured clients.
8.1.1.52 Mutual authentication Mutual authentication (also known as two-way authentication) is a security process in which both client and server authenticates the other identity before a communication is established.
Mutual authentication is implemented in WinCC OA in following ways:
• Check of X.509 certificates • Username and Password
8.1.1.53 MQTT protocol Message Queueing Telemetry Transport (MQTT) protocol is a publish-subscribe based messaging protocol. It is designed for connecting remote devices using a slow or highly delaying network. A typical use case for this communication are IoT devices.
A MQTT system consists typically of clients communicating with a server. The server is also called a broker. WinCC OA operates as a MQTT client which can establish a connection to a MQTT broker.
8.1.1.54 NAMUR NAMUR is an international association of automation technology users in the process industry. The complete original name, "Normenarbeitsgemeinschaft für Mess- und Regeltechnik in der chemischen Industrie" (Standards workgroup for measuring and control technology in the chemical industry) is no longer used today. Instead, the association has now adopted the name, "Interessengemeinschaft Automatisierungstechnik der Prozessindustrie" (Community of those interested in automation technology for the process industry). NAMUR supports exchange of engineering practices between its members and with other associations and organizations. The working results are published in the form of NAMUR recommendations and worksheets and, if required, incorporated by national and international standards committees as proposals for standardization.
8.1.1.55 NT LAN Manager (NTLM) In a Windows network, NT LAN Manager (NTLM) is a suite of Microsoft® security protocols that provides authentication, integrity, and confidentiality to users.
Page 254 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
8.1.1.56 PAM - Pluggable authentication module “One of the most common ways of implementing password complexity on a Linux system is the use of a pluggable authentication module (PAM). A PAM allows the system administrator to choose from a wide array of authentication systems available on the Internet or writes his/her own system, if the application is PAM- aware. This moves the onus for authentication away from the application itself, to separate modules that get plugged into the application. With a PAM-aware passwd utility, the administrator can simply supply the password complexity parameters, such as minimum length, presence of numbers and punctuation characters, or absence of dictionary words that will be imposed on the user’s password.
In Linux, PAM configuration is done either the /etc/pam.conf file or files within the /etc/pam.d directory, or both. When both are used, pam.conf sets default values, which can then be overridden by individual application-specific files within the /etc/pam.d directory.” (K. K. Mookhey, Nilesh Burghate, 2005, S. 53)
8.1.1.57 Perimeter Network, Perimeter, DMZ: Demilitarized Zone (ISA-99): „A segment of the perimeter network located logically between internal and external networks.
“Perimeter network” (border network, Perimeter network) is another frequently used description for the DMZ.
In the telecommunication field, it is the keyword for a computer, router or a small network, which is set up as a "neutral area" between the internal network of an organization and the "external" public network. This measure should prevent external users from having direct access to a server with corporate information.
Note:
The purpose of the so-called demilitarized zone is to enforce the guideline of the internal network for the information exchange externally as well as to grant untrustworthy external sources only restricted access to information that can be officially released. Thereby the internal network is protected against attacks from the outside.
In the context of industrial automation and process control systems “internal network” normally means the network or segment on which the security related measures primary concentrate. For example, a process control network can be considered as an internal network when it is connected to an external business network.
Example: A DMZ can be implemented using the WinCC OA proxy. A WinCC OA system with Data- and Event Managers is running in the background. A WinCC OA HTTP-Server is running separated from the system and it provides a defined mapping of the necessary data within the DMZ. The communication takes place through a routing firewall. Thereby, the proxy is running on the secured system. Externally, the WinCC OA HTTP-Server communicates through a NAT firewall with Desktop UI end devices located in a different network. In this example, the WinCC OA HTTP-Server represents the perimeter. See chapter: Secure Web Publication
Page 255 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
8.1.1.58 Plant administrator A Plant administrator is a user in a network, who administers the plant PCs with the scope of responsibility of the plant operator. The Plant administrator must not necessarily be the plant operator.
8.1.1.59 Plant, automation plant It is a production or manufacturing system (including all decentralized peripherals, sensors, actuators, drives, network and software components, buildings, switching cabinets, cabling, operation and administration personnel) consisting of process control, process visualization, automation and engineering systems networked with each another.
8.1.1.60 Plant operator, operator A plant operator or operator is a real person registered with the automation plant. This person has the training and the authority to operate this system (e.g. operator registered in the WinCC OA project).
8.1.1.61 Plant PC, plant computer It is a computer that is specifically in the scope of responsibility of the plant operator and is administered there.
8.1.1.62 Predetermined breaking point Describes a specific element where the communication chain from a device to a central server must fail in situations with unexpected high load. A DoS attack or a malfunction of the software could responsible for this unexpected load situation. The disruption of the communication between the effected components should ensure the stability of the remaining system.
8.1.1.63 Process Control (Systems) Network (PCN) It is the name for a network as part of a security cell or security area of the plant, in which the PCS systems (Process Control Systems), DCS systems (Distributed Control Systems), or SCADA systems are located (SCADA: Supervisory Control and Data Acquisition). Each of these is respectively the so-called plant or terminal or HMI (Human Machine Interface) network. This should be a special and separate network. In certain cases, the maintenance staff also uses this network.
8.1.1.64 Programmable Logic Controllers (PLC) It is a device that is used for open-loop or closed-loop control of a machine or plant and is programmed digitally. Since a few years, it has been replacing the "hardwired" programmed controller in most segments.
8.1.1.65 Protocol This is a group of rules and conventions that is used to send information over a network. These rules control the format, the repeat rate, the sequence and error control of the messages exchanged between the network devices.
8.1.1.66 Process Control Network PCN (ISA-99): Such networks that are usually connected with time-critical mechanisms for controlling physical processes.
Note:
The process control network can be split in different zones and a company or plant can have multiple process control networks.
Page 256 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
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, WinCC OA HTTP-Server.
8.1.1.68 Process Control Engineering Process control engineering designates resources and processes that are used to control, regulate and secure process-related plants. The central resources are the process control system and the programmable logic controller. Besides this, there is still the hardwired programmed controller, which is not suitable for complex applications. Hence, at present, it is used only where the installation of a PLC appears to be too expensive or there are special demands on security.
A procedural process changes material depending on the type, property and composition. Typical procedural plants are refineries, cement plants, rolling mills or paper factories. Related areas such as discrete manufacturing or building technology have developed processes like those for manufacturing control technology and building control technology. The basic task of process control engineering is to control and monitor the process. The purpose is to maintain certain set-point conditions (temperature, fill level, atmospheric humidity, etc.) and to trigger an alarm or activate a safety function in case of large deviations.
The modules of process control engineering communicate via special data links (Profibus, Modbus and LON). However, the lower-priced data links from the world of computers are being used increasingly even in this field. There is almost no system today that is not provided with the (Ethernet) network prevalent in the PC world. Modern process control systems can also send e-mails and information to cell phones via SMS.
The systems of process control engineering are programmed using pre-defined software modules. This reduces the number of errors considerably and enhances operational security (configuring instead of programming).
This is important since these systems sometimes also watch, and control processes associated with a certain hazard potential. Similarly, there are pre-defined modules to configure graphic displays (process visualization) for representing the workflows internal to the process (plant, machinery). The graphical information can be shown on a PC that is connected to the system or directly on a monitor.
8.1.1.69 Process Control Engineering, Control Equipment (ISA-99): A category that comprises decentralized process control systems, programmable logic controllers, SCADA systems, consoles for user interfaces as well as sensor facilities and control devices in the field of administration and controlling of the process.
Note
The term also covers field bus systems which contain control logic and algorithms run on intelligent electronic devices that coordinate their actions.
Page 257 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
8.1.1.70 Process Control Engineering and Personnel, IACS – Industrial Automation and Control Systems The term covers control systems for the usage in manufacture and process engineering plants and facilities, in building automation, in plants with geographical distributed operating procedures like utility companies (energy, gas and water companies), in production and distribution plants like pipelines for oil, as well as other industry branches like traffic networks that have an atomized process or are managed by remote access.
This is a combination of staff, hardware and software that can influence the reliable performance or execution of an industrial process in a safe and secure way.
Note
These systems are:
• Industrial process control systems like e.g. Distributed Control Systems/DCSs, Programmable Logic Controllers/PLCs, Remote Terminal Units/RTUs, intelligent electronic devices, SCADA systems (Supervisory Control and Data Acquisition), linked electronic sensors and controls as well as monitoring and diagnostic systems. In this context process control systems, whether in physically distributed or integrated form, feature the basic functions of process control systems as well as Safety Instrumented Systems/SIS.
• Assigned information systems like systems for expanded or changeable controls, accelerator, display for fixed installed devices, graphical user interfaces, process history, (Manufacturing Execution Systems/MES as well as plant information management systems. Assigned internal interfaces, network interfaces, machine interfaces or user interfaces that provide functions for controlling, security and production operations for continuous, batch, discrete or other processes.
8.1.1.71 Process Visualization System / SCADA SCADA is a control system architecture that uses computers, networked data communications and graphical user interfaces for process supervisory management.
For more information see Wikipedia: https://en.wikipedia.org/wiki/SCADA (acc.: 27th March 2019)
8.1.1.72 Program Management According to definition given by PMI (https://www.pmi.org (acc.: 27th March 2019)) a program is a superior collection of projects in the same environment or the same goal. In context of this guideline a security program includes different security related projects like:
• Configuration and hardening of WinCC OA. • Implementation and configuration of network infrastructure. • Definition and usage of security policies on site. In this case a program management is the process of managing several related projects with the intention of improving organization performance.
Page 258 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
8.1.1.73 Remote client Explanation according to ISA-99: "Resources external to the process control network that are connected temporarily or permanently with a host computer in the process control network via a communication link. These resources enable access to parts of the control devices and equipment in the process control network directly or indirectly."
8.1.1.74 Remote access Remote access describes the usage of systems that enable access to the resources of a security zone from a remote location. A human, a software process or a device can perform this access.
This is part of the integrated routing and RAS (Remote Access Service), the telephone worker, external field employees and Plant administrators. They administer the servers in various branches of an organization enabling network access from a remote location. Users can dial up into the network from a remote location to use certain services. These include, for example, file and printer sharing, e-mail, scheduling and SQL databases.
8.1.1.75 Remote UI This is the default user interface from WinCC OA which is installed via a common setup. It holds libraries and executables which are installed on the local machine. A UI interface establishes a connection to the associated Data- and Event manager. It is possible to execute this UI local on the same machine or on a remote machine.
8.1.1.76 Role-Based access control By using the permission bits, a user is assigned to a role. Based on the applied role different privileges can be granted or revoked for the control system.
8.1.1.77 Router This hardware enables interoperability and connectivity between local area networks (LAN) and WANs (Wide Area Network) and the interconnection of LANs with different network topologies (such as, for example, Ethernet and Token Ring). Routers compare the information contained in the packet header with a LAN segment and then choose the best possible transmission path for the packet. In the process, they try to optimize the network performance.
8.1.1.78 Samba Samba is a free software re-implementation of the SMB/CIFS networking protocol.
Samba runs on most Unix, OpenVMS and Unix-like systems, such as Linux, Solaris, AIX and the BSD variants, including Apple's Mac-OS Server, and Mac-OS client (Mac OS X 10.2 and greater). Samba is standard on nearly all distributions of Linux and is commonly included as a basic system service on other Unix-based operating systems as well. Samba is released under the terms of the GNU General Public License. The name Samba comes from SMB (Server Message Block), the name of the standard protocol used by the Microsoft® Windows network file system.
Samba provides file and print services for various Microsoft® Windows clients and can integrate with a Microsoft® Windows Server domain, either as a Domain Controller (DC) or as a domain member. As of version 4, it supports AD and Microsoft Windows NT domains.
Page 259 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
8.1.1.79 Samba 4 Domain Controller Starting from version 4.0, Samba can run as Domain controller (DC). This technology allows a centralized user and resource management for Linux based OS systems. It is a major rewrite that enables Samba to be an AD domain controller, participating fully in a Windows AD Domain.
8.1.1.80 Security-Enhanced Linux (SELinux) This is an enhancement inside the Linux Kernel itself which was originally developed by US National Security Agency (NSA). It is a standard fare on some Linux distributions like CentOS and provides mechanisms to support mandatory access control by security policies.
8.1.1.81 Service Principal Name “Service principal names are associated with the security principal (user or groups) in whose security context the service executes. SPNs are used to support mutual authentication between a client application and a service. An SPN is assembled from information that a client knows about a service. Or, it can obtain information from a trusted third party, such as Active Directory. A service principal name is associated with an account and an account can have many service principal names.” (Microsoft, Microsoft Technet, kein Datum)
8.1.1.82 Single Sign On This feature is applicable to each workstation. If the feature is enabled in the WinCC OA Windows user administration, it is not necessary to enter a password when starting the WinCC OA UI client. Windows login takes place automatically. In addition, the authorization level 'bit 32' enables the usage of SSO feature for a workstation.
8.1.1.83 Sudo command This is a Linux specific command where root permission is required when executing it as common user. This command is placed in front of the original command and the OS requests the user password at the first execution (e.g.: sudo apt-get upgrade). After the first execution the password is cached until a configurable timeout (default 15 minutes) is reached. A modification of this timeout is possible with the file /etc/sudoers. Following line reduces the default timeout to two minutes:
Defaults timestamp_timeout=120
8.1.1.84 Support PC, support device This describes a mobile or stationary PC for a support employee that has the privileges to establish a connection to the live system. In the security concept this fact is shown by allowing this computer a connection over the perimeter zone.
8.1.1.85 Support Station Stationary support PC that is either physically positioned at the plant as MES in the PCN and therefore part of the plant or positioned as a distributed MES in a perimeter network/MON and is a trustworthy distributed plant PC.
8.1.1.86 Tampering Within this document the term tampering refers to a modification of products in a way that would make them harmful to the consumer. It is essential to configure the SCADA system in a way that avoids any case of tampering. It is possible to scan the own system for vulnerability regarding tampering by usage of vulnerability scanners like MBSA from Microsoft®.
Page 260 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
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.
WinCC OA Documentation reference
System management / Authorization / Authorization levels
Page 261 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
8.1.1.93 Vimacc® System “Vimacc® is a universal digital video management system that can be seamlessly integrated into existing system structures. It not only integrates different peripheral video systems it can also be integrated itself into various superior systems. Vimacc® is platform independent and has a modular structure.
• Independent from a system's design, complexity and architecture, vimacc® • Manufacturer independent and standardized integration • Manual and alarm-controlled surveillance • Permanent recording in configurable ring; manually resp. alarm-controlled • Efficient, fast, accurate, and data protection compliant investigation • Redirecting to external systems:
• independent from manufacturer due to standard interfaces • Data protection compliant deployment for multiple clients simultaneously “ (Accellence Technologies, 2018)
8.1.1.94 Virtual Private Network (VPN) This is the extension of a private network that includes encapsulated, encoded and authenticated links over commonly used or public networks. It is possible to use remote access and routing connections for private networks via the Internet with VPN connections.
8.1.1.95 WebClient A WebClient is any computer or software application that sets up a link with another computer with a running Webserver to requests its service.
8.1.1.96 WebSocket and WebSocket secure (WS and WSS) WebSocket is a computer communication protocol, supplying full-duplex communication channels over a single TCP connection. The WebSocket protocol enables interaction between a web client (e.g. a browser) and a web server with lower overhead and is used by ULC UX client from WinCC OA. The secure mode supports encrypted communication.
8.1.1.97 WinCC OA HTTP-Server This is a Webserver for static HTML files and file transfer, dynamic HTML files and scripting on the server side using WinCC OA control script. This is a unique HTTP server technology designed for usage directly with WinCC OA and it is recommended to run this service as predetermined breaking point and inside a DMZ for security reasons. This service does not implant specific security technology as know by the common Apache Server, but it is possible to use both technologies together.
Page 262 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
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.
WinCC OA Documentation reference
System management / Authorization / Workstation authorization
8.1.1.99 X.500 X.500 Directory Service is a standard way to develop an electronic directory of people in an organization so that it can be part of a global directory available to anyone in the world with Internet access.
Page 263 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
9 Lists
Table of figures Figure 1 - IEC 62443 definition from 9th February 2018 (ISA99, kein Datum) ...... 17
Figure 2 - Responsibilities for asset owner, Integrator and Product supplier in IEC62443 (Kobes, 2016) ..... 20
Figure 3 - Weakest point in chain (Siemens, 2019) ...... 20
Figure 4 - Automation levels (Siemens, 2019) ...... 24
Figure 5 - Security Management Process (Siemens, 2019) ...... 28
Figure 6 - Basic layers of defense in depth according to responsibility ...... 29
Figure 7 - Layers of protection ...... 31
Figure 8 – Implementation of Defense in Depth concept for different Types of Access (Siemens, 2019) ..... 35
Figure 9 – Splitting of Security Cells (Siemens, 2019) ...... 38
Figure 10 - Communication in Security Cells (Siemens, 2019) ...... 38
Figure 11 - Operation Levels (Siemens, 2019) ...... 40
Figure 12 - Operation levels Personal production (Siemens, 2019) ...... 41
Figure 13 - Operation levels production (Siemens, 2019) ...... 42
Figure 14 - Operation levels Domain Production (Siemens, 2019) ...... 43
Figure 13- Usage of TLS/SSL in OSI model between Client and Server ...... 46
Figure 16 - Public/Private Key encryption (Gilliam, 2018) ...... 47
Figure 17 - Public/Private Key signature (Gilliam, 2018) ...... 48
Figure 18 - Usage of MAC Signature ...... 49
Figure 19 - TLS Handshake protocol (Zwodrei, 2015) ...... 50
Figure 20 - Kerberos Ticket granting service ...... 51
Page 264 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
Figure 21 - Phases in Security Strategy ...... 53
Figure 22 - Highly secure large system with WinCC OA DRS System ...... 58
Figure 23 - Secure small system ...... 62
Figure 24 - Secure security cell link ...... 64
Figure 25 - Secure security cell link with security tunnel ...... 65
Figure 26 - Sample configuration for security cell connection via a single WinCC OA mxProxy ...... 66
Figure 27 - Digital signature signed by ETM professional control GmbH ...... 82
Figure 28 - Access from malicious user via DCOM interface ...... 86
Figure 29 - Usage of DCOM Tunneling Software ...... 87
Figure 30 - OPC tunnel protocol from OPC Expert (https://opcexpert.com/) ...... 87
Figure 31 – Reverse-Proxy schema ...... 88
Figure 32 - Example for Apache configuration with Desktop UI or Remote UI ...... 90
Figure 33 - Import certificate into Trusted Root Certification Authorities ...... 92
Figure 34 - Start page from WinCC OA HTTP-Server with trusted certificate via Apache Server ...... 93
Figure 35 - Example for Apache configuration with ULC UX ...... 95
Figure 36 - Secure ULC UX communication via Apache Proxy ...... 97
Figure 37 - Oracle Database Appliance X7-2M ( (Oracle, 2019) ...... 98
Figure 38 - SELinux ...... 99
Figure 39 - Schematic graphic of the communication using the WinCC OA mxProxy with a remote UI ...... 103
Figure 40 - Sample configuration for a remote WinCC OA mxProxy ...... 104
Figure 41 - SSL host certificates panel ...... 110
Figure 42 - Certificates Snap-in for MMC ...... 115
Page 265 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
Figure 43 - Settings to import PKCS12 certificate ...... 116
Figure 44 - Imported host certificate and certification chain (chain of trust) ...... 117
Figure 45 - Configure Read Permission to Private Key for WinCC OA Users ...... 118
Figure 46 - Certificate in store of Current User ...... 119
Figure 47 - Example for chainPrefix ...... 120
Figure 48 - Default user role in WinCC OA ...... 125
Figure 49 - Datapoint with authorization config ...... 126
Figure 50 - Permission bits for pairs OpAll_tunnel1- tunnel1/tunnel2 ...... 130
Figure 51 - Permission bits for pairs OpAll_tunnel2-tunnel2/tunnel3 ...... 131
Figure 52 - Permission bits for the pair OpAll_tunnel3-tunnel3 ...... 131
Figure 53 - Effective user permissions for user tunnelOperator1 ...... 132
Figure 54 - Disable Automatic Unlock for mobile devices and WinCC OA Desktop UI ...... 136
Figure 55 - WinCC OA as MQTT client ...... 138
Figure 56 – Protect unsecure WinCC OA driver communication with Secure Tunnel...... 139
Figure 57 - Compare Ethernet- to Serial protocol protection ...... 141
Figure 58 - Signature for Desktop UI installation package ...... 143
Figure 59 - Digital signature for executable ...... 144
Figure 60 - Prevent DoS Attack via config settings ...... 148
Figure 61 - Prevent DoS Attack to WinCC OA driver via config settings ...... 149
Figure 62- Central user administration with Domain Controller and different permissions ...... 155
Figure 61 - System authorization panel to set permission bit 3 ...... 156
Figure 64 - Usage WinCC OA in PAM architecture ...... 157
Page 266 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
Figure 65 - Windows/Linux DC Architecture ...... 158
Figure 66 - User defined authentication with external tool ...... 161
Figure 65 - Increasing Password length with fixed Alphabet size of 26 ...... 166
Figure 66 – Increasing Alphabet size with fixed Password length of 5 ...... 166
Figure 69 - Single Sign On ...... 175
Figure 70 – Compare SSA login process with WinCC OA default mechanism ...... 177
Figure 71 - SSA example ...... 178
Figure 72 - Create certificate for SSA with session binding ...... 181
Figure 73 - Windows certificate Store with SSA certificates for Manager ...... 184
Figure 74 - Interaction VMS and WinCC OA (Accellence Technologies, 2018) ...... 190
Figure 75 - Video Security Wizard ...... 191
Figure 76 - CTK Implementation ...... 192
Figure 77 - Communication Methods in WinCC OA with remote mxProxy ...... 196
Figure 78 - Communication Methods in WinCC OA with local mxProxy ...... 198
Figure 79 - Communication Methods in WinCC OA with local mxProxy and Apache Reverse-Proxy ...... 200
Figure 80 - Usage of WSUS server ...... 206
Figure 81 - Virus Scan Overview (Siemens, 2019) ...... 209
Figure 82 - Usage of Virus scan server ...... 210
Figure 83 - Backup Schema ...... 219
Figure 84 - Grandfather/Father/Son backup principle ...... 220
Figure 85 - Magic square by Gartner for vendors of backup and restore software (Gartner, 2017) ...... 221
Figure 86 - IEC 9126 Schema ...... 222
Page 267 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
Figure 85 - Online Backup ...... 223
Figure 88 - Parameterization Backup ...... 223
Figure 89 – Archives in Historical Archive (HDB) ...... 224
Figure 90 – Archive Groups in RDB Archive ...... 224
Figure 91 - Steps of VDI/VDE 2182 ...... 226
Figure 92 - Part from Highly Secure Large System architecture ...... 228
Figure 93 – Definition of exposure ...... 230
Figure 94 – Define Likelihood matrix based on Exploitability and Exposure ...... 230
Figure 95 – Define the risk level on site ...... 230
Figure 96 – Evaluation of risk level ...... 231
Figure 97 - Definition of Security threat ...... 231
Figure 98 - Architecture BitLocker (Microsoft, BitLocker, 2016) ...... 235
Page 268 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
List of Tables Table 1 - List of Abbreviations ...... 15
Table 2 - Norms and Standards ...... 21
Table 3 - Strategy of IT Security ...... 27
Table 4 - Security Solutions ...... 54
Table 5 - Firewall Overview ...... 55
Table 6 – User authorization on folder level ...... 80
Table 7 – Port WinCC OA mxProxy ...... 102
Table 8 - Default communication ports used for alive-message communication ...... 108
Table 9 - List of useable cipher suits in WinCC OA ...... 122
Table 10 – Faults in RPM file check ...... 145
Table 11 - Compare methods of user authentication ...... 152
Table 12 – Security assessment of authentication method in WinCC OA ...... 153
Table 13 - Time for brute-force attack ...... 166
Table 14 – Matrix for UI in intended operational environment ...... 188
Table 15 – Types of OS related patches ...... 203
Table 16 - VDI/VDE Example Step 2 ...... 229
Table 17 - VDI/VDE Example Step 3 ...... 229
Table 18 - VDI/VDE example step 4 ...... 232
Table 19 - VDI/VDE example step 6 ...... 233
Table 20 - Security Checklist ...... 242
Table 21 – List of available cipher suites (Siemens, 2019) ...... 244
Page 269 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
List of citations Accellence Technologies. (2018, 09 17). https://www.accellence.de/en.
Blunden, B. (2013). Software Exorcism. New York, NY 10013: Apress.
BSI - IT-Grundschutz-Catalogues. (2013). Retrieved from https://download.gsb.bund.de/BSI/ITGSKEN/IT-GSK-13-EL- en-all_v940.pdf
BSI. (2019, 03 26). Daten auf Festplatten richtig löschen. Retrieved from https://www.bsi-fuer- buerger.de/BSIFB/DE/Empfehlungen/RichtigLoeschen/richtigloeschen.html
CIS. (2018, 11 29). Center of Internet Security. Retrieved from https://www.cisecurity.org/
Fernandez, I. (2015). Beginning Oracle Database 12c Administration: From Novice to Professional (2nd edition). Apress.
Gartner. (2017, 7 31). Retrieved 09 27, 2017, from https://www.gartner.com
Gerhard Ackermann, Robert Hönl. (2006). Schutz von IT-Anlagen gegen Überspannung. Berlin: VDE Verlag.
Gilliam. (2018, 2 25). Public-key cryptography. Retrieved 3 05, 2018, from Wikipedia: https://en.wikipedia.org/wiki/Public-key_cryptography
ICS-Cert. (2018, 1). ICS-Cert. Retrieved 1 10, 2018, from https://ics-cert.us- cert.gov/sites/default/files/recommended_practices/RP_Updating_Antivirus_in_an_ICS_S508C.pdf
IEC 62443-2-1. (2010, 11). IEC 62443-2-1. IEC.
IEC_9126, W. (2017, 4 5). IEC_9126, Wikipedia. Retrieved 9 27, 2017, from https://en.wikipedia.org/wiki/ISO/IEC_9126
ISA99, C. (n.d.). ISA99 Committee. Retrieved 2 28, 2018, from http://isa99.isa.org/Public/Forms/AllItems.aspx?RootFolder=%2FPublic%2FImages
K. K. Mookhey, Nilesh Burghate. (2005). Linux - Security, Audit and Control Features. Rolling Meadows, IL 60008 USA: Information Systems Audit and Control Association.
Kobes, P. (2016). Leitfaden Industrial Security IEC 62443 einfach erklärt. Berlin: VDE VERLAG GMBH.
Microsoft. (2016, 09 08). BitLocker. Retrieved from https://docs.microsoft.com/en-us/previous-versions/technet- magazine/cc160980(v=msdn.10)
Microsoft. (2019, 02 04). Cipher Suites in TLS/SSL (Schannel SSP). Retrieved from https://docs.microsoft.com/en- au/windows/desktop/SecAuthN/cipher-suites-in-schannel
Microsoft. (n.d.). Microsoft Technet. Retrieved 3 6, 2018, from Service Principal Names: https://technet.microsoft.com/en-us/library/cc961723.aspx
Microsoft. (n.d.). Require SMB Security Signatures. Retrieved 7 10, 2018, from https://docs.microsoft.com/en- us/previous-versions/orphan-topics/ws.11/cc731957(v=ws.11)
NSA. (2019). National Security Agency / Central Security Service. Retrieved from https://www.nsa.gov/what-we- do/research/selinux/
Page 270 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)
Oracle. (2019). Oracle Database Appliance X7-2M. Retrieved from https://www.oracle.com/engineered- systems/database-appliance/x7-2m/
Raina, K. (2003). PKI Security Solutions for the Enterprise. Indianapolic, Indiana: Wiley Publishing Inc.
Shaw, W. T. (2006). Cybersecurity for SCADA Systems. Tulsa, Oklahoma 74112-6600 USA: PennWell Corporation.
Siemens. (2019). Siemens PSS Network.
Smulders, P. (1990). The threat of information theft by reception of electromagnetic radiation from rs-232 cables. In Computer & Security vol. 9 (pp. 53-58).
Stapleton & Epstein. (2016). Security without Obsurity - A Guide to PKI Operations. Boca Raton, FL 33487-2742: CRC Press, Taylor & Francis Group.
Wikipedia. (2018, 10 9). Denial-of-service attack. Retrieved from https://en.wikipedia.org/wiki/Denial-of-service_attack
Zvarych, A.G.; Pomales, I.; Rodriguez, J.; Villasmil, D. (2014). Practical Communications Considerations for Protection Engineers. Retrieved from https://ieeexplore.ieee.org/document/6799025
Zwodrei. (2015, 3 10). SSL handshake with two way authentication with certificates. Retrieved 3 5, 2018, from https://commons.wikimedia.org/w/index.php?curid=9031795
Page 271 of 271
SIMATIC - WinCC Open Architecture3.16 FP2 (P009)