Vivid Example for Separate Domain/Tree/Forest
Many SCADA and DCS vendors are integrating their applications with Microsoft’s Active Directory. There are some benefits to this:
- Control system vendors no longer need to develop and maintain user management system and other directory services (typically not a core competency)
- Support for strong, two-factor authentication
- Group policy to harden OS platforms
- Single sign-on
However one of the benefits we often hear - - using the enterprise Active Directory eliminates the need to reenter users or maintain two sets of accounts - - requires at a minimum domain controller to domain controller communication between the enterprise and control center security zones. This communication can be exploited and a new Microsoft DNS vulnerability vividly points this out.
With this new vulnerability, that to date does not have a patch, an attacker who has gained access to the enterprise would be able to compromise an Active Directory domain controller on the enterprise. Once the attacker owns this box, he could launch attacks at Active Directory domain controllers on the control system because this communication must be allowed through the firewall. Since the domain controller on the control system is also vulnerable, the attacker would own this box as well and have a launching point for attacks on all systems in the control center.
Sometimes a vulnerability is not even required to cause this enterprise to control system problem. Many of the control systems that rely on Active Directory also rely on Active Directory’s DNS rather than hardcoding or otherwise providing name to address resolution. An innocent DNS change on the enterprise could cause control system devices to no longer know how to find each other. Similarly, a Group Policy change on the enterprise could have a negative impact on control system computers.
Digital Bond and many others in the SCADA security community have recommended for years a completely separate domain for control systems, when a domain is required. This control system domain should also not be in the same Active Directory tree or forest as the enterprise domain.
Author: Dale Peterson
Posted: April 17th, 2007 under Microsoft, SCADA Architecture.
Comments: 5
Comments
Comment from Ron Southworth
Time: April 17, 2007, 3:51 pm
Hi Dale some very good words on the subject indeed. And I dont want to deminish the message you have put together in any way.
We discussed redundancy and reliability aspects in one of the previous posts and this post remined me of this aspect again.
The Active directory system certainly provides all of these capabilities and the associated current public published vulnerability.
A simplistic example:
One drawback and concern I have with the distributed Access controls mechognisms used in MS Windows is that during say a peak network communications load storm or major event ie not necessarilay a denial of service attack the increase in network load can cause problems with logging into the SCADA system at a critical moment in time. I have seen this problem first hand. To fix the particular instance the network required upgrading redesigning / re-segmenting to reduce the traffic on the particular subnet.
Take this sanitised & over simplified perhaps real world example and picture if it was a denial of service attack causing the problem. How do you mitigate for this loss of credential checking during a critical moment of time. If credential handling is natively handled by the SCADA server & software this issue is at least more managable?
The question of size of the enterprise for certain sometimes dictates the need for a centralised administration and credential and profile management system but the majority of systems really don’t necessarily need the extra complexity to operate the core function - controlling plant.
The KISS principal has a lot of merrit!. It may take a bit longer to have static assignments and to perfrom change management on profiles but these should not be being tweaked every day in a control environment? The easiest way to block a DOS for example is to pull the plug from the entry point into the system for example!
It does mean a more labour intensive approach to change management and security control management. That seems to be the over riding factor rather than improving the security profile ?
Comment from Jake Brodsky
Time: April 17, 2007, 9:52 pm
The battle between the convenience of centralized management versus the robustness of distributed computing is something that SCADA system architects have had to deal with from the very beginning. And this latest siren call from Microsoft on the ease of Active Directory Management is quite a tempting thing.
However, I’m encouraged to see that we agree on the vulnerabilities that come from such efforts. There has been a considerable discussion about the vulnerabilities of DNS and especially DNSSEC on Matasano.com. I cringe at the very notion that someone could be putting so many eggs in such a frail basket.
And though I know I’m preaching to the choir here, just because we use Ethernet, TCP/IP, Windows, or even Active Directory does not mean the system should be integrated in to an IT domain. Good DMZs make good neighbors…
Comment from cnioperator
Time: April 18, 2007, 12:00 pm
Chaps, I usually only pitch in when I disagree with the comments however…on this occasion, I wholeheartedly agree. In our company I explicitly do not allow control systems to be part of the IT domain, no trusts, nothing. Interestingly a position that is very much supported by the IT folks who see control systems as much too complicated and diverse to be allowed to join in the very homogonous IT environment.
Good DMZs do indeed make good neighbours.
Comment from Ron Southworth
Time: April 18, 2007, 1:15 pm
Now how do you convince someone that the KISS philosophy is sound when they have not had a control systems backgtound?
The same person insists that a VLAN is as good as a DMZ even when the switch can be defaulted by a malformed packet to stop the separation between all ports locally on a switch! heck the people on the other VLAN are only sitting in a library with un- restricted access to the internet!
Comment from Kevin McGrath
Time: April 24, 2007, 10:22 am
Howdy All.
Well this is a very timely post as we have asked out corporate IT folks for some assistance in looking into the possibility of using some of the corporate AD/domain related resources in our soon to be upgraded SCADA system.
IT’s “recommendation” is for us to turn over all our new SCADA windows servers to them so they can manage and support them the “right” way.
Quoting the recently fired Don Imus, “Ya can’t make this stuff up!”
Regards,
Kevin
Write a comment