Understanding Industrial Security
Before computer security was a thing, there was Industrial Security. It was primarily physical: Guards, Gates, Guns.
The guards would periodically patrol the fence to ensure that there were no holes or evidence of tampering. They had guns to ward off direct attacks and to enforce policy within the plant. They would record who went in, and when they departed. Occasionally, they would search a vehicle, such as one being driven by a sales representative, for banned devices such as cameras (before cameras were present in everyone’s phone), weapons, or other such things.
Perhaps most guards weren’t so attentive; but for higher security sites, that was what they were supposed to do.
However, once inside, the guards often had no idea what people were doing. So for really high security situations, the guards would escort a visitor through the facility.
Why list all this? Because computer security isn’t really that different.
It comes down to Fences, Gates, Guards, Guns, and Trusted staff.
Mapping to modern control systems
Now, consider computer security. Would we let just anyone on a plant? Uh, no.
So why expose computer networks to the world? Oh, wait, there was that interesting excuse about maybe needing someone somewhere to help in the event of an emergency. But nobody knows who that person is, or what tools they’ll need, or what sort of access they should have. So everything is exposed. What. A. Fairy. Tale.
For that matter, why expose it to the rest of the office? Does the accounting office have any good reason to issue direct commands to a bottle capping machine? In real life there are usually locked doors between the offices and the plant floor.
This is the foundation behind what is called the Zone and Conduit model. But what kinds of zones should be established and what sorts of guards should be on the Conduit model?
Risk Assessments for design?
At this point, many start referring to risk assessments to determine what risks there are and what things should be done to protect the control system. This is where I start communing with my inner curmudgeon. I don’t care about the control system. I care about the process. The process itself should be designed for an intrinsically safe shutdown. Active safety systems should be limited to only those places where it is absolutely the only way to go and that safety system must be completely isolated.
People tend to write risk assessments based upon assets to determine what zones and what conduits are needed. However, this is a deeply ignorant mistake.
“A Risk Assessment of an industrial process is not about assets, but maintaining a functional, safe system.”
This is exactly where NERC CIP went horribly wrong. If an asset doesn’t qualify, it doesn’t need to be secured. However, systems are still vulnerable to parallel attacks of less “critical” devices. In fact, I think the entire notion of criticality ought to be reexamined. This is not some silly score-sheet analysis.
The whole risk assessment methodology is broken. Risks have been categorized in to 18 primary controls, each containing its own subsections. There are typically about a dozen of those per control. Each of these controls may contain enhancements. Then, if you’re working on a Department of Defense contract, each of those controls with enhancements are enumerated in terms of a Control Correlation Identifier. There are literally thousands of them.
This bureaucratic nightmare doesn’t help. Risk Assessments start with a complex model and then it gets flat-out insane. But thanks to federal law, this is guaranteed to make lots of billable hours for consultants (Full disclosure: I work for a large consulting firm).
It looked good at first, when nobody knew what in the world they were doing, but the notion has not worn well as it was applied to the field.
Very few people think in terms of risk analysis. They think in terms of specific threats, specific systems and attack vectors. That’s where we start making real designs, real policies, and real defensive tools.
So how can we categorize these efforts in a manner that makes sense?
How about these things:
- How the process Works
- Who is responsible
- Security breech detection
- Policies and protocols for a breech
- Gather Forensics
- Design and update improvements
Notice that there is no technology listed here? The technologies change much more frequently than the people. But these are the things we need to do, regardless of how we do them.
In coming blogs, I will describe further details on each of these steps. Security is actually not that difficult to understand when placed in context. Bureaucracy is not the answer.
