I figured it’s about time to write an updated version of my PI System Security blog. OSIsoft has done a lot of changes on security since 2014.
First we can take the question, why do you need to restrict the security for your data down to departments, service accounts, administrators, who has read/write access?
Security today isn’t just to stop a hacker at the firewall level. Let’s face it if you are targeted they will compromise your environment, back in the early 00’s it might have been good enough to have a basic firewall installed but in 2017 you have think security in every level of your organization. Your firewalls are just one of many barriers used to stop/limit the damage a hacker can do.
As many of us knows humans are known for “human error”, therefor the most important security measure you do is training and we are not talking about the “modern” AI training, actual people training. Us humans are the first security barrier any intruder meets, either by phishing, configuration of equipment or general social engineering.
Zero-days, Stuxnet, etc. While everyone is talking about Stuxnet and zero day’s people seems to forget the basics. Attacks like Stuxnet shouldn’t be ignored but remember this is a targeted attack by a large organization or nation with (likely) ten times the resources your IT department get in ten years. Once you are targeted by this kind of attacks there are little you can do other than involving the authorities. Unplug your internet connection, shutdown any non-essential equipment. But in the end of the day, this isn’t your/our job. Consider it like a military attack, the civilians wouldn’t jump to arms guns blazing. Focus on the important tasks that your budget allows. Security updates, windows update! The number of zero day’s attacks and targeted “Stuxnet” attacks are low, only when the zero day’s are announced (and hopefully patched) the number of attacks on these holes explode. Back to the basics that everyone seems to forget: Windows Update. EVEN IN OFFLINE NETWORKS! Reason you really need to patch offline networks is that you (likely) have some way of connecting to it from your office network. Your firewall isn’t your primary/only defense, if an attacker get’s inside your firewall and then crawls down to your “offline” network and discovers servers that hasn’t been patched for the last two years he will jump out of he’s chair and scream “P00WN3D!” Game over. I would even patch an entirely isolated network, even patch your servers that isn’t even on! Patch or destroy (physically).
I spent some time looking into pen test and social engineering and it amazes me some of the stories. “I just walked in the front door when someone was exiting, plugged in a USB in the first PC I found and in 24 hour I had full access”. Wait, what? Walked in the front door, that’s it.
Thankfully none of the client’s I have visited has that easy access. They have a receptionist and you can’t walk in without an appointment and you must be guided at all time. Locked doors everywhere, and visitors doesn’t get access card. But then you have “I just told the receptionist that I’m from the HQ IT dept.”, again you need an appointment, if you don’t have one people needs to be trained to not let them in, call HQ or wherever he claims to come from. Double check with IT if there is any reason he should be there at all etc.
Phishing. It’s a reason it still exists, people at all levels falls for them. It’s easy and unfortunately they keep getting better and better. One of our clients actually sends out phishing mails to it’s own users. Not actual phishing but mail formatted just like any other phishing mail. If you click any link in the mail you’ll automatically be registered for training (more or less). Important, not to punish people but to train them.
In short there isn’t any magical answer or one out of the box solution to solve all your security concerns. Security starts and end with the humans. Think security in all aspects of your operations. Physical, training, IT, configuration, firewalls, maintenance, software, operation systems. No point of building a bunker to house your backup if they are exposed to the internet. And no point of locking down software at all imaginable ways if they can just walk right in and take the box.
PI Data Archive
Limiting read/write access at user level, service level and “system level” is generally my go to strategy for PI Data Archive security.
I usually divide users in sites with their own read and write groups. Depending on the client users with write access has write access to all data for that site. In most of the cases almost all write access (data) could have been eliminated if OSIsoft added an additional level for annotations. There is usually a weary low number of users that manually write data.
When it comes to what I call “service level” I mean external services and interfaces that reads/writes data to a selection of tags. Even if they require global access to all data I always create one identity for each service/interface. The only exception I make is the “system level”
By “system level” I think of the PI System components such as the PI Analytics processor. I default to that the PI Analytics processor has read access to all data. The reason is simply that it takes to much time to configure security every time someone makes a new calculation in AF. Often super users can and know how to configure analyses but they are not allowed to control the security for PI tags. Which results in they creating a help-desk request on why their calculation isn’t working and depending if the case ends up with someone that knows the security model or not it can take everything from 5 minutes to 1 day to solve the issue. I understand that this is a principal that goes against my own claims (limit security to the minimum, train people) but when we put in PI Vision (PI Coresight) in the same environment everything starts to make more sense. In order to search for PI tags in PI Vision the crawler needs read access to the tags. Now we have two components of the PI Environment that I consider “system level” that both benefit from global read access.
In general, I would like if OSIsoft made some overall of the security model in the PI Data Archive, making it possible to have a template (at server level) for new tags and not just use the database setting. As many services needs access on database level but shouldn’t necessary have access to new tags. Like when you create a new analysis and the output tag from PSE, there is no reason that APS should have access to this tag but APS needs to have access to create new tags and therefor needs to have write access on the PIPoint database.
PI Asset Framework
OSIsoft has done many good things with the way you now configure security in PI AF. When I wrote my original PI Security post we had to go through each component manually (Element, Notification, Analysis, etc) but now you just checkmark which one you want to configure.
AF Identities, at the moment I’m not sure how I feel about them. It’s a good idea but also a bit confusing. I would like that AF Identities and PI Identities was the same thing (synchronized). Yes we do the same mappings for identities in AF that we do in PI Data Archive, why shouldn’t it just be synced (just the name and mapping, can’t simply sync the actual access)? One (maybe) cool solution would be that Point security is synced from where it’s placed in AF, but this woud be werry complex and might be close to impossible to get user friendly with the configuration capabilities needed (tags in AF can be for several sources in one element, the interfaces needs write access to its tags but not to tags for the other interfaces etc.)
Kerberos configuration etc – just take a look at Lubos Mlcoch post Coresight Squared – What’s next? Kerberos and more..?
I can only say, use Kerberos and SSL. If you need mobile access you have to use Basic authentication. Be warned! Basic authentication is username and password sent in “clear text” over the network. Never use Basic authentication (in any case, not just PI Vision) over an un-encrypted line. Secondly basic authentication is CPU intensive since each and every request get’s authenticated again and again. We’ve seen servers go down with using basic authentication on PI WebAPI intensive querying but PI WebAPI was never the real issue it was lsas.exe. So keep in mind basic authentication doesn’t scale good. If your environment is configured correctly you will limit the usage of basic authentication to just be between the client and PI Vision and from there it should be Kerberos authentication.
In the current release PI Vision load’s its identities from AF, but it only shows the once you are member of yourself. As an administrator this means that you have to be member of each single identity in order to configure access others.
It’s not brand new anymore but the new API introduced Windows authentication.
Where’s the Champagne?!
Right after the release I read through the documentation https://techsupport.osisoft.com/Troubleshooting/KB/KB01457 I just realized lot’s of text, so I’ll give you the short version:
Both interface node and PI Data Archive are member of the same domain:
- Change service account on the interface to a domain account, map that account to the interface identity (that you of cause configured after my recommendations above J)
- Create a local account on the interface node
- Logon with the new account
- Open credential manager -> Windows credentials
- “Add a windows credential”
Internet or network address: PI Data Archive machine name
- Test by %pihome%\adm\piartool -node PIDataArchvie -Windows -block pibasess –authdebug
- Note that there isn’t any clear “authentication failed” on this test, but if it fails it’s likely incorrect username or password. The credential manager doesn’t test your credentials.
Interface not part of the same domain as the PI Data Archive server
If you can’t logon with the local user created for this interface:
- Runas /user:ServiceAccountForInterface cmd
- CMDKEY /add:PIDataArchive /user:Domain\User/pass
- It will ask for password when you execute above
- Test by %pihome%\adm\piartool -node PIDataArchvie -Windows -block pibasess –authdebug
- NOTE: Needs to be a CMD window that runs as the same account as step 1 (your service account)
Sample success message: