Some observations after going through the tedious process of creating and modifying Windows service policy checks for an upcoming Bandolier release…

1.) The value of the OS-level audit files is different than I first thought.

I blogged about this last year after recognizing that I had mistakenly underestimated the value of the Bandolier OS-level files. The blog post shows how we are able to check a specific set of services based on the function of the server. Fast forward one year, and I’m still making new discoveries about the OS checks.

2.) Best practice is a starting point, not an end goal.

One of the problems with best practice for control systems is that it sometimes breaks application functionality or causes availability problems. We’ve made sure to identify those things and customize the Bandolier files accordingly. We even adopted the term “optimal security configuration” to describe what we measure with Bandolier. At first, I thought of this term as something less than best practice (albeit still useful), but that is not the case.

A good case in point is found in the soon-to-be-released AREVA e-terra audit files. AREVA defines for their customers exactly which services should be enabled and disabled and the list goes way beyond the traditional best practice standard. We are capturing those service policies in a customized OS-level audit file for the upcoming AREVA release. (This has been the case with most of the audit files thus far, but AREVA e-terra provides a stark example because of the number of service checks.)

3.) Windows service policies by the numbers:

38: Number of service policies outlined in CIS Benchmark for Microsoft Enterprise Servers.

41: Number of service policies outlined in CIS Benchmark for Microsoft Specialized Security-Limited Functionality (SSLF) Servers.

141: Number of service policies outlined in the AREVA e-terra System Security Guide (Automatic, Manual, Disabled)

57: Number of services beyond the CIS benchmark that should be disabled in an AREVA e-terra app server

That means there are at least 57 custom checks in the baseline Windows 2003 security audit file for AREVA e-terra servers. Of course, there are a host of other checks in the audit files for the various application components. (See a list of the components here.)

These observations have reinforced for me that Bandolier is not just about bending the best practice rules to work in control system applications; it’s about looking beyond best practice for the optimal security configuration for each application component. Optimal in the sense that it doesn’t break application functionality and in the sense that it’s customized in a way that a generic benchmark can never be.