Best Practices for Firewalls in Digital Control and SCADA Systems
From SCADApedia
Best practices for firewall describes ingress and egress rules for firewalls, firewall placement and other issues associated with creating defense in depth and perimeter controls for SCADA and Digital Control systems.
Contents |
Firewall Overview
Firewalls provide perimeter control and connection control between computer systems and network domains. They can also serve as proxies and encrypt/decrypt network traffic. Firewalls can also be configured to provide access control between domains or on a specific domain.
Firewalls for SCADA/DCS systems must:
- Authenticate before allowing any configuration change to be made.
- Be able to perform self testing.
- Perform logging.
- Not be deployed in an "out of the box" or default configuration.
Defense In Depth and Perimeter Control for SCADA/DCS systems
As legacy control systems were designed with little or no considerations towards data integrity and confidentiality, and designed to promote availability defense in depth especially perimeter control become key in mitigating control system vulnerabilities. This means that if an attacker or someone with malicious intent is able to penetrate the perimeter and access the actual control system it is very simple to "own" the control systems.
Common weaknesses on these systems include:
- Clear text passing of user names and passwords.
- Use of default user accounts including vendor default accounts and guest accounts.
- No credentials required to make major operational changes.
- No data encryption.
- No source integrity ie you can not verify that data actually originates from where it claims.
- Services with excessive privileges.
- Control systems employing corporate/enterprise services for example DNS servers.
- Active but unused services.
Defense in Depth
Defense in depth is the layering of multiple technologies, policies, and techniques to improve security posture and to make attacking a system more difficult. and example of defense in depth is to have multiple layers of firewalls from multiple vendors so that a common firewall/vendor specific vulnerability may be avoided. Other defense in depth techniques adding IDSs and IPSs to monitor communications, creating DMZs, and employing virus scanners on communications.
Defense in depth is not only technology but polices, and training so that employees and users understand the "why" and "how" of the policies. Defense in depth can create annoyances for users as certain activities become discouraged. Such activities include, web browsing and emailing from the control system segment and using control system computers for unrelated tasks and purposes.
Perimeter Control
Since once an attacker is on a control system they enjoy virtually unfettered access to the system and resources, perimeter control becomes key to security, and firewalls being the principle perimeter control technology become preeminent. A poorly configured and managed firewall provides no security and essentially acts as a router/switch.
Common firewall misconfigurations compromising perimeter control include:
- Old/outdated and undocumented rules ("why is that there again?").
- Un-removed temporary exceptions ("Bob, we need to figure out why X can't talk to Y. Can you add allow all to this host X for a while?").
- Excessively simplified rules.
- Physical connection circumventing firewalls.
- No logging or monitoring of logs.
Firewall Rules
Firewall rules dictate what action a firewall takes for specific types of connections/communications across various domains. Most firewalls are managed with some type of management console which allow for the visual creation of rules, and inspection of traffic. This console allows for the easy creation, documentation and management of the rules simplifying the task of firewall management. The inspection of traffic allows for diagnosis of connections, viewing bandwidth and traffic patterns, and ensuring that the firewall is operating correctly.
Firewall Golden Rule
The "golden rule" for firewalls, especially in critical control system environments is "That which is not explicitly permitted is expressly denied." Meaning the first rule on a firewall which controls perimeter access into a DCS/SCADA system is deny all to all after which the specific exclusion can be broken out.
Ingress Rules
Proper ingress rules are essential for preventing the infiltration of exploits, malware, viruses, etc. into the control system environment. Only connections that are essential to the mission sucess should be allowed into the control system from the outside. This means blocking the majority of incoming traffic; http, smtp, ftp, telnet, etc. into the control system. The only truly necessary connections are the connectivity between the historian master and slave, VPN tunnels into the control system for remote system maintenance, and pathways in for vendors to provide upgrades and maintenance.
The vendor pathways/rule exceptions should be temporary, created only at the time when the work is to be performed through scheduling with the vendor, and removed once the work is finished.
Good firewall ingress rules will deny the majority of attempts to first "enumerate" and then "penetrate/exploit" systems in the control system network.
As control systems are incredibly time step/latency sensitive the blocking of enumeration attempts by the firewall can be critical in avoiding control system outages, and even prevent the accidental DOSing of the system through an ill-advised port mapping/network discovery attempt by uniformed but well meaning employees.
Good ingress rules will prevent the majority off exploitation attempts by denying the inbound connection. Again the only exceptions to the deny all rule should be those that have a sound business case and are essential to achieving mission success.
Egress Rules
Good egress rules prevent attacker from remote controlling compromised systems. This forces attacker to essentially "work and the darK" and limits their ability to "enumerate", "penetrate" and "remotely control" systems. Again there is no real reason for allowing http session, ftp session, email, telnet, ssh, virtually any traffic that is not the historian master slave connection or the abound traffic of the maintenance channels described above to egress from the control system segment. If endusers need the aforementioned type of connectivity provide separate systems (PCs etc) located physically next to the operating consoles and location but connected onto the corporate/enterprise environment. This allows users to perform essential and non-essential outbound task without exposing the control system to the risk of allowing for remote connectivity. This exclusion of outbound traffic includes outbound into the enterprise environment except for those connections essential to achieving the systems mission.
Firewall Placement
In a control system environment the ideal topology is individual DMZs for each necessary firewall excepted service with virtualized or physical segmentation between the segments. There should be no ethernet connections into or out of the control system that are not firewalled, logged and monitored. There should be no direct connection into the enterprise environment, rather the enterprise services talk to the servers on the DMZ which in turn communicate with the services on the control system segment.
