Part of a PI administrator's job is to make sure that the PI system is as reasonably secure as possible. However, sometimes, it is PI itself that must be made more secure. This post compiles many of the security-related suggestions from OSIsoft's feedback website. If you don't like getting hacked or if you don't want users accidentally changing stuff, please consider voting for some of these suggestions!
Some of the products listed on the feedback website have a Security category. The links below will take you to all Security suggestions for their corresponding product:
However, not every security-related suggestion is in the Security category, hence the table below. This could be because the product does not have a Security category or because a different, but still appropriate, category was chosen instead.
Some general notes about the suggestions that were included:
- The suggestions do not appear in the Security category.
- The suggestions are hand-picked. I might have missed some, and the list is up-to-date only as of the time of this post.
- Generally, a suggestion is included if and only if its fulfillment will increase security, will add more options for configuring security, or will help promote secure practices or cybersecurity awareness.
- Suggestions for deprecated or superseded products are generally not included unless the product is still heavily used.
- Some root words of search terms that I used: secure, authorize, authenticate, impersonate, permit, restrict, access, certificate, HTTPS, TLS
Explanation of terms
Below is an oversimplified explanation of some of the technical terms used above. If I didn't explain a term, it's because I don't know it.
|Term||Explanation & relation to security|
|HTTPS||HTTP, but encrypted|
|HSTS||Redirecting HTTP to HTTPS on the server is not enough, since the client can initiate an insecure HTTP connection at any time. If a browser connects to a website that uses HSTS, the website will instruct the browser to use only HTTPS (and not HTTP) with that website in the future.|
|HSTS preloading||New releases of browsers come preloaded with a list of websites that request HSTS, which avoids the need to visit the website first. This avoids the possibility of the client's first-ever connection to the website being made over insecure HTTP.|
|After you enter your user name and password, you provide further proof of your identity before the login is successful. Usually, this is a number on an authenticator app on your phone, a number from a text message to your phone, or the activation of some hardware that only you have.|
|Their encryption is too weak to be considered secure. TLS 1.2 & TLS 1.3 are better.|
This compilation would not be complete without also mentioning the suggestions that, if implemented, would promote or prolong poor security practices as a side effect of wanting extended or better support for legacy technology to delay/avoid the cost and effort of migrating to the latest technology. Don't vote for these.
Some search terms that I used: IE, Internet Explorer, (PI) Trust, HTTP
|PI Buffer Subsystem||Allowing users to edit IP Address for creating a trust with Add Data Server Wizard in Buffering Manager|
|PI ACE||Extend Support for PI's Advanced Calculation Engine (ACE)|
|PI Connector||Better support for IE|
|PI Connector For UFL||Support Administration Pages on IE|
|PI Data Collection Manager||Make the PI Data Collection Manager default to a more user-friendly configuration|
|PI Vision||internet explorer vs Chrome|
|PI Integrator For Business Analytics||Allow PI Integrator Installation without requiring HTTPS/SSL|
|PI DataLink||Include Option to Install Legacy Add-Ins Via Installation Wizard|
|PI DataLink||Continue to support/modify the PI Trend Add-In for Excel DataLink that was in 2014 on into 2016 and beyond.|
|myOSIsoft||The current OSISoft web site is not working with Microsoft Internet Explorer 11 which is the supported|
|OSIsoft Learning||Emphasize the concept of 2+ trust in 'Configuring a Simple PI System' Online Course|
- PI Trusts are superseded by PI Mappings. PI Trusts grant permission partly based on the name of the program. However, nothing stops a malicious program from having the same name as a permitted program.
- Microsoft dropped Internet Explorer like a hot potato. New vulnerabilities that are discovered in Internet Explorer will not necessarily be patched, which leaves Internet Explorer users vulnerable to them. This reasoning can be generalized to anything that is deprecated/legacy.