The ICS Dichotomy Of Surface Area

I finished up Volume 3 of The Great Mental Models and the model, or concept, that has me thinking is Surface Area. Where we need to reduce it and where we need to expand it.

The application to security is obvious and used in the chapter. We want to minimize the attack surface to limit what an adversary can attack. Least privilege firewall rules, closing unnecessary ports, removing unnecessary software, and even the concept of role based access control to reduce user authorization to what is required are all examples or reducing surface area.

We have even seen ICS protocols consider this issue, primarily based on being firewall friendly. Allowing OPC classic through a firewall required a big hole or exhaustive and difficult configuration. So much so that Matrikon and others had successful products just to deal with this protocol failing. One of the OPC UA design objectives was to address this.

Reducing or minimizing complexity is another example of reducing surface area to increase security and reliability. The ICS community, more engineers and automation pro's than security pro's, have been less successful in this. I often think of the words of Ed Schweitzer from a S4x20 interview, saying we need to reset complexity periodically.

The problem may be that our natural bent in the ICS security and ICS community to reduce surface area reduces our creativity and openness to new ideas. The pull quote from the chapter:

Sometimes, as individuals or as organizations, we have a creativity problem. We need some fresh ideas, but have a hard time coming up with them. We rely on what we already know and often end up with more of the same. When we need to spur innovation, we can try increasing our surface area of exposures to new disciplines. More surface area can give us more diversity, which is sometimes what we need in order to innovate and create.

I'm sure you have observed, and maybe are guilty of, instances where an idea from someone new to ICS and OT is dismissed out of hand. Where someone from outside ICS was told they shouldn't even be part of an ICS security discussion because they lack experience, an engineering degree, or the ability to design and implement a control loop.

A simple example, the ability to recover in an acceptable time period is important in all systems and particularly important in ICS where downtime will have a major impact. For most of the 00's and 10's, and still occasionally today, a common recovery plan for ICS cyber assets was re-install from media. Some times it was even worse - - - call the vendor that deployed it to come out and reinstall. By increasing the knowledge surface area to include IT, much faster and effective cyber asset recovery methods were "discovered".

Expanding our knowledge surface area to IT and IT security is obvious, and it is much more than this. Megan Samford is preaching we have a lot to learn from Emergency Managers. The insurance market has many ideas on risk management to consider. What should we be learning about human factors?

We need to bring more people with diverse knowledge and experience into OT and ICS security to address the change that business opportunities are driving, or even forcing. And this dichotomy of how we treat surface area in ICS may be why we struggle so much with new ideas and new to the space people.

On one hand keeping the attack surface as small as possible, reducing complexity and perhaps reducing variability/change is the right approach. On the other hand, limiting what ideas, and people, we consider for use in solving the OT and ICS security challenge is hurting the community.