Give the parser the ability to detect assets through the CIP Get-Attribute-All and ListIdentity event
in addition to the existing ENIP ListIdentity event.
Feature Context
The parser is currently implemented such that the cip-identity.log file is created exclusively from the
ENIP event ListIdentity. While this packet contains all necessary information to create an asset log, it
is infrequent and does not contain robust information. The much more common CIP Get-Attribute-All
event contains much of the same information and would also be able to create a more
robust asset log for a given device. An interesting feature to the parser would be the ability to create
asset logs in cip-identity.log from both the ENIP and CIP equivalent events.
Feature Value Add
Using the much more common CIP event would make it possible for users to map the assets on their
network in the event that the ENIP log wasn’t seen. This gives parser users overall a better
understanding of their network environments and the assets communicating within them.
Additionally, the CIP event has more robust information about status and value tracking. The CIP
identity request is fairly common within ‘steady state’ polling between the vendor software and PLCs.
With a larger of volume of events each yielding a lot of data, users may be able to more accurately
capture mode changes during operation and other behaviors such as firmware updates in progress.
Lastly, the addition of this feature would allow for previously undiscovered devices to be logged. For
example, device modules that are connected via the backplane, which are themselves not directly
network accessible, cannot be logged via the ENIP ListIdentity event. With the CIP Get-Attribute-All
event however, these devices can be logged and tied back to their controller devices via the “path
data” field in the packet.
Implementation Notes
The CIP class 0x01 is associated with the device identity by the CIP specification and would be the
primary focus for implementing this identity tracking through Get-Attribute-All requests.
One potential problem is, since these behaviors are fairly common within standard EWS to PLC
communication, there may be many more events created by the addition of this feature. Also, depending
on where these logs are placed, this may lead to conflicting or duplicate logs across logging files.
Feature Request
Give the parser the ability to detect assets through the CIP
Get-Attribute-AllandListIdentityevent in addition to the existing ENIPListIdentityevent.Feature Context
The parser is currently implemented such that the cip-identity.log file is created exclusively from the ENIP event
ListIdentity. While this packet contains all necessary information to create an asset log, it is infrequent and does not contain robust information. The much more common CIPGet-Attribute-Allevent contains much of the same information and would also be able to create a more robust asset log for a given device. An interesting feature to the parser would be the ability to create asset logs in cip-identity.log from both the ENIP and CIP equivalent events.Feature Value Add
Using the much more common CIP event would make it possible for users to map the assets on their network in the event that the ENIP log wasn’t seen. This gives parser users overall a better understanding of their network environments and the assets communicating within them.
Additionally, the CIP event has more robust information about status and value tracking. The CIP identity request is fairly common within ‘steady state’ polling between the vendor software and PLCs. With a larger of volume of events each yielding a lot of data, users may be able to more accurately capture mode changes during operation and other behaviors such as firmware updates in progress.
Lastly, the addition of this feature would allow for previously undiscovered devices to be logged. For example, device modules that are connected via the backplane, which are themselves not directly network accessible, cannot be logged via the ENIP
ListIdentityevent. With the CIPGet-Attribute-Allevent however, these devices can be logged and tied back to their controller devices via the “path data” field in the packet.Implementation Notes
The CIP class 0x01 is associated with the device identity by the CIP specification and would be the primary focus for implementing this identity tracking through
Get-Attribute-Allrequests.One potential problem is, since these behaviors are fairly common within standard EWS to PLC communication, there may be many more events created by the addition of this feature. Also, depending on where these logs are placed, this may lead to conflicting or duplicate logs across logging files.