“The nonprofit CiA (CAN in Automation) international users’ and manufacturers’ group informs its members that products using CAN and placed on the EU markets fall under the European Cyber Resilience Act (EU CRA), unless the relevant cybersecurity aspects are covered by application-specific EU legislation. In most cases, the required risk assessment may be a self-assessment, unless the product is considered critical (as defined in the CRA Annex III).It remains to be seen, which future standards best reflect the EU CRA requirements. For now, suppliers of CAN-connectable devices are requested by their customers to comply with a dedicated SL (security level) as defined in the IEC 62443 standard series (security for industrial automation and control systems).
CiA is confident that SL 2 can often be reached with minimal effort for CAN networks. Achieving SL 3, requires more advanced security measures involving cryptography at CAN data frame (data link layer entity) or CANopen message (application layer entity) level. CiA’s assessment is that CAN networks with restricted and limited physical access usually comply with SL 2 or lower, not needing additional cybersecurity measures. This assumes that gateway functions to other networks and external interfaces are protected by means of firewalls or are made not accessible (e.g., the JTAG interface, named after the Joint Test Action Group).
If restricted and limited physical access is difficult to enforce, cybersecurity measures do not necessarily require cryptography. In CiA’s view, a security monitoring entity that scans communication on abnormal behavior, detecting and reporting attack, is an efficient security measure as indicated in the CRA regulation and the IEC 62443 standard series. It reduces overall risks for undetected attacks, having a positive influence on the risk assessment and showing a defense in-depth approach.
If cryptography is necessary, its use can be limited to core functions. While a secure software update mechanism might be mandatory for CRA compliance, in many cases, further use of security functions can be reduced to secure CAN node authentication and device configuration protection (e.g., by means of passwords). Such core security functions are currently under discussion in the CiA SIG (special interest group) HLP (higher-layer protocol) cybersecurity and expected to be integrated into CANopen CC and CANopen FD specifications.”
@CANopen #DigitalEU #Cybersecurity #Standards
No comments:
Post a Comment