Practical Steps for Securing Siemens S7 Controllers Against Cyber Threats

Disabling unused services on conventional servers is often a straightforward hardening task, but Siemens S7 controllers present unique challenges. An unused service on these controllers might actually be essential for operational integrity, supporting remote I/O traffic or providing critical process values to human-machine interfaces (HMIs). Therefore, hastily closing a service could inadvertently cause outages, underlining the importance of understanding dependencies before any security actions.

This complexity is accentuated by a recent cybersecurity advisory, AA26-231A, released by a coalition of U.S. agencies including the NSA, CISA, and FBI. Issued on August 19, the advisory highlights ongoing targeting of Siemens S7 programmable logic controllers (PLCs) and raises a call to action that includes patching vulnerabilities, minimizing internet exposure, and tightening access controls.

The Advisory's Scope and Implications

It's important to clarify that the advisory pertains to a wide array of Siemens CPUs across the S7-200, S7-300, S7-400, S7-1200, and S7-1500 series, including F-series safety controllers. However, the security features aren’t uniform across these models, presenting a challenge for operators aiming for consistent security measures.

Threat actors employ sophisticated methods—utilizing internet scanning tools and AI capabilities—to pinpoint vulnerable systems. Their tactics involve exploiting known vulnerabilities and misconfigurations rather than a singular breach in security measures. This means operators can't expect a one-size-fits-all patch; instead, they need to be proactive in mitigating risks across various environmental setups.

Siemens has emphasized that the issues highlighted in the advisory do not stem from newly discovered vulnerabilities but rather from existing flaws open to exploitation. Operators are urged to reference Siemens’ guidance, particularly their updated ProductCERT bulletin SSB-104599, which outlines best practices for maintaining secure environments.

Understanding 'Unused' Services

A significant term in the advisory is "unused." CISA suggests disabling protocols like Modbus TCP and PROFINET only if they aren't critical for operations. However, this raises questions; many systems use these protocols for essential functions, including connecting CPUs to distributed I/O and other devices. It's not enough to gauge traffic over a short period to determine a connection's necessity. Operators should confirm that communications are genuinely redundant through a comprehensive review of engineering configurations and traffic analysis.

To navigate this, teams should consider three main verification approaches: examining engineering configurations, evaluating representative traffic, and verifying with both automation and maintenance stakeholders. If there’s any disagreement among these sources, the service should remain active until its use is unequivocally validated.

Starting with hardening measures from the network edge can be most effective. Blocking TCP port 102 at perimeter firewalls is recommended, but indiscriminate blocking inside a production cell risks halting legitimate S7 traffic. The ideal approach allows access based on documented communication pairs and is critical for maintaining operational continuity.

Hardening as an Operational Technology Change

Each hardening step, such as firmware updates and tightening connection limits, represents a significant change in the operational technology environment. Just as with any production system modification, these changes require rigorous processes, including starting state approvals, testing, dedicated maintenance windows, and defined rollback strategies.

The call to "patch quickly" must be balanced with rigorous testing, as exposed systems indeed require urgent attention, yet updates can have cascading effects on various modules and safety functions. It's essential that operators keep track of the unique configurations of their environments to avoid unintended consequences.

When assessing changes, operators should not limit scrutiny to ladder logic but expand to include function block diagrams and hardware configurations, ensuring that any adjustments made are reconciled with a trusted baseline reference.

Successful monitoring should be aligned with these baseline states, focusing on signals indicating anomalies such as unsupported communications, unauthorized access attempts, or unexpected tool usage within the network.

Key Questions for Defensible Changes

To ensure that hardening changes are both secure and operationally sound, operators might ask:

1. Which asset is changing? Identify the specific CPU and firmware impacted.
2. What attack vector is being mitigated? Connect changes to exact vulnerabilities.
3. What legitimate operations rely on it? Include all relevant communication needs.
4. What is the initial state of the system? Document the existing configuration.
5. How was the change validated? Conduct tests reflecting typical operations.
6. What defines a rollback? State clear criteria for reversal in case of failure.
7. Is rollback feasible? Ensure all necessary tools and permissions are available.
8. How will functionality be verified? Include checks on all operational parameters.
9. What will the new baseline be? Document changes formally for future reference.

Operators should implement these changes methodically, avoiding multiple simultaneous adjustments. By first reducing public exposure and ensuring secure remote access, then measuring and confirming system behavior in controlled environments, organizations can minimize risks while enhancing the security posture of their Siemens S7 controllers.

In summary, effective PLC hardening involves closing off vulnerabilities while ensuring that normal operations remain uninterrupted, thereby striking a balance between security and functionality.