Model ATT&CK for ICS in the D3FEND Ontology

[netfl0]

Model ATT&CK for ICS in the D3FEND Ontology

The goal of this discussion is to identify the requirements, challenges, and solution ideas for incorporating ATT&CK for ICS into the D3FEND ontology.

Digital Artifacts

D3FEND contains most of the necessary digital artifacts for this work in the upcoming 0.12.0 release. There will need to be some additions to the ontology including the various types of PLCs and the physical things they control.

Countermeasures

Additionally, we will have to add specific hardening and detection techniques related to those artifacts, though many of the existing countermeasures will also apply.

User Interface

We will also have to add some specific UI elements to help filter the D3FEND ontology and inference views based on offensive framework. We will likely have to create an additional data property on d3f:OffensiveTechnique to enable this.

Next Steps

Once we have this work further defined, we can create specific issues to add things to the ontology.

[skhemissa]

From my perspective, we should consider the following (according to the perdue model) :

• In scope : Level 2 (Area supervisory control), Level 1 (Basic control) and Level 0 (physical process)
• Out of the scope: Level 3 (Site Operations) and Level 4/5 (Enterprise Zone) because both are considered IT systems and already covered by the standard framework.

The ontology "Embedded Computer" is ok for describing the Level 0 (physical process) components.

To add for describing level 1 and level 2 components:
Network Node \ Host :

• Industrial Controler (this ontology covers the main types of PLCs, including RTU. From cybersecurity perspective, there is no raison for distinguishing between types of PLC. All working in the same manner: hardware with fixed I/O or I/O modules, a CPU, a firmware and a program that provides the logical control)
• Industrial Sensor (such a temperature probe)

Network Node \ Host \ Client Computer

• Industrial Engineering Station (programming station for Industrial Controler, it's a sensitive components >should be part of the framework)

Digital Event \ Ressource Access \ Industrial Controler

• Input (change a value that affect a component, such increase and decrease the speed of a motor that control a conveyor)
• Output (access to a read only data, such temperature)

Software

• Industrial Controler Program (promoting : Top 20 Secure PLC Coding Practices https://www.plc-security.com/#download)

Software \ Applications
- Industrial Control Application (From cybersecurity perspective, no need for distinguishing between SCADA and DCS. Both have the same technical components. The difference is the way of addressing the control and the supervisory: DCS is process state driven while SCADA is data/event driven

Softwares \ Firmware

• Controller Firmware

Network Traffic

• Industrial Network Traffic

Open topics due to my current weak knowledge on the framework:

• Level 4/5 (Enterprise Zone) and the Level 3 (Site Operations) Laterisation to the Industrial area : to be discussed how to considered that in the framework
• How Industrial Safety Systems should be considered?
  Such system is very critical
  Components of a Industrial Safety System are the same than systems controling the production (application, Industials controlers, sensors). Meaning that countermeasures should be the same for both.
  One additional countermeasure should be considered: Industrial Safety System should be completely isolated from production control systems for safety reason.