CIP security policy
CIP Security
helps protect an EtherNet/IP connected device from malicious communications.Security within the system adheres to the
ODVA™
CIP Security™
standard for usage of cryptographic keys and certificates.Security
CIP Security
helps protect an EtherNet/IP connected device from malicious communications by:
- Applying authentication rules and rejecting messages sent by untrusted people or untrusted devices
- Verifying that data has not been altered during transmission and reject data that fails the integrity check
- Helping to prevent accessing the EtherNet/IP data by unauthorized parties for additional confidentiality
CIP
-secure policy models support these core security properties:
Property | Description |
---|---|
Device Identity | X.509v3 digital certificates provide cryptographically secure identities to devices. |
Device Authentication | The Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) cryptographic protocols provide secure transport of EtherNet/IP traffic. |
Data Integrity | Hashes or keyed-hash message authentication code (HMAC) provides data integrity and message authenticity to EtherNet/IP traffic. |
Data Confidentiality | Data encryption helps prevent accessing the EtherNet/IP data by unauthorized parties. |
Authentication methods
CIP
-secure components may use these authentication methods:
Method | Description |
---|---|
Certificate | Established by the use of an X.509v3 certificate granted by a trusted certificate authority. You can use these options for I/O Data Security if a certificate is used as the authentication method additional security:
|
Pre-shared key | Established by presentation of a shared secret key that is propagated to trusted devices in the system. A pre-shared key can be created manually or FactoryTalk Policy Manager can automatically generate pre-shared keys for distribution to the devices in your system. |
Trusted IP | Established by identifying an IP address as trusted by the policy model. A set of IP addresses can be defined as a trusted range on your network. Appropriate for use with devices that are not CIP Security capable. |
For more details about the
CIP
properties available for different policy model components, see:
Conduits
With
CIP
endpoints, you can create these conduits:
Endpoint 1 | Endpoint 2 |
---|---|
Zone | Zone |
Zone | Device |
Zone | Range |
Device | Device |
Device | Range |
Conduits must follow these rules:
- Conduits cannot be duplicated, each combination of endpoints must be unique.
- One of the endpoints must beCIP SecurityorOPC UA security policycapable.
- If one endpoint is a zone, the other endpoint cannot be a device within that zone.
- Devices not assigned to any zone or onboarding devices cannot be used as endpoints.
Ingress/Egress rules
The Ingress/Egress Object is a set of rules that govern which network nodes can communicate to the device and through the device:
- Ingress rules
- Determine which other nodes can communicate with this device.
- Egress rules
- Determine how the device can communicate with other nodes.
For more information about the Ingress/Egress rules, refer to the
ODVA™
documentation.Compatibility
CIP Security
features work with these Rockwell Automation
products:
- FactoryTalk Linxversion 6.11 or later
- ControlLogix®5580 controllers firmware revision 32.00 or later
- 1756-EN4TRControlLogixModule
- Kinetix®5300 Drives
- Kinetix5700 Drives
- PowerFlex®755T
- 1783-CSP CIP Security Proxy
- CompactLogix™5380 controllers firmware revision 34.00 or later
- Compact GuardLogix®5380 controllers firmware revision 34.00 or later
- GuardLogix®5580 controllers firmware revision 34.00 or later
Provide Feedback