https://www.mdpi.com/1424-8220/19/5/1141/pdf

Dear Rana Abubakar,

here is a small list of literature that can help you:

M. A. Ferrag, L. A. Maglaras, H. Janicke, J. Jiang: „Authentication Protocols for Internet of Things: A Comprehensive Survey“, arXiv, Dec 2016

https://arxiv.org/abs/1612.07206

Mohammad Wazid, Ashok Kumar Das, Jong Hyouk Lee: „Authentication protocols for the internet of drones: taxonomy, analysis and future directions“; Journal of Ambient Intelligence and Humanized Computing; Aug 2018; DOI: 10.1007/s12652-018-1006-x

https://link.springer.com/content/pdf/10.1007%2Fs12652-018-1006-x.pdf

LASeR: Lightweight Authentication and Secured Routing for NDN IoT in Smart Cities“, Mar 2017; arXiv:1703.08453v1

https://arxiv.org/abs/1703.08453

Mahdi Aiash, Jonathan Loo: „An integrated authentication and authorization approach for the network of information architecture“; Journal of Network and Computer Applications, Vol. 50, Apr 2015; DOI: 10.1016/j.jnca.2014.06.004

https://doi.org/10.1016/j.jnca.2014.06.004

Best regards and much success

Anatol Badach

Thank you Sir Anatol Badach

1. IoT is a marketing term. It is not a new technology. There is nothing about it that distinguishes it from other control system devices other than the foolish name. The first and best thing that you can do to secure IoT is to remove the I. Get it off the internet.

2. Authentication is easy to conceive in theory, but very difficult to implement in practice. I was on the DNP3 (IEEE 1815) SCADA protocol committee that designed the first couple iterations of authentication for the protocol. I know from first hand experience that it is not difficult to design the protocol. If a committee can do it, it might be arcane and nuanced in some silly way, but it's not that difficult.

3. The primary issue with all authenticated protocols is the propagation of keys, whether symmetric or asymmetric, with provenance. On a SCADA system, there is typically no third party Certificate Authority available. The reason for this is that it represents a single point of failure. For resiliency sake, most engineers avoid great big centralized servers of everything. You do not want to be on a petrochemical plant with things going badly all around you and then the CA quietly gets disconnected. Once the session keys expire, the plant (and your life) is in serious jeopardy.

So you ask about behavioral methods. I don't want to dump cold water on all these lovely excuses for research, but... Before you can write about behavioral methods you have to define the behavior of the polling software. The DNP3 Technical Committee has been stuck for over a decade over standardizing polling behavior on an event oriented protocol. The problem is that, like kernel design for a computing system, there are several conflicting goals and methodologies at play. You can mention a concept to a room with 15 sage, experienced persons wtih decades of experience in every aspect of design, integration, and operations of SCADA (not to mention a lot of gray hair, if they have any at all) and you'll get at least that many answers as to what it is. Everyone defines the behavior a little bit differently.

So your mission, if you choose to accept it, is to first define what nominal behavior of a polling master is. Then you can look for anomalies. Feel free to ping me if you're interested in discussing this further. My LinkedIn profile is https://www.linkedin.com/in/jakebrodsky/

Thank you Jacob Brodsky for your valuable time and concerns. But in my understating Ovation SCADA system working with certificate authority protocol (ovation highway interface). Last but not least obviously behavioral authentication methods underdevelopment area and open for researchers, dumping with cold water is not a good idea. :)