Belden HIRSCHMANN HiOS-2A User manual

UM Security BRS-2A
Release 8.7 05/2022
Technical support
https://hirschmann-support.belden.com
User Manual
Security
BOBCAT Rail Switch
HiOS-2A

2022-05-31
The naming of copyrighted trademarks in this manual, even when not specially indicated, should not be taken to mean that
these names may be considered as free in the sense of the trademark and tradename protection law and hence that they may
be freely used by anyone.
© 2022 Hirschmann Automation and Control GmbH
Manuals and software are protected by copyright. All rights reserved. The copying, reproduction, translation, conversion into
any electronic medium or machine scannable form is not permitted, either in whole or in part. An exception is the preparation
of a backup copy of the software for your own use.
The performance features described here are binding only if they have been expressly agreed when the contract was made.
This document was produced by Hirschmann Automation and Control GmbH according to the best of the company's
knowledge. Hirschmann reserves the right to change the contents of this document without prior notice. Hirschmann can give
no guarantee in respect of the correctness or accuracy of the information in this document.
Hirschmann can accept no responsibility for damages, resulting from the use of the network components or the associated
operating software. In addition, we refer to the conditions of use specified in the license contract.
You find the latest user documentation for your device at: doc.hirschmann.com
Hirschmann Automation and Control GmbH
Stuttgarter Str. 45-51
72654 Neckartenzlingen
Germany

Contents
3
UM Security BRS-2A
Release 8.7 05/2022
Contents
Document History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Safety instructions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
About this Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Key. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1 Security planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.1.1 Subject . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.1.2 Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.1.3 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.1.4 Capability security level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.1.5 Document Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.2 Defense in depth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.2.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.2.2 Defense in depth vs. hardening . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.2.3 Responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.2.4 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.3 Impact of the system lifecycle to the device lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.3.1 VLAN plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.4 Impact of device requirements on system planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.4.1 Secure installation location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.4.2 Plan a dedicated user account login policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.4.3 Plan a dedicated user account password policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.4.4 Plan a dedicated user account name and access role policy for device management . . . . . . . . 20
1.4.5 Plan a dedicated logging policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.4.6 VLAN plan considerations depending on redundancy protocols . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.4.7 Network time synchronization considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2 Device security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.1 Security vs. functionality. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.2 Prerequisites for installation and setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.3 Recommended installation work step sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.3.1 Reasons for the recommended installation work step sequence. . . . . . . . . . . . . . . . . . . . . . . . . 25
2.3.2 Recommended preparation for installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.4 Choice of a secure installation location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.4.1 Device availability requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.5 Software update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Contents
4UM Security BRS-2A
Release 8.7 05/2022
2.6 Security configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.6.1 Assign a static IP address for the device management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.6.2 Disable HiDiscovery access. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.6.3 Configure a VLAN dedicated to management access. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.6.4 Disable logical access to the Signal Contact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.6.5 Disable logical access to the Digital Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.6.6 Disable logical access to unused ports and SFP slots. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.6.7 Configure Power over Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.6.8 Disable booting from an external memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.6.9 Disable automatic device software update from an external memory . . . . . . . . . . . . . . . . . . . . . 31
2.6.10 Disable writing a configuration profile to an external memory . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.6.11 Disable loading a configuration profile from an external memory . . . . . . . . . . . . . . . . . . . . . . . . 31
2.6.12 Disable loading a configuration profile that lacks a valid fingerprint. . . . . . . . . . . . . . . . . . . . . . . 32
2.6.13 Disable insecure management protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.6.14 Configure management IP access restrictions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.6.15 Configure a dedicated HTTPS certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.6.16 Configure a dedicated SSH host key pair . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.6.17 Configure a dedicated user account login policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.6.18 Configure a dedicated user account password policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.6.19 Configure dedicated user account names and access roles for device management . . . . . . . . . 34
2.6.20 Adapt session timeouts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.6.21 Configure time synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.6.22 Configure logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.6.23 Configure dedicated login banners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.6.24 Configure advanced device security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.6.25 Configure advanced user authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.6.26 Create a backup of device-specific data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.7 Possible hardware modifications for security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.7.1 Restrict physical access to the USB port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.7.2 Restrict physical access to network ports or SFP slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.7.3 Restrict physical (visual) access to the device and port LEDs . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.7.4 Restrict physical access to the Signal Contact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.7.5 Restrict physical access to the Digital Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.8 Device installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.8.1 Data connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.8.2 Signal Contact considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.8.3 Digital Input considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.9 Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.9.1 Environmental conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.9.2 Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.10 Maintenance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.10.1 Software update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.10.2 Hardware enhancement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.10.3 Hardware replacement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.10.4 Hardware repair . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.11 Decommissioning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.11.1 Destruction of confidential data and secrets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.11.2 Secure physical destruction of device and components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3 Network security support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.2 Prerequisites for setting up network security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.3 Employ defense in depth for your network infrastructure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Contents
5
UM Security BRS-2A
Release 8.7 05/2022
3.4 Hardening the network infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.5 Measures to secure the network infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.6 Restrict logical access to your network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.6.1 Configure a dedicated management VLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.6.2 Configure VLAN segregation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.6.3 Disable GVRP and MVRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.6.4 Configure Port Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.6.5 Configure ACLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.7 Secure the network protocols used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.7.1 Disable GMRP and MMRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.8 Secure the redundancy protocols used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.8.1 Secure RSTP guards and helper protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.8.2 Secure MRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.8.3 Secure HIPER Ring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.8.4 Secure Ring/Network Coupling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.9 Configure attack protection functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.9.1 Configure Denial of Service (DoS) protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.9.2 Configure rate limiters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.10 Configure network time synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.11 Configure logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.11.1 Configure an audit trail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
A Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
B Further support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
C Readers’ Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Contents
6UM Security BRS-2A
Release 8.7 05/2022

Document History
7
UM Security BRS-2A
Release 8.7 05/2022
Document History
Version Finalize date Finalized by Relevant content changes
0.21a 2021-08-30 U. Messerle Prepared draft for review.
0.30b 2021-11-02 U. Messerle Reworked according to review results: Removed default
user credentials "user/public". Added "hardening" to scope.
Generalized some descriptions for device security (they
also apply to operation and maintenance). Added backup
recommendation. Detailed steps for sending a device for
repair. Detailed the recommendation to disable L2 loop
protection.
0.99a
(RC1)
2022-03-18 U. Messerle Added chapter "Plan a dedicated logging policy". Updated
chapter "Operations". Updated configuration details by
referring to the respective user manuals. Expanded topics
"Defense in depth" and "Hardening" in main chapter
"Network security".
0.99b
(RC2)
2022-03-30 U. Messerle Reworked the delivery states of several settings. Added
setting for OPC UA Server.
0.99c
(RC3)
2022-04-04 U. Messerle (Internal) Removed misplaced function-related tag.
0.99d
(RC4)
2022-04-05 U. Messerle Review incorporated: Improved description of hardening.
Clarified restrictions to physical access. Pointed out forced
password change. Removed claims that the external
memory function of the USB port can be disabled. Changed
delivery state setting of EtherNet/IP management access to
disabled. More detailed logging configuration. Added CLI
pre-login banner. More detailed backup creation. Added
cross references.
0.99e
(RC5)
2022-04-05 U. Messerle (Minor) Improved grammar.
0.99f
(RC6)
2022-04-06 U. Messerle Aligned document to terminology and language rules.
Improved description of PoE delivery state settings.
0.99g
(RC7)
2022-04-08 U. Messerle Moved this history to the beginning of the document and
updated column headers.
0.99h
(RC8)
2022-04-13 U. Messerle Detailed time synchronization considerations.
0.99i
(RC9)
2022-05-17 U. Messerle Defined responsibility for defense in depth and hardening
and recommended how to select security measures.
Rel. 8.7 2022-05-31 U. Messerle Released for BOBCAT Rail Switch (BRS).

Document History
8UM Security BRS-2A
Release 8.7 05/2022

Safety instructions
9
UM Security BRS-2A
Release 8.7 05/2022
Safety instructions
WARNING
UNCONTROLLED MACHINE ACTIONS
To avoid uncontrolled machine actions caused by data loss, configure all the data transmission
devices individually.
Before you start any machine which is controlled via data transmission, be sure to complete the
configuration of all data transmission devices.
Failure to follow these instructions can result in death, serious injury, or equipment
damage.

Safety instructions
10 UM Security BRS-2A
Release 8.7 05/2022

About this Manual
11
UM Security BRS-2A
Release 8.7 05/2022
About this Manual
The “Configuration” user manual contains the information you need to start operating the device. It
takes you step by step from the first startup operation through to the basic settings for operation in
your environment.
The “Installation” user manual contains a device description, safety instructions, a description of the
display, and the other information that you need to install the device.
The “Graphical User Interface” reference manual contains detailed information on using the
graphical user interface to operate the individual functions of the device.
The “Command Line Interface” reference manual contains detailed information on using the
Command Line Interface to operate the individual functions of the device.
The “Security” user manual contains considerations for system security planning,
recommendations for the device security over the device lifecycle, and descriptions how the device
can help to improve the security of your network.
The Industrial HiVision Network Management software provides you with additional options for
smooth configuration and monitoring:
Auto-topology discovery
Browser interface
Client/server structure
Event handling
Event log
Simultaneous configuration of multiple devices
Graphical user interface with network layout
SNMP/OPC gateway

Key
12 UM Security BRS-2A
Release 8.7 05/2022
Key
The designations used in this manual have the following meanings:
List
Work step
Link Cross-reference with link
Note: A note emphasizes a significant fact or draws your attention to a dependency.
Courier
Representation of a CLI command or field contents in the graphical user interface
Execution in the Graphical User Interface
Execution in the Command Line Interface

Security planning
1.1
Introduction
13
UM Security BRS-2A
Release 8.7 05/2022
1 Security planning
1.1 Introduction
1.1.1 Subject
The user manual "Security" contains security recommendations for your network device. It deals
with the following lifecycle phases of your device:
Secure installation
Secure commissioning
Secure administration and operation
Secure maintenance
Secure decommissioning
A secured device in turn can help you to maintain the security and availability of your network.
1.1.2 Audience
This security manual primarily addresses ETHERNET network planners, commissioners,
administrators, operators, maintainers, and decommissioners.
Its contents may also be useful for solution providers, sales partners, and system integrators.
1.1.3 Scope
This document deals with the recommended device security measures throughout the device
lifecycle. These recommendations include:
How to achieve defense in depth for the device
How to harden the device
How a specifically configured device can help you achieve defense in depth for your system
How a specifically configured device can help you harden your system
A network device is part of a superordinate system. Therefore, the device and the system are
interdependent. The system lifecycle and the requirements of the system for defense in depth are
outside the scope of this document. References to the system lifecycle are made only if necessary,
and only for information purposes.
For your network, additional planning and implementation steps may be necessary. For example,
you may need an L3 network plan in addition to the VLAN plan mentioned in this document. The
L3 network plan and the VLAN plan are both outside the scope of this document.

Security planning
1.1
Introduction
14 UM Security BRS-2A
Release 8.7 05/2022
1.1.4 Capability security level
The security requirements, planning steps, and measures in this document deal with the capability
security level 1 (SL-C 1) according to the standard IEC 62443-4-2. SL-C 1 means protection
against casual or coincidental security violations.
Some security requirements, measures, and steps mentioned in this document may exceed the
target security level SL-C 1. They are therefore not strictly required to achieve SL-C 1. They are
nevertheless included when these security measures and steps generally mean little effort and
reasonable effect.
1.1.5 Document Outline
The following main chapters deal with 2 main subjects:
The security of the device itself (see on page 23 “Device security”)
What a secured device can do for the security of your network (see on page 43 “Network
security support”)

Security planning
1.2
Defense in depth
15
UM Security BRS-2A
Release 8.7 05/2022
1.2 Defense in depth
1.2.1 Purpose
Defense in depth is a strategy that employs various independent security measures to guard an
asset under consideration against specific attacks.
A system that employs defense in depth first confronts an attacker with a particular barrier. If an
attacker overcomes this barrier, the system presents another barrier of a different type. A minimum
of 2 barriers of different types shall guard any system asset under consideration. This layered
security approach is considered best practice. It potentially demoralizes an attacker while taking
the imperfection of real-world security barriers into account.
1.2.2 Defense in depth vs. hardening
In comparison to hardening, defense in depth is a more selective and structured approach. Defense
in depth employs a specific subset of all conceivable security measures.
Hardening can be characterized as defense in broad. It aims at closing as many weaknesses in any
barriers as possible and reasonable. A strategy for hardening may include the concepts "least
necessary functions" for the device and "least necessary privileges" for user accounts.
Develop a strategy for defense in depth first. Then complement it by hardening.
1.2.3 Responsibilities
Defense in depth as well as hardening need planning, implementation and maintenance. It is the
responsibility of the system operator to perform these steps.
Hirschmann recommends that you consider all security measures given in this manual, and to
select those that are most relevant for the actual situation.
1.2.4 Example
ID Barrier Description
System level
1 Internet Firewall An attacker must overcome the internet firewall between to get
access to the company Intranet.
2 Industrial Firewall An attacker must overcome the industrial firewall to get access to
the industrial network. The industrial firewall separates the
industrial network from the company Intranet.
3 Dedicated device
management VLAN
An attacker must overcome VLAN restrictions to snoop packets
like unknown unicast frames of device management traffic.
Device level
4 Secure management
protocols only
An attacker must overcome encryption to snoop packet contents.

Security planning
1.2
Defense in depth
16 UM Security BRS-2A
Release 8.7 05/2022
5 Non-default user account
names1
An attacker must guess or find out the real user account names.
6Non-default passwords2An attacker must guess or find out the real passwords.
7 Specific, restricted
account privileges
An attacker must guess or find out the administrator account
credentials to read privileged data or manipulate device settings.
1. Dedicated user account names can be device-specific and could be deliberately chosen to be non-descriptive.
2. Passwords can be specific to a certain access protocol (for example HTTPS or SNMPv3) and can be device-specific.
ID Barrier Description

Security planning
1.3
Impact of the system lifecycle to the device lifecycle
17
UM Security BRS-2A
Release 8.7 05/2022
1.3 Impact of the system lifecycle to the device lifecycle
A network device is a component in a superordinate system. Therefore, the system lifecycle
determines parts of the device lifecycle. A system lifecycle involves a planning phase. The
decisions taken in the planning phase affect the device lifecycle directly or indirectly.
Typical decisions during system planning include:
The physical position of the device, for example, its installation location and environment
The logical position of the device, for example, the security zone
The requirements of the system for defense in depth
1.3.1 VLAN plan
VLANs are a software-configurable concept to segregate a LAN (layer 1) into separate Virtual
LANs (VLANs) on layer 2. Advantages include the separation of data packets belonging to different
VLANs. The separation also applies to flooded multicast, broadcast, and unknown unicast frames.
This helps confidentiality besides helping reduce the network load on layer 1.
A VLAN plan is a prerequisite for a secure configuration of the device itself and in turn for the
security and availability of your system. Create a VLAN plan that segregates your network on
layer 2. A dedicated management VLAN can be a barrier component in the strategy "Defense in
depth".
For simple networks, a VLAN plan and the configuration of VLANs may be considered unnecessary
from a functional perspective. However, VLANs are recommended from a security perspective.
Note: The redundancy protocols HIPER Ring and Ring/Network Coupling employ the fixed VLAN
ID 1 for their protocol packets. Using the VLAN ID 1 exclusively for these redundancy protocols can
help enhance network availability (see on page 21 “VLAN plan considerations depending on
redundancy protocols”).
Note: For your network, additional planning and implementation steps may be necessary. For
example, you may need an L3 network plan (outside the scope of this document) in addition to the
VLAN plan.

Security planning
1.4
Impact of device requirements on system planning
18 UM Security BRS-2A
Release 8.7 05/2022
1.4 Impact of device requirements on system planning
Some requirements of the device have an impact on the system lifecycle phases, in particular on
system planning.
Topics of this interdependence include:
A secure installation location, including the aspects:
–Device availability: Power supply, power budget, and data link redundancy
–Properties of the USB port
–Properties of the Signal Contact
–Properties of the Digital Input
–Device and port LEDs
The detailed physical device security requirements
The user account policy parameters the device offers:
–For the login policy
–For the password policy
–For the user name and access role policy
–For the SNMPv3 authentication and encryption type, and password policy
VLAN ID restrictions arising from certain redundancy protocols: VLAN IDs ≥2 for payload traffic
and device management
Note: These topics are covered in more detail (see on page 23 “Device security”).
1.4.1 Secure installation location
Refer to the user manual "Installation" for a suitable physical installation location.
Select a location that in addition offers appropriate device security by restricting physical access:
Install the device in a room that can be locked and where only authorized personnel have
access.
Install the device in a cabinet to which only authorized personnel have access.
Install the device in a cabinet with an opaque door (see on page 19 “Device and port LEDs”).
Device availability
Device availability can be an important base for the security of the superordinate system.
Therefore, check that the following device availability requirements are met as needed:
Provide redundant power supply
Provide an adequate power budget (device and PoE)
Provide data link redundancy
Signal Contact
If you plan to use the Signal Contact, consider the following security aspects:
To help protect the device, connect the Signal Contact only to a circuit that meets the device
requirements.
To help protect your system, connect the Signal Contact only to circuits that do not have explicit
security or safety requirements.

Security planning
1.4
Impact of device requirements on system planning
19
UM Security BRS-2A
Release 8.7 05/2022
Digital Input
If you plan to use the Digital Input, consider the following security aspects:
To help protect the device, connect the Digital Input only to a circuit that meets the device
requirements.
To help protect your system, connect the Digital Input only to circuits that do not have explicit
security or safety requirements.
Device and port LEDs
The device and port LEDs show important information about the device state and the port states.
To prevent information leakage, consider the following security aspects as needed in addition to
the secure installation location:
Install the device in a cabinet with an opaque door.
Cover or obstruct the LEDs with a removable cover.
1.4.2 Plan a dedicated user account login policy
The device lets you configure a login policy for the user accounts. The login policy applies to all
user accounts.
It applies to the following user interfaces and access protocols:
The Command Line Interface (CLI) using SSH or Telnet
The Graphical User Interface (GUI) using HTTPS or HTTP
You can configure the following requirements for the user login:
Maximum number of failed user logins in a row until the device locks the respective user
account.
Waiting time (Login attempts period) before the device auto-unlocks a locked user account.
Access to the CLI using the serial connection is exempt from the login policy. Users accessing the
CLI using the serial connection have an unlimited number of login attempts. They are also not
required to wait for the next login attempt, that is, the Login attempts period does not apply. This
ensures access to the device management in situations where availability may be critical, and for
users who already have physical access to the device.
Note: Hirschmann recommends planning an overarching user account login policy and apply it to
each device.
1.4.3 Plan a dedicated user account password policy
The device lets you configure a password policy for the user accounts. You can configure the
following requirements for the password:
Minimum password length
Minimum number of uppercase characters
Minimum number of lowercase characters
Minimum number of digits
Minimum number of special characters

Security planning
1.4
Impact of device requirements on system planning
20 UM Security BRS-2A
Release 8.7 05/2022
Note: The device asks you to change the default password on the first login. Hirschmann
recommends planning an overarching user account password policy and apply it to each device.
To deter attackers, consider planning different passwords on different devices.
Note: Software releases 08.1.00 and higher in the delivery state no longer offer a user account with
the name user and the associated default password public . If you need a user account that has
only read access, you can create a user account with the access role guest and the user name
user .
1.4.4 Plan a dedicated user account name and access role policy for device
management
Configure dedicated user accounts as needed:
Assign the login and password policies.
Create user accounts with:
–Dedicated names1
–Chosen access roles that offer only the least necessary privileges
Assign the new user accounts strong, individual passwords and apply the password policy
check.
–Plan strong SNMPv3 authentication and encryption types and strong related passwords for
the new user accounts.
Remove user accounts with standard names.
Note: Hirschmann recommends planning an overarching user account and access role policy and
apply it to each device. To deter attackers, consider planning different user account names and
different passwords on different devices.
Hirschmann also recommends planning an overarching policy for SNMPv3 authentication and
encryption types, and the related passwords. To deter attackers, consider planning different
SNMPv3 passwords on different devices.
1.4.5 Plan a dedicated logging policy
Configure device logging settings:
Synchronize the device system clock to a trusted source.
Assign the logging destinations you require.
Assign the severity levels you require.
Note: Hirschmann recommends planning an overarching device logging policy and apply it to each
device.
Table 1: User credentials for the user account in the delivery state
User Name Default Password Access Role Privileges
admin private Administrator Monitor the device and change settings.
1.User account could also be deliberately chosen to be non-descriptive.