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
- 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, encrypt, 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 still initiate an unencrypted 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.|
|Insecure protocols that have been superseded by TLS 1.2 & TLS 1.3.|
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 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.
- ActiveX is deprecated and insecure, and so any PI program that uses ActiveX is also insecure.