Traffic anomaly detection for IoT devices in field area network

1. A computer implemented method comprising:

generating, by one or more processor, a whitelist for a subject device from two or more devices in a field area network (FAN) listing one or more peer devices in the same FAN communicating with the subject device as respective whitelist entries, wherein the one or more peer devices indicate all other devices than the subject device from the two or more devices in the FAN, wherein the FAN is for an infrastructure without a controlled perimeter, and wherein a whitelist entry in the whitelist for the subject device corresponds to a peer device of the one or more peer devices in the FAN and comprises one or more attribute values expected in traffic between the subject device and the peer device as represented by the whitelist entry; and

monitoring the traffic at one or more points of the FAN by use of the whitelist for one or more anomaly.

2. The computer implemented method of claim 1 , the generating comprising:

determining a first set of devices that are physically communicable with the subject device in the FAN;

determining a second set of devices that communicates with the subject device based on communication policies and applications of the subject device;

determining devices in an intersection of the first set and the second set as respective objective device corresponding to each whitelist entry in the whitelist for the subject device; and

storing the whitelist for the subject device in a whitelist database, wherein the one or more attribute values expected from the traffic between the subject device and the respective objective device in respective whitelist entry include a directionality of the traffic, a periodicity of the traffic, a type of the traffic, and a volume of the traffic.

3. The computer implemented method of claim 1 , further comprising:

ascertaining, prior to the generating, that the whitelist is to be updated based on one or more of: a change in contents of device applications and policies database, a change in contents of a device geolocation and coverage database, and a change in status of a device in the FAN, as caused by installing a new application in the device, by implementing a new policy for the device, by retiring the device, replacing the device with another device, and/or redeploying the device to a new location in the FAN.

4. The computer implemented method of claim 1 , the monitoring comprising:

obtaining traffic data between the subject device and another device;

determining that the another device does not have a corresponding whitelist entry in the whitelist for the subject device and that whitelist entries corresponding to the another device in other devices of the same FAN are inconsistent; and

storing the traffic data with a flag indicating an anomaly of the one or more anomaly in the traffic data in an alert database for warning and further analysis of the anomaly.

5. The computer implemented method of claim 1 , wherein the one or more anomaly includes a device tampering, a device malfunction, a movement of a device in relation to the FAN, a cloned device, a Medium Access Control (MAC) address spoofing, and a cross-network traffic.

6. The computer implemented method of claim 1 , further comprising:

obtaining traffic data between the subject device and another device;

determining that the another device has a corresponding whitelist entry in the whitelist for the subject device;

discovering one or more discrepancy between the expected attribute values of the corresponding whitelist entry and the obtained traffic data, wherein the one or more discrepancy is greater than respective thresholds of acceptable variation with the expected attribute values; and

storing the traffic data with a flag indicating an anomaly of the traffic data in an alert database for warning and further analysis.

7. The computer implemented method of claim 1 , wherein the FAN is a radio frequency (RF) network covering one or more geographical area, wherein other field area networks are present in respective geographical areas which overlap, share borders, and/or within close proximity to the one or more geographical area covered by the FAN, and wherein each subject device in the FAN is associated with a respective whitelist including whitelist entries corresponding to other peer devices in the FAN with which the respective subject device legitimately communicates.

8. A non-transitory computer program product comprising: a computer readable storage medium readable by one or more processor and storing instructions for execution by the one or more processor for performing a method comprising:

generating a whitelist for a subject device from two or more devices in a field area network (FAN) listing one or more peer devices in the same FAN communicating with the subject device as respective whitelist entries, wherein the one or more peer devices indicate all other devices than the subject device from the two or more devices in the FAN, wherein the FAN is for an infrastructure without a controlled perimeter, and wherein a whitelist entry in the whitelist for the subject device corresponds to a peer device of the one or more peer devices in the FAN and comprises one or more attribute values expected in traffic between the subject device and the peer device as represented by the whitelist entry; and

monitoring the traffic at one or more points of the FAN by use of the whitelist for one or more anomaly.

9. The computer program product of claim 8 , the generating comprising:

determining a first set of devices that are physically communicable with the subject device in the FAN;

determining a second set of devices that communicates with the subject device based on communication policies and applications of the subject device;

determining devices in an intersection of the first set and the second set as respective objective device corresponding to each whitelist entry in the whitelist for the subject device; and

storing the whitelist for the subject device in a whitelist database, wherein the one or more attribute values expected from the traffic between the subject device and the respective objective device in respective whitelist entry include a directionality of the traffic, a periodicity of the traffic, a type of the traffic, and a volume of the traffic.

10. The computer program product of claim 8 , further comprising:

ascertaining, prior to the generating, that the whitelist is to be updated based on one or more of: a change in contents of device applications and policies database, a change in contents of a device geolocation and coverage database, and a change in status of a device in the FAN, as caused by installing a new application in the device, by implementing a new policy for the device, by retiring the device, replacing the device with another device, and/or redeploying the device to a new location in the FAN.

11. The computer program product of claim 8 , the monitoring comprising:

obtaining traffic data between the subject device and another device;

determining that the another device does not have a corresponding whitelist entry in the whitelist for the subject device and that whitelist entries corresponding to the another device in other devices of the same FAN are inconsistent; and

storing the traffic data with a flag indicating an anomaly of the one or more anomaly in the traffic data in an alert database for warning and further analysis of the anomaly.

12. The computer program product of claim 8 , wherein the one or more anomaly includes a device tampering, a device malfunction, a movement of a device in relation to the FAN, a cloned device, a Medium Access Control (MAC) address spoofing, and a cross-network traffic.

13. The computer program product of claim 8 , further comprising:

obtaining traffic data between the subject device and another device;

determining that the another device has a corresponding whitelist entry in the whitelist for the subject device;

discovering one or more discrepancy between the expected attribute values of the corresponding whitelist entry and the obtained traffic data, wherein the one or more discrepancy is greater than respective thresholds of acceptable variation with the expected attribute values; and

storing the traffic data with a flag indicating an anomaly of the traffic data in an alert database for warning and further analysis.

14. The computer program product of claim 8 , wherein the FAN is a radio frequency (RF) network covering one or more geographical area, wherein other field area networks are present in respective geographical areas which overlap, share borders, and/or within close proximity to the one or more geographical area covered by the FAN, and wherein each subject device in the FAN is associated with a respective whitelist including whitelist entries corresponding to other peer devices in the FAN with which the respective subject device legitimately communicates.

15. A system comprising:

a memory;

one or more processor in communication with the memory; and

program instructions executable by the one or more processor via the memory to perform a method comprising:

generating a whitelist for a subject device from two or more devices in a field area network (FAN) listing one or more peer devices in the same FAN communicating with the subject device as respective whitelist entries, wherein the one or more peer devices indicate all other devices than the subject device from the two or more devices in the FAN, wherein the FAN is for an infrastructure without a controlled perimeter, and wherein a whitelist entry in the whitelist for the subject device corresponds to a peer device of the one or more peer devices in the FAN and comprises one or more attribute values expected in traffic between the subject device and the peer device as represented by the whitelist entry; and

monitoring the traffic at one or more points of the FAN by use of the whitelist for one or more anomaly.

16. The system of claim 15 , the generating comprising:

determining a first set of devices that are physically communicable with the subject device in the FAN;

determining a second set of devices that communicates with the subject device based on communication policies and applications of the subject device;

determining devices in an intersection of the first set and the second set as respective objective device corresponding to each whitelist entry in the whitelist for the subject device; and

storing the whitelist for the subject device in a whitelist database, wherein the one or more attribute values expected from the traffic between the subject device and the respective objective device in respective whitelist entry include a directionality of the traffic, a periodicity of the traffic, a type of the traffic, and a volume of the traffic.

17. The system of claim 15 , further comprising:

ascertaining, prior to the generating, that the whitelist is to be updated based on one or more of: a change in contents of device applications and policies database, a change in contents of a device geolocation and coverage database, and a change in status of a device in the FAN, as caused by installing a new application in the device, by implementing a new policy for the device, by retiring the device, replacing the device with another device, and/or redeploying the device to a new location in the FAN.

18. The system of claim 15 , the monitoring comprising:

obtaining traffic data between the subject device and another device;

determining that the another device does not have a corresponding whitelist entry in the whitelist for the subject device and that whitelist entries corresponding to the another device in other devices of the same FAN are inconsistent; and

storing the traffic data with a flag indicating an anomaly of the one or more anomaly in the traffic data in an alert database for warning and further analysis of the anomaly.

19. The system of claim 15 , wherein the one or more anomaly includes a device tampering, a device malfunction, a movement of a device in relation to the FAN, a cloned device, a Medium Access Control (MAC) address spoofing, and a cross-network traffic.

20. The system of claim 15 , further comprising:

obtaining traffic data between the subject device and another device;

determining that the another device has a corresponding whitelist entry in the whitelist for the subject device;

discovering one or more discrepancy between the expected attribute values of the corresponding whitelist entry and the obtained traffic data, wherein the one or more discrepancy is greater than respective thresholds of acceptable variation with the expected attribute values; and

storing the traffic data with a flag indicating an anomaly of the traffic data in an alert database for warning and further analysis.