Sic Her He Its Hand Buch

© Siemens AG 2008
SIEMENS All Rights Reserved Energy Sector, F IE TI
Administrator Manual
Security Manual
SPPA-T3000 Release 4.2
Int-Ref: FL1601
Version 2.04 Mar 3, 2009
Security Manual for SPPA-T3000 Release 4

Mar 3, 2009 2.04 Page 1/85
© Siemens AG 2008
SPPA-T3000 Security Manual

Mar 3, 2009 2.04 Page 2/85
© Siemens AG 2008
CONTENTS
SPPA-T3000 SECURITY MANUAL ........................................................................... 2
1 INTRODUCTION ................................................................................................. 6
1.1 Purpose of the document ............................................................................................................. 6
1.2 Target group ................................................................................................................................... 6
1.3 Required knowledge...................................................................................................................... 6
2 GENERAL TERMS.............................................................................................. 7
3 SPPA-T3000 INTRODUCTION ........................................................................... 9

3.1 Standard architecture ................................................................................................................... 9
3.2 Components of SPPA-T3000 (Thin Client, Application Server, Automation Server S7,
Automation Server CM, Time Server, Firewalls, Router for Multi-Unit, Switches) ........... 10
3.2.1 User interfaces - Thin Clients ................................................................................................ 11
3.2.2 Power server – Application Server ........................................................................................ 11
3.2.3 Power server – Automation Server S7.................................................................................. 12
3.2.4 Power server – Automation Server CM104 .......................................................................... 13
3.2.5 Time server ............................................................................................................................. 13
3.2.6 Process interfaces .................................................................................................................. 13
3.2.7 Network components.............................................................................................................. 14
3.3 Networks (Application Highway, Automation Highway, Backbone Highway, DMZ)........ 16

3.3.1 Standard network topology for application and Automation Highways .............................. 16
3.3.2 Application Highway ............................................................................................................... 19
3.3.3 Automation Highway .............................................................................................................. 20
3.3.4 Backbone highways ............................................................................................................... 21
3.3.5 The DMZ network ................................................................................................................... 22
3.4 Variants (small, standard, multi-unit configuration).............................................................. 25

3.4.1 Small system........................................................................................................................... 25
3.4.2 Standard system..................................................................................................................... 25
3.4.3 Multi-unit system..................................................................................................................... 27
3.5 Software......................................................................................................................................... 28
3.5.1 Software architecture ............................................................................................................. 28
3.6 Crossover to the "outside world" ............................................................................................. 31
4 COARSE/OVERRIDING SECURITY CONCEPT .............................................. 33

4.1 Security cells ................................................................................................................................ 33
4.2 Communication rule: Everything is prohibited unless explicitly permitted...................... 34
4.3 "Reinforcing" the Thin Clients of the Control systems ........................................................ 34
4.4 Thin Clients outside the security cell "Control system" ...................................................... 34
4.5 Security logs................................................................................................................................. 35

Mar 3, 2009 2.04 Page 3/85
© Siemens AG 2008
5 THE MALWARE PREVENTION SYSTEM ........................................................ 36

5.1 Introduction .................................................................................................................................. 36
5.2 Process-flow of update mechanism ......................................................................................... 36

5.2.1 Fetching updates from Siemens servers .............................................................................. 38
5.2.2 Transferring updates to OfficeScan server........................................................................... 38
5.2.3 Installation of updates on OfficeScan server ........................................................................ 39
5.2.4 Deploying updates on OfficeScan clients ............................................................................. 39
5.3 Notification of events .................................................................................................................. 39

5.3.1 Notification of threat events ................................................................................................... 40
5.3.2 Monitoring events ................................................................................................................... 40
5.4 Dependencies ............................................................................................................................... 41

5.4.1 OfficeScan server (first Application Server).......................................................................... 41
5.4.2 Terminal Server ...................................................................................................................... 41
5.4.3 Firewall configuration ............................................................................................................. 42
6 ACCOUNT MANAGEMENT.............................................................................. 44
6.1 Access control ............................................................................................................................. 44
6.1.1 Password ................................................................................................................................ 44
6.2 Login banner................................................................................................................................. 45
6.3 Monitoring ..................................................................................................................................... 45
6.4 Auto Logoff ................................................................................................................................... 45
6.5 External Login .............................................................................................................................. 45
7 HARDENING ..................................................................................................... 47
8 SCENARIOS FOR REMOTE SERVICE ACCESS ............................................ 48

8.1 Firewall rules ................................................................................................................................ 48
8.1.1 Firewall rules 1; CAG (Customer Access Gateway) ............................................................ 49
8.1.2 Firewall rules 2; SPPA-T3000-Firewall ................................................................................. 50
8.1.3 Firewall rules 3; SPPA-T3000-Firewall/CAG combined ...................................................... 51
8.1.4 Firewall rules 4; Customer Owned Gateway and client firewall .......................................... 52
8.1.5 IP addresses of the common Remote Service Platform...................................................... 52
8.1.6 Protocols and port numbers................................................................................................... 53
8.2 General observations on remote service ................................................................................ 54

8.2.1 Comparison of external Terminal Servers and combined Thin Clients / Terminal Servers54
8.2.2 File transfer using RDP and SSH.......................................................................................... 54
8.3 Service access to SPPA-T3000 ................................................................................................. 55

8.3.1 Service access to SPPA-T3000 via Customer Access Gateway (CAG) ............................ 56
8.3.2 Service access via Customer Owned Gateway (COG) ....................................................... 61
8.4 Connection of SPPA-T3000 to an intranet............................................................................... 66

8.4.1 Thin Client in the intranet with access to SPPA-T3000 ....................................................... 67
8.5 SPPA-T3000 connection to the Internet................................................................................... 70

8.5.1 Thin Client in the Internet....................................................................................................... 70
8.6 Wireless access to SPPA-T3000 ............................................................................................... 72
8.7 Third party system connection via OPC .................................................................................. 73

Mar 3, 2009 2.04 Page 4/85
© Siemens AG 2008
8.7.1 OPC server/client system in the client intranet .................................................................... 75

8.7.2 OPC server/client system in the DMZ with access by external PI system in the client intranet
............................................................................................................................................... 77
8.8 Connecting WIN_TS via OPC ..................................................................................................... 78
8.9 Third party system connection via Modbus............................................................................ 78

8.9.1 Modbus TCP connection via CM104 .................................................................................... 78
9 ANNEXES ......................................................................................................... 80
9.1 VPN details for remote service access via cRSP................................................................... 80
9.1.1 IPSec details on establishing a VPN tunnel via the Internet to the cRSP .......................... 81
9.1.2 Configuration of the Cisco VPN client software ................................................................... 82
9.2 Applications and ports for the communication with SPPA-T3000...................................... 83
10 GLOSSARY....................................................................................................... 84

Mar 3, 2009 2.04 Page 5/85
© Siemens AG 2008
1 Introduction
1.1 Purpose of the document

The T3000 Security Manual contains information, notes and guidelines for the planning and implementation
of external access to T3000 systems.
It describes standards of a binding nature which ensure a high degree of security for the T3000 systems
and the related plant operation.
Some exemplary typical scenarios of the connection of external clients to T3000 systems are illustrated
and dealt with in detail.
The T3000 Security Manual includes:

• the information source for distributors and clients who want to know "how security is implemented in the
T3000"
• guide for planning and project design
• reference for implementation
• instruction for the network administration
The aim is to establish a common basis for the cooperation of network administrators of company
networks and of automation networks.
1.2 Target group

The T3000 Security Manual is aimed at
Clients
Distributors
Planners
Network administrators
1.3 Required knowledge

The information contained in the T3000 Security Manual is at times very specific. Therefore, some knowledge of
network administration would be an advantage.

Mar 3, 2009 2.04 Page 6/85
© Siemens AG 2008
2 General Terms
The security manual covers the complete lifecycle of a plant including FAT, commissioning phase, SAT
and operating phase. The configuration of SPPA-T3000, network topology as well as hardware and
software configuration, described in this document are the only setups authorized by Siemens E F IE. For
a secure operation of SPPA-T3000 it is obligatory to follow all instructions thoroughly. Exceptions are not
allowed.
• It is strictly forbidden to take measures which reduce the security of SPPA-T3000.

• The modification or deactivation of any instruction defined is not allowed.
• All communication parameters, such as port number and IP address, required for the accurate
operation of SPPA-T3000 are defined in this document.
• All services required for the sound operation of SPPA-T3000 are defined in this document.
Passwords:
All passwords of SPPA-T3000 are initally set by Siemens in accordance with the password policy
explained below. Siemens stores the passwords in a secure manner for remote service access. If a
customer does not agree to this he has to change the passwords.
All account passwords mentioned in this document – including operating system accounts (Windows XP
Professional and Windows Server 2003) as well as SPPA-T3000 user accounts - must meet the following
password complexity rules:
1. The password should not contain all or part of the account name of the user.
2. It should not match with the last used 4 passwords, if any.
3. It should be at least 8 characters.
4. It should contain at least one uppercase character (A to Z).
5. It should contain at least one lowercase character (a to z).
6. It should contain at least one numeric character (0 to 9).
7. It should contain at least one special character (! @ # $ % & ...etc).
8. Passwords must be changed periodically:
i. Minimum password age: 5 days
ii. Maximum password age: 90 days
Third-party systems:
It is strictly forbidden to connect third-party systems to SPPA-T3000 apart from systems used at the
commissioning phase. These can exclusively be connected to the Application Highway under the
constraint that they comply to security standard of Siemens E F IE (so-called CAT clients). Their security
standard must be tested and it is emphasised that these systems can only be connected to the
Application Highway and nowhere else.
All other access of third-party systems to SPPA-T3000 must be authorized by Siemens E F IE.
Data import and export:

Data can either be imported / exported into / from SPPA-T3000 via mobile data storage mediums (e.g.
USB memory sticks, CDs, etc.) or via network connections.
• Mobile data storage mediums : Any mobile data storage medium must previously be analyzed by
a separate system which is running an up-to-date installation of an antivirus software before it
can be connected to a SPPA-T3000 component.
• Network connections which can be used to import and export data into / from SPPA-T3000 are
only authorized inside the security cell of SPPA-T3000. In addtion, the connection endpoints must
be components of SPPA-T3000.
• Well defined data import procedures are used for specific tasks such as the regular updating of
the SPPA-T3000 antivirus database,
• No further alternative approaches to import or export data into / from SPPA-T3000 are allowed.
Firmware updates:

Mar 3, 2009 2.04 Page 7/85
© Siemens AG 2008
It is the responsibility of the customer to install new firmware on the following components of SPPA-
T3000:
• Hirschmann mGuard Eagle Firewall (http://www.hirschmann-ac.de)
• OSM/ESM- , Scalance switches
• Etc.

Mar 3, 2009 2.04 Page 8/85
© Siemens AG 2008
3 SPPA-T3000 introduction
3.1 Standard architecture
The SPPA-T3000 standard architecture is formed from 3 functional levels connected via networks.
• Presentation tier
• Processing tier
• Data tier
Functional levels Hardware
Figure 1 SPPA-T3000 levels

Mar 3, 2009 2.04 Page 9/85
© Siemens AG 2008
3.2 Components of SPPA-T3000 (Thin Client, Application Server, Automation

Server S7, Automation Server CM, Time Server, Firewalls, Router for Multi-
Unit, Switches)
Overview
User Interfaces
• Thin Clients with web browser

• Standard PCs, workstations, notebooks
Power server
• Application Server
o ft server
o non tf server
• Automation Servers
o S7
o CM104
Process Interfaces
• I/O modules
• Special I/O modules
Networks switch switch
switch switch
• Ethernet network with TCP/IP

• PROFIBUS DP fieldbus
Additional systems • Time server

• Router
• Firewalls

Mar 3, 2009 2.04 Page 10/85
© Siemens AG 2008
3.2.1 User interfaces - Thin Clients
Thin Clients form the interface between users and the functions of SPPA-T3000. In principle every
computer with a web browser can access the web applications via the local network, an intranet or via the
Internet. No particular applications need to be installed on the desktop system for this purpose.
Benefit
• Existing IT infrastructure can be used

• Easy workstation configuration for
process control applications
• No engineering or process data are
stored on the Thin Client
• Only a single input device (mouse,
keyboard) for up to four monitors
3.2.2 Power server – Application Server
Stratus ft Application Server 4300 (Aria)

High available online maintainable Application
Server
• Standard operating system (Microsoft

Window Server)
• High Performance Server (Dual Intel Xenon
Processor)
• Dual module redundancy (DMR)

Mar 3, 2009 2.04 Page 11/85
© Siemens AG 2008
non-ft Application Server

Cost-effective standard server solution
• New 64 bit Intel® Dual Xeon™ EM64T and

up to 2 MB SLC for highest performance
capability
• High data availability due to its fast, fail-safe
RAID1 system and other redundant
components
• e.g. Fujitsu Siemens PRIMERGY TX300 S2
Server
3.2.3 Power server – Automation Server S7
Scalable controllers
Scalable automation performance to project
needs
• CPU 414 / 414H (1.4 MB RAM)

• CPU 416 (5.6 MB RAM)
• CPU 417 / 417H / 417FH (20 MB RAM)
• Robust (fan-free operation, replaceable

online, designed for demanding industrial
environments)
• Reliable, stable, high availability (even
without redundancy)
Automation Server (CPU 417) for fail-safe and

non-fail-safe applications
Reduced spare part diversity and simple
maintenance
• Redundant master systems S7-400H in

divided sub-rack with redundancy connection

Mar 3, 2009 2.04 Page 12/85
© Siemens AG 2008
3.2.4 Power server – Automation Server CM104
Automation Server CM104

Data exchange between SPPA-T3000 and 3rd
party systems
• Scalable in performance and signal number

(500 to 5000 signals)
• Various physical interfaces (RS232, RS...,
Ethernet...)
• One-channel and redundant connection of
3rd party PLC/PLS to SPPA-T3000
3.2.5 Time server
Time server
Distribution of time information via the network
• Redundant use
• Highest precision using GPS time
3.2.6 Process interfaces
Standard I/Os
• ET200M
• ET200M fail-safe
Special I/Os
• Functional modules FUM
• Front-end modules AddFEM

Mar 3, 2009 2.04 Page 13/85
© Siemens AG 2008
3.2.7 Network components
3.2.7.1 Ethernet components
Application and Automation Highway

Redundant rings with fast 1 failure tolerance
Optical and electric switch modules
• Layer 2 switching
• 10/100 Mbit/s
• Ring topology
• Up to 150 km, 50 OSM per network
• Max. 3000 m between two OSMs
• High availability through fast redundancy
switching (complete transfer in 0.3)
SCALANCE (from release 4)
• Layer 2 (X20x) or Layer 3 switching (X-4xx)

• 10/100 Mbit/s
• Ring topology
• Modular/non-modular
3.2.7.2 Profibus
Process integration withProfibus DP
Flexible and fast fieldbus
Profibus OLM
• redundant design possible

• Transmission rate up to 12 Mbit/s

Mar 3, 2009 2.04 Page 14/85
© Siemens AG 2008
3.2.7.3 Routers and firewalls

These components are differentiated as:
• Router to connect SPPA-T3000 Multi-Unit systems

• Internal firewall
• External firewall
Connections in multi-unit systems

Operation of several units via a single interface
Hischmann Mach 3001
• 10/100 Mbit/s
• Combined routing and wwitching
• Modular design
Internal firewalls to access theT3000 security

cell
The gate keepers to the world of SPPA-T3000
Hirschmann Eagle
• Compact LAN to LAN firewall
• Stateful inspection firewall
• Packet filtering
• Multipoint VPN
• Virus protection
Cisco Router Series 2800

• Multiple port router with firewall
• Connection of third party networks, e.g. office
LAN
• Multipoint VPN

Mar 3, 2009 2.04 Page 15/85
© Siemens AG 2008
External firewall
Customer access gateway
Fast and safe service access
Cisco Router Series 1800 und 800

• Multipoint VPN
Connection via or
• ISDN
• Analog
• DSL
• LAN
3.3 Networks (Application Highway, Automation Highway, Backbone Highway,

DMZ)
The networks for T3000 are based on Ethernet standards and are used to connect the various SPPA-
T3000 system components. They are divided into:
• Application Highway
• Automation Highway
• Backbones (application and automation backbone)
• DMZ network
The standard topology of SPPA-T3000 consists of separate application and Automation Highways, a
DMZ network for remote access and an optional backbone for multi-unit systems. In small SPPA-T3000
systems the application and Automation Highway can be combined into a network.
3.3.1 Standard network topology for application and Automation Highways

The network of the Application Highway and the Automation Highway is designed as 1-fault tolerant ring.
For the ring installation the proven 2 layer switch modules from the industrial Ethernet product range of
the Siemens division A&D are used.
The switch modules were developed specifically for industrial use and have the corresponding
characteristics for flexible network structures, high data throughput and availability.
The ring offers a 1 failure tolerance, i.e. if a network component in the ring fails or the ring cabling is
interrupted, all connected system components remain accessible. (Exceptions are single systems e.g.
Thin Clients, printers or gateways in case of a network component failure.)

Mar 3, 2009 2.04 Page 16/85
© Siemens AG 2008
R edundan cy -
m anager
Figure 1: Ring structure
3.3.1.1 Redundancy manager (RM)

Networks on Ethernet basis usually have a bus, tree or star topology.
For the current ring structure a redundancy manager is required. The redundancy manager is a specially
configured switch module which converts the physically closed ring structure into a virtual bus structure
and monitors the ring for interruptions. For this purpose port 8 of the RM is deactivated, for sending and
receiving user data. In the RM the ring structure is "open".
For every separate ring a separate RM is mandatory.
The ring is monitored via ring test telegrams which are sent by the redundancy manager into the ring in
both directions, including port 8.
Test
Telegrams
Test
Telegrams
R edundan cy -
m anager
Figure 2: Test telegram flow in the ring

Mar 3, 2009 2.04 Page 17/85
© Siemens AG 2008
An interruption in the ring exists if at least one of the two ring test telegram currents is interrupted. The
RM then re-activates its port 8 for user data and the 2 bus segments resulting from the interruptions are
reconnected. A ring interruption is rectified for <= 50 switch modules in the ring within 0.3 sec in the
manner described above.
Interruption
Test
Activating
Telegrams
Port 8
Test
Telegrams
R edundan cy -
m anager
Figure 3: RM activation
The ring test telegram currents remain interrupted until the ring structure has been restored. When both
ring test telegram currents are received the RM re-"opens" the closed ring structure and the standard
topology is restored.
3.3.1.2 Observer (for OSM/ESM)

The redundancy manager is a vital ring component. A RM malfunction, e.g. activating port 8 without
interruption in the ring structure, would result in a significant increase in the bus load in the ring. The
performance of the affected network would be reduced considerably.
For this reason a monitoring function for the redundancy manager is provided: the observer.
The observer monitors the function of the RM and can open the ring on its behalf during a malfunction
causing the improper closing of the ring.

Mar 3, 2009 2.04 Page 18/85
© Siemens AG 2008
3.3.2 Application Highway

The Application Highway connects the components of the display level. It enables the communication
between the Thin Clients, network printers, Application Servers, backbone (for multi-unit) and internal
firewall.
The Application Highway is designed as a 1-fault tolerant ring.
All operationally relevant components are designed redundant in their communication interfaces and
CPUs or exist in multiples. Connection to the Application Highway is made in such a way, that no
component of a system redundancy may be connected to the same network component. This ensures
that the communication can continue via the remaining connection even when a network component fails.
Multiple non-redundant systems (e.g. Thin Clients) are distributed over different network components for
connection purposes. Non-redundant systems which exist only once (e.g. internal firewall) can be
plugged over onto a different network component should a component fail.
Systems at the Application Highway
System Redundant Notes

design
Application Server yes
Thin Clients no multiple existence
Printer no multiple existence
internal firewall no
Connection to the backbone yes optional for multi-unit
router
Inside
Firew all
L
G
A
E
x
1 2
P LT
U
A
F
A
/D
LS U
A
T
S
IP ADDRESS
1 2 V
.24
R
MAC-Adresse
k
1
Thin C lient 1 Thin C lient 2 .......Thin C lient 20 H orn
Aufkleber
0 VF A U L T
g
2
+ 2 4 V
+24V*
0 V
.24
V
N etw ork Printer 1 to n

Alarm Printer
switch switch switch switch

RM
Application H ighw ay
switch switch
Application
Application
Server 2
Server 1
C onnection 1 to (optional ) C onnection 2 to
Application Backbone Application Backbone
(optional ) (optional )
Figure 4: System connection to the Application Highway

Mar 3, 2009 2.04 Page 19/85
© Siemens AG 2008
3.3.3 Automation Highway

The Automation Highway connects the components of the processing level. It enables the communication
between Automation Servers, Application Servers, time servers and backbone (for multi-unit).
The Automation Highway is designed as a 1-fault tolerant ring.
All operationally relevant components are designed redundant in their communication interfaces and
CPUs. Connection to the Automation Highway is made in such a way that no component of a system
redundancy may be connected to the same network component. This ensures that the communication
can continue via the remaining connection even when a network component fails. Multiple non-redundant
systems (e.g. 2 time servers) are connected as the redundant systems to different network components.
Non-redundant systems which exist only once (e.g. CM104) can be plugged over onto a different network
component should a component fail.
Systems at the Automation Highway
System Redundant Notes

design
Application Server yes
Automation Server S7 yes
Automation Server CM104 yes/no
Time server no exists twice
Connection to the backbone yes optional for multi-unit
router
C onnection 1 to C onnection 2 to
Automation Backbone Automation Backbone
(optional ) (optional )
Application Application
Server 1 Server 2
(optional )
*)
*)
switch switch
switch switch switch

Time Time
Automation H ighw ay Server 2
Server 1
(R edundant R ing
C M 104 C M 104
Automat ion Automat ion Automat ion
Server C M Server S 7 Server S 7
Figure 5: System connection to the Automation Highway

* For multi-unit systems with backbone the time servers are connected to the automation backbone

Mar 3, 2009 2.04 Page 20/85
© Siemens AG 2008
3.3.4 Backbone highways

In multi-unit systems the multi-unit design of SPPA-T3000 allows for the operation of multiple units via the
same interface. Joint system screens, message overviews and homogeneous engineering via the
workbench can be implemented for up to 10 units.
This requires a connection of the individual system networks via 2 backbone highways.
• Application backbone
• Automation backbone
The backbone highways consist of a virtually divided redundant router to which the individual system
networks are connected also with redundancy.
L
G
A
E
x
1 2
P LT
U
A
F
A
/D
LS U
A
T
S
ADDRESS
1 2 V
.24
R
Inside
MAC-Adresse
k
IP
1
Firew all
2
Aufkleber
0 VF A U L T
g
2
+ 2 4 V
+24V*
0 V
.24
V
*
*
* switch switch switch
**
**
Router
**
Router
Unit 1 Unit 2 Unit 10
* switch
* switch switch

**
**
**
Redundant Router
Connection
Tim e Tim e
Server Server
Figure 6: Basic structure of the backbone highway
* Master connection
** Standby connection

Mar 3, 2009 2.04 Page 21/85
© Siemens AG 2008
Inside
H irschmann R outer 1
Firew all
L
G
A
E
x
E
T
U
O
-R
M P
8
T
S
A
-F
M P
8
T
S
A
-F
M P
8
T
S
A
-F
M
1 2
P F
LT
U
A
U
A
T
S
ADDRESS
A
/D
LS
1 3 5 7 1 3 5 7 1 2 V
.24
1 3 5 7 R
A
/D
S
L A
/D
S
L
A
/D
S
L
7 8 7 8 7 8
k
IP
MAC-Adresse
5 6 5 6
5 6 1
3 4 3 4 3 4
1 2 1 2 1 2
2
0 VF A U L T
2 4 6 8 2 4 6 8 2 4 6 8 g
Aufkleber
2
+ 2 4 V
+24V*
.24
V
U nit 1 U nit 2
R e du n da n t Ro u ter C o u pl in g
Application H ighw ay Application H ighw ay
Automation H ighw ay
Automation H ighw ay
E
T
U
O
-R
M P
8
T
S
A
-F
M P
8
T
S
A
-F
M P
8
T
S
A
-F
M
1 3 5 7 1 3 5 7 1 3 5 7
A
/D
S
L A
/D
S
L A
/D
S
L
7 8 7 8 7 8
5 6 5 6 5 6
3 4 3 4 3 4
1 2 1 2 1 2
2 4 6 8 2 4 6 8 2 4 6 8
H irschmann R outer 2
Figure 7: Cabling of e.g. 2 units
3.3.5 The DMZ network
The DMZ network is a network segment which must be used for external access to the SPPA T3000
system. External access, e.g. remote service or the connection to an office network, are protected by a 1
or 2 stage firewall (inside and outside firewall) and, if necessary, decoupled via proxy systems.
When using proxies there is no direct access to the SPPA-T3000 system.
The following might be present in the DMZ network:

• Terminal server; access for remote service and/or office user to SPPA-T3000
Future additions to the system will include e.g.

• OPC server/client; connection/disconnection of process data
• WIN TS; turbine diagnosis
• .......

Mar 3, 2009 2.04 Page 22/85
© Siemens AG 2008
3.3.5.1 DMZ sample variants in detail
Only remote service access via Customer Access Gateway (CAG) via Terminal Server
SPPA-T3000
DMZ-Net CAG mit
Control System
Firewall Firewall
inside outside
WAN
Application
Server
Terminal Server
Automation-
Server
Figure 8: DMZ-Net with remote service access via TS
SPPA-T3000 DMZ-Net
Control System CAG mit
Firewall Firewall
inside outside
WAN
Application
Server Terminal Server
OPC Server/Client
(optional)
WIN TS
Automation- (optional)
Server
Figure 9: DMZ-Net with remote service access and optinonal systems

Mar 3, 2009 2.04 Page 23/85
© Siemens AG 2008
Client Intranet
SPPA-T3000 DMZ-Net
Control System Firewall CAG mit
inside Firewall
outside
WAN
Application
Server
Terminal Server
OPC Server/Client
(optional)
WIN TS
Server
Figure 10: DMZ-Net with remote service access, intranet and optional systems
The following firewall HW is used:
Customer Access Gateway (Outside Firewall)

• Cisco 1800 Series
Inside Firewall
• Hirschmann Eagle mGuard

Mar 3, 2009 2.04 Page 24/85
© Siemens AG 2008
3.4 Variants (small, standard, multi-unit configuration)
Due to the universal scalability of SPPA-T3000 the system can be used for diverse system sizes.
From the "small" HKW via the "standard" GuD system to the multi-unit large power station.
SPPA-T3000 - one System fits all!
3.4.1 Small system

Application and Automation Highway
An SPPA-T3000 small system typically includes

• up to 5 Thin Clients
• 1 Application Server
• 2 parallel message printers
• a number of network printers in accordance with theSIMATIC network limit
• up to 3 Automation Servers
• up to 2500 3rd party I/Os (OPC or M/90) *
• *or up to 2 Automation Servers and up to 5000 3rd party I/Os
• *or 1 Automation Server and up to 7500 3rd party I/Os
• up to 15% network load
With this system size the network is designed as a combined application/Automation Highway. A 1-fault
tolerant ring is implemented which can be adapted ideally to the system size of the SPPA-T3000. This
allows for the hardware costs of the network to be kept to a minimum.
Thin C lient 1 Thin C lient 5

H orn
M/90
Alarm Printer inside
Firew all
Printer n
L
G
A
E
x
Printer 1
P 1 2 LT
U
FA
ADDRESS
U
TA
S
A
/D
LS
1 2 V
.24
R
MAC-Adresse
k
IP
1
switch switch
2
Aufkleber
0 FV A U L T
g
2
+ 2 4 V
+24V*
0 V
.24
V
switch switch
Application Automa tion Automat ion Time

Server Server 1 Server 3 Server
Figure 11: Typical SPPA-T3000 small system
However, the disadvantages of this structure should also be mentioned

• A conversion of the joint network structure into a separate one requires at least a partial switching
off of systems and thus a temporary removal of redundancy.
• The load at the joint network can temporarily be higher than that of a separate network and
thereby cause an increase in response times
3.4.2 Standard system

Separate application and Automation Highway
A SPPA-T3000 standard system typically includes

• up to 20 Thin Clients

Mar 3, 2009 2.04 Page 25/85
© Siemens AG 2008
• up to 2 Application Servers
• up to 2 parallel message printers
• up to 25 Automation Servers
• up to 10,000 3rd party I/Os (OPC or M/90) *
• *or up to 20 Automation Servers and up to 22,5000 3rd party I/Os
The SPPA-T3000 standard system has one separate application and Automation Highway each. These
are each designed as 1-fault tolerant ring.
Thin C lient 1 Thin C lient 20 H orn
N etw ork Printer 1 N etw ork Printer n

M /90 Alarm Printer
inside
Firew all
switch switch x
1 2
L
G
A
E
P S
LT
U
A
F
ADDRESS
A
/D
LS
1 2 V
.24
R
MAC-Adresse
k
IP
1
Application
2
Application
0 VF A U L T
Aufkleber
g
2
+ 2 4 V
+24V*
Server 1 Server 2
.24
V
Time
Server
switch switch
Modbus
C M 104
C S275 Automat ion Automat ion
C M104 Server 1 Server 25
Figure 12: Typical SPPA-T3000 standard system

Mar 3, 2009 2.04 Page 26/85
© Siemens AG 2008
3.4.3 Multi-unit system
An SPPA-T3000 standard system typically includes

• up to 10 units, with a unit representing a SPPA-T3000 standard system without the 2 time servers
• up to 200 Thin Clients, up to 20 per unit
• up to 20 Application Servers, up to 2 per block
• up to 2 parallel message printers
• up to 250 Automation Servers, up to 25 per unit
• up to 10,000 3rd party I/Os (OPC or M/90)
Several SPPA-T3000 standard systems with separate application and Automation Highways connected
via an additional backbone network. The system networks are always connected redundantly to both
backbone routers. This ensures the accessibility of the system networks even where one (1) hardware
fault is present.
Inside
L
G
A
E
x
1 2
P S
LT
U
A
F
ADDRESS
A
/D
LS
Firewall
1 2 V
.24
R
MAC-Adresse
k
IP
1
Backbone 2
0 VF A U L T
Aufkleber
g
2
Router 1
+ 2 4 V
+24V*
0 V
.24
V
Time E
T
U
O
-R
M
A
/D
S
L
P
8
T
S
A
-F
M
1 3 5 7
A
/D
S
L
P
8
T
S
A
-F
M
1 3 5 7
A
/D
S
L
P
8
T
S
A
-F
M
1 3 5 7
Server
7 8 7 8 7 8
5 6 5 6
5 6
3 4 3 4 3 4
1 2 1 2
1 2
2 4 6 8 2 4 6 8
2 4 6 8
Thin Thin Thin

Clients Clients Clients
switch switch switch switch switch

switch
Application Highway 1 Application Highway 2 Application Highway 3
switch switch switch switch switch switch
Application Application Application

Server Server Server
Automation Highway 1 Automation Highway 2 Automation Highway 3
Automation Automation Automation

Server Server Server
P
8
T
S
A
-F
M P
8
T
S
A
-F
M
Time
E
T
U
O
-R
M P
8
T
S
A
-F
M
1 3 5 7 1 3 5 7
1 3 5 7 A
/D
S
L A
/D
S
L
A
/D
S
L 7 8 7 8
7 8
Server
5 6 5 6 5 6
3 4 3 4
3 4
1 2 1 2 1 2
Redundant Router Connection

2 4 6 8 2 4 6 8 2 4 6 8
Backbone
Router 2
Figure 13: 3 units connected via backbones

Mar 3, 2009 2.04 Page 27/85
© Siemens AG 2008
3.5 Software
During the development of SPPA-T3000 the following user requirements were considered from the
outset:
• Ease of use
• Flexibility in application
• Reliability during operation
• Scalability
• Openness
• Security
3.5.1 Software architecture
The SPPA-T3000 software architecture is based on software components The functional modules for
automation are represented by individual components providing standardized interfaces. These
components not only represent the standard AS (automation system) functions but also functionalities for
control/monitoring alarms, engineering and diagnosis. The traditional division into AS, HMI, ES and DS
thus becomes obsolete.
HMI, engineering, diagnosis etc. are merely different views of the system.
3.5.1.1 Software component categories

SPPA-T3000 implements different software component categories.
Project Container
Central data manager for engineering and
process data
Saves and organizes

• Project structure
• Hardware topology
• System screens
• Engineering views
• Complete documentation
Manages and guarantees

• Storage
• ECS (Embedded Component Services)
types and instances
• Change management

Mar 3, 2009 2.04 Page 28/85
© Siemens AG 2008
Runtime container
Management and execution
• Automation functions including

processing functions
• Hardware proxies
• Management proxies
• Connections between the two
• Scheduling
• Deterministic cycle time
• Execution management
Process automation functions run on

Automation Servers (CPU), the non-real-time
information functions are realized on
Application Servers
Automation functions
Components with standardized interfaces
Offers the following main functions

• Automating tasks e.g. drives, controls,
adjustments, calculations and processing
functions
• User interface
• Message management
• Diagnosis interface
• Engineering interface
• Execution management
Connection to other automation functions via

LT input and output (LT IN/OUT)
Hardware proxy
Represents an I/O module
• Ensures the integration of the raw input

data to/from the LT interface (LT IN/OUT)
• Monitors field devices
• Collects diagnosis information about field
devices
• Integration and data conversion between

raw data and LT interface configurable
by the user
• Implements communication protocol with
a field device
Management proxy
Coordination of all software components and
services
Provides the following main functions

• SPPA-T3000 system services
• Operating System

Mar 3, 2009 2.04 Page 29/85
© Siemens AG 2008
• Server components
• Network communication
• Field device communication
Connects to other automation functions or

proxies via I&C input and output

Mar 3, 2009 2.04 Page 30/85
© Siemens AG 2008
3.6 Crossover to the "outside world"
As already described in the previous chapters the SPPA-T3000 system includes 3 functional levels:
• Presentation Tier
• Processing Tier
• Data Tier
Combined the systems of these levels form the control system.
Access by external systems to the control system is subject to strict rules which are described in more
detail in the following chapters.
"External" or "outside world" includes all systems which are not part of the control system but are to have
access to it. Access by these systems can be via:
• DMZ network (optional)

• Client intranet
• Internet
• Dial-in
Client Intranet
SPPA-T3000
Control System
Firewall
Dial-in
or
Internet
Application
Server
Terminal Server
(optional)
OPC Server/Client
(optional)
Automation- WIN TS
Server (optional)
Figure 14: Crossover to "external"
Access to the security cell "Control system" from outside always takes place via at least one firewall
system. If a DMZ network is present the crossover to the outside is implemented via additional firewalls
and router/firewall combinations.

Mar 3, 2009 2.04 Page 31/85
© Siemens AG 2008
Client Intranet
SPPA-T3000 DMZ-Net
Control System
Firewall Firewall
inside outside
Dial-in
or
Internet
Application
Server
Terminal Server
OPC Server/Client
(optional)
WIN TS
Server
Figure 15: Crossover to "external" with DMZ network
The framework conditions necessary for the DMZ network could be: e.g.
• Project requirements
• Client security policy

Mar 3, 2009 2.04 Page 32/85
© Siemens AG 2008
4 Coarse/overriding security concept

The SPPA-T3000 security concept includes the following sub-areas
• Security cells and access points
• Secured network access to the security cells
• Network management
• Computer, user and access right management
• Time synchronization
4.1 Security cells

A basic idea of the SPPA-T3000 security concept is based on security cells with different security levels.
The cells can be structured hierarchically and the security levels can be reduced from the inside to the
outside from "secure" to "not secure".
Rules for the division into security cells

• Partial systems which can be operated for some time without being connected to the remainder
of the system
• Direct connection of all components (e.g. no leased lines)
• Separation in space
• Defined access to or from
• Access only after check, logging and monitoring
• Access only for trusted individuals with appropriate training
The inner cells consist of the application and Automation Servers; the next cell includes the Thin Clients.
Together they then form the security cell of the "Control system".
All other cells outside the control systems are considered as less secure.
External Thin
C lient
D MZ N et Intranet
C ontrol System
Application
Internet
Automation
Field
Figure 16: Security cells

Mar 3, 2009 2.04 Page 33/85
© Siemens AG 2008
The optional security cell DMZ Net is switched between the security cell Control system and the non-
secure cell intranet/Internet. All access to the security cell Control system is then directed via the security
cell DMZ Net. The DMZ Net contains systems which communicate externally and internally.
4.2 Communication rule: Everything is prohibited unless explicitly permitted
For access to the security cells Control system and optional DMZ Net a restrictive basic approach is
used:
Everything is prohibited unless explicitly permitted!
In the firewalls of the optional DMZ Net and the Control system the source and target address and the
communication port used are checked. In future, application level firewalls may also be used.
4.3 "Reinforcing" the Thin Clients of the Control systems

The Thin Clients in the security cell "Control system" provide the operator workstations. This "physical
contact" between man and system implies an increased security risk. For this reason the Thin Clients are
specifically configured and locked for functions which are not required for normal control operation. This
ensures that the Thin Client is not modified in a way which could affect the Thin Client itself or other
systems in the Control system.
Only "reinforced" Thin Clients may be used in the security cell "Control system".
A Thin Client is "reinforced" for operation in the security cell "Control system" on 3 levels:
Hardware
• Disabling integrated drives and interfaces
• Locked installation location of the Thin Client hardware. Only monitor, keyboard and mouse are
accessible to the operator.
Firmware
• Setup of a BIOS password
Software
Strict limitation of the Thin Client functionality ("locking") for the user "operator" e.g.
• Automatic start of the web browser with login screen for the control technology application.
• No starting of other websites.
• No installation of additional software possible
• No starting of other applications
• No login possible under different user names
• No autostart of any drives present (e.g. CD ROM).
• No access to external drives and USB memories
• No icons, no start button, no task manager, no explorer
Note: The above limitations do not apply to the user "administrator".
4.4 Thin Clients outside the security cell "Control system"

Thin Clients outside the security cell "Control system", e.g. in the client intranet, pose a security risk. In
addition to the access restrictions to the security cell "Control systems" external Thin Clients must meet
the minimum requirements below;
• Recognized anti-virus program with current signatures installed
• All relevant security updates of the manufacturers have been installed
• Only trusted standard software has been installed on this Thin Client

Mar 3, 2009 2.04 Page 34/85
© Siemens AG 2008
4.5 Security logs
Security relevant events are monitored and subsequently logged in the security log by SPPA-T3000.
Examples are:
• Packets dropped at the firewall
• User logon and logoff (Operating system as well as application)
• Password change requests
• Etc.
For each day a security report is generated which is stored in the subdirectory “Security Logs”. The
directory is configured as a cyclic buffer which stores the reports for up to a period of 90 days. Afterwards
the oldest report is replaced by the newest report. The size of the cyclic buffer (default value 90 days) is
configurable; however the reconfiguration requires a restart of the SPPA-T3000 archive.

Mar 3, 2009 2.04 Page 35/85
© Siemens AG 2008
5 The Malware Prevention System
5.1 Introduction
In order to protect computers of SPPA-T3000 from malware, Malware Prevention System is deployed in
SPPA-T3000 system.
Malware Prevention System consists of Malware Prevention Tool (i.e. antivirus software) and a set of
ancillary components. Key features of Malware Prevention System are to:^
• Protect computers from malware.

• Automatically or manually update Malware Prevention Tool.
• Report incidents to SPPA-T3000 control system.
Trend Micro OfficeScan 8.0 will be used as malware prevention tool. OfficeScan 8.0 is responsible for
protecting all Windows based computers in SPPA-T3000.
Office Scan is a client-server application and following are the components of OfficeScan system:
• OfficeScan Server: Hosts web console and also responsible for updating OfficeScan client
software on all client computers that it manages.
• OfficeScan Client: Software component that protects all the computers with Windows
NT/2000/XP/Server 2003 from malware programs.
• OfficeScan Admin console is a Web based user interface to manage OfficeScan server and
clients.
Admin console
OfficeScan
server Manage the OfficeScan
server and clients through
Admin console
OfficeScan Clients
Figure 17: Architecture of OfficeScan
The ancillary components of Malware Prevention System:

1. Fetch and install updates on OfficeScan Server
2. Monitor OfficeScan clients
5.2 Process-flow of update mechanism
OfficeScan client must be updated regularly for the scanner to detect latest malware.
Customer can obtain updates from either Siemens Remote Servers via common remote service platform
(cRSP) or by other means such as email or CD.
The update process is a multi-step procedure. In case updates need to be fetched from Siemens servers,
the following actions are performed:
1. Fetch updates from Siemens remote server and store them on Terminal Server

Mar 3, 2009 2.04 Page 36/85
© Siemens AG 2008
2. Transfer these updates to OfficeScan Server

3. Install these updates on the OfficeScan server
4. Deploy the updates on clients
Updates obtained by email or CD can be imported into Malware Prevention System either on Terminal
Server or OfficeScan server. In this case, step 1 above is not required. If updates are deployed directly on
OfficeScan server, then step 2 above is also not required.
Figure 18: Deploying updates in High Security solution
Figure 19: Deploying updates in Low Cost solution

Mar 3, 2009 2.04 Page 37/85
© Siemens AG 2008
5.2.1 Fetching updates from Siemens servers
Latest updates will be available on Siemens Remote Access servers. In order to download updates, the
update component of Malware Prevention System (MPS) will initiate FTP session. That is, update
component is FTP client and Siemens remote service provides an FTP Server. All communication
happens in a IPSec tunnel. The tunnel is set up between the customer’s perimeter router (Customer
Access Gateway) and cRSP’s router. The component’s name is getupdcrsp.cmd. getupdcrsp.cmd will
download updates only if newer versions (as compared to the previously downloaded versions) are
available on FTP server.
Configuration
• FTP client is authenticated by a username and password.
• FTP client will connect to cRSP’s FTP server using IP Address and not domain name.
• A dedicated Windows user account is used to run the application that fetches the updates.
Figure 20: Fetching updates from Siemens servers
5.2.2 Transferring updates to OfficeScan server
getupdsftp.cmd residing on OfficeScan server is responsible for transferring updates from Terminal
Server to OfficeScan server. It uses SFTP protocol to connect to Terminal Server and download the
updates to OfficeScan server. As cygwin is installed on all computers, including OfficeScan server and
Terminal server; getupdsftp.cmd makes use of cygwin’s SFTP client to connect to cygwin’s OpenSSH
server on Terminal Server. getupdsftp.cmd will transfer updates to OfficeScan server only if the updates
are newer.
Configuration
• A dedicated Windows user account on OfficeScan server for running getupdsftp.cmd.
• A cygwin account on Terminal Server for SFTP session
• getupdsftp.cmd uses SSH-v2 RSA based authentication mechanism
• Since getupdsftp.cmd runs unattended, the RSA private must not be protected by password
• SFTP client will connect to SSH server using IP Address

Mar 3, 2009 2.04 Page 38/85
© Siemens AG 2008
5.2.3 Installation of updates on OfficeScan server
Updates need to be installed (or activated) manually using a program called tmactsvr.cmd. In case an
update has a new version of Scan Engine, the computers may require a restart. A restart may be required
after the scan engine is deployed on OfficeScan clients. In case a restart is required, OfficeScan Client
displays a notification that a restart is required.
Configuration
• None
5.2.4 Deploying updates on OfficeScan clients
After updates are installed on OfficeScan server, administrator will need to manually deploy updates on
clients. Administrator will need to login to OfficeScan’s Admin console and initiate updates.
OfficeScan server will then notify OfficeScan clients that they need to update themselves. Then
OfficeScan clients will contact the server and download the updates.
In order to receive notifications from OfficeScan server, OfficeScan Client will be listening on TCP port
number 54000. After being notified, OfficeScan client will use HTTP protocol to download updates. Note
that the local OfficeScan client present on OfficeScan server also uses the same mechanism to download
updates. Figure 21 shows deployment of updates in a High security configuration.
Figure 21: Deployment of updates on clients in High Security solution
5.3 Notification of events
There are two important types of events. These are Threat related events and Monitoring events. These
events are reported to SPPA-T3000 control system. The Threat events are generated when malware is
detected in a computer. Monitoring events are raised when Scan engine is not running or components
are out of date.

Mar 3, 2009 2.04 Page 39/85
© Siemens AG 2008
5.3.1 Notification of threat events
There are two types of Threat events. One is a Threat alert. This is raised when malware is detected. The
other event is an outbreak alert. This raises when five or more malware detections occur in less than one
day.
When malware is detected on a computer. OfficeScan client sends the event to OfficeScan server via
HTTP protocol. OfficeScan server logs this event in Windows event log. This in turn will generate an
SNMP trap. The SNMP trap will be received by SPPA-T3000 control system. Normally, all events are
stored in security log. Additionally, important events will be displayed in Alarm Sequence Display.
5.3.2 Monitoring events
An example of a monitoring event is that a Scan engine is not running. When a Scan engine is not
running, an event is logged in the Windows event log on the computer in which the Scan engine stopped
working. This event will in turn raise an SNMP trap, sent to SPPA-T3000 on the Application Server.
The dataflow of event notification is shown
Figure 22: Raising of MPS related events in ASD (High security solution)

Mar 3, 2009 2.04 Page 40/85
© Siemens AG 2008
5.4 Dependencies
5.4.1 OfficeScan server (first Application Server)
5.4.1.1 Web server
The Web server used is Apache. The version must be Apache 2.0.55 or above.
In addition, the following modules must be enabled in Apache’s conf file:

1. mod_actions.so
2. mod_asis.so
3. mod_auth.so
4. mod_cgi.so
5. mod_env.so
6. mod_include.so
7. mod_isapi.so
5.4.1.2 cygwin
cygwin with core utilities, sed and ssh package must be installed. SSH-v2 must be enabled in the config
files.
5.4.2 Terminal Server
5.4.2.1 cygwin
cygwin with core utilities, cygrunsrv, ssh package (including ssh server) must be installed. SSH-v2 must
be enabled in the config files.

Mar 3, 2009 2.04 Page 41/85
© Siemens AG 2008
5.4.3 Firewall configuration
The firewall ports are specified below.
5.4.3.1 T3000 Firewall
S.No. Service Port Source Destination
1 SSH TCP 22 OfficeScan server Terminal Server
2 HTTP TCP 80 Terminal Server OfficeScan server
3 OfficeScan TCP 54000 OfficeScan server Terminal Server
SPPA-T3000 Trap receiver

4 SNMP Trap UDP 162 Terminal Server component (located on First
Application Server)
5.4.3.2 Customer Access Gateway – high security solution

1 FTP TCP 21 Terminal Server cRSP
5.4.3.3 Customer Access Gateway – Low cost solution (no DMZ)

Mar 3, 2009 2.04 Page 42/85
© Siemens AG 2008
5.4.3.4 Customer Access Gateway – Intermediate solution
SSH
2 TCP 22 OfficeScan server Terminal Server
(SFTP)
3 HTTP TCP 80 Terminal Server OfficeScan server
4 OfficeScan TCP 54000 OfficeScan server Terminal Server

SPPA-T3000 Trap
receiver component
5 SNMP Trap UDP 162 Terminal Server
(located on First
Application Server)

Mar 3, 2009 2.04 Page 43/85
© Siemens AG 2008
6 Account Management
SPPA-T3000 Account management feature imposes various security measures that need to be
implemented on various devices that are used in DCS and DMZ of SPPA-T3000. These security
measures will be imposed on all the devices (where ever feasible) listed below.
• Thin Client (TC)
• Application Server (AS)
• Switches (SW)
• Router
• Printers
• Customer Access Gateway (CAG)
• SPPA-T3000 Firewall
• Timer (Clock)
• Terminal Server (TS)
• SPPA-T3000 Workbench
Following security features are required to implement on all the above mentioned devices (where ever
feasible):
1. Access Control (Deny access on default)
2. Passwords
3. Login Banners
4. Monitoring
5. Automatic Logout
6. Local Access
7. External Login (Login from external network)
Where ever possible, device’s built in capability will be used to implement above mentioned security
features. In case, if a device that does not support or rather can not impose a security feature, then that
device’s administrator is responsible to implement or follow that security feature manually. For example a
router may not impose strong password requirement rule while accepting and assigning a password to a
user account. In such a case administrator of the router should choose a strong password as per
password complexity guide lines given below, while selecting / assigning a password for an account.
6.1 Access control

Accessing a device without user authentication is not allowed. On each device, user accounts will be
created as per the SPPA-T3000 system requirement and user must supply his/her credentials in order to
access the device. All standard accounts will be renamed and all non used standard accounts will be
deleted or disabled. If device does not allow renaming or deleting the account then those accounts will be
kept as it is.
6.1.1 Password
Password of every account should meet following password complexity requirements.
Complexity:
• It should not be same as account name (login ID or login name).

• It should not match with the last used 4 passwords, if any.
• It should be at least 8 characters and preferably less than 20 characters.
• It should contain at least one uppercase character (A to Z).
• It should contain at least one lowercase character (a to z).
• It should contain at least one numeric character (0 to 9).
• It should contain at least one special character (! @ # $ % & ...etc).

Mar 3, 2009 2.04 Page 44/85
© Siemens AG 2008
Life cycle:
• All passwords (excluding exceptional accounts) should be changed once in 90 days or less.
• Device should prompt the user to change his/her account password from 14 days prior to
password expiry.
• Password should not be same as last 4 passwords assigned for that account.
• User can always decline the password change request and access the device with existing
password. However if user declines the password change for 3 consecutive times, then a
message will be logged in device's message logging system and subsequently report to SPPA-
T3000 logging system.
• Password will also have a minimum lifetime and that will be 1 day. User can change the
password as and when required provided the existing password is older than password minimum
lifetime i.e. 1 day.
Implementation:
Where ever possible, device's capability to enforce the password complexity rules will be used. However,
if the device does not have capability to enforcing password complexity rules, then device administrator
will be responsible to follow/adopt password policy manually.
6.2 Login banner
A login banner will be displayed to the user through device login screen. A clear statement that describes
basic rules that a user must follow while using or accessing the device will be described in the login
banner.
6.3 Monitoring
All devices will be configured to log important events. Logged event will be forwarded to SPPA-T3000
logging system. Logged information will be used to conduct audit trails.
• User authentication (success and failure).

• Password change request declined by user.
• Programs started by user (optional).
• Files accessed by user (optional).
6.4 Auto Logoff
Auto logoff feature will be enabled (if device supports) on all the devices. After successful user login, if a
device is left idle (no input via input devices like keyboard, mouse etc) for a certain time period, then
device will automatically logoff the user.
In case of remote desktop session then the idle session will be disconnected but session will be kept
active, so that user can login again and continue with disconnected session.
Terminal server will be configured to keep disconnected session running for 2 days (configurable). That
means user can connect (login with same user account) to his/her disconnected session within 2 days
(after TS disconnected the user session when it reached idle session limit) without loosing any
information. If user did not login within 2 days, TS will logoff the user and terminates the session. In such
a case, it is possible that user might lose unsaved data if any.
6.5 External Login

External login indicates, login to a device from external network i.e. network other than SPPA-T3000
security cell and DMZ. Direct external login is only possible or allowed to Customer Access Gateway

Mar 3, 2009 2.04 Page 45/85
© Siemens AG 2008
(CAG) and Terminal Server in the DMZ. Common Remote Service Platform (cRSP) is the channel that
allows an authorized user from Siemens network to get connected to CAG and TS.
External user can also access the remaining devices present in SPPA-T3000 security cell indirectly,
provided user has the required credentials to access the device. For example after starting RDP session
to TS, from TS, user can further start a RDP session to AS. From AS user can access all other devices
like application backbone router or application highway switch etc.
For external login to TS, power plant shift leader/administrator authorization is required. Every time user
tries to perform an external login to TS, a permission request dialog box will appear on TS console,
external access to the user will be granted if shift leader accepts the request otherwise external access
will be rejected.
Password generator will be integrated with CAG and be used in the power plants that have un-manned
stations. Siemens cRSP can provide such solution based on a special order. However, details on this
solution are currently out of scope to this document.

Mar 3, 2009 2.04 Page 46/85
© Siemens AG 2008
7 Hardening
The default configurations of systems leave a lot of unnecessary services and protocols enabled. Not
only does this increase the attack vector but, also the chances of disruptions due to a failure in these
unnecessary services increases.
The hardening feature disables all unnecessary services and protocols on computers and devices (such
as firewalls and printers) connected to SPPA-T3000 Application Highway. The principle used to decide
whether a service is necessary is based on the security concept 'anything required will be explicitly
requested, all others will be rejected'. These necessary services and protocols are documented in
Supplementary Document "Administrator Manual - Required Services and Protocols".

Mar 3, 2009 2.04 Page 47/85
© Siemens AG 2008
8 Scenarios for remote service access

The following chapters describe various typical connection scenarios with SPPA-T3000.
Remote access is defined as access to SPPA-T3000 from outside of the security cell.
Examples are:
• Remote service access from the common Remote Service Platform of Siemens AG.
• Remote access from Thin Clients located in the client’s intranet.
• Remote access from Thin Clients located in the Internet.
• Remote access from third-party systems via mechanisms provided by OPC.
The remote access scenarios, including the specification of the corresponding firewall rule sets, are
explained in the following.
8.1 Firewall rules

Access to SPPA-T3000’s security cell is either controlled, depending on the acutal network topology, by a
single or a dual firewall.
In the following the rules are defined for each firewall of SPPA-T3000 under consideration of the network
topology.
Abbreviations:
cRSP common Remote Service Platform

Appl. Server SPPA-T3000 Application Server
TS Terminal Server
TC/TS Thin Client/Terminal Server (only for Remote Service)
TC Thin Client
extTC externer Thin Client
WIN_TS Diagnostic System for Turbines
CAG Customer Access Gateway (Remote Access Router)
OPC OLE for Process Control
st
Office Scan Server 1 Application Server, used to update the Office Scan Clients
RSB Remote Service Board (in WIN_TS)
VPN Gateway VPN tunnel endpoint
PI Plant Information System (Universal Platform that Improves
Operations Across any Industry)
CM Communication Module

Mar 3, 2009 2.04 Page 48/85
© Siemens AG 2008
8.1.1 Firewall rules 1; CAG (Customer Access Gateway)
Scenario Figure 25
Scenario Figure 27
Application Protocol Source Direction Destination
Remote
RDP cRSP -> TS x x
Desktop
RDP cRSP -> TC/TS
Secure Shell SSH cRSP <-> TC/TS

SSH cRSP <-> TS x x
Event
Syslog CAG -> TC/TS
Logging
Syslog CAG -> TS x x
Virtual
Network VNC cRSP -> WIN_TS x
Client
HTTP
Web cRSP -> RSB x
HTTPs
File Transfer FTP TS -> cRSP x x

FTP TC/TS -> cRSP
FTP WIN_TS <-> cRSP x

Mar 3, 2009 2.04 Page 49/85
© Siemens AG 2008
8.1.2 Firewall rules 2; SPPA-T3000-Firewall
Scenario Figure 25
Scenario Figure 27
Scenario Figure 28
Scenario Figure 29
Scenario Figure 30
Scenario Figure 31
Scenario Figure 33
Scenario Figure 35
Application Protocol Source Direction Dst.
Remote Appl.
RDP TS -> x x x x
Desktop Server
cRSP -> TC/TS x x
Appl.
Secure Shell SSH TS -> x x x x
Server
cRSP <-> TC/TS x x
Office
Scan -> TS x x
Srv
Secure File Appl.
SFTP -> TS x x x x
Transfer Server
Filer Transfer FTP TC/TS -> cRSP x x
WIN_TS <-> cRSP x
Event T3000 Appl.
Syslog -> x x x x x x
Logging Firewall Server
Workbench Appl.
HTTPS TS -> x x x x x x
via Web Server
Workbench Appl.
RMI reg TS -> x x x x x x
via RMI Server
Appl.
RMI com TS -> x x x x x x
Server
RMI to Appl.
-> TS x x x x x x
WB Server
Diagnostig http Appl.
TS -> x x x x
View 8080 Server
Virtual
Client
HTTP
Web cRSP -> RSB x
HTTPs
Network Appl.
NTP TS -> x x x x
Time Server
Management SNMP Appl.
TS -> x x x x
via SNMP Trap Server
SNMP Appl.
-> TS x x x x
read Server
Office
File Transfer
HTTP TS -> Scan x x x x
via HTTP
Srv
Office
Scan
Office
Office Scan Srv -> TS x x x x
Scan
(1. Appl.
Srv.)
WIN_TS
Tunneler Appl.
OPC WIN_TS <-> x x x
Protocol Server
Tunneler
Simatic Appl.
WRA TS ! x x x x x x
Manager Server

Mar 3, 2009 2.04 Page 50/85
© Siemens AG 2008
8.1.3 Firewall rules 3; SPPA-T3000-Firewall/CAG combined
Scenario Figure 24
Scenario Figure 26
Remote
RDP cRSP -> TS
Desktop
cRSP -> TC/TS x x
Appl.
TS ->
Server
Secure Shell SSH cRSP <-> TC/TS x x
cRSP <-> TS
Event Appl.
Syslog CAG -> x x
Logging Server
WIN_TS
Tunneler Appl.
OPC WIN_TS <-> x
Protocol Server
Tunneler
File Transfer FTP TS -> cRSP
TC/TS -> cRSP x x
WIN_TS <-> cRSP x
Virtual
Client
HTTP
Web cRSP -> RSB x
HTTPs

Mar 3, 2009 2.04 Page 51/85
© Siemens AG 2008
8.1.4 Firewall rules 4; Customer Owned Gateway and client firewall
Scenario Figure 28
Scenario Figure 29
Scenario Figure 30
Scenario Figure 31
Scenario Figure 33
Scenario Figure 35
Remote
RDP ext TC -> TS x x
Desktop
cRSP -> TC/TS x x
cRSP -> TS x x
Secure Shell SSH cRSP <-> TC/TS x x
SSH cRSP <-> TS x x
Event
Syslog CAG -> TC/TS
Logging
Syslog CAG -> TS
Virtual
Network VNC cRSP -> WIN_TS x x
Client
HTTP
Web cRSP -> RSB x x
HTTPs
File Transfer FTP TS -> cRSP x x

FTP TC/TS -> cRSP x x
FTP WIN_TS <-> cRSP x x
8.1.5 IP addresses of the common Remote Service Platform
All over the world three cRSP sites exist:

• Fürth (Europe)
• Newark/CA (USA)
• Singapur (Asia)
Each site has its own cRSP infrastructure and its individual IP addresses. In case of a failure at a cRSP
site the connection is passed to one of the remaining sites. This is the reason why all three cRSP sites
must be considered when configuring a firewall.
cRSP-Site Network Address Access Server*

Fürth 194.138.39.0/27 194.138.39.24
Singapur 194.138.243.160/27 194.138.243.184
Newark (CA) 129.73.116.64/27 129.73.116.83
* The access servers are the only peers of the cRSP which communicate with SPPA-T3000 components.

Mar 3, 2009 2.04 Page 52/85
© Siemens AG 2008
8.1.6 Protocols and port numbers
Application Protocol Destination Port

Remote Desktop Protocol RDP TCP 3389
File Transfer Protocol FTP TCP 20 + 21
File Transfer Protocol Secure SFTP TCP 22
Secure Shell SSH TCP 22
Virtual Network Client VNC TCP 5800
Remote Diagnostic view HTTP TCP 8080
Event Logging SYSLOG UDP 514
Workbench via Web HTTPS TCP 443
Workbench (RMI Registry) RMI TCP 1099
Workbench (RMI Comm.) RMI TCP 50000-50050
Workbench (RMI to Workbench) RMI TCP 50000-50009
Network Time Protocol NTP TCP 123
Simple Network Management Protocol SNMP TRAP UDP 162
Simple Network Management Protocol SNMP READ UDP 161
OfficeScan OfficeScan TCP 54000
OPC Communication via Tunneling Software OPC Tunneler TCP 21379
Simatic Manager WRA TCP 8650 + 8653-8659

Mar 3, 2009 2.04 Page 53/85
© Siemens AG 2008
8.2 General observations on remote service
For external service access via WAN or Internet, the access must always be via a Terminal Server (TS)
using Microsoft Terminal Services (MS-TS).Access cannot gained direct via the Application Server(s).
The Terminal Server is either a Thin Client at the Application Highway or a server in the DMZ. In the case
of a Thin Client as Terminal Server only a remote session is possible; the local session must be logged
out.
If more than one terminal session is to be allowed at the Terminal Server, a standard server HW and
server operating system must be used.
The only exception to this rule are the applications on SSH basis Secure Shell, SFTP and SCP, which for
exclusively service purposes, may also run direct on the Application Server and Thin Clients.
8.2.1 Comparison of external Terminal Servers and combined Thin Clients /

Terminal Servers
Property external Terminal Server combined TC / TS
outside the Security Cell Control

Location inside the Security Cell Control System
System
secure, because it is outside the less secure, because it is inside the
Security
Security Cell Control System Security Cell Control System
Number of sessions several; dependent on computing
1 session, either local or remote
power
Number of
several; dependent on computing
workbenches to be 1
power
connected
8.2.2 File transfer using RDP and SSH
File transfer is an important application between the service center and the Control system. Diagnosis
data, patches, virus pattern updates etc. are frequently transferred in both directions.
Microsoft Terminal Services (MS-TS) is one of the main service applications and also offers a file transfer
option. Resources, e.g. the client drives, are connected to the server. When using the cRSP the MS-TS
client runs on CAT clients in the intranet. When using the drive connection via MS-TS all network drives
and any inserted USB drives at the CAT client would be connected to the server. This situation cannot be
modified administratively and poses a high security risk for the server. For this reason the connection of
drives via MS-TS is prohibited.
As an alternative the file transfer via SSH is used. On Application Servers and Thin Clients an SSH
program will be installed or enabled in future.
SSH File Transfer Protocol (SFTP) permits the secure data transfer and data access on remote
systems.
Secure Copy or SCP ensures the confidentiality, integrity and authenticity of the transferred data. For
this the SSH uses.

Mar 3, 2009 2.04 Page 54/85
© Siemens AG 2008
8.3 Service access to SPPA-T3000
SPPA-T3000 Service centers rely on the remote service for the fast analysis and correction of faults.
Remote Service implies a temporary data connection between the service center and the SPPA-T3000
system. The system can be connected to the service center via dial-up (ISDN or analog) or over the
Internet.
There are 2 cases:
a.) A dedicated service access for SPPA-T3000, Customer Access Gateway (CAG)
b.) A service access provided by the client, Customer Owned Gateway (COG)
In both cases a connection from the Siemens-wide Common Remote Service Platform (cRSP) to the
system is made when required. The cRSP is a centralized infrastructure permitting connections to
systems with Siemens technology globally via 3 access points.
Siemens
Intranet Service
Centre
Siemens Access
cRSP Portal
Access
Server
Data
Service
Dial in
ISDN or POTS
Internet via VPN
Customer
Site
Figure 23: cRSP structure

Mar 3, 2009 2.04 Page 55/85
© Siemens AG 2008
8.3.1 Service access to SPPA-T3000 via Customer Access Gateway (CAG)

A CAG is a router with firewall, security features and at least one WAN and one LAN interface. The WAN
access can be configured for dial-up or Internet connection.
8.3.1.1 Service access via CAG through dial-up connection (ISDN or POTS*) or
Internet
* Plain Old Telephone Service = analog connection
Dial-up connections
• For dial-up connections the service access methods are as follows
• ISDN 64kBit/s
• POTS: typically 33.6kBit/s, often less
In dial-up connections IPSec (IP Security) must be used if there are no significant reasons* against it.
*) e.g. legal reasons, country-specific reasons.
Internet connections
In an Internet connection as service access the bandwidth depends on the selected tariff.
Recommendations for minimum bandwidth:
• 192kBit/s upstream
• 2000kBit/s downstream
The Internet access should preferably be available via a fixed IP address.

In future dynamic IP addresses should also be supported.
A connection between cRSP and the system over the Internet uses public resources; therefore
mechanisms for the security of the transferred data are mandatory:
• A VPN tunnel is only established after successful authentication.
• Authentication is encrypted.
• In the VPN tunnel the data packages are encrypted using 3DES* encryption.
* In export-critical countries also only with DES
Note:
The Siemens remote service access is only intended for the service via cRSP. The specific setup of the
access does not permit any other use.

Mar 3, 2009 2.04 Page 56/85
© Siemens AG 2008
Service access via dial-up or Internet connection through combined CAG/firewall System on
TC/TS
Siemens
SPPA-T3000 cRSP Access
Control System Server
TC/TS
CAG/Firewall
Data
VPN Tunnel Service
Internet or
Dial up lines
via VPN
Application
Server
Automation-
Server
Figure 24: Service access via dial-up or Internet connection on Thin Client/Terminal Server
The firewall rules for CAG/firewall are defined in Chapter 8.1.3.

Mar 3, 2009 2.04 Page 57/85
© Siemens AG 2008
Service access via dial-up or Internet connection on Terminal Server in the DMZ
Siemens
cRSP Access
SPPA -T 3000 Server
DMZ -Net
Control System
CAG with
Firewall inside Firewall outside
Data
VPN Tunnel Service
Internet or
Dial up lines
via VPN
Application
Server
Terminal Server
Automation -
Server
Figure 25: Service access via dial-up or Internet connection on Terminal Server in the DMZ
The firewall rules for the CAG are defined in Chapter 8.1.1.
The firewall rules for the “inside firewall” are defined in Chapter 8.1.2.

Mar 3, 2009 2.04 Page 58/85
© Siemens AG 2008
Service access via dial-up or Internet connection through combined CAG/Firewall system on Thin
Client/Terminal Server and WIN TS
Siemens
cRSP Access
SPPA-T3000 Server
Control System
TC/TS
CAG/Firewall
VPN Tunnel Data

Service
Internet or
Dial up lines
via VPN
Application
Server
WIN TS
(optional)
Automation-
Server
Figure 26: Service access via dial-up or Internet connection on Thin Client/Terminal Server and WIN TS
The firewall rules for the CAG/T3000 firewall are defined in Chapter 8.1.3.

Mar 3, 2009 2.04 Page 59/85
© Siemens AG 2008
Service access via dial-up or Internet connection through CAG, Terminal Server and WIN TS in the
DMZ
Siemens
cRSP Access
SPPA -T 3000 Server
DMZ -Net CAG /
Control System
T3000 Outside
Firewall Firewall
VPN Tunnel Data

Service
Internet or
Dial up lines
via VPN
Application
Server
Terminal Server
WIN TS
Automation - (optional )
Server
Figure 27: Service access via dial-up or Internet connection, TS and WIN TS in the DMZ
The firewall rules for the CAG are defined in Chapter 8.1.1.
The firewall rules for the T3000 are defined in Chapter 8.1.2.

Mar 3, 2009 2.04 Page 60/85
© Siemens AG 2008
8.3.2 Service access via Customer Owned Gateway (COG)
If the client provides a service access this is a Customer Owned Gateway (COG).
Where a COG exists, the connection is not made direct from the cRSP to the CAG and the DMZ of the
SPPA-T3000 system but to the client gateway. After authentication the data is transferred from the cRSP
over the client network to the gateway at the DMZ.
With regard to the communication relationships there is little change compared to access through a CAG.
The client must at his access gateway and in his network enable the protocols required by the service.
8.3.2.1 Service access through COG via dial-up connection (ISDN)

For a COG with ISDN Dial-in the security policy of the client usually determines whether IPSec encryption
is to be applied to the dial-up connection or not. As far as the standard for SPPA-T3000 is concerned,
IPSec (IP Security) must be used unless there are significant reasons* against it.
*) e.g. legal reasons, country-specific reasons.
However, technical reasons at the COG may also prevent the use of IPSec. In this case the use of
alternatives must be checked.
For external access via WAN or Internet the access may not be direct to the Application Server(s) but
must always be via a Terminal Server (TS) using Microsoft Terminal Services (MS-TS). See chapter 4.1
Optional additional systems, e.g. WIN-TS are also connected at least via the T3000 firewall or are within
the optional DMZ. This means they can also be accessed externally through the COG.
8.3.2.2 Service access through COG via Internet VPN connection

If the client provides an Internet access as service access point, establishing a VPN tunnel is mandatory.
A connection between cRSP and the system over the Internet uses public resources; therefore
mechanisms for the security of the transferred data are mandatory:
* In export critical countries potentially with DES
For the external access via Internet the same conditions as for dial-up connections apply.

Mar 3, 2009 2.04 Page 61/85
© Siemens AG 2008
Service access through COG, TS in the DMZ

(Only permitted with RDP encryption)
Siemens
Internet cRSP Access
Client VPN Server
Intranet
COG
Data
Service
Dial up lines
IPSec encryption ISDN , POTS
Client
Firewall
SPPA -T 3000
Control System DMZ -Net
Firewall inside
Application
Server
Terminal Server
Automation -
Server
Figure 28: Service access through COG and client intranet on TS in the DMZ
Note:
This variant is only permitted with RDP encryption. Encryption must be enabled at the Terminal Server.
The firewall rules for the COG are defined in Chapter 8.1.4.
The firewall rules for the T3000 firewall are defined in Chapter 8.1.2.

Mar 3, 2009 2.04 Page 62/85
© Siemens AG 2008
Service access through COG, Thin Client as Terminal Server
Siemens
cRSP Access
Client Server
Intranet
COG
VPN Tunnel Data
Service
Internet or
Dial up lines
Client Firewall via VPN
SPPA -T 3000
Control System
TC/TS
Firewall
Application
Server
Automation -
Server
Figure 29: Service access via dial-up or Internet connection on Thin Client/Terminal Server
The firewall rules for the COG and the Client firewall are defined in Chapter 8.1.4.

Mar 3, 2009 2.04 Page 63/85
© Siemens AG 2008
Service access through COG, Thin Client as Terminal Server and optional WIN TS
Siemens
cRSP Access
Client Server
Intranet
COG
VPN Tunnel Data
Service
Internet or
Dial up lines
Client Firewall via VPN
SPPA -T 3000
Control System
TC/ TS
Application
Server
WIN TS
(optional)
Automation -
Server
Figure 30: Service Access via dial-up or Internet connection on TC/TS and optional WIN TS
The firewall rules for the COG and Client Firewall are defined in Chapter 8.1.4.

Mar 3, 2009 2.04 Page 64/85
© Siemens AG 2008
Service access through COG, Terminal Server and optional WIN TS in the DMZ
Siemens
cRSP Access
Server
Client
Intranet
COG Data
VPN Tunnel Service
Internet or
Dial up lines
via VPN
Client
Firewall
SPPA -T 3000
Control System
Router with
Firewall inside
DMZ-Net
Application
Server
Terminal Server
WIN TS
(optional)
Automation -
Server
Figure 31: Service access via dial-up or Internet connection on TS and optional WIN TS in the DMZ
The firewall rules for the COG and the Client firewall are defined in Chapter 8.1.4.

Mar 3, 2009 2.04 Page 65/85
© Siemens AG 2008
8.4 Connection of SPPA-T3000 to an intranet

The connection to an existing client intranet must always be via the inside firewall. In this case it is
designed as a router/firewall. On the inside firewall the rules for limiting the data traffic from the client
intranet are parameterized. Access from the client intranet direct e.g. by Thin Clients (TC), by Remote
Service through COG or a combination of both is possible. Besides the firewall function the router also
enables the resolution of address conflicts between the client intranet and SPPA-T3000 through NAT
(Net Address Translation).
Client
Intranet
COG
Client
Firewall
SPPA-T3000
Control System
Router with
Firewall inside
DMZ-Net
Application
Server
Terminal Server
WIN TS
Server
Figure 32: Connection of SPPA-T3000 to a client intranet
The details for remote access through COG and client intranet have already been covered in previous
chapters (see chapter 4.1). The following describes in detail additional rules for access of Thin Clients
from within the client intranet.

Mar 3, 2009 2.04 Page 66/85
© Siemens AG 2008
8.4.1 Thin Client in the intranet with access to SPPA-T3000

The client intranet is considered an "untrusted area". Access by Thin Clients from within the client intranet
must therefore be secured separately.
A Thin Client can have access to the SPPA-T3000 Application Server via a Terminal Server in the DMZ.
Figure 33: Connection of a Thin Client in the intranet to SPPA-T3000
The firewall rules for the Client firewall are defined in Chapter 8.1.4.

Mar 3, 2009 2.04 Page 67/85
© Siemens AG 2008
Option: Thin Client access via VPN client connection
The Thin Client in the client intranet must first establish a VPN connection (VPN tunnel) to the inside
firewall (router/firewall) in the DMZ. The inside firewall acts as VPN gateway.
The HTTPS and RMI connections are then channeled through this protected tunnel.
The Thin Client in the client intranet must meet the requirements in chapter 3.5.
Conditions for the establishment of a VPN tunnel between TC and inside firewall:
• TC: VPN Client Software (Cisco VPN Client) installed and configured, for
configuring the Cisco VPN Client see "appendix"
• Inside firewall: Configuration as VPN gateway
Figure 34: Connection of a Thin Client in the client intranet to SPPA-T3000 via VPN

Mar 3, 2009 2.04 Page 68/85
© Siemens AG 2008
Communication relationships via the client firewall

Permissions required in the client firewall
Connection Protocol/
Application Source IP Target IP
direction target port
Establishment of
TC-> VPN VPN gateway on ISAKMP
VPN connection, TC IP
Gateway the inside firewall UDP 500
key management
IPSEC NAT TC-> VPN VPN gateway on
TC IP UDP 10000
Transparency Gateway the inside firewall
IPSEC Tunnel TC-> VPN VPN gateway on

TC IP ESP
Encapsulation Gateway the inside firewall
Communication relationships between TC in the client intranet and the VPN gateway in the inside
firewall
Permissions required at the inside firewall, the access to the security cell "Control System"
The communication here is divided into 2 parts:
1. Establishing the tunnel
2. Application communication
Re 1, establishing the tunnel
Establishment of
TC-> VPN VPN gateway on ISAKMP
VPN connection, TC IP
key management
IPSEC NAT TC-> VPN VPN gateway on
TC IP UDP 10000
IPSEC Tunnel TC-> VPN VPN gateway on

TC IP ESP
Re 2, application communication
Workbench VPN-Client IP of HTTPS
TC-> Appl. server Appl.Server IP
HTTPS connection the TC* TCP 443
VPN-Client IP of RMI
RMI reg TC-> Appl. server Appl.Server IP
the TC* TCP 1099
VPN-Client IP of RMI
RMI com. TC-> Appl. server Appl.Server IP
the TC* TCP 50001-50050
RMI
RMI to VPN-Client IP of
Appl. server -> TC Appl.Server IP TCP 50000-50001
Workbench** the TC*
***
* allocated by the VPN gateway
** outgoing connection
*** Expandable up to 50009 if required (e.g. multi-unit)

Mar 3, 2009 2.04 Page 69/85
© Siemens AG 2008
8.5 SPPA-T3000 connection to the Internet
The connection of SPPA-T3000 to the Internet may be required for the following reasons:
• Access for client personnel
• Access for third parties
The use of the Internet by Siemens remote service has already been covered in chapter 4.1. This also
defined that the Internet access via Customer Access Gateway CAG (the Internet is connected direct to
the DMZ Net via CAG) can only be used for service via cRSP.
The information above determines that access by client personnel and third parties to the SPPA-T3000
must be carried out via a separate Internet access.
A connection over the Internet uses public resources; therefore mechanisms for the security of the
transferred data are mandatory:
8.5.1 Thin Client in the Internet
In addition to the Remote Service via the Internet it may be necessary also to connect individual Thin
Clients over the Internet to SPPA-T3000, e.g. client personnel from home.
The client must provide the corresponding access for this purpose. This gateway forms the access point
for individual systems via Internet or dial-in.
The Internet is considered an "untrusted area". Therefore, access by TC from the Internet must be
especially secure. The TC in the Internet must first establish a VPN connection (VPN tunnel) to the client
gateway. Protected by this VPN tunnel a MS-TS connection to the Terminal Server in the DMZ can be
made. No direct access to SPPA-T3000 systems from the Internet is permitted.
The Thin Client in the Internet must meet a minimum of the following requirements:
• Recognized anti-virus program with current signatures installed
• All relevant security updates of the manufacturers have been installed
• Only trusted standard software has been installed on this Thin Client

Mar 3, 2009 2.04 Page 70/85
© Siemens AG 2008
Figure 35: Connection of a Thin Client in the Internet to SPPA-T3000 via VPN and TS
The communication is divided into 2 parts:

1. Establishment of the VPN tunnels as client responsibility
2. Establishment of the MS-TS connection to the Terminal Server in the DMZ Net of SPPA-T3000;
RDP encryption must be enabled at the Terminal Server
The firewall rules for the Client firewall are defined in Chapter 8.1.4.

Mar 3, 2009 2.04 Page 71/85
© Siemens AG 2008
8.6 Wireless access to SPPA-T3000
Wireless communication technologies (WLAN, Bluetooth or infrared) should not be used in the I&C
network and deactivated by system configuration.
If the customer is determined to use WLAN communication despite the serious security concerns, the
following concept is recommended for reasons of security and also to ensure efficient operation:
An I&C-specific WLAN network should not be built up. WLAN communication is performed exclusively via
the general WLAN network operated under the company-wide security policy.
WLAN users identify themselves in the corporate network. When accessing the I&C network, the WLAN
user is therefore subject to the same security regulations as all other users in the corporate network.
This procedure
• allows the use of WLAN access channels (also for the I&C)
• establishes a company-wide, uniform WLAN policy
• avoids the operating and administration effort for separate WLAN networks (office network,
I&C network).
SPPA -T300 0 DMZ-Ne t

C ontro l System
Ro uter w ith
Fi rew all i nsi de Wi rele ss
Acce ss Poi nt
VP
N
Ap pli ca ti on
Ser ve r
Termin al S erver Office environment
A utoma ti on -
Ser ve r
Cor por ate LAN
Wi rel ess
Acc ess Po int
Plant floor
SPPA T3000 : WLAN access
Figure 36: Connection of Thin Clients via WLAN
If there is no WLAN network throughout the site, or a network of this type is not possible for other
reasons, the following procedure is recommended:
The WLAN access points are connected to a separate LAN segment that is used exclusively for WLAN
coupling. The LAN segment is connected with the application highway using a firewall. A terminal server
provides the necessary SPPA-T3000 workbench sessions. Direct access to SPPA-T3000 is not
permitted. The access points must provide the security functions of the outside firewall (CAG) of a DMZ
according to the SPPA-T3000 security manual.
The wireless route must be secured using up-to-date encryption technology. Single-use passwords are
recommended for the users of the WLAN link as well as identification and monitoring of the permissible
WLAN devices.

Mar 3, 2009 2.04 Page 72/85
© Siemens AG 2008
8.7 Third party system connection via OPC

OPC Openness, Productivity, Collaboration (formerly: OLE for Process Control)
OPC is a standardized software interface which enables applications by different manufacturers to

exchange data based on the client/server principle.
A pplication Server External OPC Server /C lient
OPC OPC
C lient /Server Server /C lient
OPC D ata
Inside
Firew all
Figure 37: Principle of the OPC connection
For the communication between the applications OPC currently, mainly uses the DCOM technology
(Distributed Component Object Model).
The result of using DCOM would be:
• DCOM has to be configured
• An unpredictable number of TCP/UDP connections would be opened.
The 2nd point in particular would represent a serious security problem, because it would no longer make
a static firewall configuration possible.
The solution to the problem is in the use of an "OPC tunnelers" e.g. by Matrikon Inc., which reduces the
OPC communication between client and server to one (1) TCP connection.
The target port TCP 21379 has been defined for the tunneler.
A pplication Server External OPC Server /C lient
OPC OPC
C lient /Server OPC Tunnel OPC Tunnel Server /C lient
OPC Tunnel
C lient Side OPC D ata Server Side
Inside
Firew all
Figure 38: OPC connection via an OPC tunnel

Mar 3, 2009 2.04 Page 73/85
© Siemens AG 2008
If the external OPC server is located in an insecure environment, e.g. in the client intranet, a VPN
connection is required in addition between the OPC server and the VPN gateway on the inside firewall
A pplication Server VPN External OPC Server /C lient
OPC OPC
C lient /Server OPC Tunnel OPC Tunnel OPC Tunnel Server /C lient
CClient
lient Side OPC D ata Server Side
VPN Tunnel
Inside Firew all /

VPN Gatew ay
Figure 39: OPC connection via OPC and VPN tunnel

Mar 3, 2009 2.04 Page 74/85
© Siemens AG 2008
8.7.1 OPC server/client system in the client intranet
Here a VPN tunnel between the OPC system in the client intranet and the VPN gateway in the inside
firewall is mandated.
OPC Server/Client
via OPC- and VPN Tunnel Client
Intranet
VPN Client
Connection Client
Firewall
OPC Tunnel
SPPA-T3000 with OPC
Control System Connection
Router with
Firewall inside +
VPN Gateway
DMZ-Net
Application
Server with
OPC
Terminal Server
WIN TS
Server
Figure 40: OPC connection via OPC and VPN tunnel
Communication relationships in the client firewall

Permissions required in the client firewall without VPN tunnel.
OPC-> Appl.
OPC Tunnel OPC Appl.Server IP TCP 21379
server

Mar 3, 2009 2.04 Page 75/85
© Siemens AG 2008
Communication relationships in the client firewall

Permissions required in the client firewall with optional VPN tunnel
Application source IP Target IP
Establishment of
OPC-> VPN VPN gateway on ISAKMP
VPN connection, OPC IP
key management
IPSEC NAT OPC-> VPN VPN gateway on
OPC IP UDP 10000
IPSEC Tunnel OPC-> VPN VPN gateway on

OPC IP ESP
Communication relationships between OPC server/client in the client intranet and the VPN
gateway in the inside firewall
Settings in the inside firewall, the access to the security cell "Control System"
The communication here is divided into 2 parts:
1 establishing the tunnel
2 communication by the application
Re 1, establishing the tunnel
Establishment of
OPC-> VPN VPN gateway on ISAKMP
VPN connection, OPC IP
key management
IPSEC NAT OPC-> VPN VPN gateway on
OPC IP UDP 10000
IPSEC Tunnel OPC-> VPN VPN gateway on

OPC IP ESP
Re 2, communication in the OPC tunnel
OPC-> Appl. VPN-Client IP of
OPC Tunnel Appl.Server IP TCP 21379
server the OPC*
* allocated by the VPN gateway

Mar 3, 2009 2.04 Page 76/85
© Siemens AG 2008
8.7.2 OPC server/client system in the DMZ with access by external PI system in
the client intranet
Here the OPC system is located within the DMZ, access is e.g. via a PI system in the intranet.
Figure 41: PI server in the client intranet and OPC connection through an OPC tunnel
Communication relationships via the client firewall

Permissions required in the client firewall
PI to OPC
PI -> OPC System PI IP OPC IP TCP 5450
connection
PI to OPC RDP
PI -> OPC System PI IP OPC IP
connection TCP 3389

Mar 3, 2009 2.04 Page 77/85
© Siemens AG 2008
Communication relationships via the inside firewall

Permissions required in the inside firewall
OPC-> Appl.
OPC Tunnel OPC IP Appl.Server IP TCP 21379
server
8.8 Connecting WIN_TS via OPC
WIN_TS is a diagnostic system for turbines and generators. As it is not an integral part of SPPA-T3000 it
is located in the DMZ. WIN_TS evaluates measured variabels and by doing this it assesses the state of
the running turbines and generators respectively.
The process data is gathered by the Application Server of SPPA-T3000 which in turn forwards the data to
the WIN_TS server. The communcation between Application Server and WIN_TS relies on OPC
mechanisms and uses the communication ports 6666, 6677 and 7777. Accordingly, the firewall must be
configured to allow communication over these ports.
8.9 Third party system connection via Modbus
SPPA-T3000 provides the option to control and monitor 3rd party PLC / PLS
Various protocols and interfaces have been implemented.
Protocols
• MODBUS
• CS275
• IEC 60870-5
Interfaces
• Ethernet
• RS 232, 422, 482
In the present version of the SPPA-T3000 Security Manual only the Modbus connection via CM 104 is
initially described. Other connections will follow.
8.9.1 Modbus TCP connection via CM104
A CM104 can be used as a Modbus gateway. The advantages are:
• high availability (redundant configuration of CM104 possible)

• decentralized structure
The Modbus CM is connected to the Automation Highway. If the access by the 3rd party Modbus system
is implemented via an unsecured network, a firewall is required for modbus communication.

Mar 3, 2009 2.04 Page 78/85
© Siemens AG 2008
SPPA -T3000 R outer /

C ontrol System 3 rd Party Plant A rea
inside D MZ- N et
sw itch Firew all
sw itch sw itch
Application
Server
Terminal
Server
sw itch sw itch
WIN TS
( optional )
sw itch sw itch Firew all
(optional )
L
G
A
E
x
1 2
P S
LT
U
A
F
IP ADDRESS
A
/D
LS
1 2 V
.24
R
MAC-Adresse
k
LAN
2
0 VF A U L T
Aufkleber
g
2
+ 2 4 V
+24V*
C M 104
0 V
Automat ion Automat ion .24
V
Modbus TC P
Server 1 Server 25 C onnection
Figure 42: The Modbus firewall (optional)
Communication relationships via the optional Modbus firewall *

* mandated for the connection via an unsecured network to the 3rd party Modbus system
Permissions required in the Modbus firewall
3rd party system Modbus TCP
Modbus protocol 3rd party IP CM104 IP
-> CM104 TCP 502

Mar 3, 2009 2.04 Page 79/85
© Siemens AG 2008
9 Annexes
9.1 VPN details for remote service access via cRSP
cRSP is based on 3 distributed locations globally.
Fuerth (Europe)
Newark/CA (America)
Singapore (Asia)
Each location has a cRSP infrastructure and specific IP addresses.
Fuerth
dial-up IP Internet IP local DMZ access server FTP Server
169.254.0.3 194.138.39.1 194.138.39.0/27 194.138.39.24 194.138.39.19
Singapore
194.138.243.169 194.138.240.3 194.138.243.176/29 194.138.243.178 -
Newark (CA)
129.73.116.86 129.46.135.193 129.73.116.88/29 129.73.116.92 129.73.116.91

Mar 3, 2009 2.04 Page 80/85
© Siemens AG 2008
9.1.1 IPSec details on establishing a VPN tunnel via the Internet to the cRSP
Internet IPs cRSP side Internet IP plant side

194.138.39.1 fixed IP for COG
194.138.240.3 fixed or dynamic IP for CAG
129.46.135.193
Parameters for establishing the tunnel and
IKE parameters Options Recommendation for cRSP
MD5
Authentication SHA1
SHA1
DES
Encryption * 3DES
3DES
Diffie-Hellman 768Bit
Key exchange security Diffie-Hellman 1024 Bit Diffie-Hellman 1024 Bit
Diffie-Hellman 1536 Bit
* observe country-specific restrictions and export regulations!
Tunnel parameters Options Recommendation for cRSP
none
AH Authentication MD5 none
SHA1
none
ESP Authentication MD5 SHA1
SHA1
none
ESP Encryption* DES 3DES
3DES
none
Diffie-Hellman 768Bit
PFS none
Shared Secret
- At least 12 a/n characters
* observe country-specific restrictions and export regulations!

Note: The current version of cRSP only supports Shared Secret, not certificates.

Mar 3, 2009 2.04 Page 81/85
© Siemens AG 2008
9.1.2 Configuration of the Cisco VPN client software
IPSec parameters in the Cisco VPN gateway
IPSec parameters
Authentication algorithm: ESP/MD5/HMAC-128
Encryption algorithm: 3DES-168
Encapsulation mode: Tunnel
Perfect Forward Secrecy: Disabled
Lifetime Measurement: Time
Data Lifetime: 10000kB
Time Lifetime: 28800sec
IKE Parameters:
Negotiation Mode: Main
Digital Certificate: none
IKE Proposal: IKE-3DES-MD5
The following table shows the required ports and protocols.
Service Protocol Number Source Port Destination Port
ISAKMP/IPSEC Key Management 17 (UDP) 500 500

IPSEC Tunnel Encapsulation 50 (ESP) N/A N/A
IPSEC NAT Transparency 17 (UDP) 10000 (default) 10000 (default)

Mar 3, 2009 2.04 Page 82/85
© Siemens AG 2008
9.2 Applications and ports for the communication with SPPA-T3000
A port is an address component to allocate data to the correct services (protocols). This concept is
implemented e.g. in TCP and UDP .
Port ranges:
• Port numbers between 0 and 1023 are permanently allocated to specific applications
• Port numbers between 1024 and 49151 are "registered ports" of specific application
manufacturers
• Port numbers between 49152 and 65535 are private ports which can be used variably
For security reasons the communication to the security cell Control system must be reduced to the
absolute necessary minimum.
Depending on the design, with or without DMZ Net, this is implemented using 1 or 2 firewalls.
Where a DMZ Net exists there is an inside firewall at the security cell Control system and an outside
firewall at the remote access point (Customer Access Gateway). If the client intranet is connected, this
access also terminates at the inside firewall of the Control system.
The following applications and communication ports are currently provided for SPPA-T3000.
* OPC Server/Client
TC: Thin Client

TS Terminal Server
TC/TS: Combined Thin Client / Terminal Server
.
Application Protocol Destination Port

Remote Desktop Protocol RDP TCP 3389
File Transfer Protocol FTP TCP 20 + 21
File Transfer Protocol Secure SFTP TCP 22
Secure Shell SSH TCP 22
Virtual Network Client VNC TCP 5800
Remote Diagnostic view HTTP TCP 8080
Event Logging SYSLOG UDP 514
Workbench via Web HTTPS TCP 443
Workbench (RMI Registry) RMI TCP 1099
Workbench (RMI Comm.) RMI TCP 50000-50050
Workbench (RMI to Workbench) RMI TCP 50000-50009
Network Time Protocol NTP TCP 123
Simple Network Management Protocol SNMP TRAP UDP 162
Simple Network Management Protocol SNMP READ UDP 161
OfficeScan OfficeScan TCP 54000
OPC Communication via Tunnler Software OPC Tunneler TCP 21379
Simatic Manager WRA WRA TCP 8650 + 8653-8659
All other ports must be blocked

Mar 3, 2009 2.04 Page 83/85
© Siemens AG 2008
10 Glossary
Advanced Encryption Standard

AES Encryption based on the Rijndael algorithm
H Authentication authenticates the whole IP

Authentication Header
AH packet including the outer (gateway) IP
address
Common Remote Service Platform
cRSP Siemens-wide Remote Service Platform
Customer access gateway Service access point in accordance with the

CAG
cRSP standard
COG Customer Owned Gateway Service access point provided by the client
a protocol defined by Microsoft to allow

DCOM Distributed Component Object Model program components to communicate via a
network
Computer network with access options
DMZ Demilitarized Zone
controlled by security technology
ESP authentication authenticates the inner IP
ESP Encapsulating Security Payload header (e.g. of the external system) but not the
outer IP header.
Encryption and for the authentication of the
Hyper Text Transfer Protocol
https communication between Web server and
(Secure)
Browser
Internet protocol
IP prevalent network protocol
provides a security architecture for the

IPSec Internet Protocol Sercurity
communication via IP networks
the hardware address of each individual

MAC Media Access Control
network adapter
Method to replace address information in data
NAT Net Address Translation packages in an automated and transparent
fashion.
a standardized interface which permits the data
Openess, Productivity, Collaboration
OPC exchange between applications of different
(in the past: OLE for Process Control)
manufacturers
it is impossible to deduct keys used earlier or
PFS Perfect Forward Secrecy:
later from an exposed key
Encryption method in which the keys must be

PSK Preshared Key
known to both nodes prior to communication
Runtime describes the time period during

RT Run Time
which a program is executed by a computer
Service Set Identifier

SSID Identification of a wireless network
End device or terminal of a network whose

TC Thin Client
functionality is limited to input and output

Mar 3, 2009 2.04 Page 84/85
© Siemens AG 2008
Method for the cyclical replacement of keys in

TKIP Temporal Key Integrity Protocol
WLAN
Terminal server
TS Computer, emulating several terminals
VLAN Virtual Local Area Network a virtual local network within a physical network
facilitates the secure transmission via an
VPN Virtual Private Network
unsecured network
WPA Wi-Fi Protected Access an encryption method for a wireless LAN
Thin Client connected via a wireless network
wTC Wireless Thin Client
infrastructure

Mar 3, 2009 2.04 Page 85/85

Sic Her He Its Hand Buch

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Sic Her He Its Hand Buch

Diunggah oleh

Hak Cipta:

Format Tersedia

© Siemens AG 2008

SIEMENS All Rights Reserved Energy Sector, F IE TI

SPPA-T3000 Release 4.2

Version 2.04 Mar 3, 2009

Security Manual for SPPA-T3000 Release 4

SPPA-T3000 Security Manual

Security Manual for SPPA-T3000 Release 4

SPPA-T3000 SECURITY MANUAL ........................................................................... 2

1.2 Target group ................................................................................................................................... 6

1.3 Required knowledge...................................................................................................................... 6

3 SPPA-T3000 INTRODUCTION ........................................................................... 9

3.3 Networks (Application Highway, Automation Highway, Backbone Highway, DMZ)........ 16

3.4 Variants (small, standard, multi-unit configuration).............................................................. 25

3.6 Crossover to the "outside world" ............................................................................................. 31

4 COARSE/OVERRIDING SECURITY CONCEPT .............................................. 33

4.2 Communication rule: Everything is prohibited unless explicitly permitted...................... 34

4.3 "Reinforcing" the Thin Clients of the Control systems ........................................................ 34

4.5 Security logs................................................................................................................................. 35

Security Manual for SPPA-T3000 Release 4

5 THE MALWARE PREVENTION SYSTEM ........................................................ 36

5.2 Process-flow of update mechanism ......................................................................................... 36

5.3 Notification of events .................................................................................................................. 39

5.4 Dependencies ............................................................................................................................... 41

6.2 Login banner................................................................................................................................. 45

6.3 Monitoring ..................................................................................................................................... 45

6.4 Auto Logoff ................................................................................................................................... 45

6.5 External Login .............................................................................................................................. 45

8 SCENARIOS FOR REMOTE SERVICE ACCESS ............................................ 48

8.2 General observations on remote service ................................................................................ 54

8.3 Service access to SPPA-T3000 ................................................................................................. 55

8.4 Connection of SPPA-T3000 to an intranet............................................................................... 66

8.5 SPPA-T3000 connection to the Internet................................................................................... 70

8.6 Wireless access to SPPA-T3000 ............................................................................................... 72

8.7 Third party system connection via OPC .................................................................................. 73

Security Manual for SPPA-T3000 Release 4

8.7.1 OPC server/client system in the client intranet .................................................................... 75

8.8 Connecting WIN_TS via OPC ..................................................................................................... 78

8.9 Third party system connection via Modbus............................................................................ 78

9.2 Applications and ports for the communication with SPPA-T3000...................................... 83

Security Manual for SPPA-T3000 Release 4

1.1 Purpose of the document

The T3000 Security Manual includes:

1.2 Target group

1.3 Required knowledge

Security Manual for SPPA-T3000 Release 4

• It is strictly forbidden to take measures which reduce the security of SPPA-T3000.

Data import and export:

Security Manual for SPPA-T3000 Release 4

Security Manual for SPPA-T3000 Release 4

3.1 Standard architecture

Functional levels Hardware

Figure 1 SPPA-T3000 levels

Security Manual for SPPA-T3000 Release 4

3.2 Components of SPPA-T3000 (Thin Client, Application Server, Automation

• Thin Clients with web browser

Networks switch switch

• Ethernet network with TCP/IP

Additional systems • Time server

Security Manual for SPPA-T3000 Release 4

3.2.1 User interfaces - Thin Clients

• Existing IT infrastructure can be used

3.2.2 Power server – Application Server

Stratus ft Application Server 4300 (Aria)

• Standard operating system (Microsoft