ControlMQ – Secure communications for control system applications
You bring up many valid points.<p>I won’t say much about crypto at this point other than we plan on having FIPS-140-2 certified crypto in the near future.<p>Yes, we are using a new protocol, but I don’t agree that it needs to be a full IETF standard.  We are working within the standard IP 99 protocol.  A protocol is just another piece of code, just like any other part of a systems code base.  It just happens that this code talks to code on another machine.  Should IETF or others review all code before using?  Has all the code you use been so reviewed?<p>We don’t know if there is a protocol error in the definition of our stuff.  If we did, we would fix it.  What we did is a careful analysis and design of a highly constrained solution that was then carefully implemented and tested.  That’s about as good as a human constructed machine can be built.  If errors are found as the protocol is used, we will fix them, provided they are revealed to us.  That’s the problem with cybersecurity, you never really know.<p>You need a peer review of a protocol.  OK, but I ask again, does all your code need such a review before you will use it? Or are you singling out network protocols?  BTW we are considering making this an open standard for the language and the wireline protocol, but we need to see how this plays out first.<p>Respectfully, I stand behind my statement that a system can’t be proven secure.  I understand that there is a lot of good work going on in provably correct systems using formal methods.  And I think that they will help greatly in making systems more correct, but they will never ultimately prove correctness in the mathematical sense.  Take the Erlang code, how do you know it’s design is correct?  That is, maybe it does exactly the wrong thing. Or that the code testing the Erlang code is correct?<p>Black box testing is the place to start.  Then progressively lighting the testing, from gray to white box is usually recommended.  Yes, testing is not perfect, but has defendable arguments about its correctness. Hence, the movement to use test-driven development.<p>Yes, there is a chance that our product will get hacked.  But, that is not the issue.  The issue is: will that take more effort, time, money, and resources to do than for what is being used today?  We think the answer is yes.<p>Whether a protocol, or any code, is published or not, it is still vulnerable to being hacked and that hack being kept confidential.  The effect is the same.<p>MQTT is a good example.  The payload can be anything, including malware, as in the example where a client gets compromised.  Our protocol is highly restricted so that secretly passing malware in a message is highly unlikely.<p>Again, respectfully, I stand by the statement that security is based on trust.  Proof has to be believed to be useful, so you have to trust the source of the proof, and who provides it.<p>Overall, we believe that our product is simpler and less error prone to configure, and less vulnerable to exploits then assembling all the technologies that have been mentioned here.  We are providing just one piece of a cybersecurity framework that only covers controls network communications, as part of an overall cybersecurity plan.