Insecure By Design

Earlier this year at the SANS SCADA Security Summit, Michael Assante used his position as program chair to ask various speakers and panels whether People, Process or Technology was the most important issue to address to improve ICS security. The answer he wanted was People and almost everyone gave this to him, while quickly adding that all three are necessary and need improvement.

With the similar caveat that all three are necessary and need improvement, I’d answer technology.

My guess is most answering the question were probably thinking is it more important to deploy a Tofino, Waterfall, ICS/IDS, application whitelisting or some other solution that an increasing number of security products or better train people on security? I might agree with the people answer if this was the question.

The real hinderance to an organization that is serious about securing their ICS is the “technology” in the ICS itself. As we have proven and harped on in PLC’s and protocols in Project Basecamp, most ICS are insecure by design. Even if source and data integrity security features are built in, a sizable percentage haven’t been through a Security Development Lifecycle (especially threat model and fuzz testing). They are easy prey for a moderately skilled attacker who can write an exploit.

You can have the most well trained, professional people in the world, and if the bad guy or malware reaches the ICS it is all over. The underlying process is either stopped or modified, and the degree of damage is only limited by the time and skill of the attacker and an, inaccessible from the ICS, safety system.

Approaching the issue from a different direction, we have clients that have been diligently working on ICS security for over five years. This insecure by design and fragility of ICS solutions is the one problem they can’t solve. One client, who has an ICS security policy that is regularly audited, incident response plan, ICS IDS, great security perimeter, …, was forced into choosing between insecure by design PLC’s in their replacement project. So sad.

An argument can be made that processes are even more important than people. If technology limited what USB drives could be used, and there was a secure process for passing data between zones, would it really matter if the people understood the security ramifications. It’s not uncommon for processes to be followed in ICS without the people understanding the reasoning behind the process. When X alarm goes off, I do Y and Z.

Solutions should require the ICS team to think as little about cyber security as possible. It should be built in to the solutions and vendors should be deploying the solutions in a secure manner. A world where a large portion of the ICS team needs significant security training is a failure.

The only way I’d agree with the people answer is if we are talking about C-level executives and top government and industry officials. There leadership on demanding ICS security would make the biggest difference, but the thrust of the question meant “people” at the workforce level.

Once we have systems that can be secured the answer may change, but right now the biggest problem is technology.

Image by Verbatim