DHS Best Practice for Remote Access Falls Short

DHS's Control Systems Security Program (CSSP) group recently released their best practice on securing remote access to trusted networks like control systems and their semi-trusted demilitarized zones (DMZ).  The best practice can be viewed by clicking here.  Unfortunately, if we maintain the "think like a hacker" mentality, this document still falls very short of expectations, and is not far off of the NIST guidance document produced in September 2010.

In order to provide a comprehensive defense-in-depth strategy for remote access that addresses both internal (company) and external (non-company or contract) personnel, the focus has to be expanded from just providing basic authentication and confidentiality.  The solution needs to address the health of the endpoint, as well as provide a mechanism to restrict access to the trusted system once access is granted.


During the Fall Conference of the U.S. Dept. of Homeland Security's Control Systems Security Program (CSSP) Industrial Control System Joint Working Group (ICSJWG), I presented a paper on security remote access to control system networks.  The link to that presentation is provided here, as well as an agenda of the Fall conference.

The gap between the DHS best practice and my paper centers around a lack of definition of what the solution is trying to accomplish.  My approach focuses on a few key premises:

• “Keep the bad guys out of the trusted network(s)”
• “Keep the bad guys in (to contain the breach and minimize negative consequences)”
• Completely isolate the remote client from specific networks (PCN, PIN, ELAN, WAN) that they have no reason to access
• Encrypt all data in transit outside the enterprise
• Monitor remote access traffic for any unusual or suspect activity
• Correlate information from multiple-sources for rapid threat identification
• Ability to quickly revoke access
• Platforms are not company-controlled which limits applications, policies, etc.
• Must consider various IT security policies including required firewall configurations, port access, etc.

This can only be accomplished when a solution is based on not only traditional Authentication, Authorization, and Accounting (which is what most solution tend to emphasis), but also Assessment, Remediation, Access Control, Monitoring, and Event Detection.  Only when all of these components have been installed will you have a solution  that not only control access, but also provides threat mitigation should there be a breach resulting from the authenticated access granted to an infected endpoint.

In order to accomplish, the solution needs to leverage existing Virtual Private Networks (VPN) that can be implemented with various appliances such as firewalls or software-based implementations like Microsoft's Forefront Threat Management Gateway (TMG).  One recommendation at this point is to create a separate VPN connection that will be used for trusted control system network access.  In doing so, it will facility both internal and external personnel.  Remember, you should not allow foreign, untrusted hosts to land on a network if you can avoid it - a hacker always says, if I can see a host, I can compromise the host!  Furthermore, you cannot always assume that an external user can support a thick-client that is often the case with IPsec-based VPN installations.  For this reason, consideration should be given to lighter clients for personnel who may access the network with platforms that are different to your corporate IT standards.

Next, it is essential to perform health assessment on the endpoints once they have been properly authenticated.  If this is not performed, it is possible to introduce malicious content directly on the trusted network, with little or no detection due to the encrypted nature of the VPN.  Assessment can be performed with various Network Access Control (NAC) products including Microsoft's Network Policy and Access Services role which can be assigned to Server 2008 hosts.

The next most vital step is to then restrict access between the remote host and the hosts resident on the trusted network.  This is best performed at the switch level using either policy-based switch (as with Enterasys products) or other technologies such as dynamic VLANs (RFC3580).  Any remote user should be restricted in the scope of hosts with whom they can communicate (directly or indirectly).

Finally, remote access introduces significant risk to the overall security posture of the solution.  For this reason, all remote access should be implemented with some form of intrusion monitoring and event monitoring applications to supervise the remote sessions, and generate alerts when any unusually activity is performed.  Most remote access solutions focus too much on protecting data in transit and guaranteeing some high-level of authentication.  They do not, however, provide much in the way of making sure that this "foreign" host meets the requirements of other nodes with which it can communicate on the trusted control system networks.

A remote access solution recommended by SCADAhacker would contain several of the following defense-in-depth strategies (the actual solution is based on the risk exposure of each installation):

• Security risk assessment & quantification process to understand threats and the necessary Security Controls
• Network segmentation (zones & conduits) process which often leads to multiple "functional" DMZs
• VPN with encrypted tunnels
• Strong multi-factor authentication
• Virtual LANs - especially within the DMZs
• Network access control for role or policy-based access (don't be afraid to try another vendor who may provide a product more tailored to remote access)
• Secondary firewall from different vendor  - implementing firewalls in "series" for security rather than "parallel" for availability
• Security information event management (SIEM)
• Intrusion detection (IDS)
• Security awareness & training program (eliminate split tunnels, use of certain public WiFi, etc.)
• Incident response & forensics
• Vulnerability testing to assess the resilience and strength of the implementation

If you have questions on any of this, or would like additional information, please feel free to drop me a note.