ICS are different is a constant refrain over the past decade, and there is truth to the fact that ICS control a process and can result in loss of life that is unusual even for a 24x7x365 mission critical IT network.
However the biggest reason ICS are different is the vast majority of owner/operators and vendors continue to make excuses for fragility and poor security practices rather than address them head on. This fragility and embarrassing security practices would not be accepted on a corporate network let alone a mission critical IT network.
And the last thing we need is new ICS security products that lull people into believing these dangerous security practices are ok if you just install the latest gizmo.
Yesterday I had a twitter exchange with @scadahacker and a few others on allowing control system protocols through the corporate/ICS security perimeter that illustrates this. It began with:
Which led me to ask why?
The answer was “IT firewalls” don’t support deep packet inspection of control system protocols. Yikes! The last thing we want is to make it easy to reach ICS servers and field devices with control and monitoring protocols from the corporate network.
The only communication that should be allowed through the corporate / ICS security perimeter is pushing out historical data and inbound emergency remote access – and this should be mediated through a DMZ. A historian, such as a PI server, can very easily push out historical data: source PI server on DMZ, destination PI server or database on corporate network, destination port TCP/5450 or a database port. It’s simple and in place in numerous ICS today.
Emergency remote access is more worrisome because it is inbound and has significant privileges — and many organizations use this for regular remote access rather than emergencies. The best systems use a secure protocol to eventually get to a jump server on the ICS, have multiple authentication steps and two-factor for at least one, and have this capability disconnected by default. Someone in the control center has to physically switch it on and it has a time out. We even see owner/operators that check the logs to see if this has been used on a daily basis and investigate any use.
Some would say that even this limited communication through the security perimeter is too much and a one-way device is required. We are increasingly sympathetic to this viewpoint, especially for any system that claims a huge impact if their system lost availability or integrity.
Joel Langill responded:
It is true that many owner/operators are remotely accessing their ICS on a regular basis for control and monitoring, and it is true that many of the vendors are providing guidance and recommendations on how to do this.
The disagreement is whether the ICS security community should focus on searching for ways to make this insecure access slightly less insecure or telling the owner/operators it is a serious attack vector that is unacceptable in most ICS.
We have had these discussions with our clients for years. The client wants regular inbound ICS access for a variety of reasons. They start with a firewall, then another perimeter security device, then two-factor authentication, … all with the goal of getting the security consultant to say that this access is now ok. While it is tempting to be the nice guy, problem solver and say yes, it is where ICS security types need to stand tough.
Going back to the beginning of this post, from a cyber security perspective the biggest reason ICS are different from IT networks is ICS are to date willing to live with a level of fragility and insecurity that would be unacceptable in even basic IT networks.
Image by stoneysteiner