Security Hardening Guide

AVEVA Telemetry Server Communication
Drivers
Security Hardening Guide
AVEVA Solutions Limited

High Cross Madingley Road
Cambridge CB3 0HB
Tel +44 (0)1223 556655
Fax +44 (0)1223 556666
aveva.com
Legal Information
DISCLAIMER
AVEVA Group Plc makes no representations or warranties with respect to this documentation and, to
the maximum extent permitted by law, expressly limits its liability for breach of any warranty that may
be implied to the replacement of this documentation with another. Further, AVEVA Group Plc
reserves the right to revise this publication at any time without incurring an obligation to notify any
person of the revision.
COPYRIGHT
©2022 AVEVA Group Plc. All Rights Reserved.
AVEVA gives no express warranties, guarantees or conditions and to the extent permitted under
applicable laws, AVEVA disclaims all implied warranties, including any implied warranties of
merchantability, fitness for a particular purpose or non-infringement of third parties’ intellectual
property rights.
No part of this documentation shall be reproduced, stored in a retrieval system, or transmitted by any
means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written
permission of AVEVA. No liability is assumed with respect to the use of the information contained
herein. Although precaution has been taken in the preparation of this documentation, AVEVA
assumes no responsibility for errors or omissions. The information in this documentation is subject to
change without notice and does not represent a commitment on the part of AVEVA. The software
described in this documentation is furnished under a license agreement. This software may be used
or copied only in accordance with the terms of such license agreement. ArchestrA, Aquis, ArchestrA,
Aquis, Avantis, Citect, DYNSIM, eDNA, EYESIM, InBatch, InduSoft, InStep, IntelaTrac, InTouch,
OASyS, PIPEPHASE, PRiSM, PRO/II, PROVISION, ROMeo, SIM4ME, SimCentral, SimSci,
Skelta, SmartGlance, Spiral Software, Termis, WindowMaker, WindowViewer, and Wonderware
are trademarks of AVEVA and/or its subsidiaries. An extensive listing of AVEVA trademarks can be
found at: https://sw.aveva.com/legal. All other brands may be trademarks of their respective owners.
Publication date: 1/7/2022
AVEVA Group plc

High Cross Madingley Road
Cambridge CB3 OHB. UK
https://sw.aveva.com/
GENERAL INFORMATION
Some product names used in this documentation are used for identification purposes only and may
be trademarks of their respective companies.
Documentation Revision Version: 6.84
AVEVA Telemetry Server Communication Drivers (Version 6.84) • Page ii

PLEASE NOTE
Electrical equipment should be installed, operated, serviced, and maintained only by qualified
personnel. No responsibility is assumed by Aveva Group Plc for any consequences arising out of the
use of this material.
©2022 AVEVA Group Plc. All Rights Reserved.
Validity Note
The present documentation is intended for qualified technical personnel responsible for the
implementation, operation and maintenance of the products described. It contains information
necessary for the proper use of the products. However, those who wish to make a more "advanced"
use of our products may find it necessary to consult our nearest distributor in order to obtain additional
information.
The contents of this documentation are not contractual and in no way constitute an
extension to, or restriction of, the contractual warranty clauses.
For information on how to contact sales, customer training, and technical support see
https://sw.aveva.com/contact.
Page iii • AVEVA Telemetry Server Communication Drivers (Version 6.84)

Contents
Legal Information ii
Contents iv
Welcome to the Security Guide 1
Security Standards 4
Hardware and Operating System Security 5
Hardware BIOS Configuration 6
Embedded Server Management 8
Common Server Configuration 9
Role and Features 10
Time Synchronization 11
Windows Updates 12
Windows Firewall 13
Disable Indexing on C drive 14
Set All Icons to Show in Notification Bar 15
Stop Hibernation 16
Power Option to High Performance 17
Remote Access 18
Server Operating System Manual Hardening 19
Server Group Policy 21
Workstation Group Policy 22
Services 23
Understanding Telemetry Server Security 29
Check the Version of your Telemetry Server Software 30
System Architectures 33
Server Label 34
Lone Server Architecture 35
Hot-Standby Pair Architecture 36
Triple Standby Architecture 37
Dual Network Servers 38
Secure Network Ports 39
Use Trusted Certificates for Server and Client Communications 40
Using External Authentication with Telemetry Server 41
Certificates for Telemetry Server and Client Connections 42
SSL Certificates for Driver Communications 44
Import an SSL Certificate into the Database 46
Server Tools - Security 48
Enable and Manage the Client Access Control List 49
Set the Security Strength 50
Use Server Side Permission Restrictions 51
iv
Password Policy 52
Organize your Users and User Groups 53
Configure User Accounts Appropriately 55
Guest User Account and Everyone User Group 57
Disable the Super User Account 58
v
Welcome to the Security Guide
This guide offers advice for setting up Telemetry Server from a security perspective for new
installers and maintainers of Telemetry Server system. The advice contained should be reviewed in
the context of your architecture and security requirements. We recommend that you also take
advice from qualified security experts.
The following chart indicates the key areas of the server that can be used to further enhance the
security of your SCADA system:
AVEVA Telemetry Server Communication Drivers (Version 6.84) • Page 1

This document has been prepared for Telemetry Server 2021 , with recommendations included for
all currently supported Telemetry Server versions.
Page 2 • AVEVA Telemetry Server Communication Drivers (Version 6.84)

Intended Audience
This guide is intended for system administrators and engineers who are responsible for managing
and configuring the various security features, such as User accounts and User Groups.
Document Scope
This guide explains the concept of Telemetry Server security, including User accounts, User
Groups, and permissions. It also describes the various security settings and provides information on
configuring the security features for your system.
IMPORTANT: This release of AVEVA Telemetry Server Communication Drivers does not
support Alarms, although some references to the Alarm functionality may appear in the Product
and Help.

Security Standards
Telemetry Server is software that can form part of a complete system that is compliant with various
security standards issued by NIST, NERC and IEC, such as NERC-CIP, the NIST Cybersecurity
Framework and IEC-62443. While these standards have much more than the SCADA software in
their scope, Telemetry Server has features and compatibilities that enable it to be configured and
placed within a secure system. Telemetry Server includes features for password management,
communications and software updates that are required by the standards, but (for example)
NERC-CIP also specifies system recovery plans, personnel training, and visitor management. For
a system to be compliant with these standards it must be architected, configured, maintained and
managed as an ensemble, including the networking, operating systems, remote equipment and
people processes. We recommend that competent/certified security professionals with SCADA
skills are used to create and sustain that security. Telemetry Server documentation and AVEVA
resources are available to provide guidance for this, and this document forms part of this. We also
recommend that you consult the product Help and online Resource Center, both available from the
Help menu in Configurator.

Hardware and Operating System Security
The security of Telemetry Server is also dependent on the operating system as well as the
hardware platform on which it is installed. The following sections are aimed at System
Administrators who are setting up and configuring the systems prior to the installation of Telemetry
Server and are recommendations that should be considered to improve the general security. These
aspects of the document are suggestions of good practice, but are not comprehensive, and need to
be allied with recommendations for server and client configuration from the operating system
software vendor, hardware vendor and security experts.
l Hardware BIOS configuration.

l Embedded Server Management.
l Common Server Configuration.
l Server Operating System Manual Hardening.
l Server Group Policy.
l Workstation Group Policy.
l Services.

Hardware BIOS Configuration
Boot Options
The following are common security recommendations relating to the configuration of the BIOS for
client and server machines. These recommendations are aimed at reducing the ability of
unauthorized users compromising the physical systems. You should refer to the manufacturer's
system manuals of each machine for detailed information about the available BIOS settings as they
may vary for each machine.
Boot devices
To reduce the risk of unauthorized access to a server or workstation using various
forms of bootable media (for example, USB devices, PXE Network and CD/DVD’s),
we recommended that you change the permitted boot devices to only enable the
local disk.
NOTE: If the server hardware is using a Virtual environment (such as VMWare

ESXi), then the local SD Card or Internal USB port may also need to be enabled to
allow the system to boot correctly.
Boot Sequence
If more than one single boot device has been enabled, you should ensure that the
boot sequence is correctly configure to give the local disk the highest priority access.
If the CD/DVD drive is required and is enabled as a boot device, you should ensure
that the boot sequence for the CD/DVD drive is configure to a lower priority below
that of the local disk to reduce the risk of unauthorized media running upon start-up.
One-Time boot
We recommended that you disable one-time boot options from the start up menu.
This provides an additional level of security to prevent users from bypassing any
defined boot sequences within the BIOS.
Boot Sequence Retry

We recommended that you disable “Boot Sequence Retry”. This prevents the
system from attempting to retry boot devices without power cycling.

Integrated Devices
We recommend that you disable any integrated devices that are not be used as part of the default
server role. This may include internal USB/SD card devices, PCI slots, PCIe slots, PCI-X slots and
network cards.
BIOS Configuration Password Access

The majority of systems provide an option to configure a password to restrict access to the BIOS
configuration.
We recommended that you define a Setup password, that is suitably complex, to prevent any
system changes to the BIOS configuration.
NOTE: We recommend that you keep a secure record of BIOS setup passwords in the event
configuration changes need to be made.
Using a password within this setting prevents unauthorized access to the BIOS configuration (and
in some cases the boot menu override), unless correctly entered after any power cycle event.

Embedded Server Management
We recommend that physical servers are supplied with an Embedded Server Management (ESM)
system. This allow a level of resilience to provide power recovery of a SCADA based server. An
ESM system allows you to monitor the physical server in the event of an Operating System lockup
or failure or if the server is physically turned off. There may also be specific instances where remote
access would be required to allow full control of the physical server (for example, remote rebooting).
Although an ESM is a recommended tool it is also a potential security vulnerability. To configure an

ESM to provide remote access to the Embedded Server Management tool, an IP address will need
to be allocated from the relevant network range and entered within the system. It is recommended
that the network address for management purposes are on a separate LAN isolated from the
corporate and engineering LAN to prevent direct access from a possible compromised network.
User management
To further harden access to the Management interface, it is recommended to define
a user name and secure password.
Operating System Pass-through

With some management interfaces, there are options available to allow access to the
Operating System by means of pass-through.
If this option exists, it is recommended to disable this feature.
Remote Enabling
With some management interfaces, there are options to allow remote enablement
from a central management server. It is recommended to have this option disabled to
prevent any possibility of a compromised management server gaining access to the
management interfaces of connected systems.

Common Server Configuration
There are various server configurations and installations available to further enhance the security of
a system and help reduce the servers attack footprint for possible compromise. This section will help
provide requirements and procedures to enforce the necessary changes on a Microsoft Server
platform.
l Roles and Features

l Time Synchronisation
l Window Updates
l Windows Firewall
l Secure Network Ports
l Disable Indexing on C drive
l Set All Icons to Show in Notification Bar
l Stop Hibernation

Role and Features
Server and roles and features are an important part of the security planning process. We
recommend that you only install the roles and features that a server will be performing as this only
enables the necessary services and applications required, this helps to keep the potential attack
surface as small as possible.

Time Synchronization
Time Synchronization is an important security tool that ensures any logging times are as accurate
as possible in order to help you identify any possible intrusion attempts.
There are various options available for use as a time source for time synchronization. GPS based
time solutions or LAN based (either a firewall or other LAN NTP time source) are generally used as
a reference point, separate from the Corporate or business LAN.
NOTE: If you use a single GPS time source for synchronizing time across a network (such as a
shared time source throughout all network and security layers), we recommend that you have a
secondary alternative time source available for use as a delta comparison with monitoring rules in
place. This is to ensure the integrity of the time signal on the SCADA LAN and that if either source
is compromised or becomes unavailable that sufficient notice is provided to the network
operators, and time skew kept to a minimum.
Depending on the network infrastructure, we recommend that all Domain Controllers are set to
update from an accurate NTP source on a secured LAN, with the domain member machines (Non-
DC Servers or Clients) configured to update from the domain controllers using Group Policy
enforcement.
To configure a Domain Controller to synchronize with an external common time source, you can
either use the command line or modify the registry.
For Virtual environments, the guest has the ability to sync with the local Virtual Server host (such as
those provided with VMWare tools and Hyper-V configurations), but it is best practice and we
recommended that you disable this option on the guest to reduce excessive CPU for committing
time updates.
Using VMWare or Hyper-V

VMWare best practice for time synchronizing is available from the following website.
https://kb.vmware.com/selfservice/microsites/search.do?language=e
n_US&cmd=displayKC&externalId=1318
For Virtual Domain Controllers in Hyper-V environments it is recommended to disable the time
synchronization to the Hyper-V hosts to prevent any issues with time updates that are incorrectly
applied.
Additional information is available from the following link:
https://technet.microsoft.com/en-us/library/d2cae85b-41ac-497f-
8cd1-5fbaa6740ffe(v=ws.10)#deployment_considerations_for_
virtualized_domain_controllers

Windows Updates
To maintain security from newly found vulnerabilities it is important to upgrade the Operating
System and other programs installed on the server.
Implementing Updates
If possible the Windows Operating system should be regularly patched, using the Microsoft
Windows Server Update Service (WSUS), with the latest verified updates from Microsoft.
We recommend the use of a form of pre-production staging area to test updates. This allows you to
verify the installation of a patch and ensure there is a method to revert back to a good point in time
should the patch fail or cause a failure to the machine itself.
NOTE: Due to the nature of SCADA, you may not be able to perform updates live if they require a
server reboot or where certain patches are known to conflict with SCADA processes and
services. Please check the AVEVA Technology Matrix for its compatibility with the latest
Windows Updates.
Formulate a "back out" plan

We also recommend that a working “back out” plan is created or in place for the Production or “Live”
System. This allows you to restore the system to its original state with the minimum of disruption
should any updates have a negative impact on the system.
Use a local WSUS server

You can connect clients and servers to a local WSUS server. This allows you to safely implement
tested and approved updates using the domain group policy setting. You can manage the
distribution of updates within the network to ensure that the minimum of disruption occurs with. It
requires that the BITS (Background Intelligent Transfer Service) and the Windows Update
(WUAUSERV) service are correctly enabled.
Check the AVEVA Technology Matrix for the status of Telemetry Server compatibility with the latest
Windows updates.

Windows Firewall
We recommend that you have an endpoint firewall installed as part of your security model. The
firewall should be enabled for “review” or “learning” mode (or the mode specific to the vendor
firewall, which allows automatic rule creations), for a short duration inside a known controlled
environment. This allows the to generate the necessary rule set based on actual activity. This can
then be evaluated (depending on the firewall vendor) and incorporated into a general policy for
deployment.
Windows Firewall comes as a standard feature that can be enabled and configured to provide an
effective, extra level of defense within a network from outside attack. Known protocols, ports,
sources and destinations can be pre-configured within the domain security policy and implemented
throughout the network.
Non-domain based systems would need to be configured manually. This process could be easily
implemented using installation scripts or alternatively the use of a third party endpoint firewall with a
central management console could be more efficient.
NOTE: The additional tools, drivers and services used by a SCADA system can make the
configuration more complex to define at the earlier part of the system design.
If a third party endpoint protection is to be used, then it is recommended to disable the windows
firewall to prevent any possible conflict.

Disable Indexing on C drive
We recommend that the use of the built-in disk indexing service within Windows is disabled for all
connected drives as this impacts on the system performance, in particular for Virtual Environments.
The performance of drives that are allocated for the storage of events or historic data, where they
are under constant change with the addition of files would be severely impacted as a result of the
indexing service constantly re-applying updates to its internal reference database.

Set All Icons to Show in Notification Bar
Setting all icons to show in the notification bar helps to prevent any icons from not showing correctly,
especially Telemetry Server where the icon changes to display its current working status.
You can configure the environment to ensure the Telemetry Server icon remains visible at all times.

Stop Hibernation
We recommend that you disable the hibernation feature on all servers to prevent any issues on
shutdown or restarting.
You can disable hibernation using the command line, open a command prompt using administrative
privileges and enter the following:
Powercfg.exe –h off
You can also disable the feature from within a Group Policy template, which will be dependent on
the customer requirements and system architecture.

Power Option to High Performance
When you install a Windows Server operating system and configure it with the File Server role, the
default Power Setting is configured to balance power efficiency and power.
We recommend that you review the system power plan options to ensure that it is set to “High
Performance” to prevent any possibility of power management hindering the system.
NOTE: This is not recommended for every file server. The Balanced (default) profile will be
enough for most cases, with high and constant load being the exception.

Remote Access
For Windows machines, access may be required remotely using the built in Remote Desktop tool.
This is disabled by default. To enable the feature, you will need to open the System Properties
window and enable Remote Desktop.
Ensure that the “Allow connection only from computers running Remote Desktop with
Network Level Authentication (recommended)” option is enabled as this provides an additional
level of security with Remote Desktop sessions.
Unless there is a specific business requirement, we recommend that you disable the Remote
Assistance option if it was previously enabled to further reduce the attack surface of the machine.

Server Operating System Manual Hardening
The following are features that you can manually configure to provide additional security for the
server operating system:
Network Adapter Configuration

To reduce attack surfaces, Network communication protocols should be limited to
only those which are required.
We recommend that the following items should be disabled from each local network
interface installed on the machine. You should check that they are not used or
required as part of the customer architecture.
l QOS Packet Scheduler

l Internet Protocol 6 (TCP/IPv6)
Lock Down Admin Shares
You should consider disabling the local admin shares as a possible security
measure. However, this will be dependent upon any additional software which may
use the admin shares for data transfer, or if there are future requirements to deploy
software remotely.
NOTE: Microsoft does not recommend this change and therefore careful
consideration must be taken into account if you wish to lock down the admin
shares.
To disable the admin shares, you can apply the following registry key setting:
Computer\HKEY_LOCAL_
MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\
Parameters
"AutoShareWks"=dword:00000000
We suggest this is only performed once all the required software installations,
especially AV deployments have been completed as they often require the use of the
ADMIN$ share for file transfer.
To enable admin shares, apply the following value:
"AutoShareWks"=dword:00000001
Access the application registry at:
Computer\HKEY_LOCAL_
MACHINE\SOFTWARE\AVEVA\TelemetryServer\Server
Apply the settings shown below. This removes any MD5 based ciphers from the
available list. MD5 is now considered vulnerable.

NOTE: Many (older) browsers require RC4_128_SHA to connect as they do not
all support AES.
Terminal Services
When Terminal Services are used, ensure that the property 'Allow connections
only from computers with NLA' is set.

Server Group Policy
When the SCADA network is using Windows Active Directory, we recommend the use of Group
Policies to apply global security settings for all server and client machines on the domain. This
method provides you a much easier way to maintain the network and for further enhancement
without having to perform the changes manually on each individual machine.
Most, but not all, of the settings applied are available via local security policy, which could also be
used for standalone machines that are not part of a domain. However, Group Policy provides the
most manageable deployment solution for multiple machines across a network.
We recommend you consult local system administrators for the guidance needed to set this up.
There are various other options common to the Server Group Policies, which will need to be
considered and dependent upon the customer requirements. Some suggestions are provided
below, but the list is not exhaustive.
l Disable LLMNR (Link-Local Multicast Name Resolution) using the setting 'Turn Off Multicast
Name Resolution'
l Disable NBT-NS (Netbios Name Service)
l Disable WPAD (Web Proxy Auto-Discovery Protocol)
l Disable NTLMv1 Authentication
l Set the Windows Logon Cached Logons Count to zero
(HKEY_LOCAL_MACHINE\Software\Microsoft\Windows
NT\CurrentVersion\Winlogon\CachedLogonsCount).

Workstation Group Policy
There will be various requirements and considerations that need to be included when introducing or
applying changes to a Workstation Group Policy.
Some considerations are below.
l Restricted desktop by means of:

l Alternative to the windows Explorer
l Start Menu options
l Shutdown prevention
l Restricted task manager options
l Screensavers
l Registry access denial
l File execution prevention (for example, disable Command Prompt, Explorer.exe)
l Web Browsing restrictions
l Fixed Default browser
l Disable changing home link
l Internet Options
l Security Zone settings.

Services
Understanding and managing services that appear on the server and clients is an important part of
the security procedure. Disabling services not in use reduces the ways in which the server can be
attacked.
A sample configuration of services and their start-up state are listed below.
Name Caption State StartMode

AeLookupSvc Application Experience Running Auto
ALG Application Layer Gateway Service Stopped Manual
Appinfo Application Information Stopped Manual
AppMgmt Application Management Stopped Manual
aspnet_state ASP.NET State Service Stopped Disabled
AudioEndpointBuilder Windows Audio Endpoint Builder Stopped Manual
Audiosrv Windows Audio Stopped Manual
BFE Base Filtering Engine Running Auto
BITS Background Intelligent Transfer Stopped Manual
Service
Browser Computer Browser Stopped Disabled
CertPropSvc Certificate Propagation Running Manual
clr_optimization_v2.0.50727_ Microsoft .NET Framework NGEN Stopped Disabled
32 v2.0.50727_X86
clr_optimization_v4.0.30319_ Microsoft .NET Framework NGEN Stopped Auto
32 v4.0.30319_X86
COMSysApp COM+ System Application Running Manual
CryptSvc Cryptographic Services Running Auto
CscService Offline Files Stopped Disabled
DcomLaunch DCOM Server Process Launcher Running Auto
Dhcp DHCP Client Running Auto
Dnscache DNS Client Running Auto
dot3svc Wired AutoConfig Stopped Manual
DPS Diagnostic Policy Service Running Auto
EapHost Extensible Authentication Protocol Stopped Manual
EventLog Windows Event Log Running Auto

EventSystem COM+ Event System Running Auto
FCRegSvc Microsoft Fibre Channel Platform Stopped Manual
Registration Service
fdPHost Function Discovery Provider Host Stopped Manual
FDResPub Function Discovery Resource Stopped Manual
Publication
FontCache Windows Font Cache Service Running Auto
FontCache3.0.0.0 Windows Presentation Foundation Stopped Manual
Font Cache 3.0.0.0
gpsvc Group Policy Client Running Auto
hidserv Human Interface Device Access Stopped Manual
hkmsvc Health Key and Certificate Stopped Manual
Management
idsvc Windows CardSpace Stopped Manual
IKEEXT IKE and AuthIP IPsec Keying Modules Running Auto
IPBusEnum PnP-X IP Bus Enumerator Stopped Disabled
iphlpsvc IP Helper Running Auto
KeyIso CNG Key Isolation Stopped Manual
KtmRm KtmRm for Distributed Transaction Running Auto
Coordinator
LanmanServer Server Running Auto
LanmanWorkstation Workstation Running Auto
LICENCESERVER Telemetry Server License Server Running Auto
lltdsvc Link-Layer Topology Discovery Stopped Manual
Mapper
lmhosts TCP/IP NetBIOS Helper Running Auto
MatrikonOPC Server for MatrikonOPC Server for Simulation Stopped Manual
Simulation and Testing and Testing
MMCSS Multimedia Class Scheduler Stopped Manual
MpsSvc Windows Firewall Running Auto
MSDTC Distributed Transaction Coordinator Running Auto
MSiSCSI Microsoft iSCSI Initiator Service Stopped Manual

msiserver Windows Installer Stopped Manual
napagent Network Access Protection Agent Stopped Manual
Netlogon Netlogon Running Auto
Netman Network Connections Running Manual
NetMsmqActivator Net.Msmq Listener Adapter Stopped Disabled
NetPipeActivator Net.Pipe Listener Adapter Stopped Disabled
netprofm Network List Service Running Auto
NetTcpActivator Net.Tcp Listener Adapter Stopped Disabled
NetTcpPortSharing Net.Tcp Port Sharing Service Stopped Disabled
NlaSvc Network Location Awareness Running Auto
nsi Network Store Interface Service Running Auto
OpcEnum OpcEnum Stopped Manual
PeerDistSvc BranchCache Stopped Manual
pla Performance Logs & Alerts Stopped Manual
PlugPlay Plug and Play Running Auto
PolicyAgent IPsec Policy Agent Running Auto
ProfSvc User Profile Service Running Auto
ProtectedStorage Protected Storage Stopped Manual
RasAuto Remote Access Auto Connection Stopped Manual
Manager
RasMan Remote Access Connection Manager Running Manual
RemoteAccess Routing and Remote Access Stopped Disabled
RemoteRegistry Remote Registry Running Auto
RpcLocator Remote Procedure Call (RPC) Stopped Manual
Locator
RpcSs Remote Procedure Call (RPC) Running Auto
RSoPProv Resultant Set of Policy Provider Stopped Manual
sacsvr Special Administration Console Helper Stopped Manual
SamSs Security Accounts Manager Running Auto
SCardSvr Smart Card Stopped Manual
Schedule Task Scheduler Running Auto

SCPolicySvc Smart Card Removal Policy Stopped Manual
seclogon Secondary Logon Running Auto
SENS System Event Notification Service Running Auto
SepMasterService Symantec Endpoint Protection Running Auto
SessionEnv Terminal Services Configuration Running Manual
SharedAccess Internet Connection Sharing (ICS) Stopped Disabled
ShellHWDetection Shell Hardware Detection Running Auto
slsvc Software Licensing Running Auto
SLUINotify SL UI Notification Service Stopped Manual
SmcService Symantec Management Client Running Manual
SNAC Symantec Network Access Control Stopped Manual
SNMPTRAP SNMP Trap Stopped Manual
Spooler Print Spooler Running Auto
SSDPSRV SSDP Discovery Stopped Disabled
SstpSvc Secure Socket Tunneling Protocol Running Manual
Service
swprv Microsoft Software Shadow Copy Stopped Manual
Provider
SysMain Superfetch Stopped Disabled
TapiSrv Telephony Running Manual
TBS TPM Base Services Stopped Auto
TermService Terminal Services Running Auto
Themes Themes Stopped Disabled
THREADORDER Thread Ordering Server Stopped Manual
TrkWks Distributed Link Tracking Client Running Auto
TrustedInstaller Windows Modules Installer Running Manual
UI0Detect Interactive Services Detection Stopped Manual
UmRdpService Terminal Services UserMode Port Running Manual
Redirector
upnphost UPnP Device Host Stopped Disabled
UxSms Desktop Window Manager Session Running Auto
Manager

vds Virtual Disk Stopped Manual
VMTools VMware Tools Running Auto
vmvss VMware Snapshot Provider Stopped Manual
VSS Volume Shadow Copy Stopped Manual
W32Time Windows Time Running Auto
WcsPlugInService Windows Color System Stopped Manual
WdiServiceHost Diagnostic Service Host Stopped Manual
WdiSystemHost Diagnostic System Host Running Manual
Wecsvc Windows Event Collector Stopped Manual
wercplsupport Problem Reports and Solutions Stopped Manual
Control Panel Support
WerSvc Windows Error Reporting Service Running Auto
Winmgmt Windows Management Running Auto
Instrumentation
WinRM Windows Remote Management (WS- Running Auto
Management)
wmiApSrv WMI Performance Adapter Stopped Manual
WPDBusEnum Portable Device Enumerator Service Stopped Manual
WPFFontCache_v0400 Windows Presentation Foundation Stopped Manual
Font Cache 4.0.0.0
wuauserv Windows Update Running Auto
wudfsvc Windows Driver Foundation - User- Stopped Manual
mode Driver Framework
We recommend that you review the permissions of services, particularly those added by third-party
software, and check whether users other than administrators can access them.
We also recommend that service paths are enclosed in quotes. A command to discover these is:
wmic service get name,displayname,pathname,startmode |findstr /i

/v "Disabled" |findstr /i /v "c:\windows\\" |findstr /i /v """

Virtual Accounts
ATTENTION: When virtual accounts are used for ancillary processes such as those mentioned
above, the 'NT SERVICE\ALL SERVICES' account has to be assigned the 'Log on as a
service' user right. For details on how to do this, see https://technet.microsoft.com/en-
us/library/cc794944(v=ws.10).aspx. With virtual accounts used for licensing services, you also
need to grant permissions for the virtual user account to read the directory in which the license file
is stored.
If the 'NT SERVICE\ALL SERVICES' account is not assigned the 'Log on as a service' user
right, the virtual account will not work and an error will be shown in the system log files in
Windows.

Understanding Telemetry Server Security
Security is applied by the Telemetry Servers to every client that accesses the system (Configurator,
third-party OPC applications, and so on.). For example, a user that accesses the system via a third-
party OPC client is subject to the same restrictions as when accessing the system via Configurator.
Telemetry Server Security

The following chart allows you to select the key areas of Telemetry Server security:
Third-party applications that access Telemetry Server will use a configured user account or the
built-in Guest user, depending on whether client security is supported by the Third Party application.

Check the Version of your Telemetry Server Software
The latest Telemetry Server software includes the most up-to-date security features designed to
help protect your system from unauthorized access.
To check that you have the latest version of the Telemetry Server software, Telemetry Server client
software and Telemetry Server service pack:
1. Log on to the Telemetry Server Configuration Tool on your Telemetry Server.

2. Select the Help menu, then choose the About Server Config... option.
Information about the Telemetry Server software is displayed in a dialog box.
NOTE: The image shown above is for illustration purposes only. Later versions of Telemetry
Server may be available.
The About dialog box contains contact details for Technical Support and Application
information. The Application information includes details of the product label and version.
l The product label is:
Telemetry Server <Year>R<Release Number>.<Service Pack>[ <Hot Fix> ]

Example:
TelemetryServer 2009 R2.14

(the product label for TelemetryServer 2009 Release 2, Service Pack 1, Hot Fix 4).
(TelemetryServer is the name by which Telemetry Server was formerly known.)
Telemetry Server 2019
(the product label for the first release of Telemetry Server 2019 ).
l The product version consists of four numbers:

l <Major>—This number represents the version of the product and is set to 6.
l <Minor>— The release number.
l <Build>—A number that represents the amount of days that have elapsed since 1-
Jan-2000 (when the build was requested).
l <Revision>—Represents the build number within a specific day. This is usually 1 as
it is uncommon for there to be multiple builds on the same day.
3. Compare your version of the Telemetry Server software to the latest Telemetry Server
software.
4. Log on to Configurator on one of your Telemetry Server clients.
5. Access the version information.
In Configurator:
i. Select the File menu.
A context-sensitive menu is displayed.
ii. Select the Help option.
A further context-sensitive menu is displayed.
iii. Select the About option.
The About dialog box is displayed.

The About dialog box provides information about the software version that is running on
that particular client. The About dialog box uses the same format as the About dialog box
for the server software.
Following an upgrade, the version of Telemetry Server software that is running on the
client might differ to that running on the server. If so, the client will only provide access to
the database items and properties that are supported by the version of software that is
running on that client.
6. Again, compare your version of the software to the latest Telemetry Server software.
If you discover that a newer version of the software is available, please contact your vendor for more
information.
For the optimal security, we recommend that you upgrade the latest version of the Telemetry Server
software with the latest service pack. However, if you choose not to upgrade, you should at least
install the latest service pack for your existing version of Telemetry Server.

System Architectures
The first stage of the server configuration is to define the type of system architecture to which the
server belongs. You can use the Server Configuration Tool’s Partners settings to configure the
server so that it recognizes the structure of your system and can interact with any other servers. To
do this, you should have an understanding of the various server architectures and server connection
and monitoring features.
The following sections describe the available server architectures and explain how the servers
synchronize and interact with each other.
l Server Label
l Lone Server Architecture
l Hot-Standby Pair Architecture
l Triple Standby Architecture
l Dual Network Servers
NOTE: Multi-server systems (redundancy) are only supported by full versions of Telemetry
Server. You can find information about the version you have installed by running Configurator
and selecting Help>About.

Server Label
Use the Server Label field on the Partners section of the Server Configuration Tool to define a
label that uniquely identifies the server.
The Server label is used within the system architecture to uniquely identify the server. When
connecting to a partner, the servers exchange label information. Likewise, clients obtain label
information when they poll the server. On a new server, the Server Label defaults to the NetBIOS
name of the machine on which the server is installed, however you can replace this name with a
more meaningful label if required. Server Labels are restricted to 30 characters as they comprise
the names of OPC properties.
Ensure that the Server Label field is populated with a label that is unique to all of the servers on
your system.
When a Configurator client connects to a Telemetry Server, Telemetry Server updates that client's
ServerLabels.xml file to maintain Server Label information about the server(s) to which the client
connects. (The Server Label information might change, for example, if the client's connections
configuration is reconfigured, or the Server Label itself is reconfigured.) The xml file provides a
mechanism to populate the Database Bar on the Configurator client with data about the server to
which the client is currently, or was last, connected. This enables information to be provided about
the server even if the client cannot currently connect to that server.
Telemetry Server also uses the Server Label field to populate the Server Label OPC property
value. In Configurator, you can access this and other OPC properties that relate to server status by
expanding the System Status branch of the OPC Data Bar.
ATTENTION: In order to cache information about the server, write access is required to the
location at which the ServerLabels.xml file is stored on the View. If the user that is logged on to
the Configurator only has read access to this location, Configurator will be unable to cache the
server data. As such, additional Server Label information will only be available for the server to
which the client is currently connected provided that the Configurator is able to poll that server
successfully (as opposed to if the client is currently unable to access that server).

Lone Server Architecture
The simplest form of Telemetry Server system is a Lone Server architecture. This involves a single
server that runs independently, stores the database and communicates with the clients and
hardware (outstations, PLCs and so on).
As Lone Server architectures have only one server, there is no redundancy. If there is an
unexpected problem with the server or it loses its connections to the clients or hardware, the
Telemetry Server system will go offline.

Hot-Standby Pair Architecture
A Hot-Standby Pair architecture uses two servers to provide redundancy and allow for load sharing.
NOTE: Multi-server systems (redundancy) require a license and so are only supported by full
versions of Telemetry Server.
In a Hot-Standby Pair, one server acts as the Main server and the other server acts as a Standby
server. The Main server runs the system drivers and acts as the primary server whereas the
Standby server is used as a backup server.
During synchronization, the Main server updates the Standby server. This process provides the
Standby server with data and configuration that accurately represents the data on the Main server.
So, if the Main server goes offline or there is a manual changeover, the Standby server can take
over the duties of the Main server and the system will continue to run.

Triple Standby Architecture
Triple Standby server architectures are similar to Hot-Standby pair architectures except that instead
of there being one Standby server, there are two. As with Hot-Standby Pair arrangements, one of
the servers is recognized as the Main server, with the other servers being Standby servers. Clients
and plant can be connected to any of the servers, but the data they report is sent to the Main server
and stored in the Main server’s database. The Main server then updates the databases in the
Standby servers so that they match the Main server database.
The diagram above shows a possible Triple Standby architecture, where three servers are
connected via a LAN / WAN. Triple Standby architectures provide additional backup in the event of
a hardware, software or network failure.
When a manual changeover is performed, the Main server will switch to Standby and the Standby
server that has been running the longest amount of time will switch to become the new Main server.
NOTE: Multi-server systems (redundancy) require a license and so are only supported by full
versions of Telemetry Server.

Dual Network Servers
Some servers are fitted with two network cards and so can support dual networking (multiple
physical connections between network devices). Typically, dual network servers are used with
Telemetry Server to provide redundancy—they allow a server to have two physical connections to
another server, meaning that should one network path fail, Telemetry Server can use the ‘backup’
network path instead. Dual networking can also be used to isolate networks and to provide
additional bandwidth.
To configure dual networking you can use Telemetry Server's native network sharing feature, or the
configuration features of the operating system and / or network card software. We recommend the
latter, and to do this, you need to use Microsoft Windows Control Panel to configure Network
Connections. In the configuration for each network card, you will need to define:
l An IP address—Used to identify the port used by each card

l A subnet—Defines the number of IP addresses that are available in the network.
When you have set up each network card in Windows, you will need to configure Telemetry Server
to recognize the two network cards.

Secure Network Ports
For a secure system we recommend that Telemetry Server is set up in a firewalled environment.
This section describes the ports used so that firewalls can be set up appropriately.
Telemetry Server TCP Ports

Telemetry Server uses network ports for various forms of client / server and device communication.
These are dependent on the protocols and ports configured in the Telemetry Server database. A
guide is available here:
https://extlogon.aveva.com/adfs/ls/?wa=wsignin1.0&wtrealm=https%3a%2f%2f1.800.gay%3a443%2fhttps%2fg
csresource.aveva.com&wctx=rm%3d0%26id%3dpassive%26ru%3d%252fTechnologyMat
rix&wct=2021-11-18T12%3a33%3a41ZNetwork-Ports-used-by-TelemetryServer/ba-
p/278605
Telemetry Server DBServer uses a database server port for all native Telemetry Server
communications. This is used to synchronize one server with another server, Configurator client
access, and client API access (for example COM, ODBC, .Net). The default port is 5481. Generally
there’s no reason this should be modified, but it can be changed through the Database Manager,
the Server Configuration Tool, or (while the server is stopped) by altering the following registry key:
HKLM\SOFTWARE\AVEVA\TelemetryServer\DB\Port
NOTE: If you use a non-default database instance, (for example if you are running multiple
Telemetry Server instances on a node), the key becomes:
HKLM\SOFTWARE\AVEVA\TelemetryServer-<instance name>\DB\Port
The server port number needs to match the port number configured on clients in the Configure
Connections utility, and needs to match the port numbers configured on other servers for database
synchronization.
An additional requirement applies if the either end of the connection (server or client) is
running a version of Telemetry Server that is earlier than Telemetry Server 2020 R2. With
such a setup, the Configurator client listens on a separate TCP port to allow the server to connect to
the client and deliver real-time updates. This port must be open for the client to access the server,
and appropriate measures should be taken to allow firewalls to pass this connection through. The
default port range is 5000 – 5009 and can be modified using the Telemetry Server Client Applet.
NOTE: The OPC client connections also require this port.

Use Trusted Certificates for Server and Client
Communications
Telemetry Server 2020 R2 onwards is designed to use certificates to initiate secure connections
and encrypt the data that is transmitted between Telemetry Servers and clients (see Certificates for
Telemetry Server and Client Connections). We strongly recommend that you obtain
certificates from a trusted certification authority to use for such communications.
Recommended security:
l Obtain and install trusted server certificates

Increased security:
l Obtain and install trusted server certificates

l Obtain and install trusted client certificates
We recommend that you do not:
l Use the default server generated non-trusted server certificate.

Using External Authentication with Telemetry Server
Telemetry Server provides you with an External Authentication feature. By using the External
Authentication feature, you can associate Telemetry Server user accounts with Microsoft Windows
or LDAP (Lightweight Directory Access Protocol) user accounts. When Telemetry Server user
accounts are configured to use External Authentication, they are verified against the corresponding
Windows or LDAP User Profile. Each Telemetry Server user account and password, when
entered, should match that of the Windows or LDAP User Profile with which the credentials are
associated. When enabled and set up, External Authentication enables you to:
l Disable a Telemetry Server user account by disabling the corresponding Windows/LDAP user
account
l Manage the password of a Telemetry Server user account by managing the corresponding
Windows/LDAP user account.
The main benefit of using External Authentication is that it can reduce the amount of time and effort
it takes for IT staff to restrict access via Telemetry Server user accounts. It also means they can
manage password related settings through Windows/LDAP rather than Telemetry Server.
However, using External Authentication can cause minor delays (milliseconds) with connections
and Telemetry Server user account response times.
NOTE: If a user attempts to log on via a Telemetry Server user account that is not configured to
use External Authentication, they only need to enter a user name and password that is valid in
Telemetry Server.

Certificates for Telemetry Server and Client
Connections
The use of certificates to initiate secure connections and encrypt the data that is transmitted
between Telemetry Servers and clients is supported by Telemetry Server 2020 R2 onwards. From
this version of Telemetry Server, two sets of certificates are supported:
l Server certificates that the Telemetry Server provides to the clients, so that the clients can
verify that the server is a valid Telemetry Server.
l Client certificates that the clients provide to the Telemetry Server, so that the server can
verify that the clients are valid clients.
You can optionally require the client certificates to map to a Windows user account.
We strongly recommend that you set up your system to use trusted certificates to initiate
secure connections and encrypt the data that is transmitted between Telemetry Servers
and clients. To configure your system to use such certificates:
1. Each server and client machine (if client certificates are required) should have its own unique
certificate, which must have a private key associated with it. Obtain the required certificates
from a trusted certification authority and load each certificate into the Windows certificate store
on the relevant machine. (Store the server certificate on the relevant server machine, and the
client certificate on the relevant client machine.) For more information about certificate stores,
see the Windows help.
2. On the server machine, set up the required settings in the Server Configuration Tool (see
'Configure the Connection Security Settings' in the Telemetry Server Guide to Server
Administration).
If the server is in a multi-server system, also configure the security settings that apply for
outgoing server-to-server connections during which this server acts as a client (see
'Connection Security Tab (for Server-to-Server Communications)' in the Telemetry Server
Guide to Server Administration).
Repeat this step on each server in your system.
3. On each client machine, set up the required client connection security for the client (see
'Configure the Client Connection Security Settings' in the Telemetry Server Guide to Client
Administration).
On Telemetry Server systems on which certificates are used:
l If a Telemetry Server that does not have a valid certificate attempts to communicate with
another Telemetry Server on the system (that requires valid server certificates):
l The connection will be declined
l An entry will be logged in the server log file of the server to which the connection attempt
was made. The entry will indicate that the other server did not have a valid certificate (or
has no certificate at all).

l If server certificates are required and a client attempts to connect to a Telemetry Server that
does not have a valid certificate:
l The client log file will indicate that a connection was attempted to a Telemetry Server that
does not have a valid certificate (or has no certificate at all).
l If client certificates are required and a client that does not have a valid certificate attempts to
connect to a Telemetry Server:
l An entry will be logged in the server log file to indicate that a connection was attempted by
a client that does not have a valid certificate (or has no certificate at all).
WARNING
POTENTIAL SECURITY BREACH
Clients that are running a version of Telemetry Server that is earlier than Telemetry Server 2020
R2 use a different communications protocol and are exempt from requiring valid client
certificates. We recommend that you upgrade all of your clients as soon as it is practicable, to
ensure that they run a version of Telemetry Server that does support client certificates.
Failure to follow these instructions can result in death, serious injury, or equipment
damage. The breach in system security could expose sensitive data and leave the
database vulnerable to unauthorized and potentially malicious use.
Clients that are running a version of Telemetry Server that is earlier than Telemetry Server 2020 R2
are exempt from requiring valid client certificates and can still communicate with a server that has
been updated to require client certificates.

SSL Certificates for Driver Communications
WARNING
We strongly recommend using network-connected Telemetry Server drivers in a private

network only (either physical or virtual). We recommend against using such drivers for
communications over the public Internet. If the drivers are used over the public Internet, as a
minimum those drivers should use valid SSL certificates to initiate secure connections and
encrypt the data that is transmitted over the network.
damage. The breach in system security could expose sensitive data and the leave the
To enable some Telemetry Server drivers to communicate more securely with another device or
application, a valid SSL certificate is required. The certificate is used during the communications
establishment phase to initiate a secure connection between Telemetry Server and the other
device. Once the certificate's credentials have been verified, the communications between
Telemetry Server and the other device or application are encrypted.
If an SSL certificate is required, this is specified in the driver-specific guides. If so, you should
purchase a certificate from a trusted Certificate Authority and store that certificate securely. In order
for Telemetry Server to use the certificate, you need to import that certificate into the Telemetry
Server database. To do this, you need to:
1. Create a suitable SSL Certificate database item. Choose whichever type of database item
suits the required security setup:
l SSL Certificate—Used to import a public certificate into the database. The driver can
use this type of certificate to verify that the device or application to which it is connecting
has a trusted certificate.
l SSL Certificate and Key—Used to import a private certificate and matching private key
into the database. This type of certificate enables the server to which Telemetry Server is
connecting to verify Telemetry Server's identity.
SSL Certificate database items are available from the Security branch of the Create New
menu. The configuration Forms of the database items merely contain tabs of properties that
are common to many database items.
2. Use the SSL Certificate database item to import and store the SSL certificate details in the
database (see Import an SSL Certificate into the Database).
3. Reference the SSL Certificate database item from the relevant driver-specific item. This type of
database item varies per driver (see the driver-specific guide for details).

With a multi-server system that provides redundancy, you only need to import an SSL certificate into
the database once; thereafter the imported certificate details are synchronized between the main
and standby servers.
NOTE: SSL certificates are referred to as 'digital certificates' in some third-party documentation.
NOTICE
LOSS OF COMMUNICATION
If Telemetry Server is unable to establish a network connection with a device that uses an SSL
certificate, check that the certificate is valid, has not expired, and has not been revoked. Perform
these checks in addition to those that you would otherwise perform if Telemetry Server is unable
to establish a connection with a device.
Failure to follow these instructions can result in loss of communications between

Telemetry Server and the network-connected device.

Import an SSL Certificate into the Database
WARNING
We strongly recommend using network-connected Telemetry Server drivers in a private

network only (either physical or virtual). We recommend against using such drivers for
communications over the public Internet. If the drivers are used over the public Internet, as a
minimum those drivers should use valid SSL certificates to initiate secure connections and
encrypt the data that is transmitted over the network.
damage. The breach in system security could expose sensitive data and the leave the
In order for Telemetry Server to use an SSL certificate, you have to import that certificate into the
database. To do this, you use the Import Certificate pick action on the relevant SSL Certificate
database item (the database item that is used to store the certificate details). The dialog box that is
displayed when you select the pick action varies, depending on the type of SSL Certificate database
item:
Import Certificate (SSL Certificate database item)
l Certificate File Name—Use the browse button to display a File Name window. Use the
window to locate and select the SSL certificate that you want to import into the database.
l Certificate Description—Enter a brief description of the certificate. Use the description to
differentiate between the various SSL certificates that might be imported into the Telemetry
Server database.
Import Certificate (SSL Certificate and Key database item)

l Certificate File Name—Use the browse button to display a File Name window. Use the
window to locate and select the SSL certificate that you want to import into the database.
l Key File Name—Use the browse button to display a File Name window. Use the window to
locate and select the private key that you want to import into the database.
l Certificate Description—Enter a brief description of the certificate. Use the description to
differentiate between the various SSL certificates that might be imported into the Telemetry
Server database.
l Passphrase—Enter the passphrase that was used to encrypt the private key.
NOTICE
LOSS OF COMMUNICATION
If Telemetry Server is unable to establish a network connection with a device that uses an SSL
certificate, check that the certificate is valid, has not expired, and has not been revoked. Perform
these checks in addition to those that you would otherwise perform if Telemetry Server is unable
to establish a connection with a device.
Failure to follow these instructions can result in loss of communications between

Telemetry Server and the network-connected device.

Server Tools - Security
Telemetry Server has a Server Configuration Tool and a Server Status Tool that you can use to set
up and monitor your system servers. Telemetry Server's security features help to protect these
server tools against unauthorized access.
To access the Server Configuration Tool and Server Status Tool, you need to log on via a user
account that has the System Admin permission for the System item ($Root Group). When you first
install Telemetry Server, the built-in Super User has the System Admin permission. As you
configure your system, we recommend that you create user accounts for your system, and allocate
the System Admin permission to one or more of them. You can then remove the Super User.
Check that the Telemetry Server Guest user has appropriate permissions, or none at all if possible.

Enable and Manage the Client Access Control List
The Client Access Control List (CACL) allows you to define a list of client IP addresses that have
authorized entry to your Telemetry Server. You can restrict the clients that are authorized to access
the Telemetry Server using the Client Access Control List (CACL) to define an IP address or
IP Range to identify the clients that have access to the database.
NOTE: The CACL is an additional security feature and distinct from the Access Control List
(ACL) that is used to define the permissions for each object within the database.

Set the Security Strength
ATTENTION: The password settings mentioned in this topic only apply to user accounts that are
managed directly in Telemetry Server. With user accounts that are associated with Windows or
LDAP User Profiles, password management is performed via the relevant Windows domain or
LDAP server.
Telemetry Server has settings that enable you to enforce user account security. You can set the
minimum password length, the number of permitted password entry attempts, whether users can
change their own passwords, and so on.
To help protect your system from unauthorized use, we recommend that you change these settings
to suit your security needs. However, you should first consider the implications. You can make your
system more secure from unauthorized access, but user accounts may need more management.
You may need to change passwords more frequently, and there is a chance that users will then
forget their login details (especially if passwords have to include letters and numbers).
Account Disable and Lockout

We recommend that you consider the implications of failed logins to your system.
Failed password attempts can arise from user action or applications accidentally or maliciously
attempting to log in with incorrect passwords. In the System Configuration tool, you can change the
number of failed password attempts before a user account is disabled.
You can temporarily lock out accounts if multiple password attempts are made in a limited time. You
use this feature to avoid the account being permanently disabled. However, be aware that if a
legitimate user makes repeated login attempts with incorrect passwords, Telemetry Server may
deny them access.
A further feature available from this version is login ‘throttling’ which will slow the login process if it
has failed for a set number of attempts. This feature will not block logins to an account but will help
prevent actors from attempting to use multiple guesses on a password, by restricting the frequency
at which login attempts can be made.
We recommend that you consider whether account disable or lockout is appropriate for your
system, and whether you use the login throttling feature.
When you install Telemetry Server it will, by default, disable account disable and lockout, and will
enable login throttling.
NOTE: There is a client access control list that you should use to prevent attempted login from
clients not designated for login.

Use Server Side Permission Restrictions
You use the Permission Restrictions section of the Server Configuration Tool as a means of
restricting access to the system on a per server basis. You can then restrict access to other features
and/or database items on a per User Group, or individual User, basis, if required.
You use the Permission Restrictions settings to deny certain permissions at one of four different
levels:
l Server Denied Permissions—To deny access to features from every Configurator client that
is connected to the server. The settings also apply to other types of client that are connected to
the server, such as OPC or ODBC clients, or the Automation Interface.
l Configurator User Denied Permissions—To deny access to features from every
Configurator client that is connected to the server.
l Standard Pick Menu Denied Permissions—To deny access to specific options on the
standard context-sensitive pick action menus that are available on Configurator clients that are
connected to the server. (The pick action menus are also referred to as 'Object menus'.)
By restricting access to permissions on a server-wide basis in this way, you can make your system
more secure by limiting which features are available to clients that connect to Telemetry Server via
specific server(s).
Example:
You may decide that you want your users to be able to issue a control when they log on via
Configurator. To enforce this, you would clear the Control check box in the Configurator User
Denied Permissions settings.
To use the server side permission restrictions effectively, you need to consider the working
procedures of your operators, engineers and administrators. Taking into account their expected
duties, you can restrict their access so that when they log on they can only access the features they
need.
By default on new installations, four permissions are restricted via the Server Denied
Permissions section of the tool (Unacknowledge Alarms, Assign Alarm Responsibility, Off/On
Scan, and Cancel Request). Depending on the role of the installed server, these and other
restrictions may, or may not, be appropriate. We recommend that you assess which permission
restrictions are appropriate for each server, based on its role in your system and the system's
operational requirements, and then configure the required restrictions accordingly.
NOTE: Remember that the settings that you apply using the Server Configuration Tool only apply
to the server on which you have configured those settings. On a multi-server system, you also
need to apply similar settings to the other servers on the system (taking into account the different
roles of those servers, and your system's operational requirements).

Password Policy
When a new user account is created it is allocated a randomly generated password that needs to be
reset by the System Administrator before the account can be used by the user. This includes user
accounts that are created when database objects are imported via an ‘sde’ file.
We recommend using the Pre-expired check box in the User configuration to define whether the
user of this account is prompted to create a new password the first time they log on via this account.
If you select the Pre-expired check box, the user will be prompted to create a new password; if you
leave the Pre-expired check box clear, the user will not be prompted to create a new password
when they log on, and they will have to use the password defined in the configuration of the user
account.

Organize your Users and User Groups
As User accounts, User Groups, and (if applicable) User Patterns are a key element of Telemetry
Server security, it is important that you try to protect them from unauthorized use. By restricting
access to the individual User Accounts, User Groups and User Patterns, you reduce the chance of
a user being able to change the access permissions of their own user account or that of other
system users.
We recommend that you store your User Accounts, User Groups, and User Patterns in a single
Telemetry Server Group folder. You can then configure the security settings for the Group folder so
that the folder and its contents can only be accessed by a select few members of staff.
NOTICE
SECURITY THREAT
On systems on which Telemetry Server can Create users automatically from group
membership, the incorrect assignment of security permissions on User Patterns and User
Groups can compromise the security of the system. Always restrict the security permissions that
are allocated to User Patterns, and to User Groups that are integrated with Windows domain
groups or LDAP user groups. Only assign those permissions that are actually required, to help
prevent the automatic creation of new user accounts that allow Windows or LDAP users to
perform high-level tasks, such as shutting down the server.
Failure to follow these instructions can result in equipment damage.

NOTICE
SECURITY THREAT
On systems on which the 'Everyone' 'Everyone' User Group is enabled, all User Accounts on
the system automatically inherit the security permissions that are assigned to the 'Everyone'
User Group, including the Guest user (which does not require a logon). Each user's security
permissions comprise: Everyone permissions + User Group permissions + User Account
permissions. To help avoid providing all users with unintended access to features and
functionality that should be restricted, use configured User Groups configured User Groups
rather than the 'Everyone' User Group. If the 'Everyone' User Group has to be used, it MUST be
assigned the minimum permissions required, with access restricted where possible to just the
relevant parts of the database. (On new installations, the built-in 'Everyone' User Group is
inactive and is not assigned any security permissions by default.)
Failure to follow these instructions can result in equipment damage and a breach in
system security.

Configure User Accounts Appropriately
Telemetry Server's security feature can act as an effective security tool, helping to protect your
system from being accessed by unauthorized users. But its effectiveness is dependent on the
appropriate configuration of user accounts.
For more effective security, you should configure the settings for each user account so that they only
provide the required access. Ideally, you should configure a user account so that it only allows the
user of that account to access the features and items they need to perform their expected duties.
For security purposes, the settings you should pay particular attention to are:
Access Type
Allows you to define whether the user can access Telemetry Server via Configurator
User Group
Allows you to associate a user account with one or more User Groups. The user
account will have its own permissions plus those that are allocated to the User Group
(s).
With user accounts that are integrated with Windows or LDAP user accounts, a
user's User Group membership is updated automatically at log in (for those
Telemetry Server User Groups that are integrated with Windows domain groups or
LDAP user groups).
Operational
The Operational settings on the Configurator tab—You can use the check boxes
to control which operator level features are available to the user.
Configuration
The Configuration settings on the Configurator tab—You can use the check
boxes to control which configuration features are available to the user.
Explorer Bars
The Explorer Bars settings on the Configurator tab—You can use the check
boxes to control which Explorer Bars (navigation hierarchies, such as the Database
Bar) are available to the user.
The user-specific security settings that are on the Security tab (only available if the
Allow per User option is enabled at the server, and the user accounts are managed
directly in Telemetry Server, rather than via the Windows User Authentication
feature). You can use the Security settings to define the password length, password
strength, password expiry, and so on, for the user account.
NOTE: External authentication using Windows Active Directory or LDAP extends the capability
of Telemetry Server by transferring password and optionally user account management to an
external system.

NOTICE
SECURITY THREAT
On systems on which the 'Everyone' 'Everyone' User Group is enabled, all User Accounts on
the system automatically inherit the security permissions that are assigned to the 'Everyone'
User Group, including the Guest user (which does not require a logon). Each user's security
permissions comprise: Everyone permissions + User Group permissions + User Account
permissions. To help avoid providing all users with unintended access to features and
functionality that should be restricted, use configured User Groups configured User Groups
rather than the 'Everyone' User Group. If the 'Everyone' User Group has to be used, it MUST be
assigned the minimum permissions required, with access restricted where possible to just the
relevant parts of the database. (On new installations, the built-in 'Everyone' User Group is
inactive and is not assigned any security permissions by default.)
Failure to follow these instructions can result in equipment damage and a breach in
system security.

Guest User Account and Everyone User Group
The Guest user account is a built-in user account built-in user account. It is used whenever a user
accesses Telemetry Server via Configurator, OPC, or Automation without logging on. By default,
the Guest user has no permissions set and immediately after a new installation you can only log on
to the system using the Super User account Super User account. You can then change the
permissions of the Guest user at a later stage (but only if it is genuinely required to provide
necessary access without logging on).
Telemetry Server has a single built-in User Group named Everyone. Every user account that is
created is automatically associated with the 'Everyone' User Group, including the Guest user (which
does not require a logon). On new installations, the 'Everyone' User Group is inactive and is not
assigned any security permissions by default.
The Guest user account and Everyone user group should not be used. Instead, you should add
'configured' User Accounts and User Groups to the system and grant them the relevant security
access and privileges. This provides greater flexibility and control over the functionality and features
to which individual users, or groups of users, have access.
NOTE: Some third-party applications such as OPC clients that do not support 'OPC Private
Security' will need to use the Guest user to access Telemetry Server. They require the Guest user
account to have at least the Read permission so that they can access system data. This
permission can be applied just to the objects which the application needs to read.

Disable the Super User Account
During the installation process, you are presented with the option of setting up a Super User
account. Designed to be used when incorrect security configuration stops users from accessing the
system, the Super User account has access to every database item and feature.
While the Super User account can be useful, it does pose a security risk to your system - if an
unauthorized user were to discover the user name and password for the Super User, they would
have access to your entire system. For this reason, we recommend that once your system has been
set up and is running, you disable the Super User account.
NOTE: If a user encounters difficulties when trying to access the system at a later date, the Super
User can be enabled again and used to alter the security settings. To do this the installation kit
needs to be re-run on the server node. A further use is that it may also be necessary to use the
Super User account to correct the security settings for imported groups which had their own
security settings and refer to users not present in the database.
To disable the Super User account, you can use the Change Super-User dialog box.

© 2021 AVEVA GROUP PLC AND ITS SUBSIDIARIES. ALL RIGHTS RESERVED.
AVEVA, THE AVEVA LOGOS AND AVEVA PRODUCT NAMES ARE TRADEMARKS OR REGISTERED
TRADEMARKS OF AVEVA GROUP PLC OR ITS SUBSIDIARIES IN THE UNITED
KINGDOM AND OTHER COUNTRIES. OTHER BRANDS AND PRODUCTS NAMES
ARE THE TRADEMARKS OF THEIR RESPECTIVE COMPANIES.
AVEVA
HIGH CROSS MADINGLEY ROAD
CAMBRIDGE CB3 0HB
TEL +44 (0)1223 556655
FAX +44 (0)1223 556666
AVEVA.COM

Security Hardening Guide

Uploaded by

Copyright:

Available Formats

Security Hardening Guide

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Security Hardening Guide

Uploaded by

Copyright:

Available Formats

AVEVA Telemetry Server Communication

AVEVA Solutions Limited

©2022 AVEVA Group Plc. All Rights Reserved.

Publication date: 1/7/2022

AVEVA Group plc

Documentation Revision Version: 6.84

AVEVA Telemetry Server Communication Drivers (Version 6.84) • Page ii

©2022 AVEVA Group Plc. All Rights Reserved.

Page iii • AVEVA Telemetry Server Communication Drivers (Version 6.84)

AVEVA Telemetry Server Communication Drivers (Version 6.84) • Page 1

Page 2 • AVEVA Telemetry Server Communication Drivers (Version 6.84)

AVEVA Telemetry Server Communication Drivers (Version 6.84) • Page 3

Page 4 • AVEVA Telemetry Server Communication Drivers (Version 6.84)

l Hardware BIOS configuration.

AVEVA Telemetry Server Communication Drivers (Version 6.84) • Page 5

NOTE: If the server hardware is using a Virtual environment (such as VMWare

Boot Sequence Retry

Page 6 • AVEVA Telemetry Server Communication Drivers (Version 6.84)

BIOS Configuration Password Access

AVEVA Telemetry Server Communication Drivers (Version 6.84) • Page 7

Although an ESM is a recommended tool it is also a potential security vulnerability. To configure an

Operating System Pass-through

If this option exists, it is recommended to disable this feature.

Page 8 • AVEVA Telemetry Server Communication Drivers (Version 6.84)

l Roles and Features

AVEVA Telemetry Server Communication Drivers (Version 6.84) • Page 9

Page 10 • AVEVA Telemetry Server Communication Drivers (Version 6.84)

Using VMWare or Hyper-V

Additional information is available from the following link:

AVEVA Telemetry Server Communication Drivers (Version 6.84) • Page 11

Formulate a "back out" plan

Use a local WSUS server

Page 12 • AVEVA Telemetry Server Communication Drivers (Version 6.84)

AVEVA Telemetry Server Communication Drivers (Version 6.84) • Page 13

Page 14 • AVEVA Telemetry Server Communication Drivers (Version 6.84)

AVEVA Telemetry Server Communication Drivers (Version 6.84) • Page 15

Page 16 • AVEVA Telemetry Server Communication Drivers (Version 6.84)

AVEVA Telemetry Server Communication Drivers (Version 6.84) • Page 17

Page 18 • AVEVA Telemetry Server Communication Drivers (Version 6.84)

Network Adapter Configuration

l QOS Packet Scheduler

To enable admin shares, apply the following value:

Access the application registry at:

AVEVA Telemetry Server Communication Drivers (Version 6.84) • Page 19

Page 20 • AVEVA Telemetry Server Communication Drivers (Version 6.84)

AVEVA Telemetry Server Communication Drivers (Version 6.84) • Page 21

Some considerations are below.

l Restricted desktop by means of:

Page 22 • AVEVA Telemetry Server Communication Drivers (Version 6.84)

Name Caption State StartMode

AVEVA Telemetry Server Communication Drivers (Version 6.84) • Page 23

Page 24 • AVEVA Telemetry Server Communication Drivers (Version 6.84)

AVEVA Telemetry Server Communication Drivers (Version 6.84) • Page 25

Page 26 • AVEVA Telemetry Server Communication Drivers (Version 6.84)

wmic service get name,displayname,pathname,startmode |findstr /i

AVEVA Telemetry Server Communication Drivers (Version 6.84) • Page 27

Page 28 • AVEVA Telemetry Server Communication Drivers (Version 6.84)

Telemetry Server Security

AVEVA Telemetry Server Communication Drivers (Version 6.84) • Page 29