1 Introduction

This document provides guidance information necessary to install, commission, verify and maintain the cybersecurity certified capability of VTScada in accordance with applicable IEC 62443 cybersecurity standards.

In addition, it provides guidance relative to other referenced documents for the benefit of integrators and end users.

The content of this security manual is intended to assist the end user as to what threat vectors may need to have mitigations implemented and managed by the persons responsible for the deployed system security and provides installation and commissioning information to aid in the creation of a secure system.

1.1 Product Support

Product support can be obtained from Trihedral Engineering Limited. Visit our website at https://vtscada.com for further information.

1.2 Referenced Documents

[IEC 62443-2-1]	IEC 62443-2-1 Establishing an industrial control system security program
[IEC 62443-3-2]	IEC 62443-3-2 Security risk assessment for system design
[IEC 62443-3-3]	IEC 62443-3-3 System security requirements and security levels
[NIST 800-63B]	NIST Special publication 800-63B, Digital Identity Guidelines

1.3 Acronyms / Abbreviations

AD	Active Directory
API	Application Programming Interface
DMZ	Demilitarized Zone
MFA	Multi-factor Authentication
VAM	VTScada Application Manager
WSI	Windows Security Integration
MITM	Man in the Middle attack
PKCE	Proof key for code exchange

1.4 Terms

Conduit	a) Logical grouping of communication assets that protects the security of the channels it contains. b) Logical grouping of communication channels, between connecting two or more zones that share common security requirements. Note: Conduits are analogous to the way that a physical conduit protects cables from physical damage.
Firewall	a) Inter-network connection device that restricts data communication traffic between two connected networks. b) Hardware device or software package that provides filtering and/or provision of rules to allow or deny specific types of network traffic to flow between internal and external networks. Note: A firewall may be either an application installed on a general-purpose computer or a dedicated platform (appliance) that forwards or rejects/drops packets on a network. Typically, firewalls are used to define zone borders. Firewalls generally have rules restricting which ports are open.
Threat	a) Potential for violation of security, which exists when there is a circumstance, capability, action or event that could breach security and cause harm. b) Circumstance or event with the potential to adversely affect organizational operations (e.g., mission, functions, reputation), organizational assets, IACS, or personnel via means contrary to security policy, intentionally or unintentionally cause the destruction, disclosure, modification of data, control logic, SCAI logic, and/or denial of service.
Threat Agent	Method(s), individual(s) or organization(s) that could breach the security of a facility, operation or system by exploiting a vulnerability.
Threat Vector	Path or means by which a threat agent can gain access to an asset resulting in a negative outcome.
Vulnerability	a) Flaw or weakness in a system’s design, implementation, or operation and management that could be exploited to violate the system’s integrity or security policy. b) Weakness in an IACS function, procedure, internal control or implementation that could be exploited or triggered by a threat source, either intentionally designed into computer components (e.g., remote port access) or accidentally inserted at any time during the lifecycle.
Zone	A grouping of logical or physical assets that share common security requirements.

2 VTScada Description and Scope

VTScada and its components have been reviewed for their security capabilities, as described in this section. The extent of the certification scope is shown in the boundary diagram below.

This Security Guidelines Manual is intended to assist the end user as to what threat vectors are addressed by VTScada. This information allows the end user to determine what additional means of protection may need to be implemented and managed.

Providing an appropriate security level for the system as a whole is the responsibility of the end user.

2.1 Example Deployment

The following diagram shows one example of how VTScada might be installed in a network environment and will be referred to for illustrative purposes.

Note that this is not a design for your system. It is reproduced purely to illustrate an approach recommended by the IEC 62443 standard.

This example shows the practice of partitioning the control system into “Zones”, interconnected by “Conduits”. The numbers in parentheses for each zone map to the various levels of the Purdue model.

Viewing your control system in this manner helps you focus on the security of the conduits to prevent unwanted intrusion and assist in separation of equipment into appropriate zones.

The concepts of Zones and Conduits and the process for assessing these for system design is covered in [IEC 62443-3-2]. The reader is referred to that standard for the proper assessment of the security of a system under construction. This section provides a simple overview of some basic concepts to aid in reading the remainder of this document.

Within a zone, devices have the same common security requirements and trust each other to some degree but do not trust devices in other zones. The conduits between the zones provide trust between interconnected zones by providing isolation, regulating network traffic between the zones and providing network traffic monitoring points.

2.1.1 Plant Zones

The Plant Zone networks are connected via a firewall or router to provide redundant access to the plant I/O and to distribute data acquired from the I/O in one zone to other zones.

Note that, in this diagram, the Plant Zones contain the I/O devices as well as their controllers. It is often the case that RTUs/PLCs are not local to the SCADA Zone equipment but located some distance away. In such cases, you should regard the RTUs/PLCs as being in their own zone with dedicated conduits to the SCADA Zone that protect data communication.

Even in cases where the RTUs/PLCs are local to the SCADA Zone, the conduit to the Plant Zone should be protected and monitored for unexpected communication that might indicate a security breach. The conduits to the Plant Zones are tightly regulated to strictly limit the network traffic to that which is necessary.

You should also consider what physical security should be provided for your Plant Zones, for example card swipes or keypads controlling access doors.

2.1.2 SCADA Zones

The SCADA Zones contain your primary VTScada systems. Often these systems consist of a pair of redundant VTScada servers or multiple VTScada servers configured as a distributed, multi-way redundant system.

Remote sites, usually with their own Plant Zones, have their SCADA Zones connected to other SCADA Zones via a VPN, providing secure communication and a network traffic monitoring point.

You should consider what physical security should be provided for your SCADA Zones.

2.1.3 Control Zone

The Control Zone contains devices used for the maintenance and sometimes operation of the control system. Ingress and egress are protected by a firewall that permits access to the SCADA zone and other zones as necessary.

Note there is no connection to higher numbered zones other than via a firewall and the Plant DMZ.

2.1.4 Plant DMZ

The Plant DMZ contains servers that provide isolation of lower-numbered zones from higher numbered zones.

The Plant DMZ may contain servers for monitoring, network flow and external device gateways.

A jump server is typically used to provide an authentication and authorization point for access to the lower numbered zones from the Enterprise and DMZ Zones.

A Data Diode may be used to provide a one-way flow of data from the SCADA Zones to Internet-facing servers in the DMZ. In conjunction with a firewall this provides network monitoring and protection against a compromised DMZ server or Enterprise Zone device.

2.1.5 Enterprise Zone

This consists of non-control system devices, such as office desktops and laptops where control system data and reports, often exported from the SCADA or Control Zones to enterprise servers, may be viewed and analyzed.

2.1.6 DMZ

In our example, the DMZ contains a VTScada “Thin Client Server”. This is a server that contains a shadow copy of the control system data, populated by servers in the Plant DMZ, providing access to remote clients.

To penetrate the Control, SCADA or Plant Zones from the Internet or Enterprise Zones is therefore guarded by multiple layers of defense. At least 2 layers of firewall prevent direct access and active network monitoring for suspicious communication is facilitated by having conduits.

2.2 Defense In Depth

Although VTScada is developed using multi-layered secure design principles, security extends to the deployment of a product such that multiple layers of defense are provided in a deployed system so that if one layer is compromised, further layers continue to afford system protection against an actor attempting to infiltrate the system further.

These layers may take the form of physical controls (e.g., controlling access to equipment), technical controls (e.g., encryption, authentication) or administrative controls (e.g., audit logs and monitoring). Each layer plays its part in the overall security of the system to protect against threats.

It is the responsibility of the end-user to properly assess the threats present in the deployed system, determine what security controls are necessary and mitigate those threats. This is a continual process as the threat landscape is not static.

The security capabilities of VTScada are identified in this document to assist in the assessment of security capabilities, threats and mitigations to help achieve a secure system design.

3 Installation Environment

3.1 Host Device Requirements

Correct configuration and maintenance of the host device is an end-user responsibility. Where such operations affect VTScada, they are described above.

3.2 Thin Client Device Requirements

Correct configuration and maintenance of the thin client device is an end-user responsibility, especially when the user chooses to use the Stay Signed In option for Anywhere Clients.

3.3 Network Device Requirements

Correct configuration and maintenance of networking devices is an end-user responsibility. Where such operations affect VTScada, they are described above.

3.4 Protection from Malicious Code

VTScada is compatible with most antivirus and antimalware protection systems. It is an end-user responsibility to verify that VTScada is compatible with the chosen antimalware system. Anti-virus Protection lists exclusions and other considerations that should be observed.

3.5 Threats Requiring User Mitigation

Trihedral maintains threat models that identify specific threats to VTScada along with measures for mitigation. Many of these threats are mitigated at the product level and do not require further mitigation.

The following table lists possible threats where the end-user must address mitigation on their own through some means external to VTScada.

Subsystem/Threat Name	Category	Description
Multiple CRASH	Denial of Service	VTScada supports redundant computers and distributed systems. Loss of one computer causes only brief disruption to a properly designed control system. The end user is encouraged to ensure that each VTScada service is distributed to at least one other computer to reduce potential impact.
Multiple INTERRUPTION	Denial of Service	The end user is responsible for ensuring the system is partitioned into zones and the ingress to the networks contained in those zones is properly regulated to mitigate interruption of data flowing across a trust boundary. Redundant servers are recommended to further mitigate this threat. Fallback connection URLs may be required for thin clients.
Networking TCPFLOOD UDPFLOOD	Denial of Service	The end user is responsible for providing networking infrastructure monitoring and control to prevent DoS attacks from external actors.
Networking HTTP_SERVER_FLOOD	Denial of Service	The end user is responsible for deploying protection against excessive HTTP requests resulting in backing up of VTScada HTTP server queues.
Networking UDP_PORT_HIJACK	Denial of Service, Tampering, Information Disclosure	The end user is responsible for ensuring only trusted software is installed on computers running VTScada. For Plant Zone devices using a UDP protocol a badly behaved process could prevent use of a UDP port or tamper with UDP datagrams.
Multiple INPUT_SNIFFING	Information Disclosure	The end user is responsible for ensuring only trusted software is installed on computers running VTScada. Badly behaved software could sniff keyboard or other input to gain unauthorized access.
Multiple FILESYSTEM_ACCESS	Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service	The end user must provide strict control over file system access on control system computers. Run VTScada in an operating system user account that has only the necessary privileges. When not running VTScada as a service, it is recommended that kiosk mode be used to prevent other uses of the computer.
Repository REPO_SPACE	Denial of Service	There is no inbuilt feature to monitor disk space and react to its depletion. End-user monitoring of disk space is recommended.
Repository CHANGESET_INFODISC	Information Disclosure	Credentials inside changesets are encrypted. Other information is not confidential to anyone who gets possession of the changeset. The end-user must handle off-machine changesets securely. This includes using public key cryptography when transmitting a changeset and use of encrypted media.
I/O Device Drivers	Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service	Communication between VTScada and I/O devices must only be conducted over secure networks unless the driver protocol has support for secure communication. Where possible use encryption, packet signing and authentication to provide the highest degree of protection. The end-user is responsible for the management of certificates and other security items.
Driver Discovery PORT_ACCESS	Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service	Communication between VTScada and I/O devices must only be conducted over secure networks unless the driver protocol has support for secure communication. Where possible use encryption, packet signing and authentication to provide the highest degree of protection. The end-user is responsible for the management of certificates and other security items. Firewall settings may need to be temporarily adjusted to allow for the sending and receiving of broadcast messages used in the discovery process.
Driver Discovery BROADCAST_LIMIT	Information Disclosure, Spoofing	Request messages could be captured by external devices. The end user must set a proper broadcast address while discovering devices to keep the system safe.
HTTP Server FILE_SPOOF, FILE_INFODISC	Spoofing, Information Disclosure	The end-user is responsible for securing a VTScada server’s file system to prevent unauthorized users tampering with VTScada application files made available via the HTTP protocol. See also FILESYSTEM_ACCESS.
OPC OPC_SPOOFING	Spoofing	The end-user is responsible for configuring DCOM security to restrict access to only trusted users with trusted applications.
OPC OPC_THROTTLING	Denial of Service	OPC Clients must be controlled/tested to the extent that their requests will not overwhelm the system.
OAuth 2.0 TAMPERING, MITM	Tampering, Man in the Middle, Information Disclosure	The end-user is responsible for correctly configuring a certificate for TLS connections with external OAuth providers to protect data confidentiality. This is required along with the implementation of PKCE within the OAuth 2.0 provider to ensure data integrity during consent operations.
RPC IMPERSONATION	Spoofing, Tampering, Information Disclosure, Denial of Service	The end-user is responsible for ensuring VTScada has access to a secure, correctly configured DNS server.
RPC MACHINE_SPOOFING	Spoofing	The end-user is responsible for maintaining a whitelist of computers permitted to connect to each VTScada server.
RPC CONNECTION_INTERRUPTION	Denial of Service	Temporary interruptions are tolerated and recovered by VTScada. Persistent interruptions can be alarmed. The end-user is responsible for ensuring that communication health alarms are properly configured.
RPC SNIFFING	Information Disclosure	Data flowing between VTScada computers may be sniffed by an attacker. The end-user is responsible for securing the network to prevent this. Where VTScada RPC crosses a trust boundary, the end-user must ensure the security of the connection.
RPC TAMPERING	Tampering, Denial of Service	Data flowing between VTScada computers may be tampered with by an attacker. The end-user is responsible for securing the network to prevent this. Where VTScada RPC crosses a trust boundary, the end-user must ensure the security of the connection.
HTTP Client REMOTE_SERVER_SPOOFING	Spoofing	The HTTP server the VTScada HTTP client communicates with may be spoofed. The end user is responsible for securing the relevant network infrastructure to prevent this where spoofing would present a threat.
VOIP PJSIP_SIP_TAMPER PJSIP_RTP_TAMPER	Tampering, Denial of Service	Data flowing between VTScada computers and a VOIP adapter may be tampered with by an attacker. SIPS should be configured when possible. If use of SIPS is not possible, communications should only be conducted over a secured network.
VOIP PJSIP_SIP_IM_TAMPER	Tampering, Information Disclosure	Instant messages sent over SIP are vulnerable to tampering and redirection by untrusted proxies. All VOIP proxies in use should be trusted to appropriately protect the contents of a SIP instant message.
Embedded Browser CROSS_ORIGIN_THREATS	All	The content from different hosts and ports are allowed to be loaded in the embedded browser on the Anywhere Client. The end-user is responsible for configuring the external link safely to avoid malicious flows and contents.
SNMP Driver DEVICE_HEALTH	Denial of Service	The SNMP Driver communicates with customer devices for SNMP interactions. It is the end-user’s responsibility to ensure that the SNMP router or other devices remain available and function as expected.

4 Legacy Code Security

VTScada has been developed over many years and, as such, contains code that was produced before the adoption of modern security considerations. As a result of continuous development, the code within VTScada is constantly being analyzed and revised in accordance with our security practices.

Additionally, third party software used by VTScada is periodically reviewed and updates made as required to address any vulnerabilities.

There are no mitigations that need to implemented to address legacy code within VTScada.

5 Installation and Configuration

Installation should be performed as per the VTScada help. This section provides guidance on configuring VTScada and your VTScada applications.

For detailed instructions on configuring VTScada, refer to the help provided with VTScada.

5.1 Installation of Trihedral TSP and Modem Audio driver

The Trihedral TSP driver runs at the kernel level and is not compatible with core isolation. This driver should only be installed when necessary for use with a modem. Uninstallation instructions can be found in the VTScada help files.

5.2 Execution Environment

VTScada can be run as an interactive application or as a service.

Interactive application mode can be used during system configuration development as a natural way to run an application and providing direct access to the user interface presented by the application under development as well as the tools and utilities used during development.

For deployed systems configured to run as an interactive application, Trihedral recommends the use of “kiosk-mode” (see the VTScada Help for further information) to prevent execution of programs other than those directly accessible through the user interface configured for the deployed system.

When installed as a service, the VTScada application(s) are configured to auto-start on operating system boot and is generally used for unattended or headless server systems. Here the user interface of the control system is accessed from other systems using a VTScada thin client, thereby preventing unauthorized application execution directly on the deployed system.

5.3 Operating System Account

When VTScada is run as an interactive application it will run with the authority and permissions of the user account that launches VTScada. When run as a service it will run under the user account configured during VTScada service installation. You can modify this after installation - see the VTScada help for further information.

The user account selected for interactive operation should be a minimally privileged account, i.e., it should have no administrative rights whatsoever on either the local computer or domain. Access to external resources required for control system operation, such as access to an external database, should be configured for that user account.

The same, least privileged user account should be used for service operation (i.e., VTScada runs as a service), so that any interactive modification required is performed using the same account. In the case of a service, the user account also needs the “Run as a service” privilege to be granted by an administrator.

The only time administrative rights are required are during the installation of VTScada. After installation it may be necessary to adjust operating system Access Control Lists (ACLs) for the user account that will run VTScada to permit read/write access to the installation folder.

5.3.1 File System Permissions

VTScada requires the following file system locations to be readable or writable, post installation:

File System Location	R/W	Notes
%PROGRAMFILES%\Trihedral	Read only	This is where the VTScada executable binary images are installed. This should be strictly read-only without elevated privilege to all users.
VTScada Installation Folder	Read/Write	This is where the run-time and configuration files for VTScada are located. By default, this is C:\VTScada.
OEM and end-user application files	Read/Write	This is where additional OEM layers and applications are stored. By default, these are stored subordinate to the VTScada installation folder.
Historical Data	Read/Write	This is where per-application historical data files are stored. This can be in the application folder or in a separate location.
ProgramDataand all sub-directories and files	Read/Write	This is where dump files generated upon system failure are stored.

5.4 SecurityManager

Configuration of users, their credentials and privileges are handled by VTScada’s SecurityManager. Software processes using a VTScada API, such as the REST interface, are required to provide authentication. Credentials for these APIs is configured by creating one or more user accounts, normally specifically for the API access, in the same manner as a user account used by a human.

Each VTScada application has its own instance of SecurityManager and its own database for user security, providing isolation of user accounts across applications.

The authentication credentials can be housed directly in VTScada. These are persisted on disk in an encrypted form whose cryptographic keys are unique to the application and are synchronized between VTScada servers running the same application. A change to credentials on one server is automatically propagated to the other servers. Passwords are hashed using a cryptographically secure hash and not stored in plain text.

The authentication credentials can also be stored in an Active Directory (AD) domain and Windows Security Integration (WSI) used. In this case authentication is made to AD by VTScada. If AD group policy permits, the host on which VTScada is running will cache AD credentials, permitting authentication when temporarily isolated from the AD domain controllers. AD users are assigned to roles, based on their group membership in the domain. You use VTScada to assign privileges to these roles and AD management tools to control role membership for users and user account enable/disable.

OpenID Connect can be also used as an authentication alternative. Both this and AD authentication (via Smart Cards) can offer Multi-Factor Authentication (MFA) for a higher security level.

5.4.1 Security Options

Security Options are available once the first account has been created. The first account created will have administrative rights to control all aspects of other user accounts.

The number of administrative accounts should be strictly limited and MFA is highly recommended for these accounts.

• Configure Automatic Sign Out. This option automatically logs a user session out after a defined period of inactivity. By default, this is enabled and set to 15 minutes. Assess an appropriate session timeout for your deployment and configure this accordingly.

• Password Strength. By default, password strength is not enforced. We recommend configuring the password strength to meet the current NIST guidelines [NIST 800-63B].

In addition, there are a set of application properties that control rate limiting and account lockout time, triggered on consecutive authentication failures. These are set to default values that can be modified.

5.4.2 Smart Cards

When VTScada uses Windows Security Integration (WSI), it will support smart card readers. Smart cards contain one or more X.509 certificates that can be used to authenticate to the AD domain. This provides MFA by requiring possession of the card and a PIN.

5.4.3 Public Key Infrastructure Certificates

VTScada relies on the operating system security providers to securely store private keys and maintain one or more certificate stores. If the host system supports hardware private key security (for example key wrapping by a Trusted Platform Module) and the operating system is configured to use this, then VTScada will leverage this capability.

VTScada does not provide management of certificates or private keys. This is delegated to the established operating system support tools. Some device drivers (e.g., the OPC UA Client Driver) provide for generation of self-signed certificates and human actions to accept or reject remote device certificates supplied via protocol. There is no automated distribution of certificates and keys.

5.4.4 Security Privileges and Roles

VTScada provides a rich set of security privileges that can be assigned to a user account to control the actions a user is authorized to perform.

A privilege is a fine-grained access control mechanism and these can be grouped into “roles”. A role is best used to define the set of privileges a user needs to perform a specific task. For example, the pre-configured “Operator” role allows some alarm operations, report and historical data access, viewing of equipment graphical pages and the ability to control outputs. An Operator does not need the ability to configure tag parameters, add or delete pages or modify user accounts. These privileges are assigned to other roles.

VTScada comes with a set of pre-configured roles that contain the set of least privileges for that role in a typical deployment. We recommend you review these roles, modify them as appropriate and create a set of roles that are appropriate to your organization and system deployment.

In doing so, it is usually better to have a larger number of roles so that you can assign responsibilities using the principle of least privilege. In other words, a user only receives the set of privileges required to perform the tasks they need to perform. If a role assigned to that user contains extraneous privileges, then the user will have privileges that may be inappropriate. This principle also reduces the damage potential should an account be compromised.

Additionally, VTScada provides the ability to create your own set of privileges and assign them to various actions, equipment or pages to meet your needs.

Refer to the help documentation provided with VTScada for a description of the default roles and privileges and the permissions they grant.

5.4.5 Master Subordinate application privileges

VTScada support for master-subordinate applications expects the privileges defined within the subordinate application correspond to the equivalently numbered privileges within the master application. It is important that these values are kept consistent to ensure privileges granted to users in the master application do not permit access beyond the expected components within the subordinate application.

5.5 Audit Records

5.5.1 Alarm and Event log

Alarms are exceptional situations, such as a process variable exceeding a configured limit. Events refer to system event-level actions that are recorded, generally for audit purposes, such as user logins or changes to process setpoints, to implement non-repudiation.

Alarms and events are normally retained in 2 separate VTScada Historian databases. A Historian database can be configured to use a VTScada proprietary database system that maintains synchronization between VTScada servers, or to use a third-party database, such as SQLite, SQLServer and others.

The native VTScada event database has been shown to be many times faster than general purpose third-party databases and is live synchronized between VTScada servers configured to do so, providing resilience.

The databases, regardless of provider can be queried using SQL for custom reporting and audit log analysis.

5.5.2 Configuration Repository

The VTScada configuration repository is a per-application version control system that records all configuration changes made to the system and maintains an audit log attributing timestamped changes to the user account that made the change, thereby implementing non-repudiation for configuration changes.

The repository is in a proprietary format and is automatically synchronized between VTScada servers running the same application.

There are no external APIs available for querying the repository audit log, however a repository can be exported and the audit log viewed offline on another VTScada system. Note that transferring a repository must be done securely, as it may contain sensitive information, both commercially sensitive and of use to a potential attacker.

5.6 Networking

The security requirements of networks connected to a VTScada system are governed by the overall system design of zones and conduits. Networks within zones require a level of protection against any threats present in those zones. Inter-Zone networks (conduits) require network appliances that control access to the zones it separates. Particular caution should be made in cases where user connections to the Internet can be made.

5.6.1 VTScada RPC Connections

VTScada communicates with other VTScada systems using a proprietary protocol (the VTScada RPC protocol). The protocol is not proof against tampering and is designed for efficiency and reliability.

Within a zone, any VTScada system can communicate with another VTScada system using VTScada RPC. If there a security requirement to prevent this, the VTScada systems that communicate with each other must be configured to only accept connections from approved machines by configuring a whitelist on each server. Refer to the VTScada help for further detail.

Where anti-tampering or confidentiality is required, additional measures must be taken by the end user, such as enforcing IPSec connections between servers. VTScada will use all available networks when transmitting RPC messages to a remote VTScada server. Any measures taken for securing the communications must be applied to all networks over which VTScada is expected to transmit RPC communications.

5.6.2 I/O Device Connections

Where I/O devices are connected to the control system via networks, measures need to be taken to preserve the availability of the connection and integrity of the data transferred. Loss of field I/O or tampering with the data could have catastrophic consequences.

If the device protocol supports tamper-proof communication this should always be used. If the device supports authentication methods to prevent malicious connection to the device, this should also be used and authentication credentials should be strong.

In the absence of these security measures, the end-user must consider other protection methods, such as using a dedicated, closed network, or interposing network devices to harden the communication.

5.6.3 SQL Connections

VTScada supports several connections that can bear SQL queries and responses.

In cases where requests are handled by an ODBC driver, you must ensure that communication to the external database is secure and that credentials and data are secure.

5.6.3.1 ODBC/REST Interface

Third-party programs can access VTScada tag values via the VTScada ODBC driver. This is installed on the system sourcing the requests and communicates with a VTScada server using HTTP Representational State Transfer (REST) queries.

We recommend the REST interface is secured using a separate VTScada account granting the minimum privileges required. To protect authentication credentials, HTTPS is strongly recommended using a TLS transport layer.

The REST interface can also be used directly. The same recommendations as for REST via the VTScada ODBC driver are made, along with using a custom HTTP header for authentication to prevent browser caching of credentials. See the VTScada help for further information.

5.6.3.2 VTScada SQL Data Query Driver

The VTScada SQL Data Query Driver allows access to an external database and storage of values retrieved from it in VTScada tags via SQL queries. Access to the external database is via a third-party ODBC driver. You must ensure that communication to the external database is secure and that credentials and data are secure.

5.6.3.3 SQL Logger Group

SQL Logger Group tags allow VTScada to store tag values in an external database via SQL queries. Access to the external database is via a third-party ODBC driver. You must ensure that communication to the external database is secure and that credentials and data are secure.

5.6.3.4 External Historian Database

Alarm/event or tag data can be logged to an external database by the VTScada Historian. Access to the external database is via a third-party ODBC driver. You must ensure that communication to the external database is secure and that credentials and data are secure.

5.6.4 SOAP

Simple Object Access Protocol (SOAP) requests to VTScada over HTTP are supported. Authentication credentials can be transferred using HTTP Basic authentication or as part of the SOAP request. Always use HTTPS for SOAP over a TLS transport layer to protect the integrity of credentials.

5.6.5 SNMP Connections

A VTScada application can be a SNMP command generator (traditionally known as a SNMP Manager) and/or a SNMP command receiver (traditionally known as a SNMP Agent).

• The manager role is enabled via a single or multiple instances of the VTScada SNMP Drivers and allows reading from or writing to remote SNMP agents.
• The agent role is enabled via the VTScada SNMP Agent service and allows remote managers to read or set I/O tags values of the VTScada application.

The Driver supports SNMPv1, SNMPv2c, and SNMPv3. The Agent supports SNMPv2c and SNMPv3. Both support read-only and read-write modes. Both support the User Security Model (USM uses symmetric or private-key cryptography) for SNMPv3. The Transport Security Model is not supported. The Agent does not support an access control model in the sense that once a user has access to one object of VTScada’s MIB, he/she would have access to all of the available objects. All objects are under a single context, the default one or the one specified in the configuration SNMPv3AgentContextName.

The inclusion of I/O tags and their properties in the MIB may be controlled by manually manipulating the SNMPAgentTagExposedProperties setting and the MIB internal representation file SNMPAgentConfig.JSON.

SNMPv1 and SNMPv2c have extremely weak security in the form of a weak authentication mechanism using public community strings, and have no privacy. SNMPv3 is the recommended version to use for stronger security as it provides stronger authentication and/or privacy.

For the Driver, the legacy SNMPv3 security configuration (SNMPv3DefaultUserAuthProtocol, SNMPv3DefaultUserPrivProtocol, SNMPv3DefaultUserAuthKey and SNMPv3DefaultUserPrivKey) should not be used in new post-12.1 applications: the credentials are plain text configuration settings and is only kept for backward compatibility with pre-12.1 SNMP applications.

Post-12.1 each driver has its own set of SNMPv3 settings. For notifications received by the drivers, care should be taken since these may change the values of I/O tags: it is recommended to only accept authenticated and encrypted notifications and to allow notifications received by a driver to set data only if it is necessary. It would be better if the I/O tags, expected to be changed by notifications from a certain agent, are attached to a single driver whose “Allow traps to set data” flag is set. All the other drivers connected to the same agent would have that flag unset.

The configuration setting SNMPDriverLegacyV3Notifications should not be set in new post-12.1 applications: this setting allows notifications from any user with credentials to set data and is kept for backward compatibility with pre-12.1 applications.

For the Agent, the configuration setting SNMPAgentWriteEnable may be used to prevent any SetRequest from setting data even from a Read/Write user. The setting SNMPAgentIPListener specifies the name of the SNMPListener tag used to wrap the UDP port on which the Agent listens. This wrapper tag is useful in providing additional enhancement to the security via its IP Allow list.

5.6.6 OPC DA Connections

OPC Data Access (OPC DA) connections have their security, both access rights and authentication, controlled by the Microsoft Distributed COM security. An operating system utility provides the means to configure DCOM security.

5.6.7 SSL/TLS Connections

Versions of TLS prior to TLS 1.2, and all versions of SSL, are now considered deprecated and insufficiently secure. TLS 1.0 and TLS 1.1 were formally deprecated in March 2021 as a result of insurmountable security issues.

We therefore recommend that you configure your VTScada systems to use TLS 1.2 or later. TLS 1.3 is supported by VTScada in 12.1.30 and later when running on Windows 11 or Windows Server 2022. TLS 1.2 is supported by all versions of VTScada on all supported versions of Windows.

We recommend barring the use of TLS 1.1 and earlier by configuring your operating system appropriately to exclude those protocols and weak cipher suites. Consult Microsoft documentation for your operating system for further details.

5.6.8 WebSockets

The current implementation of WebSockets on VTScada uses the HTTP Basic Authentication scheme. To ensure security all WebSocket connection requests must be made using TLS.

A SETUP.INI variable controls the maximum message size received by HTTPServer/WebSockets and has a 16k default. This can be changed by the user. Refer to the VTScada Help for further information.

5.7 X.509 Certificates

Certificates are widely used to: - Verify the identity of a remote entity. - Commonly this is used by the TLS protocol to secure HTTPS connections. Here the purpose is to verify the identity of a remote server. VTScada thin clients should always be used over HTTPS connections so that they use the server-supplied certificate to verify the server’s identity. - Embedded into various device protocols, for example OPC UA. Here certificates are used to mutually verify the identity of the OPC UA client and server - the connection will be refused if the server can’t verify the identity of the client and vice-versa. VTScada supports mutual authentication over any TLS channel. - Protect data in transit (meaning data that is written to somewhere and read by another party - this is usually a network connection but could also be a file or email). Data in transit can be encrypted and signed using the asymmetric keys associated with a certificate or by symmetric keys derived from those. - Verify the identity of a person (as opposed to verifying the identity of a computer). Some protocols, e.g., OPC UA, allow a user account to be identified using a certificate instead of the more traditional username and password. This creates stronger identity verification.

5.7.1 Certificate Stores

Certificates are normally held in a certificate store. In Windows, certificate stores are provided by the operating system and keep certificates safely partitioned into different categories, e.g., Root Certification Authority certificates or User Personal certificates.

Each certificate that needs to be provided to another entity also has a private key stored for it. It is imperative that the private key associated with a certificate is kept securely. If an unauthorized person were to obtain the private key associated with a certificate, they can use them to spoof your identity and fool a browser (or any other software for that matter) into believing that an attacker was actually you.

In Windows there are two types of certificate store - a machine-wide one and user ones. For TLS use, VTScada loads the certificate from the machine-wide store. This has the advantage that to export the private key for your certificate requires privilege elevation. For VTScada to access the private key to use in TLS communication, the user account that runs VTScada must be granted Read access to the private key. This means that anyone who can successfully log in using the same account that VTScada runs under can read (and therefore export) the private key, so it is a good idea to create an account specifically for VTScada, rather than a regular user account.

5.7.2 Certificate Lifetime

Certificates have a lifetime, thereby limiting the window during which a stolen certificate could be used (assuming that the owner did not realize it was stolen). It is therefore important that certificates are renewed in advance of their expiry to prevent certificate usage errors and to discourage users from accepting an expired certificate. Users should be aware that an expired certificate is a security risk and should not be accepted for use.

5.7.3 Cipher Strengths

Over time attack methods against various ciphers become more accomplished to the point where some ciphers are no longer considered sufficiently secure. Such ciphers should be disabled. VTScada requests the operating system to only use strong ciphers on client (outbound) connections. For inbound connections you should disable weak ciphers by configuring the registry manually or by group policy. Refer to the Microsoft website for more details.

5.7.4 Dos and Don’ts

• Educate your users to NEVER accept or ignore a certificate that is expired or whose name recorded on the certificate does not match the server.
• ALWAYS keep your private keys secure. If one is compromised, have the certificate revoked and get a new certificate with a new private key.
• Disable weak ciphers on your system to guard against downgrade attacks.

5.8 Thin Client Servers

Thin client servers require special security consideration. They are the access points for the VTScada Internet Client, VTScada Anywhere Client and VTScada Mobile Client. Often communication between the thin clients and their servers are over untrusted networks, such as the Internet.

Thin client servers run an instance of VTScada whose data is populated from production servers elsewhere in your organization. Remote client applications then connect to the thin client servers using HTTP protocol to retrieve and display this information.

Access to the VTScada application requires authentication as an account with Internet Client Access privilege. Accounts without this privilege are not permitted to connect. As an authenticated user may also have privilege to operate control system outputs or affect other parts of the system, care should be taken to ensure only the privileges needed are granted to user accounts that can remotely access the system.

It is therefore imperative that adequate security countermeasures are employed.

A defense-in-depth approach should be taken, considering the following:

• Thin client servers should be placed in a zone to isolate it from more sensitive zones, for example, a DMZ.

• Access to a thin client server should be protected by at least 2 levels of authentication and authorization, for example, authentication to access the zone and VTScada authentication. If MFA is available, this should be used.

• Thin client servers need to communicate with another server that has a copy of the control system data. This “relay” server should not form a key part of the monitoring and control of the control system, limiting the reach of a compromised thin client server.

• Separate, commercially available intrusion detection mechanisms for thin client servers should be used.

• It should not be possible for a thin client server to open a communication port that crosses the DMZ boundary. Thin client servers should only accept an inbound connection from one or more relay servers located in the trusted network side of the perimeter.

• HTTP communication between the thin client servers and the thin clients must be conducted over a TLS connection (HTTPS) to protect the integrity and confidentiality of the communication.

5.9 Privileged VTScada applications

VTScada is shipped with a set of engineering and utility applications. Certain of these applications require to have additional security measures imposed.

For each of these applications:

• Thin clients can only use the application if it has been placed into one of the pools of remotely accessible applications (realms) using the VTScada Application Manager (VAM). The application therefore should not be placed in a realm.

• On production systems, consider removing these applications from the VAM entirely. For engineering access, the application can be added back into the VAM for the duration of the engineering activity. Access to the VAM is restricted by a privilege that should only be granted to an appropriate user account.

5.9.1 Source Debugger

Anyone who can run the Source Debugger has read/write access to the internals of VTScada and your application. It is therefore imperative that this application is secured against unauthorized use.

5.9.2 Trace Viewer

The Trace Viewer can capture, record and display (either live or offline) inter-VTScada system communication (RPC) and driver communication to I/O devices, risking exposure of confidential data. Use of the Trace Viewer also places an additional load on your VTScada system that may impact performance. Access to this should therefore be restricted.

5.9.3 VTScada Application Manager

The VAM is also a VTScada application and, as such, can be run remotely if so configured. The VAM can start and stop any application in your VTScada system. If remote access is essential, access should be restricted to specific, privileged user accounts.

Where VTScada is installed as a service, the VAM should be made accessible to thin clients. Restrict the accounts that have access to only those necessary.

5.9.4 Internet Client Monitor

The Internet Client Monitor (ICM) provides monitoring and session control of thin clients connected to the VTScada system. This can reveal usernames, IP addresses and other potentially sensitive data. It is also capable of terminating thin client sessions.

Standard VTScada applications contain the same user interface as the ICM application, protected by a privilege, so access to the ICM application is rarely required. If remote access is essential, access should be restricted to specific, privileged user accounts.

6 Operation and Maintenance

6.1 Anti-virus Protection

Trihedral does not recommend any specific brand of anti-virus protection software. For performance reasons, it is best to exclude a VTScada application’s Data folder from having files scanned before write. If using a storage location other than the Data folder for Historian data, this too should be excluded from anti-virus “scan before write” checking.

6.2 User account maintenance

How VTScada user accounts are maintained is determined by the type of authentication authority configured. In all cases, the end user must be proactive in disabling or removing accounts no longer required.

For VTScada native accounts, SecurityManager is used to create, modify and delete user accounts, assign roles to users and privileges to roles and users.

For Windows Security Integration (where AD is used to provide authentication), group membership of the AD account determines the roles assigned to the corresponding user account in VTScada. Modifying the AD account (changing group membership) modifies the roles assigned to the user in VTScada. Disabling the account in AD disables the account in VTScada.

For other external authenticators, SecurityManager is used to assign roles and privileges to the user accounts. There must be a VTScada user account corresponding to each externally authenticated account. A user account may be disabled or removed using VTScada’s SecurityManager, thereby removing that user’s access to the control system.

The preferred approach to assigning privileges to users is via roles, however a user account should only be assigned the privileges needed to allow the user to perform their tasks. Assigning additional privilege exposes more of the system functionality in the case that a user account is compromised. This requires careful planning of user roles and accounts from the outset.

6.3 Digital Signature Verification

All binaries released for production by Trihedral are digitally signed. It is strongly recommended that a command script be produced that automatically runs at system startup that verifies the digital signature on all the Trihedral released executable images. These are held in %programfiles%\Trihedral\VTScada. The Microsoft SignTool utility can be used to accomplish this. Consult the Microsoft documentation on the tool for further details.

6.4 Patch Management

Trihedral do not provide patches for VTScada. Revisions to VTScada are provided via a new release of the product. The VTScada help section “Moving to the Current Version” contains general information about upgrading and specific instructions when upgrading a VTScada system on more than one server.

Reading the release notes supplied with each version of VTScada will highlight any issues and enhancements to help you decide when to install the newer version. How you manage when to update and your specific update process is determined by your own site procedures.

6.5 Periodic installation security review

Due to the rapidly changing threat environment, end-users must be proactive in understanding the threat landscape. The end-user needs to ensure a procedure exists to make sure security guidelines are being followed and equipment and software that is protecting the installation are kept up to date.

This document will be updated periodically as threats that are not mitigated by measures described in the current version of this document come to light. The end-user will receive a new copy of this document with subsequent releases of VTScada. Changes to this document should be studied by the end-user, as these may require changes to the end-user system defenses.

6.6 Manufacturer Notification

Notification of security issues should be notified to Trihedral Engineering Limited. Visit our website at https://vtscada.com for further information.

7 Decommissioning

Decommissioning a VTScada system generally occurs at the end of the lifetime of the computer hardware upon which VTScada is running.

7.1 Uninstalling VTScada

Follow the instructions in the VTScada help documentation under “Uninstall VTScada”.

7.2 Post-Installation

Although uninstalling VTScada removes VTScada and all its components from your system, any applications you have created and data that has been gathered is untouched. This is intentional, should you wish to move that data to another system.

The location of your applications and data is determined by how you configured your application.

After copying your applications and data to another location, we recommend you securely erase the application and data directories from your system. This will erase all sensitive information used by VTScada safely.

8 End-User Responsibilities

The information in this security manual is intended to provide information that can be used by the end user to make informed decisions regarding means to achieve their required security level.

The security of VTScada assumes at a minimum that the baseline requirements documented in [IEC 62443-3-3] have been implemented and are maintained. It is further suggested that compliance with [IEC 62443-2-1] also be implemented and maintained.

It is the end user’s responsibility to determine their security requirements for the zone(s) in which VTScada is to be located. To achieve this, mitigations must be implemented by the end-user. Threats Requiring User Mitigation contains information about threats that require end-user additional mitigation measures. To achieve higher levels of capability, refer to [IEC 62443-3-3] for enhanced requirements to address higher security levels.

Host Device Requirements and Network Device Requirements contain information on Host and Network device requirements.

It is also the responsibility of the end-user to ensure the design and their overall IACS Cyber Security Management System can implement and maintain the network’s security to their target level over time in an ever-changing threat landscape. The security performance of any product is reliant on operational security policies and practices in place at the installed location. It is the responsibility of the user organization to maintain the cybersecurity environment.

9 Cybersecurity Issue Best Practices

This document does not aim to instruct you on cybersecurity incident handling, but it is best to assume that there will be a cybersecurity incident at some point and to prepare for it well in advance.

Reduce your risk levels by making sure your users are well aware of the policies you apply to the SCADA system and any other devices that can have connectivity to it. For example, prohibiting Internet browsing on such devices or applying restrictions or additional security to the use of personal handheld devices.

Establish a plan of how to deal with a cybersecurity incident. Know who needs to be informed and how they can be contacted. Know who is going to take action in the event of an incident.

We recommend you have personnel trained in dealing with cybersecurity to prepare you for an incident and can mitigate its effect.

10 Network Traffic / Ports

This section lists the network ports and traffic types used by VTScada. This excludes ports that the end-user has configured for I/O devices.

10.1 Ports for use within a Zone

Port	Traffic Type	Notes
TCP/80	HTTP	Used by VTScada HTTP Server and thin clients only where the end-user has not configured HTTPS. We recommend always using HTTPS and never plain HTTP. If the end-user system does not use HTTP, this port is unused.
TCP/443	HTTPS	Used by VTScada HTTP Server and thin client. This is the recommended method.
TCP/5780	VTScada RPC	Used for RPC communication between VTScada servers and “thick client” workstations.
TCP/50001 onwards	VTScada ModemManager	Used for redirection of modem communication between VTScada ModemManager servers. Each application consumes 2 ports. The first application to start will consume 50001 and 50002, the second 50003 and 50004 and so on.
UDP/161	SNMP	Used by the SNMP Agent in a VTScada application when enabled.
UDP/162	SNMP	Used by SNMP Drivers for receiving SNMP notifications.

Note that the above ports can be reconfigured by the user onto any other available ports. The table lists the defaults.

Other than the ports listed in Ports for use Externally, these ports should not be externally accessible without suitable security mitigations being in place.

10.2 Ports for use Externally

The following ports have sufficient security strength for use with devices on external networks.

Port	Traffic Type	Notes
TCP/443	HTTPS	Used by VTScada HTTP Server and thin client.

10.3 Windows firewall rules

When VTScada is installed, rules are added to the Windows firewall as follows:

Protocol	Network Zone	Notes
TCP	Domain + Private	VTScada is allowed to communicate with any TCP port and to accept connections from any TCP port that it is listening on
UDP	Domain + Private	VTScada is allowed to communicate with any UDP port and to accept connections from any UDP port that it is listening on

We recommend that you modify these firewall rules to restrict network communication to only the ports that you will use.

Copyright © 2024. Trihedral Engineering Limited