NERC Publishes Practice Guide for Assessing SVCHOST.EXE

Image

One of our customers (You know who you are, thanks!) made us aware of a new practice guide titled “ERO Enterprise CMEP Practice Guide: Assessment of SVCHOST.EXE” published exactly two weeks ago today on September 15th, 2020. North American Electric Reliability Corporation (NERC) seldom releases guidance like this, so they shouldn’t go unnoticed. They’ve published three such Critical Infrastructure Protection (CIP) specific guides including this one since 2017, according to their website. The CMEP Practice Guides are described as “provid[ing] direction to ERO Enterprise CMEP staff on approaches to carry out compliance monitoring and enforcement activities.” Based on that statement, not only should they not go unnoticed, but they also shouldn’t be taken lightly due to the fact that NERC and the Electric Reliability Organization (ERO) Enterprise adopt these guidance policies and audits according to their language.

What's inside the "Assessment of SVCHOST.EXE"?

The practice guide summarizes the CIP-007-6 R1.1 requirement to establish a process for enabling only those ports on each in-scope asset that is needed for its functionality and to provide evidence to demonstrate that need. The quality of that evidence is the focus of the guide, specifically regarding a rather important Window system process called svchost.exe. Svchost.exe is integral to the function of shared service processes as it can reduce system resource consumption by doing some of the heavy lifting for port management. Therein lies the problem; svchost.exe serves as a host for many services, specifically for Dynamic Link Libraries (DLLs) and whatever port they need opened on their behalf. Here’s an example of my Windows 10 workstation’s task manager details tab in Figure 1. (Click to expand.)

Image

Figure 1 As you can clearly see, that is, in fact, a bunch of svchosts! There is a much easier way to see what’s behind each of those by looking at a different view in the processes tab, as seen in Figure 2.

Image

Figure 2 In the above example, we can see that the Windows Time service is the culprit in this instance. So as you might suspect, if a Responsible Entity (you, the asset owner) is not clearly documenting in your evidence which service is actually opening the port, i.e. only showing svchost.exe, that is inadequate per the document. At Tripwire, our customers leverage the Tripwire State Analyzer App (formerly Tripwire Whitelist Profiler App) to do all the heavy lifting to help our customers satisfy the CIP-007 R1.1 requirement and include as part of the output for its ports and services control not just the protocol (TCP), the service name (svchost.exe) and any other required fields (Iike business justifications) but also the process name that requested svchost.exe to open a port on its behalf. Here’s an example of that output:

********************************** ** UNAUTHORIZED OPEN PORT FOUND ** ********************************** Protocol: UDP Port: 123 Process Name: svchost.exe (Service Name: W32tm) Process ID: 716

In order to enumerate the service name, the Tripwire State Analyzer App employs the native Windows ‘netstat –b’ command. (It has had this functionality available for more than two and a half years.) The ‘netstat’ command was selected in order to support operating systems pre-Windows 8.1 that could not leverage Powershell commands. In response to this Practice Guide, Tripwire is performing additional research internally to ensure that our approach meets or exceeds the requirements and the language of the guide specifically. If any findings warrant it, an update will be published to this article. If you have any opinions or questions on this matter, I welcome you to reach out to me at [email protected].