Demystifying the IEC/ISA 62443 Security Standard for Industrial Systems
As industry 4.0 and smart factories continue to connect their assets and equipment to the cloud, the attack surface grows exponentially. The IEC/ISA 62443 specification has been developed to help companies providing equipment and infrastructure to the industrial segment to architect their systems with security in mind. Join Microchip's webinar to learn how our ATECC608 secure element and consulting expertise from our partner, Security Pattern, can facilitate your journey to a successful IEC 62443 certification.
-Read our blog post about IEC62443 and secure element [link to come later]
-Read our application note about IEC 62443, which includes valuable technical information about our solutions [link to come later]
Visit our TrustFLEX ATECC608 page to discover how our preconfigured use cases can accelerate your IEC62443 design.
According to Xavier Bignalet, what security property is the highest priority for industrial automation and control systems (IACS), and why?
Hello, check out this video that explain the difference : https://www.youtube.com/watch?v=YVtpz7d9v0o .
Essentially, Trust&GO is a blackbox secure element which policies are not modifiable and it comes with cert/private key for TLS connection or symetric key for LoRA. TrustFLEX also has a proposed default cert/private but not locked so you can change them with your own. TrustFLEX also offers many more use cases, TrustCUSTOM is a blank secure element fully customizable
Hello Xavier,
thank you for your presentation. I have a question concerning the definition of the security level in correlation to the main roles:
does every role define the security level of it's area of responsibility independently? Or does the IEC/ISA62443 also provide guidance about the inheritance of security levels.
I think in terms of defense in depth aproaches it is very important to get a common understanding of the objectives of each role.
the security level that is mentioned in the presentation is the so called "Capability Security Level (SL-C)" and it only qualifies the raw capabilities components (when they are correctly integrated and configured). The process is usually the following: Asset Owners perform a risk management activity on their plants. They define a "Target Security Level (SL-T)" which encompasses and is the target protection level for the overall system. They start (also through System Integrators) to procure components and systems and to define their policies and procedures. Each component they procure, ideally, is certified and characterized by its SL-C. It is not required that the SL-C of each single component to be equal or higher than the SL-T defined at plant level. The SL-T is typically achieved (and then measured - the standard mentions the "Achieved Security Level (SL-A)), by leveraging on a mix of three ingredients:
- components with a decent enough (compared to the target application) SL-C
- a set of policies and procedures at plant level
- a set of system-level countermeasures.
These last two can and are typically used to compensate for any shortcomings from the component side w.r.t. the needs of the final application.
Matteo Giaconia
Senior System Engineer, Security Pattern
M. +39 339 8324158
Hi NicoPeper,
the security level that is mentioned in the presentation is the so called "Capability Security Level (SL-C)" and it only qualifies the raw capabilities components (when they are correctly integrated and configured). The process is usually the following: Asset Owners perform a risk management activity on their plants. They define a "Target Security Level (SL-T)" which encompasses and is the target protection level for the overall system. They start (also through System Integrators) to procure components and systems and to define their policies and procedures. Each component they procure, ideally, is certified and characterized by its SL-C. It is not required that the SL-C of each single component to be equal or higher than the SL-T defined at plant level. The SL-T is typically achieved (and then measured - the standard mentions the "Achieved Security Level (SL-A)), by leveraging on a mix of three ingredients:
1) components with a decent enough (compared to the target application) SL-C
2) a set of policies and procedures at plant level
3) a set of system-level countermeasures.
These last two can and indeed are typically used to compensate for any shortcomings from the component side w.r.t. the needs of the final application.
After looking at the website you reference in the Abstract tab I noticed the Trust&Go, TrustFLEX, and TrustCustom devices the first and last appear the same in the table and the only difference with TrustFLEX is I assume AES-GCM supports greater than 128-bit keys. Spent some time going back and forth but I am not getting the big picture of how these options are different from each other.