| Thanks for the detailed response. I understand the need to see inside the technology to understand how and why it works. Some of our technology is being patented, so it will be published. Some is trade secrets, so we keep that closely held. These are business decisions that may change in the future as needed. We are considering publishing the protocol on the wire standard and the SIDL language, as so many people will likely want an open standard for these. We don’t believe in “security through obscurity” as that is just delaying the inevitable and fooling ones self. On the other hand, we do have some competitors that may like some of our closely held techniques, which we would rather not share. The example of the motor controller is a good one, and one that this technology handles well. In the case of a command to set motor speed the interface message specifies the acceptable range of values and the implementation on each side enforces those limits. So, the motor won’t spin beyond its capabilities. These are just the kind of use cases for which the protocol was designed.
With regards to RFCs, they are recommendations not specifications per se. That is, a vendor is free to implement the RFC as it sees fit. An offensive cyber operator told me that if you want to hack a network just open the RFCs and search for the word “may” and start there. So, what you get can be very vendor specific. Our chief concern as to attackers is the nation-state actors. We believe that they have the best techniques and are at the leading edge of cyberoffense capabilities. Unfortunately, there work is highly classified and we only get a glimpse or an innuendo occasionally as to what they do. One of the features of the technology that really enhances the defensive strength is the use of the highly constrained interface specification. If an attacker on a compromised client tried to shoehorn some malware into a message it would almost certainly get dropped as the bit combination in the message arguments would most likely not pass the constraint validation tests. Thus, the attack surface for the interface is greatly reduced from that allowed by other protocols. We don’t trust SSL, SSH, and SCP, as we’ve been told not to. We only use these during configuration when we tell users to disconnect the system from the network. I appreciate the thoughts. Makes me think hard about what we’re doing and how to communicate it. What about the “flagged”? |