Submitting your feedback...
Knowledge Base Article
KB01160 - Securing PI Interfaces with Service Hardening
Product: PI Interface for HTML / PI Interface for Relational Database (RDBMS via ODBC) / PI Interfaces / PI Interface for OPC HDA / PI Interface for OPC DA / UNIINT
Version(s): UniInt 4.6 and later

Audience

Interfaces based on UniInt 4.6 automatically apply service security hardening techniques described below.  However, if you upgrade from an earlier version of the interface, service hardening must be applied manually.  This article will explain how to achieve this.

Issue

When considering your vulnerability to cyber security threats, OSIsoft recommends making Windows service hardening a primary focus. "Service Hardening" increases your ability to defend against cyber security threats by enforcing the principle of least privileges on Windows services. That is, Windows services are only granted the permissions necessary to maintain functionality. This approach reduces attack surface area (and damage potential) should a cyber-attack occur.

Windows services often represent one of the largest attack surfaces in any computer system. By default, a number of services in Windows operate under high privileged accounts, such as the "Local System" account. These accounts have varying levels of access to resources within and outside the host machine, so they are often an attractive target for attackers. In many cases, the Windows services running under one of these accounts do not need the excess privileges granted to them. Therefore, if a Windows service running under one of these accounts is compromised, the attacker could gain unauthorized access.

Hardening efforts for your PI System should be comprehensive, ongoing and iterative. Service hardening is just one part of an overall security strategy that is based on defense-in-depth principles. Consider Anti-Virus and Whitelisting as part of your overall strategy. Keep in mind that because every system is unique, there is no single correct way to harden. Our hope is that this guide gives you a good starting place for hardening your PI Interface nodes.

Background

Starting with Windows XP and Windows Server 2003, Microsoft introduced features that simplified the implementation of Service Hardening on Windows operating systems. These features help restrict Windows Services from performing tasks and accessing resources that could be exploited by malware or other forms of cyber attacks. To start, Microsoft configured many built-in Windows Services to logon with accounts that have lesser privileges, such as Local Service and Network Service. In addition, they limited the number of Windows Services which were enabled by default.

However, one of the most significant features was the introduction of the per-service security identifier (SID) with Windows Vista. This feature allows you to utilize existing Windows access control lists (ACL) on a per-service basis. Originally, if a service required access to a high-privileged resource, it had to run under an account which had access to that specific resource. In most cases, this account would also have access to many other high-privileged resources - which is not ideal because it authorizes the service access to extraneous resources that it doesn't utilize. With the introduction of the per-service security identifier (SID),  one can initially run a Windows service with a low-privileged account and then grant it access to higher level resources as needed. As a result, other services running under the same account (and the account itself) will not have access to the higher-level resource.

To create a per-service SID, you must change the service sidtype property. A sidtype of "none" is the default for all new services and means your service will not have a per-service SID. A sidtype of "unrestricted" means your service has a per-service SID that can be used normally in Windows permission settings. This is the configuration we will be using in this article. A sidtype of "restricted" means your service will have both a per-service SID, and a write-restricted token (using the restricted model is an additional, albeit more complex, step in hardening, and not within the scope of this article).

Furthermore, in Windows Server 2008 R2 and Windows 7, the Virtual Service Account was introduced. This account type is defined as "NT Service\<service_name>" and emulates a unique instance of the Network Service account. This account type doesn't need to be created, and there is no password management, so this makes auditing and tracking significantly more simplistic. On the local computer, a Virtual Account is not privileged - it is merely a member of the local Users group. On a network, if in a domain, a Virtual Account takes on the identity of the computer account (DOMAIN\computer_name$); if not in a domain, it is "Anonymous". 

Depending on the version of the Windows operating system that one is utilizing, Service Hardening can be implemented using either a low-privileged Windows account in conjunction with a per-service security identifier (SID), a Virtual Account, or a combination of both.

Solution

In this example, we will apply the concept of Service Hardening using both Virtual Accounts (Windows Server 2008 R2 and Windows 7 or later) and low privileged Windows service accounts along with a per-service security identifier (SID) (Windows Vista and later). In particular, we will be using a generic PI Interface called "PI_Interface." As with any new configuration, we strongly recommend you test first in a non-production environment and ensure your production operation will not be affected.

It’s important to note that this example makes several assumptions about feature scope, which are outlined in Table 1 under the "Notes" section. These assumptions are made in order to provide a clear and concise starting point for those new to service hardening. If your particular PI Interface configuration is utilizing one of the Out of Scope features, then the Details column provides additional suggestions on tightening PI Interface security with that feature; the More Information column directs you where to find out more about that feature in our documentation. It is still possible to implement Service Hardening with out-of-scope features enabled; however, this may introduce additional complexity that requires additional research on your part to determine compatibility with your particular configuration. Contact OSIsoft Technical Support if you have questions that go beyond the scope of this article.

Service Hardening - Virtual Accounts (Windows Server 2008 R2 and Windows 7 or later)

This procedure will configure a Virtual Account for both the PI Buffer Subsystem and PI Interface services (Steps 1 & 2). In addition, we will set the necessary read/write permissions for the PI Buffer Subsystem to write to buffer queue files (Steps 3-5). Note that this procedure is not valid if you're using a Windows version earlier than Windows Server 2008 R2 or Windows 7 - Virtual Accounts will not exist. If this is the case, please follow the procedure, Service Hardening - Assign Low-Privileged Account and Per-Service (SID) to Relevant Services (Windows Vista and later).

Step Screenshot Details
1.
st-widget-{image: 2014-=04-=03 13_22_04-=jkafer-=test -= Remote Desktop Connection.png}
 
Verify that both the PI Buffer Subsystem and PI Interface instance are installed and available. PI Interfaces can run interactively, which doesn't require that they're created as a service. For this procedure to work, you must have the PI Buffer Subsystem and PI Interface created as services.

Locate the PI Buffer Subsystem and PI Interface instance (in this case, "PI_Interface") services. If they're running, there is no need to stop them. We will restart both of these services to apply the changes at the end of this procedure. Note that restarting these services may result in data loss.

(Start > Run > Services.msc)
2.
st-widget-{image: 2014-=07-=10 09_18_04-=jkafer-=test -= Remote Desktop Connection.png}

 
In this step, we will configure the service to run under a Virtual Account. As mentioned before, this is a unique instance of the Network Service Account and will limit the permissions available to each service.

Right-click on the PI Interface service (PI_Interface), select the "Log On" tab, and change the service to log on as "This account". Next, enter "NT Service\<service_name>" for the account and clear the password fields. Finally, click "Apply" and then "OK". Please note that the service name may not be the same as the display name. The service name is found under the "General" tab in "Properties".

Repeat this step for the PI Buffer Subsystem.


Note – Some PI Interfaces, like the PI Interface for OPC DA, require their own specific user account. In this case, use the specific account allocated for this service instead of the Virtual Account. If you have configured the specific user account sufficiently, then it will already have the minimal privileges necessary to maintain operation. Remember, least privilege is the overall goal for this procedure. See FAQ for additional information.
 
3.

st-widget-{image: 2014-=04-=03 13_33_12-=jkafer-=test -= Remote Desktop Connection.png}

 
In this step, we will edit the permissions to the directory where the buffer queue files are stored. The PI Buffer Subsystem is not yet added to the ACL for the buffer queue directory.

Navigate to the directory using Windows Explorer, right-click on the folder, and select "Properties".

Select the "Security" tab and click "Edit…"

Note - Depending on the version of the PI Buffer Subsystem you're using, the directory in which buffer queue files are stored may vary.

PI Buffer Subsystem (3.4.375 & 3.4.380): %PIHOME%\dat
PI Buffer Subsystem (4.3): %ProgramData%\OSIsoft\Buffering

However, it is possible to change these locations.
If you have altered the piclient.ini file to modify the buffer queue location, you should modify the ACL of that specific directory and not the default directories listed above.

 
4.
st-widget-{image: 2014-=04-=03 13_34_28-=jkafer-=test -= Remote Desktop Connection.png}
 
The Windows service is selected in the same way that you would a normal user, or group, on an ACL.

Add the Access Control Entry (ACE) for pibufss to the ACL.

Click "Add…", ensure the location is set to the local machine, and type NT Service\pibufss into the text box.

Select "Check Names" to verify the account, then press "OK".
5.

st-widget-{image: 2014-=04-=03 13_35_05-=jkafer-=test -= Remote Desktop Connection.png}

 
After adding the Windows service (pibufss), you will notice that it is now present in the list. However, we still need to define the permissions that it has in this directory. The PI Buffer Subsystem needs Read/Write privileges for the buffer queue files. When this is complete, we will restart the PI Buffer Subsystem.

Highlight "pibufss" and check the "Read" and "Write" boxes in the permissions section. Finally, click "OK" for the dialogue box, and then again click "OK" for the properties dialogue box.

Restart the PI Buffer Subsystem and check for any errors in the Message Logs.

Note – We want to make sure that pibufss does not have both the ability to write and execute files in this folder. If this service was to be compromised, the attacker could write malicious files to this folder and then execute them.

Service Hardening - Assign Low-Privileged Account and Per-Service SID to Relevant Services (Windows Vista and later)

This procedure will configure per-service security identifiers for both the PI Buffer Subsystem and PI Interface services (Steps 1-3). In addition, we will set the necessary read/write permissions for the PI Buffer Subsystem to write to buffer queue files (Steps 4-6). If you are using Windows Server 2008 R2, Windows 7, or later, then it is recommended to follow the procedure Service Hardening - Virtual Accounts (Windows Server 2008 R2 and Windows 7 or later).

Step Screenshot Details
1.
st-widget-{image: 2014-=04-=03 13_22_04-=jkafer-=test -= Remote Desktop Connection.png}
 
Verify that both the PI Buffer Subsystem and PI Interface instance are installed and available. PI Interfaces can run interactively, which doesn't require that they're created as a service. For this procedure to work, you must have the PI Buffer Subsystem and PI Interface created as services.

Locate the PI Buffer Subsystem and PI Interface instance (in this case, "PI_Interface") services. If they're running, there is no need to stop them. We will restart both of these services to apply the changes at the end of this procedure. Note that restarting these services may result in data loss.

(Start > Run > Services.msc)
 
2.
st-widget-{image: 2014-=04-=03 13_23_31-=jkafer-=test -= Remote Desktop Connection.png}

 
In this step, we will change the account the services run as. This will limit the permissions available to each service.

Right-click on the PI Interface service (PI_Interface), select the "Log On" tab, and change the service to log on as "This account". Next, enter "Network Service" for the account and clear the password fields. Finally, click "Apply" and then "OK".

Repeat this step for the PI Buffer Subsystem.


Note – Reference Table 2 in the "Notes" section for more information regarding what Windows logon accounts should be used for different system architectures or scenarios.
3. st-widget-{image: 2014-=04-=03 13_25_41-=jkafer-=test -= Remote Desktop Connection.png}
In this step, we further harden our services by assigning per-service security identifiers (SID) to both the PI_Interface and PI Buffer Subsystem services. Once created, we can select these specific services in Windows Access Control Lists (ACLs). We will use this feature to set the appropriate ACLs in later steps.

Launch an Administrative Command Prompt
(Start > All Programs > Accessories > Right-Click "Command Prompt", select "Run as administrator").

Run the following command to assign a Per-Service SID to each service (pibufss and PI_interface):

sc sidtype <service_name> unrestricted
(E.g. sc sidtype pibufss unrestricted)


Next, execute the command below to verify that the proper changes have been made to each service:

sc qsidtype <service_name>
(E.g. sc qsidtype pibufss)
4.

st-widget-{image: 2014-=04-=03 13_33_12-=jkafer-=test -= Remote Desktop Connection.png}

 
In this step, we will edit the permissions to the directory where the buffer queue files are stored. The PI Buffer Subsystem is not yet added to the ACL for the buffer queue directory.

Navigate to the directory using Windows Explorer, right-click on the folder, and select "Properties".

Select the "Security" tab and click "Edit…"

Note - Depending on the version of the PI Buffer Subsystem you're using, the directory in which buffer queue files are stored may vary.

PI Buffer Subsystem (3.4.375 & 3.4.380): %PIHOME%\dat
PI Buffer Subsystem (4.3): %ProgramData%\OSIsoft\Buffering

However, it is possible to change these locations.
If you have altered the piclient.ini file to modify the buffer queue location, you should modify the ACL of that specific directory and not the default directories listed above.

 
5.
st-widget-{image: 2014-=04-=03 13_34_28-=jkafer-=test -= Remote Desktop Connection.png}
 
The Windows service is selected in the same way that you would a normal user, or group, on an ACL.

Add the Access Control Entry (ACE) for pibufss to the ACL.

Click "Add…", ensure the location is set to the local machine, and type NT Service\pibufss into the text box.

Select "Check Names" to verify the account, then press "OK".
6.

st-widget-{image: 2014-=04-=03 13_35_05-=jkafer-=test -= Remote Desktop Connection.png}

 
After adding the Windows service (pibufss), you will notice that it is now present in the list. However, we still need to define the permissions that it has in this directory. The PI Buffer Subsystem needs Read/Write privileges for the buffer queue files. When this is complete, we will restart the PI Buffer Subsystem.

Highlight "pibufss" and check the "Read" and "Write" boxes in the permissions section. Finally, click "OK" for the dialogue box, and then again click "OK" for the properties dialogue box.

Restart the PI Buffer Subsystem and check for any errors in the Message Logs.

Note – We want to make sure that pibufss does not have both the ability to write and execute files in this folder. If this service was to be compromised, the attacker could write malicious files to this folder and then execute them.

FAQ

  • I am using a PI Interface for OPC DA that uses a specific user account for DCOM security. Do I need to follow a different procedure?
    • This procedure is valid for most PI Interfaces, including OPC. However, there may be other considerations not covered in this article. Review Table 2 below for more information on which account is appropriate for the service logon account in your situation. Remember that whatever account is chosen, this account should have only the minimum permissions it needs for functionality. In the case of the PI Interface for OPC DA, that includes permissions to access the OPC server via proper DCOM configuration. See the DCOM Configuration Guide for more information.
  • When using buffering, does it matter which service starts first? (ACL on buffering objects is set when instantiated)
    • Yes. As described in the PI Buffering User Guide, PI Interfaces running as services on the node where PI Buffer Subsystem is installed are dependent on the PI Buffer Subsystem service. If PI Buffer Subsystem and the interfaces are set as automatic startup (recommended), the service installation must include this dependency. PI ICU automatically sets up service dependencies between PI Interfaces and PI Buffer Subsystem.
  • Are there permissions issues with interactive use of buffering diagnostics?
    • Generally, no. The permissions will be those of the account that is used to run the interactive session.
  • Why isn't the PI Interface service added to any Access Control Lists (ACLs)?
    • Although PI Interfaces write information to the PI SDK Message Logs (UniInt 4.5 and greater), they do so via RPC calls to the PI Message Subsystem. Therefore, they do not write directly to the message log files and do not need access to additional resources. However, it is important to note that some PI Interfaces, like the PI Interface for Relational Database (RDBMS via ODBC), do write to their own respective log files. In this case, one would need to add the PI Interface service to the necessary directory ACL so that it has access to the proper resource(s). For more information on PI Interface-specific logs, please refer to the respective PI Interface User Manual.
  • How does the PI Interface process share data with the PI Buffer Subsystem?
    • When a PI Interface is dependent on the PI Buffer Subsystem, the PI Buffer Subsystem must be started first. This creates the PI Buffering objects and associated ACLs for the PI Interface before it is started, which means that the user does not have to explicitly do this. This action enables the PI Interface to write data to the instantiated PI Buffer Subsystem objects.

Summary

In this KB article you successfully hardened your PI Interface node using the principle of least privileges. Again, we strongly recommend you test any new configuration in a test environment before attempting to use it with your production system. Every system is different and will have different hardening requirements.

OSIsoft intends to build on this work and share further recommendations for interface service hardening with these features at a later date. Again, service hardening should be regarded as an ongoing effort -- you will find there are many opportunities to further harden your system against cyber attacks.

Notes

  • The "SC.exe" command is used for communicating with the Service Control Manager and services. This command line utility can be used to query different attributes of a service, make changes to these attributes, and send particular commands to a service. In Step 3 (Windows Vista and later), the security identifier type (sidtype) was changed to "unrestricted" in order to assign the service a Per-Service SID. This enables one to define the necessary privileges for the particular service (Steps 4-6, Windows Vista and later).
    • There are 3 possible settings for a service sidtype:
      • None – This is the default setting and indicates that the Per-Service SID is not used.
      • Unrestricted – Indicates that the Per-Service SID is used.
      • Restricted – Indicates that the Per-Service SID is used and the service is write-restricted.
  • A per-service security identifier (SID) is only within the scope of the local machine. You cannot configure an ACL using a service on a remote machine.
  • The following tables provide further information regarding assumptions made in this procedure, and logon account information relevant for hardening your PI Interface services:

Table 1 - Assumptions and feature scope covered in this article
Feature Assumption made for this Article Details More Information
Data buffering with PI Buffer Subsystem (pibufss) In Scope
Aside from a few scenarios, PI Buffer Subsystem is recommended as the preferred buffering solution by OSIsoft. It's more robust from a security standpoint and is only limited in the amount of data buffered by available disk space.

When following the procedure below, please note the particular version of the PI Buffer Subsystem which you will be using. This will help determine the default location in which buffer queue files reside (unless otherwise changed by the user).
 
PI Buffer User Guide

PI Buffer Subsystem Release Notes (4.3.0.28)
Data buffering with PI Buffer Server (bufserv) Out of Scope
Generally, PI Buffer Server is not recommended as a buffering solution by OSIsoft. The PI Buffer Server is limited to only 2GB of buffered data and can be difficult to recover if corrupted. If PI Buffer Server is required for your operation, you can follow the same hardening recommendations provided in this article for PI Buffer Subsystem.
 
PI Buffer User Guide
UniInt Failover Out of Scope
In Phase 2 failover, a shared file is used to synchronize failover operations. File system permissions must allow read/write access to this file for both primary and backup interface services. Because this shared file is often stored on a third, independent server, PI Interface services using Phase 2 failover usually need to run as a network account to access the shared file path. If UniInt failover is required for your operation, service hardening should include file system permissions that prevent the interface services from executing from the shared path.
(/UFO_Sync parameter)
 
UniInt Interface User Manual (Chapter 8)
UniInt Windows Performance Counters Out of Scope
Consider interface-specific health and status points to monitor the interface instead of UniInt Windows Performance Counters. Disable UnitInt performance counters (/DisableCounters) to minimize permissions required by the interface service. Enabling Performance Counters on the interface machine requires that the interface have access to the registry, which complicates security configuration and increases attack surface area. If your operation requires UniInt Windows Performance Counters, you will have to enable access to the registry for your interface services. 

Note: OSIsoft managed interfaces (mPI) require UniInt performance counters.
 
UniInt Interface User Manual (Chapter 5)

The Interface specific performance counters are installed in the local registry under:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\
<Service_Name>+<Service_ID>\Performance
Disconnected Startup (with point caching) Out of Scope
With disconnected startup, the interface needs permission to read/write from the cache path (/CachePath). If your PI Interface requires disconnected startup, you must grant the service access to the cache path. The file system permissions should be configured so the service is not allowed to execute from any path to which it also has write access.
 
UniInt Interface User Manual (Chapter 7)
PI Interface Service Logon Account Network Service
There are many factors to consider when selecting a logon account to use for your PI Interface, including the particular PI Interface, system architecture, and the presence of a Windows Active Directory Domain.

In this article, we will assume that a generic PI Interface instance is located on its own host, separate from the host with the data source. We will assume both hosts reside on the same domain. In this example, the PI Interface will use the Network Service built-in account in order to enable network authentication to the remote host.

Your interface type and system architecture will dictate what logon account to use in order to provide least privileges to the PI Interface. For example, if the PI Interface is located on the data source, then the Local Service account may be sufficient. Alternately, PI Interfaces that require authentication to connect to the data source, for example the PI Interface for OPC DA and PI Interface for Relational Database (RDBMS via ODBC), may require a local or domain service account.
 
Windows Service Accounts

Table 2 (below) describes logon account options in more detail

Table 2. Windows logon accounts explained.
Logon Account Considerations Architecture
Local System Use of the Local System account for PI Interface services is highly discouraged. The Local System account is a highly privileged account and PI Interfaces do not need such privileges.

Furthermore, any service running as Local System is a highly valuable target for attackers. If a service running as Local System was compromised, it would then have access to any resources the Local System account was authorized to access.
Not recommended.
Local Service The Local Service account is a built-in Windows service account that has the same level of access as the Users group, meaning very limited privileges. Services running as Local Service that access resources over the network do so as a null session. This means that it does so without credentials.

An ideal use case for this account is where the PI Interface is on the same host as the data source and no other authentication is required by the data source (DCOM, Windows Security, etc). This logon account may also be viable for PI Interfaces where no network credentials are required, for example, the PI Interface for HTML connecting to a website that permits anonymous logon.

st-widget-{image: 2014-=04-=02 09_33_52-=Drawing1 -= Visio Professional.png}
PI Interface resides on same host as data source. No DCOM or other authentication required.
Network Service The Network Service Account is another built-in Windows account with the same level of access as the Users group, but authenticates across the network differently than the Local Service account. A service that runs in the context of the Network Service account presents the computer's credentials to remote servers. By default, the remote token contains SIDs for the Everyone and Authenticated Users groups. Thus, the Network Service account permits authentication against network resources in a domain.

This account may be appropriate when the PI Interface is located on a separate host from the data source, but on the same domain. However, be aware that any service running as Network Service on the PI Interface host will have the same permissions on the network as the PI Interface service. A more secure approach is to use either a local user or domain account (see below).

st-widget-{image: 2014-=07-=08 11_48_54-=Securing PI Interfaces with Service Hardening _ Customer Support Wiki.png}
PI Interface and data source reside on different hosts in the same domain. No DCOM or other authentication required.
Local User Account For several PI Interfaces, such as the PI Interface for OPC DA and PI Interface for Relational Database (RDBMS via ODBC), a dedicated user account may be required for the PI Interface logon account. This is due to the required additional user-based authentication needed for the respective data sources, such as DCOM, in the case of OPC, or Windows Integrated Security, in the case of relational databases.

If the PI Interface and the data source are not on a domain, or are on different domains, a dedicated local user account is recommended. For more information specific to the PI Interface for OPC DA, you can reference the DCOM Configuration Guide.

If you use a local account, its important to ensure that the account is used solely for accessing the data source and maintains the least privileges necessary to access that data. When hardening your PI Interface, it is recommended to use as account with limited access to computer resources. An account that is a member of the local Users group is a good starting point.

st-widget-{image: 2014-=07-=08 11_41_10-=Securing PI Interfaces with Service Hardening _ Customer Support Wiki.png}

PI Interface and data source reside on different hosts; hosts are not on a domain, or are on different domains.
Domain User Account
If a dedicated user account is required and your PI Interface and data source are both located on the same domain, a domain account is recommended. For more information specific to the PI Interface for OPC DA, you can reference the DCOM Configuration Guide.

If you use a domain account, its important to ensure that the account is used solely for accessing the data source and maintains the least privileges necessary to access that data. As with local account, membership in the local Users group is a good starting point.

st-widget-{image: 2014-=07-=08 11_48_54-=Securing PI Interfaces with Service Hardening _ Customer Support Wiki.png}

PI Interface and data source reside on different hosts; hosts are on the same domain.

Article ID: KB01160 Created: 2015-02-27
Article Type: How-To Last Updated: 2015-03-12