opshield hardening guide

GE Digital OpShield Hardening Guide 1

OpShield Hardening Guide


Legal Notice The accompanying software package is confidential and proprietary to GE Digital or its respective licensors. No use or disclosure is permitted other than as set forth by written license with the authorized distributors of GE Digital.

Trademarks

OpShield is a trademark of the General Electric Company. All other trademarks are the property of their respective owners. GE Digital reserves the right to make changes in specifications and features shown herein, or discontinue the product described at any time without notice or obligation. All values are design or typical values when measured under laboratory conditions.

Disclaimer

GE Digital retains the right to change information in this guide without notice. GE Digital believes the information in this guide to be reliable and accurate but it is not guaranteed. Using and relying on this guide is at your sole risk. GE Digital is neither liable nor responsible for any loss, damage or expense arising from any omission or error in this guide.

GE DIGITAL GIVES NO WARRANTIES, EXPRESS OR IMPLIED. ALL IMPLIED WARRANTIES, INCLUDING IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT ARE DISCLAIMED AND EXCLUDED BY GE DIGITAL IN NO EVENT SHALL GE DIGITAL BE LIABLE FOR ANY CONSEQUENTIAL, INCIDENTAL OR INDIRECT DAMAGES, OR FOR ANY LOSS OF PROFIT, REVENUE, DATA, COMPUTER PROGRAMS, OR OTHER ASSETS, EVEN IF ADVISED OF THE POSSIBILITY THEREOF. This guide does not constitute a recommendation, endorsement or guarantee of any of the hardware or software products tested or the hardware and software referred to therein.

The OpShield has been tested in an internal lab environment under precise test conditions. Use under different conditions or environments may cause performance to vary. GE Digital does not guarantee that the OpShield will perform in a particular manner under conditions different to those in which it was tested.

This guide does not imply any sponsorship, endorsement, affiliation or verification by or with any company mentioned in the guide.

All trademarks, service marks and trade names used in this guide are the trademarks, service marks and trade names of their respective owners. No endorsement, sponsorship, affiliation or involvement in either the testing, the guide or GE Digital is implied nor should it be inferred.

Warning

Do not physically open the OpShield or attempt to service it. It must be serviced by authorized personnel only. GE Digital is not liable for any damages that might occur as a result of the user physically opening the OpShield or attempting to repair it. © 2017 GE Digital LLC. All rights reserved.

WST-0040-002


Document Scope This document is indented for security professionals seeking guidance on how to best secure production OpShield deployments. The initial section discusses OpShield at a high-level, and describes potential areas of concern. Subsequent sections explain implementation specifics and provide recommendations related to the setup and maintenance of OpShield devices.


Architecture OpShield provides network-based security protection for industrial control systems (ICS) and supervisory control and data acquisition (SCADA) systems. It uses awareness of ICS network protocols to enforce policies concerning the types of actions allowed over those protocols between various networked devices, such as programmable logic controllers (PLC), distributed control systems (DCS), human-machine interfaces (HMI), engineering workstations and servers.

OpShield also offers signature-based detection of exploit attempts of known vulnerabilities in networked ICS devices and applications. OpShield can be configured to detect and block attacks, providing a measure of protection for devices and applications that have not yet been (or cannot be) patched to address underlying vulnerabilities.

OpShield can be deployed in several modes on a network.

• Detection-only “tap” mode: listens to traffic from a network tap or SPAN/mirror port.

• “Inline” mode, or “transparent firewalling”: blocks unwanted traffic without requiring address changes to existing devices on the network.

• “Router” mode: used for traditional routing at the network protocol layer.

Two types of OpShield devices are involved in typical deployments: perimeter units and field units. Perimeter units are the central management component in a deployment and are responsible for:

• Mapping network topologies.

• Defining network policies.

• Defining which vulnerability signatures to check for.

• Configuring and updating field units

• Collecting alerts and events from field units.

• Sending alerts and events to remote systems.

Field units dissect and inspect traffic on industrial controls networks, enforcing the policies and signatures defined by the perimeter unit to which they are bound, and sending alerts back to perimeter units.

Threat Model

OpShield was designed to be hardened against both network- and application-level attacks. All mitigations put in place tie directly into one or more of the following protection objectives:

• Attackers cannot compromise OpShield to monitor or change network traffic, or its routing.

• Attackers cannot compromise OpShield to disable what they expect OpShield to alert on.

• Attackers cannot extract information about OpShield protected networks or data.

• Attackers cannot manipulate bugs in OpShield to disrupt network connectivity.

• Attackers cannot use the management interfaces to pivot between networks.

• Attackers cannot extract knowledge of vulnerabilities from OpShield.


• Attackers cannot maintain network persistence using OpShield.

System Security

OpShield is designed with system-level security measures in place in all software components, with a strong focus on mitigating unknown or yet-to-be exploited software vulnerabilities.

PaX/GRSecurity®

All OpShield devices run Linux kernels that include the stable GRSecurity patch set. This ensures that OpShield is not a viable target for a wide array of bug classes and exploitation techniques. In addition to taking advantage of GRSecurity’s state-of-the-art exploit mitigations, OpShield also relies on its RBAC feature as a form of Mandatory Access Control (MAC).

Mandatory Access Control

All OpShield components that receive input directly from users or untrusted networks run under a least-privilege MAC. policy, which minimizes the impact of a successful exploitation attempt, requiring the successful exploitation of auxiliary vulnerabilities in order to compromise the integrity of the system.

Sandboxing

Because OpShield is designed to receive, parse and inspect traffic from untrusted and hostile networks, all inspection engine instances run within a least-privilege seccomp sandbox. This feature significantly reduces the internal attack surface of the product, minimizing the risk of a successful attacker’s ability to elevate their privileges, or pivot to other OpShield components.

Privilege Separation

All OpShield components that receive input directly from users or untrusted networks run in separate processes with the minimum level of privilege. This ensures that if a single component becomes compromised, it cannot impact the other components in unintended ways unless a second vulnerability can be successfully exploited.

Attack Surface

Attack surface is any interface or data that may be used to compromise the integrity, availability, or confidentiality of a system.

Figure 1 shows all remote trust boundaries and communication interfaces considered to be attack surface in OpShield. The subsequent sections focus on individual elements, detailing all controls built into the product, as well as any additional controls customers can put in place to ensure that deployments are as secure as possible.


Figure 1: Wire diagram of communications across trust boundaries between OpShield components. Grouped by Customer Infrastructure, Perimeter and Field Units

Some sections of this diagram are deemed optional. To ensure the minimal amount of attack surface, it is recommended that customers disable or avoid using these interfaces if possible.

Trust Boundaries All inputs received by an OpShield device that cross a trust boundary are considered potential threats and must be treated as such. By default, OpShield uses only encrypted protocols for traffic crossing any trust boundary. Depending on your deployment needs, it may be possible to reduce the risk at any trust boundary by disabling optional components.

Physical Management Trust Boundary An attacker with physical access to an OpShield device can gain full control over all functions of the device. Therefore, it is critical that appropriate physical security be put in place that would prevent an untrusted person from accessing any I/O ports or the device chassis itself.


Security Recommendations Install OpShield devices in locked cabinets

To ensure that only authorized personnel have access to the physical I/O ports of an OpShield device, install OpShield hardware in cabinets that remain locked, except when under maintenance. Ensure that all I/O ports, power and network cabling are not accessible from outside the cabinets while they are locked. Refer to the NIST 800-53 (Rev 4) standard for physical access control and logging best practices.

Control and log all physical access to OpShield devices

Keep auditable logs of all persons who have physical access to OpShield I/O ports, power and network cabling at any time. Refer to the NIST 800-53 (Rev 4) standard for physical access control and logging best practices.

Management Network Trust Boundary This trust boundary separates OpShield management interfaces from a customer’s management and IT networks.

Security Recommendations Deploy a Network Firewall to protect management interfaces OpShield will accept inbound network traffic from any IP address that can communicate with the management interface. Using a third-party network firewall to restrict all inbound traffic to the management interface of OpShield greatly reduces the potential sources of attack against the management interface.

HTTPS This is the primary interface used to configure and deploy policies in OpShield. As such, it is a high risk/high value target for attack. The HTTPS interface uses only TLS 1.2 compliant cipher suites for securing connections.

Security Recommendations

Perform initial setup and configuration in a controlled environment

As OpShield devices use a self-signed certificate by default, it is important to perform initial setup and installation of a customer-specific HTTPS certificate in a controlled environment that prevents attackers from performing man-in-the-middle (MITM) attacks during initial setup.


Deploy an HTTPS certificate signed by a trusted Certificate Authority

Refer to Certificate Management in the OpShield User Guide for instructions on deploying a CA-signed certificate to perimeter units.

Replace and remove default ‘admin’ user account

The web interface comes with a pre-configured user account that should be used only for initial setup. It is best practice to not share accounts belong to individual people. It is recommended that the “out-of-the-box” user account be changed.

1. Log in using the default ‘admin’ account. 2. Navigate to ‘User Management’. 3. Follow the ‘Create New User’ process and add a user with the ‘Admin’ role. 4. Log in as the newly created user. 5. Navigate to ‘User Management’. 6. Delete the ‘admin’ user account.

NTP

If configured with an NTP server, OpShield will poll NTP servers for time data and use this information to synchronize the clocks of all connected field units.

LDAP(S)

OpShield can defer authentication and authorizations to an external LDAP server. This is useful for scaling OpShield in enterprise environments. However, if an externally configured LDAP server used for authentication is compromised, the entire OpShield environment, including field units, may become exposed.


Use only encrypted transport

Customers should configure LDAP to use only encrypted connections on port 636/tcp to avoid leaking sensitive information onto the management network. Please refer to Server Authentication in the OpShield User Guide and ensure the secure options detailed there are enabled on all perimeter units.

Ensure proper controls and security measures are in place to protect external LDAP servers

Securing an enterprise LDAP server is out of scope for this document. It is recommended to follow best practices for your LDAP server and environment. Customers who do not have confidence that their LDAP servers are sufficiently secure should opt to use local account management only.


Syslog

Users may configure up to two remote syslog servers that perimeter units can send event information to. This is useful for collating logs from multiple perimeter units, or feeding data into a SIEM.


Refer to Syslog Settings in the OpShield User Guide for specific instructions on implementing Syslog-related security recommendations.

Use TCP only for sending Syslog data

As UDP traffic is stateless and can be easily spoofed, configure remote syslogging using TCP connections to ensure an attacker cannot send fake alerts or events while posing as an OpShield device.

Use only mutually authenticated TLS for communicating with remote syslog servers

OpShield has the ability to generate a CSR that can be exported, signed by a trusted Certificate Authority, and re-imported as a signed public key to be used for rsyslog communications. OpShield also allows users to import a trusted CA that has been used to sign an rsyslog server’s public key. Configuring syslog on an OpShield in this way ensures that logs cannot be faked or intercepted by a malicious third party. Restrict the set of cipher suites on the receiving syslog server

Because OpShield does not use a reduced set of cipher suites for communicating with syslog servers, it is recommended that customers configure their syslog server to utilize only cipher suites approved in NIST.SP.800-175B.

SNMP

SNMP is disabled by default in OpShield, but may be turned on from the serial console. OpShield supports only SNMPv3, as it provides the best available security model.


Refer to SNMP Configuration of the OpShield User Guide for specific instructions on enabling and communicating with OpShield devices via SNMP.

Use a secure password when enabling SNMP

SNMPv3 relies on password-based authentication. As such it is important to choose a secure password when enabling SNMP on an OpShield device. Refer to the Password Complexity section of this document for details regarding OpShield password requirements.


Leave SNMP disabled if it is not needed for your deployment

Since SNMP is an optional feature that adds potential attack surface to a device, customers are recommended to leave this functionality disabled if SNMP monitoring is not explicitly required in their deployment.

SSH

SSH is always enabled on OpShield devices, with a device-specific key installed at fulfillment time to allow GE Digital support technicians to diagnose and troubleshoot issues. Customers may use the serial console setup menu to enable an ssh-setup user account that can perform minimal configuration tasks. Ssh-setup users are capable of retrieving system information, modifying network configuration, initiating VPN connections from the Field Units, and disabling SSH.


Disable the ssh-setup user when not in use

Typically, customers may want to enabled ssh-setup for initial deployment of OpShield devices, so that they can be configured remotely. Since this is a one-time operation, it should be feasible for most customers to disable the ssh-setup user after initial configuration is complete.

Distributed Management Trust Boundary

The Distributed Management Trust Boundary sits between field unit management interfaces and the perimeter pnit. Some deployments may allow operator workstations to communicate directly with field units across this trust boundary for monitoring purposes. All communications across this trust boundary utilize encryption. The primary

TLS/OpenVPN All communication between perimeter and field units is done over a OpenVPN channel secured with TLS 1.2. The trust relationship between devices used to establish this connection is accomplished through a secure binding process, which includes mutual authentication at both ends of the communication. Managing VPN authorizations requires physical access to the perimeter unit in a deployment and provides operators with the ability to revoke access should a field unit be decommissioned or compromised.



Manually validate key fingerprints during binding process Operators with physical access to a field and perimeter unit are able to view a device-specific key fingerprint, which can be used at the other end of the VPN tunnel to validate that they are communicating with the expected device. See Binding in the Configuration Management section of this document for detailed process instructions that ensure both ends of VPN communications are properly authenticated.

Revoke decommissioned field units Perimeter units will accept VPN connections from any client presenting a previously authorized key. To avoid the risk of keys from a decommissioned unit being used to gain access to VPN tunnels, it is important that an operator with physical access to a perimeter unit revoke the relevant device’s binding authorization from the serial console setup menu. See Binding in the Configuration Management section of this document for detailed instructions on how to revoke a field unit’s VPN authorization. Securely wipe decommissioned devices

Offline devices may contain customer network information or sensitive key material that is left resident on the hard disk of the device, even after a factory reset. It is important that customers securely erase the hard disk of any field units taken out of service. See Secure Wipe in the Data Security section of this document for detailed instructions on securely erasing all storage on an OpShield device. Use a site-password to protect VPN connections

In addition to the mutually authenticated TLS tunnel established for securing VPN connections, it is possible to set a site-specific password that all endpoints must be configured to use in order to communicate with a perimeter unit. This reduces the risk of an attacker exploiting vulnerabilities in the TLS implementation, and provides an additional layer of integrity checks on all traffic sent to perimeter units from field units. See Binding in the Configuration Management section of this document for instructions on how to set a site password.

SSH The SSH service available through the Distributed Management Trust Boundary runs on field units and has the same options as the SSH service on perimeter units.


SNMP The SNMP service available through the Distributed Management Trust Boundary runs on field units and has the same options as the SNMP service on perimeter units.

Inspection Trust Boundary The inspection trust boundary sits between OpShield and potentially hostile networks. All traffic received across this boundary is treated as if it is malicious. The inspection services receiving traffic run in a least-privilege seccomp sandbox, Mandatory Access Controls, and under isolated user accounts. In addition to constraints placed on the inspection service, all protocol parsers used for dissecting network traffic have been heavily fuzzed and audited for vulnerabilities.


Data Security

Perimeter Unit Communications

Protocol Port(s) Cryptography Authentication Optional Type

HTTPS 443/tcp TLS 1.2 Password No Server

SSH 22/tcp SSHv2 Certificate No Server

LDAP 389/tcp, 636/tcp

TLS Password Yes Client

rsyslog 514/tcp, 514/udp

TLS Certificate Yes Client

OpenVPN 1194/udp TLS, Blowfish Certificate, Password

No Server

NTP 123/udp None None Yes Client

SNMP 161/udp 3DES Password Yes Server Table 1

Field Unit Communications

Protocol Port(s) Encryption Authentication Optional Type

OpenVPN 1194/udp TLS, Blowfish Certificate, Password

No Client

SSH 22/tcp SSHv2 Certificate No Server

SNMP 161/udp 3DES Password Yes Server Table 2

Log Retention and Alerts

The following table lists the types of information and duration for which OpShield will retain it:

Field Unit Network traffic Until Power Cycle

Field Unit Network alerts and events Until Power Cycle

Perimeter Unit Network alerts and events Until factory reset

Perimeter Unit Configuration changes Until factory reset

Perimeter Unit User actions Until factory reset

Perimeter Unit Network topologies Until factory reset

Perimeter Unit Field Unit networking information

Until factory reset

Table 3

Secure Wipe When decommissioning a unit, it is important that customers wipe all data from the device before taking it offline. If this step is skipped, the following information may leak from the device:

• Information about customer networks.


• Key material that is authorized to connect to the perimeter unit.

• GE Digital intellectual property. Prior to decommissioning a field unit, it is important for the owner to revoke authorization using the console of the management unit the field unit is bound to. If this step is not performed, and a field unit is not properly wiped upon decommissioning, an attacker would be able to compromise all OpShield devices connected to that management unit. Secure-wipe can be performed as part of a factory reset via an optional prompt. Refer to Factory Reset in the OpShield User Guide for instructions on performing a factory reset.

Cryptographic Baselines Table 4 describes the cryptographic algorithms supported and used by all OpShield components for both communication and at-rest data integrity.

Data Encryption Signing

Signature Packs RSA RSA

OS Images RSA RSA

Support Archive RSA None

Backup AES-CBC-128 None Table 4: Integrity checks

Password Storage Passwords that reside on OpShield devices are stored using the hashing algorithms described in Table 5.

Credential Algorithm Salted

Web interface SHA-512 Yes

SNMP SHA1 No Table 5: Password hashing algorithms

Communications Table 6 lists all cryptographic algorithms and cipher suites that OpShield uses when storing or sending information as of OpShield release 1.16. Users can refer to the release notes for subsequent releases to obtain any information regarding cryptographic changes.

Supported Cipher Suite Signing Key Length

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA ECDH-256 bits

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH-256 bits

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 ECDH-256 bits

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA ECDH-256 bits

TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 DH-2048 bits

TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 DH-2048 bits

TLS_DHE_RSA_WITH_AES_128_CBC_SHA DH-2048 bits Table 6: Web interface


Supported Cipher Suite Signing key Encryption key

TLS-DHE-RSA-WITH-AES-256-CBC-SHA

DH-2048 bits 256 bits

Table 7: VPN connection

LDAPS

It is recommended that customers review the supported cipher suites of their LDAP server to ensure that it utilizes only ciphers approved in NIST.SP.800-175B. The LDAP client utilized by OpShield supports the following cipher suites:

• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256

• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

• TLS_RSA_WITH_AES_128_CBC_SHA256

• TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256

• TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256

• TLS_DHE_RSA_WITH_AES_128_CBC_SHA256

• TLS_DHE_DSS_WITH_AES_128_CBC_SHA256

• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA

• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

• TLS_RSA_WITH_AES_128_CBC_SHA

• TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA

• TLS_ECDH_RSA_WITH_AES_128_CBC_SHA

• TLS_DHE_RSA_WITH_AES_128_CBC_SHA

• TLS_DHE_DSS_WITH_AES_128_CBC_SHA

• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

• TLS_RSA_WITH_AES_128_GCM_SHA256

• TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256

• TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256

• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

• TLS_DHE_DSS_WITH_AES_128_GCM_SHA256

• TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA

• TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA

• SSL_RSA_WITH_3DES_EDE_CBC_SHA

• TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA

• TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA

• SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA

• SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA

• TLS_EMPTY_RENEGOTIATION_INFO_SCSV

Syslog


OpShield supports the default set of gnutls cipher suites for sending syslog events. Customers should ensure that the syslog server receiving events is restricted to a set of cipher suites that conforms with NIST.SP.800-175B.

SSH

Usage Algorithm

Key Exchange [email protected]

Key Exchange diffie-hellman-group-exchange-sha256

Host Key ssh-ed25519

Host Key ssh-rsa

Encryption [email protected]



Encryption aes256-ctr



MAC [email protected]

MAC [email protected]

MAC [email protected] Table 8

SNMP

The SNMP daemon offered by OpShield utilizes the HMAC-SHA-96 authentication protocol as defined in RFC-3414, and AES-CFB-128 as defined in RFC-3826 for encryption.


Security Configuration

Binding

OpShield utilizes an OpenVPN tunnel for all communication between field and perimeter units. This tunnel is secured through a manual binding process that requires physical access to both the VPN client and server. To securely bind two OpShield devices together, use the following process: On field units: 1. Log into the console menu as setup and select Binding Configuration. 2. Enter the IP address of the perimeter unit. 3. Select OK. 4. Select System Information from the main setup menu and record:

Serial number.

Fingerprint. The field unit will now attempt to connect to the management console, however it cannot authenticate until manually authorized by someone with physical access to the perimeter unit.

1. Log into the console menu as setup and select Binding Configuration. 2. Locate the serial number you wish to authorize in the list of field units. 3. Verify that the fingerprint and serial number match the values recorded from the field unit setup

console. 4. Select Authorize.

By validating the fingerprints manually outside the communication channels, users are able to mutually authenticate both the management and field units.

Revocation Field units bound to a perimeter unit have the ability to connect to send traffic across the Distributed Management Trust Boundary inside a secure VPN tunnel. It is important that field units that are decommissioned, no longer used, or have been compromised, have their access to this tunnel revoked.

Use the following steps to disconnect a field unit from the management console to prevent it from sending communications inside the secure VPN tunnel:

1. Log-in to the serial console menu of the Perimeter Unit as the setup user. 2. Select Binding Configuration and press enter. 3. Choose the field unit from the list of bound devices, and press enter. 4. Select Revoke and press enter.


The field unit will be immediately disconnected and will no longer have the ability to send alerts and events to the perimeter unit. Revoked field units will remain in the list of devices in the setup menu and can be re-authorized at any time.

Site Password In addition to the manual binding process that provides mutual authentication, OpShield deployments also support adding a site password as an additional outer layer of security on the management VPN tunnel.

This serves the dual purpose of additional authentication, and providing an outer layer of MAC on all messages, which can reduce the unauthenticated attack surface of the VPN server used by OpShield.

Adding a site password to a deployment prevents attackers without knowledge of the site password from exploiting vulnerabilities in OpenSSL and OpenVPN.

To enable a site password, perform the following:

On the perimeter unit:

1. From the serial console of the perimeter unit, log-in as the setup user. 2. Select Site Password and press enter. 3. Select Enable and press enter. 4. Input a site password in both fields that meets the requirements outlined in the Password

Complexity section of this document. 5. Select OK and press enter.

On all field units:

1. From the serial console of the field unit, log-in as the setup user. 2. Select Site Password and press enter. 3. Input the site password that was configured on the perimeter unit. 4. Select OK and press enter.

Warning: Adding a site password to a perimeter unit that already has field units connected to it will immediately disconnect all field units until they are configured with a matching site password.

Identity Management and Access Control

Privilege Model – Web Admin/User Separation There are three types of user roles that can be created to manage OpShield: Admin, Oper and Monitor. This section provides a brief overview of each role type and the recommended use cases for each role.


Administrator

Administrative web-users are considered by OpShield to be fully trusted, and may be able to gain full control over both management and field units. Access to administrative accounts should be given only to trusted individuals.

It is recommended that OpShield users do not rely on accounts with an Administrator role to perform device configuration and setup, or for day-to-day maintenance of an OpShield deployment.

Administrators have the following attributes:

• Able to perform all functions.

• There must be at least one Admin user on the system.

Operator

The operator role should be used for policy development, topology development, and all other initial setup activities required to deploy an OpShield device. Operators have the following attributes:

• Able to perform all functions except user management and software update.

• Able to change their own user profile, but not their role.

• Unable to see a listing of users on OpShield.

Monitor

Monitor users cannot make configuration changes to any OpShield devices, and have read-only access to logs and events. Although Monitor accounts are significantly less sensitive than Administrator accounts, an attacker may still be able to determine information about topologies, devices, or other network information for systems OpShield has been put in place to protect. Monitor users have the following attributes:

• Read-only access to everything on the system.

• Unable to edit or make changes.

• Able to change their user profile, but not their role.

• Unable to see listing of users on OpShield.

Functions unavailable to a user's role will not be visible to the user. It is recommended this be the most frequently used role for operations and monitoring outside of maintenance.


LDAP vs. Standalone

Note: When an LDAP repository is used for authentication, the password complexity rules outlined in this document and the OpShield User Guide do not apply. It is recommended that customers configure their LDAP server to enforce complexity requirements that reflect the rules in this document detailed in the Password Complexity section

Default Passwords To first log in to an OpShield, a username of admin and a default password of Achilles12 is used. Users are required to change the administrative password before proceeding through the login process to the management interface. Because of this, no production devices are capable of running with default credentials of any kind.

Password Complexity OpShield password complexity rules impose the following constraints on passwords:

• Minimum of ten characters.

• A combination of at least three of the following four character sets:

Lower case characters.

Upper case characters.

Numeric characters.

Special characters: [!”#$%&’()*+,-/:\;=<>@^_`{|}~

Syslog Offload OpShield has the ability to forward log events to a remote syslog server, such as rsyslog. It is strongly recommended this option be enabled and that communications with this server be done via a mutually authenticated TLS session. To ensure OpShield is logging via a mutually authenticated TLS session, perform the following actions: 1. Configure your remote syslog server to use a certificate signed by a trusted Certificate Authority

(out of scope of this document). 2. While logged in to the OpShield web interface as an Administrative user, navigate to

Configuration from the top-left menu. 3. Select the Certificates tab. 4. Click Import in the Server #1 CA Certificate section. 5. Upload Certificate Authority certificate used to sign the remote syslog server’s certificate. 6. Click Generate CSR to download a CSR that can be used to generate a syslog client certificate. 7. Sign the downloaded file using a Certificate Authority that is trusted by the remote syslog server

(out of scope of this document). 8. Click Import in the Common Client Certificate section. 9. Upload the signed certificate which corresponds to the downloaded CSR. 10. Select the Syslog Settings tab.


11. Click the Enable checkbox next to 1st Server. 12. Select TCP from the Protocol drop-down menu. 13. Enter the IP Address and Port information for your remote syslog server. 14. Check the Enable Encryption box. 15. Input the subject name for the remote syslog server’s certificate in the Allowed Name text box. 16. Click Save.


Patch Management

Obtaining Software Updates Customers can obtain security updates and other release assets through https://digitalsupport.ge.com/communities/. If you require assistance accessing this portal, please contact [email protected]. Refer to Upgrading OpShield in the OpShield User Guide for instructions on patch installation.

Vulnerability Notifications To receive immediate notification about software updates and signature pack releases, complete the following: 1. Log-in to https://digitalsupport.ge.com/communities/. 2. Click on your name at the top left hand side of the page. 3. Select the Notifications tab on your profile page. 4. Enter ‘OpShield’ in Filter by Product. 5. Check Alerts. 6. Check Downloads. 7. Click on Save.

You will now receive e-mail notifications when new OpShield signature packs and software updates are released. Please see the Fixed Vulnerabilities section of the OpShield Release Notes to determine whether or not there are security implications to installing an update. GE internal customers also have the ability to join a Yammer group and receive advanced warning of soon to be released updates and software. To receive notifications via Yammer: 1. Log-in to https://www.yammer.com/ge.com/#/threads/inGroup?type=in_group&feedId=8879478. 2. Select Join Group.

For questions regarding notification channels, customers should e-mail [email protected] with any inquiries.

Update Integrity Verification All software updates and signature packs are encrypted and signed by GE Digital. OpShield devices will not accept updates that have not been signed by an authorized GE Digital key. In addition to update package signing, download archives hosted on digitalsupport.ge.com contain a file called checksums.txt that describes hashes for all files in the archive with the format:


OpShieldUpgrade-R1.13.afu checksums:

• MD5: 7ec1eae4b40484a4969bc52962bc91c7

• SHA1: 4398e3ea488b368ec9d99359cc2115e780083af2

• SHA224: b55f223768a1265860766792d9f2297f2eb1a4a151510e632eff368c

• SHA256: 7f553119d6e21832f1c6213541dbd55d3b666f9f2da6e75a2913e33bc7dd2c76

• SHA512: 4d67281d9a93eb6fd9ee74440dabc5747ebd88cb140162e3bee026c67793bf99e81b00084e1c43f945de67e1a649456e006628713e838815823b5313cb5267fa

It is recommended that customers record this information for later verification and auditing of installed software versions.

QA Process for Security Patches OpShield security updates are subject to the same performance and reliability testing as a feature release. Additionally, all functionality that relies on the patched component undergoes full functional testing and quality assurance.

Auditing Patch Status on Devices It is recommended that customers regularly verify the patch levels of OpShield devices, and check this against the current available version. There are two ways to determine what version an OpShield device is currently running. Through the perimeter box web interface: 1. Log-in using an account with the Administrator role. 2. Using the drop-down menu at the top-left; select Software Upgrade. 3. Review the Version field on both the Perimeter Box and all Field Boxes.

Through the serial or ssh interfaces:

1. Log-in using the ‘setup’ user or ‘ssh-setup’ user accounts. 2. From the setup menu use the arrow keys to navigate to System Information and press the enter

key. 3. Version information is contained in the Firmware field displayed on this page.

Maintaining an up-to-date inventory of serial numbers, IP addresses, software versions, and last verified date is critical to determining the scope of any security updates released for OpShield. It is recommended that customers perform a full audit of all devices at a minimum, once every three months.


Vulnerability Procedures To report a vulnerability or incident involving OpShield, please follow the disclosure processes described at http://www.ge.com/security.

GE Digital closely monitors all public vulnerability feeds for information regarding third-party components used in OpShield. Issues are assessed for impact and may result in firmware or hardware revisions specifically to address them. Customers looking for information regarding a specific vulnerability can check the ‘Fixed Vulnerabilities’ sections in OpShield’s firmware update release notes or contact [email protected] and provide CVE numbers for which they wish to see impact assessments.


Appendix A – Security Recommendation Checklist

Networking Deploy a network firewall to protect management interfaces

Physical Install OpShield devices in locked cabinets

Physical Keep a log of all personnel with physical access to OpShield devices

HTTPS Perform initial setup and configuration in a controlled environment

HTTPS Deploy an HTTPS certificate signed by a trusted Certificate Authority

LDAP Use only encrypted transport

LDAP Ensure proper controls and security measures are in place to protect external LDAP servers

SYSLOG Offload log events to external syslog server(s)

SYSLOG Only use TCP for syslog communications

SYSLOG Use only mutually authenticated TLS for communicating with remote syslog servers

SYSLOG Restrict the set of cipher suites on the receiving syslog server

SNMP Use a secure password when enabling SNMP

SNMP Leave SNMP disabled if it is not needed for your deployment

SSH Disable the ssh-setup user when not in use

PATCHING Perform regular audits of device version and track inventory

PATCHING Enroll in notifications for OpShield security updates and releases

Decommissioning Unbind decommissioned devices from their perimeter unit

Decommissioning Perform a secure wipe of all OpShield devices when taking them out of service

Identity Management Create and use accounts with the Monitor role for regular operations

Binding Manually validate key fingerprints on perimeter and field units during binding

Binding Make use of site passwords in all OpShield deployments Table 9: Security Recommendation checklist


Bibliography

• NIST. 2017. NIST 800-53 (Rev 4.). NVD. [Online] 1 23, 2017. https://nvd.nist.gov/800-53/Rev4/family/PHYSICAL%20AND%20ENVIRONMENTAL%20PROTECTION.

• Security, Wurldtech. 2017. OpShield Hardening Guide. GE Digital Support. [Online] 01 01, 2017. https://digitalsupport.ge.com/communities/en_US/Download/OpShield-1-13.


About GE GE (NYSE: GE) is the world’s Digital Industrial Company, transforming industry with software-defined machines and solutions that are connected, responsive and predictive. GE is organized around a global exchange of knowledge, the “GE Store,” through which each business shares and accesses the same technology, markets, structure and intellect. Each invention further fuels innovation and application across our industrial sectors. With people, services, technology and scale, GE delivers better outcomes for customers by speaking the language of industry.

Contact Information 1-800-433-2682 [email protected]

www.ge.com/digital/cyber-security ©2018 General Electric. All rights reserved. *Trademark of General Electric. All other brands or names are property of their respective holders. Specifications are subject to change without notice.

grsecurity is a registered trademark of Open Source Security, Inc.

mailto:[email protected]

opshield hardening guide

Documents