Submitting your feedback...
Knowledge Base Article
KB01631 - Security tips for PI Vision
Product: PI Vision
Version(s): Multiple


Safety and security mechanisms for the web are rapidly advancing and a wealth of guidance is available.  Prominent examples include:
  • Web Security Cheat Sheet published by Mozilla listing web security guidelines and ranking them in terms of effectiveness, implementation difficulty, and recommended order.
  • Benchmarks for IIS published by the Center for Internet Security (CIS).
This article highlights measures in the sources above you can use to make PI Vision more secure.
Note: this article assumes familiarity with basic web security terminology. Links have been provided where appropriate to external sources that explain these terms. A Glossary of acronyms is also included at the end of the article.

1. Configure Strong Transport Layer Security

First, before implementing any layered defenses, ensure that an HTTPS binding is configured for the web site and Transport Layer Security (TLS) settings are optimized.  The binding should use a certificate issued by a trusted authority, either a 3rd party trusted by the OS or an enterprise CA managed by your IT department, not a self-signed certificate issued by the web server.  Server-side TLS settings should disable insecure ciphers.

PI Vision installs with an HTTPS binding by default, but upgrades for PI Vision do not reconfigure existing site settings. If you are upgrading from PI Coresight, then may need to configure PI Vision to use and HTTPS binding. For instructions about how to configure an HTTPS binding, see this Live Library section.

Recommended TLS settings are provided by Mozilla, CIS, and others. Configuration as per the MS support article on restricting cryptographic algorithms and protocols is often tedious.  The IIS Crypto utility is a convenient tool to set the server-side TLS settings, with GUI and command line options.

2. Ensure clients use TLS

Users will not always remember to use HTTPS once it has been configured, so it is a good practice to gracefully redirect them from the HTTP endpoint to the HTTPS endpoint. There are numerous methods to implement this redirect. Method 1 in the MSDN blog post HTTP to HTTPS redirects on IIS 7.x and higher provides a simple option. It leverages the URL Rewrite Module (available via Web Platform Installer or direct download).

3. Layer defenses with HTTP Headers

You can use HTTP Headers to enable optional layers of web defenses built into modern browsers. Browsers often connect to many servers at a time. Layers of defense help protect users and PI Vision from other web sites. The following table lists some common threats and defenses against them that are automatically enabled by PI Vision 2017.
Threat Defense
Insecure Resources Resources loaded over HTTPS (if HTTPS binding configured)
Cross-Site Request Forgery (CSRF) 2017 release implemented protection (AL00320)
Cross-Site Scripting (XSS) X-Content-Type-Options header set to ‘nosniff’ to reject responses with incorrect MIME types. MIME type confusion presents XSS threats as illustrated in this MSDN blog post
Cookies Secure attribute set on cookies utilized for security
Clickjacking X-Frame-Options header set to ‘SAMEORIGIN’ to prevent framing from other sites

OSIsoft will continue to enable browser defenses as part of each PI Vision update. Provide feedback on the OSIsoft customer feedback site if you are interested in a specific header.

In the meantime, you can configure custom HTTP response headers to harden your system. For detailed instructions on how to add a custom header, see Custom Headers on IIS.NET. That guide provides instructions using IIS Manager or working with configuration files.

HTTP Strict Transport Security (HSTS)

This header instructs the browser to upgrade all requests to HTTPS, even if the user attempts to access via HTTP explicitly.  Additionally, HSTS will prevent the click through prompts that allow users to ignore certificate errors and navigate to a site anyway.  The max-age parameter indicates how long subsequent requests should be upgraded to HTTPS (in seconds). Mozilla suggests a minimum of 6 months (15768000 seconds) but recommends two years (63072000 seconds).

You can apply this setting to all subdomains with the includeSubDomains attribute. This means if has HSTS, it would affect all sites whose URLs match *

Note: there are no exclusions for subdomain sites once includeSubDomains is included; verify that HTTPS is used on all subdomains before applying this setting!
NAME: Strict-Transport-Security
VALUE: max-age=63072000; includeSubDomains

Content Security Policy

Content Security Policy (CSP) enables tight control over where resources (that is other files in addition to the main webpage) are loaded from. CSP detects and mitigates attacks such as XSS, clickjacking and code injection. Although it is not yet possible to implement strict CSP settings with PI Vision, the following table lists settings currently available.
Directive Benefit
block-all-mixed-content Prevent insecure resource loading
default-src ‘self’ ‘unsafe-inline’ ‘unsafe-eval’ Limit to resources from same scheme, domain, and port as PI Vision, although inline and eval cannot be eliminated
frame-ancestors ‘self’ Prevent clickjacking by disallowing other sites to frame PI Vision
object-src ‘none’ Disallow plugins like Flash and Silverlight since they are not needed
img-src ‘self’ data: Allow data: only for images and limit images to the same scheme, domain, and port

Combining the benefits listed in the table produces the policy below, which provides added protection from insecure resources, plugins, foreign resources, and clickjacking.
NAME: Content-Security-Policy
VALUE: block-all-mixed-content; default-src 'self' 'unsafe-eval' 'unsafe-inline'; frame-ancestors ‘self’; object-src 'none'; img-src 'self' data:

XSS Protection

Adding this custom header allows supporting browsers (Internet Explorer, Edge, Chrome and Safari) to block reflected XSS attacks detected by the browser. “The misunderstood X-XSS-Protection” is an interesting article that illustrates the disadvantages of the default value of this header.
NAME: X-XSS-Protection
VALUE: 1; mode=block

Referrer Policy

The HTTP Referer (sic) header can reveal the site a user originated from to the destination site. A Referrer-Policy header set to 'same-origin' will include the "Referer" header only when the linked destination has the same origin as the original page with the link. Using the setting 'no-referrer' will avoid sending the header altogether.
NAME: Referrer-Policy
VALUE: same-origin
That is all there is to it: four name-value pairs that can bolster security for your PI Vision installation!

To learn more about securing PI System applications, check out the PI System Cyber Security page or the PI Square Security Group.


Acronym Full Term Description
CSP Content Security Policy " [A]n added layer of security that helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS) and data injection attacks. These attacks are used for everything from data theft to site defacement or distribution of malware." - Mozilla
CSRF Cross-Site Request Forgery " [A]ttack that forces an end user to execute unwanted actions on a web application in which they're currently authenticated." - OWASP
HSTS HTTP Strict Transport Security " [O]pt-in security enhancement that is specified by a web application through the use of a special response header.  Once a supported browser receives this header that browser will prevent any communications from being sent over HTTP to the specified domain and will instead send all communications over HTTPS. It also prevents HTTPS click through prompts on browsers." - OWASP
TLS Transport Layer Security "TLS and SSL are most widely recognized as the protocols that provide secure HTTP (HTTPS) for Internet transactions between Web browsers and Web servers. [...] TLS/SSL enables server authentication, client authentication, data encryption, and data integrity over networks such as the World Wide Web." - TechNet
XSS Cross-site Scripting " [T]ype of injection, in which malicious scripts are injected into otherwise benign and trusted web sites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user." - OWASP
Article ID: KB01631 Created: 2017-08-28
Article Type: Informational Last Updated: 2017-08-29