Configuring McAfee Application Control Whitelisting and Updater Exceptions for WinCC in PCS 7

When implementing McAfee Application Control (Solidcore whitelisting) on SIMATIC PCS 7 v8.1 SP1 systems, adding an execution attribute exception for hh_wincc.exe via 'sadmin attr add -a' fails to stop event log modification blocks. The WinCC HTML help and faceplate viewer hh_wincc.exe is dynamically spawned, injected, and modified at runtime by the Split Screen Manager process CCSsmRTServer.exe. To resolve this violation, configure CCSsmRTServer.exe as a trusted Updater process using the command 'sadmin updater add -p ...\CCSsmRTServer.exe', allowing WinCC to manage runtime components without whitelisting blocks.

Industrial Cybersecurity and Application Whitelisting in PCS 7

In accordance with IEC 62443 industrial cybersecurity standards, SIMATIC PCS 7 systems frequently deploy application whitelisting tools—specifically McAfee Application Control (Solidcore). Unlike conventional signature-based antivirus software, application whitelisting solidifies the filesystem, preventing any unauthorized executable, dynamic link library, or script from running.

Siemens certifies specific versions of McAfee Application Control (e.g., version 6.1.3 on PCS 7 v8.1 SP1) under defined security guidelines. While standard Siemens software binaries are solidified into the authorized whitelist during commissioning, certain runtime components dynamically generate temporary files or modify in-memory execution handles.

Why Individual Binary Attribute Exceptions Fail for hh_wincc.exe

When an operator accesses context-sensitive help or opens certain specialized faceplates in WinCC Runtime, the system invokes hh_wincc.exe (WinCC HTML Help Viewer located in C:\Program Files (x86)\Siemens\WinCC\bin\).

Engineers often attempt to resolve whitelisting blocks using:

sadmin attr add -a "C:\Program Files (x86)\Siemens\WinCC\bin\hh_wincc.exe"

However, the Windows Event Viewer continues logging Solidcore error events: Prevented modification of hh_wincc.exe.
* Technical Reason: The attribute -a authorizes execution permissions. It does not grant write or memory modification rights to parent processes.
* In runtime, hh_wincc.exe is supervised and dynamically updated by the WinCC Split Screen Manager process CCSsmRTServer.exe.
* Because CCSsmRTServer.exe is not designated as a trusted updater, Solidcore interprets its process injection and handle manipulation as an unauthorized software tampering attempt and blocks it.

Configuring CCSsmRTServer.exe as a Trusted Updater Process

The following table details the distinct roles of execution attributes versus updater rules in McAfee Application Control:

Whitelisting Rule TypeConfiguration CommandScope of AuthorizationAppropriate UsageExecution Attribute (attr add)sadmin attr add -a <path>Allows a specific static binary to execute.Fixed third-party utilities that do not modify files.Updater Process (updater add)sadmin updater add -p <path>Grants parent process rights to create, modify, and launch child binaries.Software managers like CCSsmRTServer.exe and Windows Update.Directory Write Exemptionsadmin write-protect -r <dir>Permits files within a directory to be modified freely.WinCC project database folders and %TEMP%.

Table 1: Whitelisting rule classification in McAfee Application Control.

McAfee Application Control Standalone and ePO Configuration Commands

To resolve the hh_wincc.exe modification block cleanly:

Standalone Command Line Workflow:
* Open Windows Command Prompt as Administrator.
* Add the WinCC Split Screen Manager runtime process as an authorized updater:
cmd sadmin updater add -p "C:\Program Files (x86)\Siemens\WinCC\bin\CCSsmRTServer.exe"
* Confirm that the rule is registered:
cmd sadmin updater list
* Re-solidify the WinCC binary folder if prompted:
cmd sadmin solidify "C:\Program Files (x86)\Siemens\WinCC\bin\"
Centralized Enterprise Workflow (McAfee ePO):
* Open the McAfee ePolicy Orchestrator (ePO) console.
* Navigate to Policy Catalog > Application Control > Rule Groups.
* Under Updaters, add a new process rule for CCSsmRTServer.exe.
* Push the updated policy to the PCS 7 server and client nodes.

Verification

To confirm that whitelisting exceptions are operational:

In WinCC Runtime, open several process pictures and click the Help button or trigger an HTML help faceplate call.
Confirm that hh_wincc.exe launches cleanly and displays documentation without lag or crash dialogs.
Open Windows Event Viewer > Applications and Services Logs > Solidcore:
* Verify that no blocked modification events are recorded for hh_wincc.exe.
In command prompt, run sadmin status: verify that Application Control reports status Enabled and Solidified.

Limitations and Operational Precautions

Never place McAfee Application Control in disabled mode or observation mode indefinitely on production systems; doing so invalidates plant security compliance.
When applying official Siemens hotfixes or update collections, place Application Control into Update Mode (sadmin begin-update) before installing patches, and finalize with sadmin end-update upon completion.
Do not designate entire generic directories (such as C:\Windows\System32) as updaters; only authorize explicit, validated Siemens executables.

Engineer FAQ

What other WinCC processes require updater privileges in McAfee Solidcore?

Siemens security guidelines recommend designating CCProjectMgr.exe, CCExpServer.exe, and SIMATIC Security Controller as updaters during initial system solidification.

Does McAfee Application Control impact WinCC real-time performance?

Because Solidcore operates at the kernel file system filter driver level without continuous background file scanning, its impact on CPU and RAM performance is significantly lower than traditional signature-based antivirus software.

Can Solidcore prevent malware that runs inside PowerShell?

Yes. McAfee Application Control solidifies script environments, blocking unauthorized PowerShell scripts, VBScripts, and batch files unless signed by trusted certificates.