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
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
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.
||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
||Secure attribute set on cookies utilized for security
||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 pivision.mycompany.com has HSTS, it would affect all sites whose URLs match *.pivision.mycompany.com.
: there are no exclusions for subdomain sites once includeSubDomains is included; verify that HTTPS is used on all subdomains before applying this setting!
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.
||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
||Prevent clickjacking by disallowing other sites to frame PI Vision
||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.
VALUE: block-all-mixed-content; default-src 'self' 'unsafe-eval' 'unsafe-inline'; frame-ancestors ‘self’; object-src 'none'; img-src 'self' data:
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.
VALUE: 1; mode=block
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.
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
||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
||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
||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
||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
[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