Q: So Applocker only applies to apps a "user" tries to run, doesn't apply to background services?
A: Yes, Applocker dll and exe rules are ignored when Windows starts a background service. In a sense, the PI services are whitelisted by administrators when installed. As a next step, we may be able to develop code integrity policy for the newest versions of Windows as a strong whitelist for background services.
Q: How do we get security notifications for any vulnerability identified for PI server or interfaces?
A: See OSIsoft KB01199 for details on how to subscribe to security bulletins.
Q: In November 16, CERT Australia received a public report of a vulnerability within a number of OSIsoft PI System products which could result in a denial of service. OSIsoft have released patches for the affected products so have they all been addressed?
A: Yes, affected products have all been addressed. The report this question is referring to is linked here: CERT Australia’s report. This report refers to an OSIsoft security bulletin AL00308 with the relevant details.
Q: Is there a requirement for ANY tcp/udp ports to be opened other than the standard PI 5450?
A: This question is likely concerned that additional ports need to be opened when switching from a PI Trust to Windows authentication. You do not need to open additional ports.
In a scenario where the interface is in a workgroup, it must be able to access TCP ports:
- Destination Port 5450 on the PI Data Archive, to receive point attribute updates and initially connect
- Port 53 to the DNS server (if DNS is needed for name resolution)
In a scenario where the interface is domain joined, in order to leverage Kerberos, the interface must be able to communicate with active directory infrastructure (2820OSI8).