PCS 7 V9.0 Symantec Endpoint Protection: Firewall Policy

Overview of the PCS 7 / Third-Party Security Software Constraint

SIMATIC PCS 7 V9.0 is a process control system designed for continuous operation in industrial environments. The system relies on a tightly defined set of Windows services, COM/DCOM components, S7 communication channels, and SQL Server instances. When third-party security products are introduced, two categories of risk appear: (1) real-time packet inspection or connection-state tracking that interferes with industrial protocols, and (2) on-access file scanning that delays or blocks writes to the project directories and to the WinCC archive databases.

Siemens documents its compatibility scope explicitly: only the Windows Firewall bundled with the operating system is released for use with PCS 7 and WinCC. Components from Symantec Endpoint Protection, McAfee Endpoint Security, Trend Micro, Sophos, Kaspersky, or similar products are not part of the compatibility test matrix. This is the engineering equivalent of "out of scope" - the vendor has not validated the interaction, and a failure cannot be escalated as a product defect.

The practical consequence is straightforward. The firewall module of Symantec Endpoint Protection (the SEP client firewall, also called the Network Threat Protection module) must be disabled on every PCS 7 station. The Windows Firewall must remain enabled and rule-defined by the PCS 7 setup. The antivirus/antispyware, intrusion prevention, and exception-based application control functions of SEP may remain in place, provided they are configured to whitelist the PCS 7 processes, paths, and ports.

PCS 7 V9.0 Security Architecture

PCS 7 V9.0 supports the following Windows platforms, which are documented in the PCS 7 V9.0 release notes on the Siemens Industry Online Support portal:

• AS / OS server: Windows Server 2012 R2 Datacenter (64-bit) or Windows Server 2016 Datacenter (64-bit)
• Engineering station (ES) and Operator Station (OS) clients: Windows 10 Enterprise LTSB 2016 (64-bit) or Windows Server 2012 R2 / 2016
• Process Historian and Information Server: Windows Server 2012 R2 or 2016 Datacenter

The system uses WinCC V7.4 SP1 as the runtime. SQL Server 2014 SP2 (Standard or Enterprise) provides the archive and message database. SIMATIC Logon Service provides central user management through Active Directory.

Three communication classes cross the firewall boundary:

1. S7 communication between AS and OS over ISO-on-TCP, TCP/102. This is the field-level path carrying the process image, alarms, and operator authorization.
2. DCOM / OPC between OS servers, between OS server and OS client, and between the ES and the OS server. DCOM uses an initial connection on a high RPC port and then negotiates a callback port in the ephemeral range 49152-65535.
3. WinCC archive and user archive replication over TCP/1433 (SQL Server) to the Process Historian, plus TCP/2308 (SQL Server Browser) and TCP/5050-5051 for SIMATIC Logon and license service.

A stateful firewall that is not tuned to the PCS 7 DCOM behavior will close the callback port, and OPC connections will fail with CoCreateInstance errors and RPC server unavailable messages. A non-stateful product that filters by content can corrupt the S7 frames on TCP/102. The Siemens engineering rule resolves this by limiting the firewall to the Windows platform's own, PCS 7-aware rule set.

Siemens Compatibility and Release Policy

The release statement is published in the SIMATIC PCS 7 / WinCC security concept and in the PCS 7 V9.0 readme. The exact statement is: "Firewall - only the Windows Firewall is released for use with PCS 7 and WinCC, as this is configured automatically depending on the product installed."

This is not a recommendation - it is a release boundary. From a quality-management standpoint, only the components inside the release boundary inherit a Siemens support commitment. Components outside the boundary are at the integrator's risk.

The technical rationale is that the Windows Firewall is configured by the PCS 7 setup to open exactly the ports and protocols required by WinCC, and Siemens can guarantee that the ruleset is correct. Third-party firewalls do not have a PCS 7-aware rule set, and the integrator must hand-craft the rules, which is error-prone and outside the test matrix.

The release boundary also extends to remote-management tools. Remote Desktop Protocol (TCP/3389), WinCC Remote Bridge, and the SIMATIC Automation License Manager all have specific firewall requirements that the Windows Firewall handles automatically. A third-party firewall that intercepts RDP, for example, can break the TLS handshake and produce a "Remote Desktop cannot verify the identity of the remote computer" error that looks like a certificate problem but is in fact a packet filter.

Symantec Endpoint Protection Architecture

Symantec Endpoint Protection (SEP) consists of two products installed on the Windows host:

1. Symantec Endpoint Protection client (SEP client) - the local protection stack. It contains the firewall (Network Threat Protection), antivirus/antispyware engine, intrusion prevention (Proactive Threat Protection), application and device control, and the system lockdown component.
2. Symantec Endpoint Protection Manager (SEPM) - the management server. The SEPM hosts the policies, definitions, and the Java console. Clients pull policies from the SEPM over HTTPS (default TCP/8443 or TCP/9090 depending on version).

Firewall and antivirus policies are defined in SEPM and pushed to the client. The client enforces them locally. According to the Symantec Endpoint Protection Manager - Antivirus and Antispyware reference, the Antivirus and Antispyware Policy is the central policy object that contains the scan settings, exception lists, and the Scans tab used to schedule on-demand and scheduled scans.

For a PCS 7 host, the policy flow is:

1. The PCS 7 station joins the SEP client group "PCS 7 Hosts" (a group you create in SEPM).
2. The "PCS 7 Hosts" group inherits a customized Antivirus and Antispyware Policy with the PCS 7 exclusions.
3. The same group overrides the Firewall Policy to a "Firewall Disabled" template.
4. The Exceptions Policy is configured with PCS 7 application, file, and folder exceptions.

SEPM version compatibility is important. SEP 14.x supports Windows Server 2012 R2 and 2016 natively. SEP 12.1.x is the last version that supports Windows XP and Server 2003 - if the plant has legacy PCS 7 V7 stations, they may still be on SEP 12.1. SEP 14.0 MP1 and later support Server 2016 and are the recommended versions for PCS 7 V9.0 on Server 2016. For Server 2012 R2, SEP 14.0 MP2 or later is required to receive current definition updates.

Disabling the SEP Firewall Component

Two methods exist. The first uses the SEP client UI on each host; the second uses an SEPM policy and is the correct one for a fleet of PCS 7 stations.

Method A: Local SEP Client UI

1. Open the SEP client by clicking the system tray icon (gold/yellow shield).
2. Click Change Settings in the main window.
3. Click Configure Settings next to Network Threat Protection.
4. Clear (uncheck) Enable Network Threat Protection.
5. Click OK.
6. Repeat on every PCS 7 station (AS, OS Server, OS Client, ES, Process Historian, Information Server).

This method is suitable for one or two hosts. For a full PCS 7 plant, use the SEPM method.

Method B: SEPM Policy Override (Fleet)

1. Open the SEPM console and connect to the SEPM server.
2. Navigate to Policies > Firewall.
3. Create a new Firewall Policy named "PCS 7 - Firewall Disabled".
4. Open the policy, and on the Policy Settings tab, set Enable this policy to Off (or uncheck the rule enforcement).
5. Save the policy.
6. Navigate to Clients, locate the "PCS 7 Hosts" group, right-click and choose Properties > Policies.
7. Detach the inherited Firewall Policy and attach the new "PCS 7 - Firewall Disabled" policy.
8. Click OK and force a policy update on the clients (Update Policy from the client UI, or wait for the next heartbeat).

Verify on a client that the SEP client shows Network Threat Protection as Disabled. The Windows Firewall should now show as the only active firewall:

PS> Get-NetFirewallProfile | Format-Table Name, Enabled
Name    Enabled
----    -------
Domain     True
Private    True
Public     True

All three profiles must report True. If any profile shows False, the Windows Firewall was disabled by the SEP installation. Re-enable it through Group Policy or through netsh advfirewall set allprofiles state on. The Public profile is rarely used on a closed control network, but it must remain on because the OS server may join a public profile on first boot if the network is not classified.

Activating and Verifying Windows Firewall

The PCS 7 setup writes a Windows Firewall rule set during installation. Do not delete or modify these rules. Verify their presence with PowerShell:

PS> Get-NetFirewallRule -DisplayGroup "SIMATIC*"   | Select DisplayName, Enabled, Direction, Action
PS> Get-NetFirewallRule -DisplayGroup "WinCC*"     | Select DisplayName, Enabled, Direction, Action
PS> Get-NetFirewallRule -DisplayGroup "SQL Server*" | Select DisplayName, Enabled, Direction, Action
PS> Get-NetFirewallRule -DisplayGroup "SIMATIC Logon*" | Select DisplayName, Enabled, Direction, Action

If any rule group is missing, the PCS 7 setup was not run with administrator privileges or was rolled back. Re-run the setup. Do not hand-craft replacement rules - they will not match the Siemens test matrix.

The Windows Firewall logging can be enabled per profile to confirm what is being allowed and denied. Run netsh advfirewall set allprofiles logging allowed enable on the OS server to capture accept events, then read %systemroot%\System32\LogFiles\Firewall\pfirewall.log to confirm the S7 and DCOM traffic is being allowed.

Antivirus Scan Exclusions: Paths, Processes, and Extensions

The antivirus module can remain enabled, but it must be told to leave PCS 7 files alone. The exclusion list is defined in the SEPM under Policies > Antivirus and Antispyware > [Policy Name] > Windows Settings > Exceptions > Scans. According to the SEP Manager Antivirus and Antispyware reference, the Scans tab is the location to specify the exception rules for on-access, on-demand, and scheduled scans. The exclusions are layered: Windows Exceptions cover the file system, Application and Device Control covers the executable launch path, and Application Exceptions cover the specific process identities.

Required Folder Exceptions

Required Process Exceptions

Required File Extension Exceptions

• *.log - WinCC, S7, Process Historian, Information Server log files
• *.mdf, *.ldf, *.ndf - SQL Server data and transaction log files
• *.AR0 through *.AR9 - WinCC alarm archive files
• *.TRC - WinCC trace files
• *.PDL, *.PDB, *.PDL.CC - WinCC picture files and picture cache
• *.LST, *.PZL - WinCC list and process value archive files
• *.bak, *.trn - SQL Server backup and transaction log backup files

Add these to the Scans tab in the SEPM Antivirus and Antispyware Policy. Apply the policy to the "PCS 7 Hosts" group. The exclusions are additive - they layer on top of the default Symantec exclusions, they do not replace them. Always close the policy with a verification scan from the SEPM console to confirm the rules have propagated.

Required Network Ports and Protocols

The Windows Firewall ruleset must permit the following traffic. Confirm with PowerShell:

PS> Get-NetFirewallPortFilter |
    Where-Object { $_.LocalPort -match "^(102|1433|2308|3389|5050|5051|8443|9090|4900|4901|4902|5001|5002|80|443|22|445)$" } |
    Select-Object LocalPort, Protocol, InstanceID | Format-Table -AutoSize

The DCOM range is the most common source of failure. The Microsoft default dynamic port range since Windows Vista is 49152-65535. The PCS 7 setup opens this entire range between the OS server and OS client. If a network engineer has narrowed the dynamic port range for security reasons, the PCS 7 DCOM will fail. Verify with:

PS> netsh int ipv4 show dynamicport tcp
Protocol tcp Dynamic Port Range
Start Port      : 49152
Number of Ports : 16384

If the range has been narrowed, restore the default or set a static DCOM range through the registry and the Component Services snap-in (dcomcnfg > My Computer > Properties > Default Protocols > Connection-Oriented TCP/IP). A static range of 49152-65535 (or a sub-range such as 50000-50100 for 100 simultaneous DCOM connections) is acceptable and reduces the firewall opening.

SQL Server, WinCC Runtime, and Process Historian Exclusions

SQL Server is the largest single performance risk under antivirus scanning. The SQL engine maintains an append-only pattern in the transaction log and a checkpoint-driven pattern in the data files. Real-time scanning of *.mdf, *.ldf, and *.ndf files can introduce I/O latency of 5-30 ms per write, which compounds across thousands of inserts per second in the WinCC archive.

The Process Historian (PH) uses a proprietary compressed storage. Each cycle, the OS server pushes its alarms, messages, and process values to the PH over TCP/1433. The PH also generates a high volume of small writes to its own data directory. The same exclusion rules apply:

• Add the PH data directory (default C:\Program Files\Siemens\Automation\Process Historian\DB) to the folder exclusion list.
• Add the PH service executables (PHSrv.exe, PHConfigService.exe) to the process exclusion list.
• Add the Information Server data directory (C:\Program Files\Siemens\Automation\Information Server\IS\data) and the service (WCCILpmon.exe) to the same lists.

For the WinCC Runtime, the alarm and tag logging archives are switched between on disk by the alarm server. The list of archive files (*.AR0..AR9, *.PZL, *.LST) rotates and grows. The exclusion must cover the entire project path, not just the project root, because the picture cache (*.PDL.CC) and the picture tree database (*.PDB) are also high-write.

The OS server's own SQL Server instance (for the local project archive) must be excluded in the same way. On the OS client, the WinCC client runtime does not host a SQL instance, but it does host the SQL Server Native Client. Exclude SQLNCLI*.dll and sqlncli*.dll from the on-access scan to prevent the client from being slow at login when the WinCC client pulls the user archive schema.

SIMATIC Logon and Active Directory Integration

SIMATIC Logon Service (SCC) provides the central user authentication for PCS 7. It queries the Active Directory through LDAP (TCP/389 or TCP/636 for LDAPS). The SCC service is configured per station; the Logon server role is on one PCS 7 host (typically the domain-joined OS server). If the SEP firewall is still enabled, the LDAP traffic to the domain controller will be subjected to SEP's packet filter, which can flag the LDAP query as a connection-state mismatch when the OS client reconnects after an operator lock.

To confirm the Logon service is functional after the SEP firewall is disabled, run on the OS client:

PS> Get-Service -Name "SCCLogonService" | Select Status, StartType
Status     StartType
------     ---------
Running    Automatic

PS> Test-NetConnection -ComputerName <DomainController> -Port 389
ComputerName     : <DomainController>
RemoteAddress    : <IP>
RemotePort       : 389
TcpTestSucceeded : True

If Test-NetConnection fails on TCP/389 or TCP/636, the Windows Firewall is missing the LDAP rule, or the SEP firewall is still intercepting. Fix the Windows Firewall rule first (it should have been added by the PCS 7 setup), then re-check the SEP client firewall status.

SIMATIC Logon also relies on the WinCC Logon plug-in (SCCLogonHost.exe and CCUserAdmin.exe). These must be added to the SEP application exception list. If a user receives "Logon server not reachable" on one OS client but not another, the SEP exception list is usually the cause - the policy has not propagated to the failing client.

Redundancy and License Service Considerations

PCS 7 V9.0 supports redundant OS server pairs. The redundant pair exchanges a heartbeat over a dedicated NIC or VLAN, defaulting to TCP/5000 (the redundancy port). The rt_hrt.exe process on each server monitors the partner's status. If the SEP firewall is enabled, the heartbeat packet is inspected and the connection is dropped after the first SYN retry, causing a false failover.

For licensing, the Automation License Manager (ALM) uses AR_SVC.exe on the license server and the local ALM service on each host. The license service port range is 4410-4411 by default, with the proprietary AR_SVC protocol on TCP/5001-5002. Add the license service path (C:\Program Files (x86)\Siemens\Automation\bin) to the SEP folder exclusion and the AR_SVC.exe process to the SEP application exception.

The Information Server uses SQL Server Reporting Services (SSRS) internally. SSRS listens on TCP/80 (default) or TCP/443 (HTTPS). Add ReportingServerService.exe, ReportServerWebApp.dll, and the SSRS report directories to the SEP exception list. The Information Server also uses OPC UA, defaulting to TCP/4840. Open the port in the Windows Firewall and add the OPC UA server executable to the SEP application exception.

Verification Procedure

After the configuration is applied, run the following verification steps on each PCS 7 station. The procedure is suitable as a commissioning acceptance test.

1. SEP client firewall state - confirm "Network Threat Protection" is disabled in the SEP client UI.
2. Windows Firewall state - confirm all three profiles (Domain, Private, Public) are enabled.
3. PCS 7 firewall rule groups - confirm the "SIMATIC", "WinCC", "SQL Server", and "SIMATIC Logon" rule groups exist and are enabled.
4. SEP antivirus exclusion set - confirm the folder, process, and extension exclusions are applied to the host's policy group.
5. S7 communication test - from the ES, open NetPro and run a "Check Connection" to each AS.
6. WinCC connection test - on the OS server, open the WinCC Explorer > "Server Data" and confirm the OS client connections are listed and have a "Connected" status.
7. Process Historian replication - on the PH server, run PH-LckChk.exe (in %ProgramFiles%\Siemens\Automation\Process Historian\bin) to verify the database consistency.
8. Information Server reports - open a standard report and confirm it returns data within 5 seconds.
9. Operator login - on the OS client, perform a logon with an Active Directory user, confirm the user role is applied, and log off again.
10. Alarm flooding test - generate 1000 alarms in 60 s on the OS server, confirm the OS client receives all of them and the WinCC Explorer > "Time Synchronization" shows no drops.
11. Redundancy failover test - on the redundant OS server pair, pull the master server's network cable; the standby should take over within 5 seconds and the OS client should reconnect without operator intervention.
12. License check - run the SIMATIC Automation License Manager and confirm all license keys are recognized as valid.

Document the verification result in the commissioning protocol. This evidence is the basis for any future support request. The protocol should include a screenshot of the SEP client showing Network Threat Protection disabled, the output of Get-NetFirewallProfile, and the output of the S7 and WinCC connection tests.

Troubleshooting Matrix

For deeper diagnosis on S7 connection failures, use the SIMATIC diagnostic tools: S7OPCPST.exe on the OS server tests the OPC path, and S7SCANA.exe on the AS tests the S7 connection. The trace output identifies whether the failure is on the ISO-on-TCP layer (TCP/102) or the OPC layer (DCOM). A failure on TCP/102 points to a firewall or network issue; a failure on the OPC layer points to a DCOM or authentication issue.