Imagine it is that once a decade time when you are installing or performing a significant upgrade to your ICS. Your ICS vendors have spent the last five years adding security controls and developing white papers, install instructions and other tips to better protect the availability and integrity of their products in your system. This is a huge opportunity.
Unfortunately more often than not, 90%+ of the time in our experience, the team deploying the system puts it in the same way they have been deploying the ICS ten years ago. It’s not that they are bad people or incompetent. It’s just that installs are hard and detailed enough without adding this security complexity, and they probably have not run across a customer who has had their ICS hacked so why bother.
It is incumbent on you as the owner/operator to understand the optimal security configuration and related security practices for your SCADA or DCS. Now here is the good news: the system, application and device vendors are increasingly putting out detailed guidance on how to secure their systems. When your deployment team balks or proposes the “legacy” installation, pull out that guidance document and say we want it installed as the vendor recommends.
It’s a powerful argument. It turns a very common “that is impossible” or a bad idea response, to a red face and often the need for the deployment team to get up to speed on the vendor security recommendations. You will get integrators and vendor deployment teams pushing hard their view that security will make the ICS less reliable, so it will require some backbone. You may need to push for higher level vendor involvement because clearly they would not recommend something that would make the system less reliable.
It would be nice to say that showing the documentation will solve all problems. And it is more likely to get your system installed properly if the security requirements are in the RFP, contract and acceptance testing plans. If you wait until commissioning you are more likely to face delays and additional project costs to make the security related changes. However with life cycles measured in decades do you really want to live with a ten-year-old security approach for the next twenty years?