I am pleased to report that our Architecture and Specification Working Group is making great progress on adoption of the .NET Core/Standard that will allow our new FDT Server-based architecture to be completely platform independent. Additionally, I’m happy to report that our FDT 2.1 Common Component developer tool kits for FDT/FRAME™ and FDT/DTM™ development have been finalized and released, thus clearing the way to begin enhancing them for the FDT IIoT Server™ (FITS™) .NET Core/Standard technology for next-generation product development for the FDT Server and Web-based Device Type Managers™ (DTMs™).
As we prepare the emerging FITS standard for the market, one common inquiry we receive centers around data security of the Internet of Things (IoT). This is certainly understandable as we transition from primarily a single user, desktop standard to one that also supports browser-based Clients accessing an FDT Server deployed in the enterprise, on-premise or in the cloud. However, there is good news: From the beginning of FDT, security has been a central focus of our architecture and has grown with the adoption of a dedicated security team attentive to the implementation of a secure core design approach for the emerging FITS architecture. Having this team focused on nothing but security frees them from the burdens of developing the standard, in order to remain singularly focused on defining risks, threats and best practices to meet the use case requirements for quality assurance for security.
In prior versions of the FDT standard, we have always had a user authentication requirement and granted authorizations to the user using a role-based security model. This has served the end user community and our developer community very well over the past decade. The role-based security model will be retained and enhanced in the core of the FITS architecture by adopting a layered security approach based on the defense-in-depth strategy as the architecture becomes more distributed. As a result, we have added Server and Client device authentication as well. These X.509 certificate-based authentication schemes use industry standard Transport Layer Security (TLS) to confirm that not only is this the correct FDT Server, but that the Client device is also authorized to communicate with the Server. This “triple handshake” of Server, Client device, and end user authentication ensures that no impersonations, man in the middle attacks or otherwise unauthorized access is permitted.
Additional provisions have been made so no one can eavesdrop on any of the communications. Again, we turned to well-tested TLS to encrypt all Client and app communications with the Server, in both directions, to ensure ultimate privacy.
For our OPC UA Server built into the FDT Server architecture, we support all security mechanisms that are prescribed by the OPC Foundation.
Finally, as a Server-based architecture, the ability to deploy the FDT Server in the public or corporate cloud allows full replication of the Server environment for instant cut-over in the event of a virtual Server or network failure. This improves availability, as all communications between a remote Server and the local control networks is conducted through a Virtual Private Network (VPN) tunnel or equivalent in order to shed the most nefarious of intrusion attempts.
This edition of our newsletter has a more in-depth look at security. I hope you will agree with me that our FITS architecture is engineered from the ground up to give you the assurance of a secure deployment. While we are happy with the progress so far, we remain committed to continued review of best practice implementations to ensure comprehensive data security.
Lee Lane; FDT Board of Directors Chairman