Submitting your feedback...
Knowledge Base Article
KB00833 - Seven best practices for securing your PI Server
Product: PI Data Archive
Version(s): 3.4.380.36 and above, 3.4.380.79 and above

(December 2016) This article mentions PI trusts, now superseded by more secure forms of authentication. AL00309 discusses the move from PI trusts to Windows Integrated Security (WIS) for PI API.

st-widget-{image: YouTube_Icon.jpg} OSIsoft: Configure PI Server Security

Issue

What are the best practices that PI administrators can follow to secure their PI Server (more recently referred to as PI Data Archive) deployments?  

Solution

OSIsoft recommends the following seven security best practices to increase security for PI Data Archive. These practices rely on Windows Integrated Security and other recent advances and cover migration to Windows authentication, disabling risky aspects of the existing security model, and the principle of least privilege.

For a software-based infrastructure, following these best practices is an essential part of common network-based defense.

Note: Illustrations in this article refer to an Active Directory example domain named PISchool, used to highlight security practices that involve user principals and access roles.
 

Security Best Practice #1: Upgrade to the latest version of Windows and the PI Data Archive components

The single most effective action you can take to improve software security and reliability is to upgrade to the latest version of software. The most recent releases contain the largest number of fixes and defenses for vulnerabilities. 

PI Data Archive security relies on enforcement by the Windows operating system. Updating Windows is so important to security that OSIsoft publishes security patch compatibility results within days of availability from Microsoft to help facilitate the process.

Consider using Windows Server Core for host machines. PI Data Archive supports Windows Server Core mode, as outlined in KB00649 - PI Server support for Windows Server Core. Windows Server Core provides maximum protection because fewer components are installed and running on the host machine. The lack of a memory-mapped GUI greatly reduces the attack surface as well. Server Core also provides significant benefits for administration, such as reduced patch maintenance (~40‑50% of updates do not apply), less disk usage, smaller memory/resource requirements, and fewer required maintenance reboots, all of which help reduce the total cost of ownership.  

Note: Windows Server 2012 R2 supports a GUI for routine servicing.

 Whitelisting is the practice of specifying approved applications that are permitted to be present and active on the host machine. Whitelisting techniques are essential countermeasures for modern malware threats. PI Data Archive software enables the deployment of whitelisting defensive technology built into Windows Server 2012 R2. OSIsoft provides specific advice for whitelisting PI System applications using Windows Applocker and PI System communications whitelisting using Windows Advanced Firewall.

OSIsoft's goal is to increase service reliability and better withstand malicious attack with each new version of software. OSIsoft uses MIcrosoft's Security Development Lifecycle (SDL) process to minimize security-related issues in the PI Data Archive, and to detect and eliminate vulnerabilities as early as possible.  

PI Data Archive 2017 includes fixes for security bugs summarized in Table 1 below. These bugs were discovered after the release of PI Data Archive 2016 R2 using SDL practices.  The full context is provided in the PI Data Archive 2017 Release Notes. Any version older than PI Data Archive 2012 has greater security risk compared to PI Data Archive 2017.

Table 1. Internally Discovered Security Vulnerabilities Fixed in PI Data Archive 2017
 
Severity Category CVSS Base Score Range Number of Fixed Vulnerabilities
High 7.0 - 10 1
Medium 4.0 -6.9 1
Low 0 - 3.9 0

 PI Data Archive also leverages the greatest number of security defenses provided by the compiler and Windows as shown in Table 2. 

Table 2. PI Data Archive Leveraging Microsoft Software Security Defenses
 
  2010
(3.4.385.x)
2012
(3.4.390.x)
2015
(3.4.395.x)
2016
(3.4.400.x)
2017
3.4.410.x
Supports Windows Authentication Yes Yes Yes Yes Yes
C++ Compiler Version VC++ 2008 SP1 VC++ 2010 SP1 VC++ 2012 Update 4 VC++ 2015 Update 1 VC++2015 Update 2
Native 64-bit Option Yes Yes Yes, 64-bit only Yes, 64-bit only Yes, 64-bit only
Supports Windows Server Core mode Yes Yes Yes Yes: 2012+ Yes: 2012+
/GS Stack Buffer Overrun Detection Yes Yes Yes Yes Yes
/SafeSEH Image has Safe Exception Handlers Yes Yes Yes Yes Yes
Structured Exception Handler Overwrite Protection (SEHOP) Yes Yes Yes Yes Yes
Data Execution Prevention (DEP) / No eXecute (NX) Yes Yes Yes Yes Yes
Address Space Layout Randomization (ASLR) Yes Yes Yes Yes Yes
Heap Metadata Protection No Yes Yes Yes Yes
Migration of buffer-overrun prone functions to safer versions 2% complete 80% complete 95% complete 95% complete 95% complete
/SDL Security Development Lifecycle Checks No No Yes Yes Yes
Control Flow Guard No No No No On core subsystems

High availability options are supported for PI Data Archive and are recommended to help roll out upgrades without any loss of service.

In summary, OSIsoft recommends using PI Data Archive 2017 on Windows Server 2012 R2 in Server Core mode, with application and communication whitelisting provided by Applocker and the Windows Advanced Firewall.

Security Best Practice #2: Use Windows authentication instead of PI User authentication (also known as explicit login)

st-widget-{image: YouTube_Icon.jpg}OSIsoft: Disable the Least Secure Authentication Options on Your PI Data Archive

Starting with PI Data Archive 3.4.380.36, PI Data Archive supports Windows authentication (via Kerberos or NTLM). With Windows Integrated Security, modern PI Data Archive defenses, such as ciphers, are enabled during a Windows logon to the PI System and used to protect communication between PI Data Archive server and its clients. Baseline network security for classic PI API and PI SDK applications now enjoys parity with AF SDK-based applications.

Explicit login authentication is inherently insecure, and is not recommended for use. AL00206 - Security Alert: PI Authentication Weakness discloses information about the fundamental weakness for passwords for PI Users for PI Data Archive. In fact, explicit logins have been disabled automatically by default start with PI Data Archive 3.4.380.36 for all PI Users (see Figure 2.1).  You are at significant security risk if you have not updated to PI Data Archive 3.4.380.36 or later, or if you have re-enabled explicit logins. This could potentially result in exposure of confidential operational information and/or tampering of sensitive data.

st-widget-{image: Figure 2.png}
Figure 2.1 PI System Management Tools Security Settings showing all PI User authentication is disabled by default for PI Data Archive 3.4.380.36 and later

Note: The use of PI Users in PI mappings is perfectly acceptable. The insecure aspect of PI Users involves the password associated with PI User. As long as explicit login remains disabled, PI Users and PI Groups pose no inherent risk.

To migrate to Windows authentication quickly, consider mapping existing PI Users and PI Groups to Windows principals. This is one of the most expedient ways to move forward with this upgrade process. PI Identities can be used in parallel as new identities are necessary.  PI Data Archive 3.4.380.36 was specifically designed to give administrators greater flexibility and control over both authentication and authorization so that better security could be implemented gradually over time.

To leverage Windows authentication, applications may use the AF SDK (all versions), PI SDK (1.3.6 and later) and the PI API for Windows Integrated Security (2.0.1.35 or later). 

Note: Standard UniInt-based interface rely on API-based connections.

To learn more about the environment requirements for Windows authentication, refer to KB00354 - Supported Windows Security Configurations in Domains and Workgroups for the PI Data Archive. The majority of the requirements are the same for all applications that support Windows authentication, such as PI Data Archive, PI AF Server, and SQL Server. If you have already made investments in configuration and infrastructure for another application, you will not be required to make them again for the PI Data Archive. However, if you are starting from scratch, making these decisions and considerations around Windows authentication for the PI Data Archive will also benefit other applications in the future.

To learn more about configuring Windows authentication with the PI Data Archive, including quick-start guidance for upgrades, refer to Configuring PI Server Security.

For PI AF 2015 and later, PI Identities and Mappings are supported, and follow a similar security model as PI Data Archive. Prior to PI AF 2015 (version 2.7), users would grant access to PI AF server resources such as an element collection or object using a Windows user or group. This model will continue to rely on Windows Integrated Security for authentication and provide its own authorization for PI AF objects using PI AF identities and mappings. To configure security for PI AF objects, create a PI AF identity that has access to the PI AF server resources, and then create a PI AF mapping between the Windows user or group and that PI AF identity. Refer to PI System Explorer documentation to learn more about PI AF identities and mappings.  

Security Best Practice #3: Use Windows authentication instead of PI trust authentication

st-widget-{image: YouTube_Icon.jpg}OSIsoft: Disable the Least Secure Authentication Options on Your PI Data Archive

Similar to PI User authentication, PI trust authentication is a weak form of authentication due to potential for fake credentials and should be avoided, unless technically required for application compatibility. PI Data Archive 3.4.380.36 and later support Windows authentication as an authentication protocol.  Windows authentication is compatible with applications connecting to a PI Data Archive using AF SDK (all versions), PI SDK (1.3.6 and later) and the PI API for Windows Integrated Security (2.0.1.35 or later). Windows authentication through PI API 2016 for Windows Integrated Security requires PI Data Archive 2016 R2 or later. Once PI Data Archive and client applications have migrated from PI trust to Windows Integrated Security, PI trust authentication can be disabled globally for all applications as shown in Figure 3.1 below.  

It is worth noting that Windows authentication is compatible with scenarios where the host machines are in a workgroup or untrusted domains. In such cases, Windows credential manager should be used on the interface node in cases where service account credentials are invalid for a PI mapping.  See KB01457 for further guidance on this scenario.

For PI Data Archive 2016 R2 and later, PI trusts for all types of applications remain enabled by default. Therefore, this security best practice is opt-in by nature.

PI trusts are still available as a method for authenticating PI interfaces, or any other PI API-based client application. However, you should only use PI trusts when Windows authentication cannot be used.

st-widget-{image: SliderPITrustsDisabled.PNG}
Figure 3.1 PI System Management Tools Security Settings showing PI Trust authentication is disabled for all applications

Consider disabling PI trusts on PI SDK and AF SDK connections while waiting for migration of applications to Windows authentication with the PI API 2016 for Windows Integrated Security. An assumption in this case is that the PI Buffer Subsystem has been configured to use Windows authentication (more on this in Security Best Practice #6).

st-widget-{image: Figure 3.png}
Figure 3.2 PI System Management Tools Security Settings showing PI Trust authentication is disabled for SDK applications in PI Data Archive 3.4.380.36 and later

st-widget-{image: WIS.png}

Security Best Practice #4: Do not use piadmin

Do NOT use the piadmin PI user.  If you require it to perform administrative tasks, use the piadmins PI Group instead. 

Any entity that is authenticated to the PI Data Archive as piadmin is granted full permission to all resources regardless of how individual resources are configured in PI System Management Tools (PI SMT). Widespread use of piadmin exposes your PI Data Archive to severe and unnecessary risks, especially in conjunction with weak authentication methods like explicit logins and PI trusts Just say "no" to piadmin and "yes" to piadmins.

Starting with PI Data Archive 3.4.380.36 and later, there is exactly one legitimate scenario that requires using piadmin: recovering from accidental lockouts.  For most other administrative scenarios, access can be easily and arbitrarily delegated to other PI Users, PI Groups, or PI Identities.  Again, for the very few administrative scenarios that cannot be delegated, the piadmins PI Group can be used. 

For new installations of PI Data Archive 3.4.380.36 and later, the piadmins PI group will have explicit write permission to all objects by default, making this migration and upgrade very easy.  Upgrades to PI Data Archive 3.4.380.36 and later will require some reconfiguration to grant the piadmins PI Group explicit write permission, but this is still very straightforward and the needed configuration can be completed relatively quickly.


st-widget-{image: piadmin.png}
Similarly, Microsoft recommends Windows authentication instead of SQL Server's legacy built-in SA account.  For PI AF Servers, the "AFservice" service account should not be an administrator; that imposes unnecessary risk to the entire SQL Server database, including potential compromise of the SQL Server host computer itself.  

A safer option is to configure the AF Service to run as the virtual service account 'NT SERVICE\AFServer'. This can be selected at the time of the installation, or configured in the Services dialog after setup is complete. Using the virtual service account provides the ability to more tightly lock down the service without incurring the overhead of managing user accounts.  

st-widget-{image: VirtualServiceAccount.png}
 

Security Best Practice #5: Configure minimum permissions for interfaces

st-widget-{image: YouTube_Icon.jpg}OSIsoft: Configure Most Secure Authentication for PI Interfaces & Buffering

It is important to grant only the minimum level of permissions on any interface connected to the PI Data Archive. Most interfaces are granted too many permissions on the PI Data Archive.  Configuring only required permissions, known as least privileging, is a standard defensive measure that limits the impact in the event of compromise or a successful intrusion.  Because most interfaces are configured for buffering, they require no write permission to points whatsoever.  Most interfaces only need permission to read the configuration of all their points.  Only the buffering process, such as the PI Buffer Subsystem, needs permission to write data to points, but it does not require any data read permission for any points. Therefore, grant separate and distinct permission levels to the interface and the PI Buffer Subsystem. The interface and the PI Buffer Subsystem should use two separate PI identities, as they have two different required levels of access. 

st-widget-{image: minPermissionsAnalySIS.png}

This most common scenarios for interface permissions are summarized in Table 5.1 below:
 
Table 5.1 - Minimum PI Data Archive Permissions for Interfaces: Buffering, No Output Points
Process Read Permissions Write Permissions
Interface PIPOINT DBSecurity, PtSecurity None
Buffering (PIBUFSS or BufServ) None DataSecurity

If a buffered interface also has output points, the only additional required permission is read to the data for the source points of these outputs.  Required access in this scenario is summarized in Table 5.2 below:
 
Table 5.2 - Minimum PI Data Archive Permissions for Interfaces: Buffering, Output Points
Process Read Permissions Write Permissions
Interface PIPOINT DBSecurity, PtSecurity, DataSecurity (output source points) None
Buffering (PIBUFSS or BufServ) None DataSecurity
 

In the uncommon scenario where buffering is deliberately not configured, then and only then does the interface process itself require write permission to the data of its points.  Required access in this scenario is summarized in Table 5.3 below:
 
Table 5.3 - Minimum PI Data Archive Permissions for Interfaces: No Buffering, No Output Points
Process Read Permissions Write Permissions
Interface PIPOINT DBSecurity, PtSecurity DataSecurity

In the even rarer scenario where buffering is not configured and there are output points, the only additional requirement is read access to the data for the source points of the output.  Required access in this scenario is summarized in Table 5.4 below:
 
Table 5.4 - Minimum PI Data Archive Permissions for Interfaces: No Buffering, Output Points
Process Read Permissions Write Permissions
Interface PIPOINT DBSecurity, PtSecurity, DataSecurity (output source points) DataSecurity
 

It is important to note that even though the interface permissions described in Table 5.4 are necessary only in the rarest of scenarios, those permissions are being used for the most common scenarios with buffering configured. One reason for this discrepancy is the well-worn methodology for setting up a new interface: first get the interface working without buffering, and then configure buffering and ensure the interface is still working. This approach is indeed a good one for functional troubleshooting. However, if you  forget to go back and remove permissions once everything is working with buffering, you will always end up with Table 5.4 and with the interface too exposed upon intrusion.

Note: The above scenarios and corresponding permission tables apply to standard UniInt-based interfaces only.  Some interfaces require additional access for certain features, such as point creation via the PI Interface for Universal File and Stream Loading (UFL). Please consult the appendix in Configuring PI Data Archive Security for other Task-Based Access Permissions and Product Access Permissions.

Security Best Practice #6: Upgrade to the latest version of PI Buffer Subsystem and use Windows authentication

st-widget-{image: YouTube_Icon.jpg}OSIsoft: Configure Most Secure Authentication for PI Interfaces & Buffering

As a system of record, it is important to maintain strict administration of PI Identities with write permission. Whenever possible, you should only grant write permissions to PI Identities using Windows authentication.

Due to the fact that most write activity is from interface nodes, and the PI Buffer Subsystem is normally enabled for writing data to the PI Data Archive, this best practice is based on using a recent version of  PI Buffer Subsystem (PIBUFSS).  If you are still using an older version of PIBUFSS or BufServ, you should install PIBUFSS 3.4.380.79 or later and use Windows authentication. As of version 3.4.380.79,  PIBUFSS has the capability to use Windows authentication on PI Data Archive 3.4.380.36 and later.  All previous versions of PIBUFSS and the PI API-based PI Buffer Server (BufServ) can only use PI trust authentication, which is a weaker form of authentication. 

In summary, PI mappings with Window Integrated Security should be used whenever possible, and especially for mission-critical activity such as write access to the PI Data Archive. Windows credential manager should be used on the interface node in cases where PIBUFSS service account credentials are invalid for a PI mapping, such as when an interface node is in a workgroup or untrusted domain.  For more information regarding leveraging Windows Credential Manager with PI applications, see KB01457.

Security Best Practice #7: Use Windows groups for PI Identity Mappings


Use Windows groups as much as possible instead of Windows users when configuring your PI Data Archive (and PI AF) PI Mappings to PI Identities as part of Windows Integrated Security.

See Figure 7.1 below for a simple example showing the creation of a PI Identity Mapping between a domain 'PIReaders' group and the 'PI Readers' PI Identity. 
See Figure 7.2 below for a simple example showing the creation of a PI AF Identity Mapping between a domain 'PIReaders' group and the 'PI Readers' AF Identity.

Using Windows groups will help you determine the distinct categories of access upfront and will require less maintenance within the PI Data Archive and PI AF Servers over time. Once properly configured, your administrative decisions should then mostly reduce to decisions about Windows group membership as opposed to anything specific to PI Data Archive and PI AF Server.  Hopefully, you already have existing Windows groups that could suffice and an organizational process for making group membership decisions, and you could merely extend this process for evaluating access to the PI Data Archive and PI AF Servers.

st-widget-{image: PISchool_SMT.png}

Figure 7.1 Using PI System Management Tools to create a new PI Identity Mapping between the Windows group 'PIReaders' and the' PI Readers' PI identity

st-widget-{image: PISchool_PSE.png}

Figure 7.2 Using PI System Explorer to create a new PI AF Identity Mapping between the Windows group 'PIReaders' and the 'PI Readers' PI AF identity


st-widget-{image: groupsNotUsers.png}

Keep in mind that you can use both Active Directory (AD) groups and local Windows groups.  While only AD groups support nesting (of other AD groups), local groups can still contain both AD groups and AD users.  Therefore, as long as you have local administrative access to the PI Data Archive computer, you may find that local groups provide some autonomy from your domain administrators in terms of managing group membership for your PI Data Archive security needs.  Of course, the more PI Data Archive computers you must maintain, the more difficult and costly it becomes to manage local groups.  Thus, at some relatively low threshold, the investment in AD groups and establishing a streamlined organizational process to update their membership becomes well worth the hassle.

Conclusion

Although certainly not exhaustive, these security best practices will greatly improve the security of your PI Data Archive. Of the seven listed, upgrading Windows and the PI Data Archive is the most important and effective, especially if you have not upgraded within the past couple of years. Newer software is generally a prerequisite for almost every security best practice, and for those that do not technically require newer software, implementation is easier and less costly with more recent versions. If you have yet to implement or at least plan to implement many of these seven security best practices, now is a great time to start making meaningful progress. As always, OSIsoft is available to help answer your questions and provide further guidance.
Article ID: KB00833 Created: 2013-08-15
Article Type: Informational Last Updated: 2017-09-11