In the current industrial automation landscape cyber-securing the device in the network poses a big challenge. Securing EtherNet/IP CIP endpoints remains difficult when reliance is placed only on perimeter controls. Firewalls, segmentation, VPN, and (D)TLS wrappers protect the channel, but they do not by themselves decide whether a specific CIP object, service, or operational command is authorized for a given requester in the device’s current state or mode. However, there are many instances where these approaches are compromised, and packets reached the device to attack. Some published paper does not consider authentication, packet integrity enforcement & command validation [1]. The other paper [2] describes Intrusion Detection (IDS), not prevention. Therefore, packets will reach device, and device will process malicious data which poses threat to the device.
The proposed methods provide a practical multi-layer enforcement pipeline for CIP endpoints that composes existing ODVA CIP Security (Volume 8) profile with Confidentiality, User Authentication, and Device-Based Firewall where applicable. Therefore, it adds mode or state aware, object-level application policy.
The device based firewall performs traffic filtering at the device. CIP object, service and role checks are post-(D)TLS application policy which is performed after a secure channel and authenticated identity are verified.
Device keeps track of the session binding of requester identity to an active security context, role, CIP object access, operational-mode gates, fail-closed behavior, and mutual agreement of allowable object access at session setup.
Device defines and maintains its operational state and checks the current state with current requested operation state for authenticating the requester for further communication. It admits only commands permitted in that state which prevents authenticated but inappropriate configuration or control.
Device restricts the access of Common Industrial Protocol (CIP) objects based on the requester type and authenticity. Both the device and requestor have mutual agreement for accessing the CIP objects. CIP object access is restricted by requester role and an explicit mutual agreement at session setup. If there is any access request beyond the agreed objects or service access permission it will be rejected (fail-closed).
