Part 3 of the recently released OPC Security whitepaper series provided step by step instructions for implementing the available security measures for OPC clients and servers. It is complex, and we wondered if there was a simple way to audit OPC servers compliance with Part 3. We still are wondering, but we have a partial answer.

The Tenable’s Nessus vulnerability scanner has a Policy Compliance plugin family that is available for Tenable Direct Feed subscribers. Compliance is becoming a huge issue. In fact, many of my friends with SEM vendors say that accumulating log records for compliance is driving sales of SEM products more than the security correlation and analysis features. The Policy Compliance plugins allow you to compare registry, file and other settings on a host to a predefined policy. Tenable promotes these plugins for compliance with SOX, GLBA, FISMA and other regulations.

The good news is anyone can create their own audit template, in the form of a .audit file, and use Nessus to compare a host’s configuration against the template. So we did that for the OPC security recommendations in Part 3. We have developed .audit files for Windows 2000 Server, 2003 Server, and XP as well as a document explaining the audit checks and how to modify the .audit files. These are now available for Digital Bond subscribers.

• OPC Server Audit Document
• OPC Server .audit file for Windows 2000
• OPC Server .audit file for Windows 2003
• OPC Server .audit file for XP

At the beginning of this blog, I mentioned this tool was only a partial answer. It is very effective, but some of the compliance checks require customization for different OPC servers and the DCOM auditing capabilities of Nessus are not as full featured as we would like.

A simple customization example is the check on the services running on the OPC server. We performed a default install of an operating system and OPC server and eliminated all unnecessary services. Nessus will check that only those services are running on the OPC server. Your install or standard build may have additional authorized services, and these will need to be added to the .audit file – - or you can simply ignore the findings in the Nessus results related to that service.

Another simple customization example is auditing the opc accounts. The whitepaper recommends creating and using an opcadmin and opcuser account. If you choose different account names that section of the .audit file will need to be modified.

A more complex customization is related to auditing the DCOM permissions, which are one of the most critical security settings in OPC servers. The OPC server Application ID must be added to the .audit file for this part of the audit to work. It is unique to each OPC Server version. The OPC Audit Tool document describes where the Application ID is found and where to modify it in the .audit file.

This experience with Nessus Policy Compliance has been very interesting, and we see a lot of places it would be helpful. In fact, it is slotted into some of our research projects, and we are creating .audit files for HMI and other systems for our clients. OPC is not the best example of this audit feature, but try it out and let us know what you think.