The cases being made in ICS owner / operator companies for the “best” organizational structure for ICS detection, and response, are heartfelt, well considered and often at great variance with one another. The case for Operational Technology (OT) SOC vs. Enterprise SOC was covered in a S4x18 debate and was reprised in an OT specialized tools vs. Enterprise tools debate at S4x19.
There are two important and generally agreed upon points regardless of the selected organizational structure:
- ICS / OT knowledge is required as part of the detection and response process, particularly for understanding the severity of the incident and the appropriate response.
- Information on OT incidents needs to flow up to the enterprise, CISO and other executive management. The days of ICS being an island out of executive concern are past.
My analysis has led me to a conclusion of what is the best organizational structure for ICS detection and response in general, for a generic company. In reality, there is no generic company. Each company has a culture, a current level of detection and response capability, and potential resources that can be put on ICS detection and response. I have visited asset owners where my preferred structure and solution would have been a disaster, and almost the converse of the generic recommendation is the best solution.
The bigger issue, and the issue that is hiding in many of the early ICS detection efforts, is will the ICS detection being deployed be effective at detecting various types of ICS attacks? And subsequently, will the asset owner be able to respond?
The experience from early efforts on the enterprise network are not encouraging. IDS and other detection information sources were either ignored or set to such a high alert threshold to be of minimal value. MSSP’s not alerting asset owners for even robust scanning and exploitation was common in our assessments. It is still uncommon to see ICS owner/operators diligently monitoring their existing and high fidelity cyber incident detection sources. The purchasing and deployment of an additional detection capability is the easy part and what we are seeing in ICS.
ICS owner/operators should have expectations on what types of attack they will be able to detect. And importantly they should be testing both the detection and response to these attacks. The difficulty of testing ICS detection capabilities was noted in a recent article on the ICS Detection Challenge. Actual cyber incidents on ICS are still rare, as opposed to cyber incident activity on the Enterprise. An ICS owner/operator could deploy detection, never detect or respond to anything, and declare success.
Before purchasing and deploying additional ICS detection solutions an ICS owner/operator should:
- Identify and insure existing high fidelity ICS cyber incident detection sources are being effectively monitored.
- Create a short list of example cyber incidents that the new solution should detect (your expectations). This does not need to be an exhaustive list, and three to five might be a good place to start. Ideally these incidents would not be one packet incidents. They would include the various steps an attacker would take to achieve a goal. This list shouldn’t be repetitive of cyber incidents that would be detected by proper monitoring of existing solutions such as endpoint protection, active directory logs, and firewall logs.
- Create those three to five incidents and test your selected detection solution in a pilot.
- Use those three to five incidents to exercise your incident response.
Detection and response is not easy. The right structure for your ICS detection is an important decision. An even more important decision is what are your expectations for the ICS detection and response program you have planned? And how will test those expectations?