ControlMQ – Secure communications for control system applications
cognoscentisystems.com
ControlMQ – Secure communications for control system applications
1–10 of 34 posts
Re: ControlMQ – Secure communications for control system applications
#2Re: ControlMQ – Secure communications for control system applications
#3Re: ControlMQ – Secure communications for control system applications
#4Re: ControlMQ – Secure communications for control system applications
#5I already have access to ZeroMQ, RabbitMQ, Mosquitto, Californium, and plenty more. And they all are open source under reasonable licenses.
So can someone please tell me:
1. Why should I trust your claim of security?
2. Why your product is worth money when I can go Open Source for free?
3. Why should I deal with Vendor lockin?
4. Why should I trust you?
Well... The obvious answer is that it's not worth it, at any cost.EDIT: I flagged it. I would encourage others to do the same. This is bad, horrible, no good junkware.
Re: ControlMQ – Secure communications for control system applications
#6Re: ControlMQ – Secure communications for control system applications
#7Re: ControlMQ – Secure communications for control system applications
#8So you cannot use TCP/UDP/TLS/QUIC -- they are too insecure; instead let's have a bunch of code designed by unknown people, likely with not professional crypto experience, and not verified by anyone.
Riight....
Re: ControlMQ – Secure communications for control system applications
#9Wow. This is a 30 day trial offer over supposed "hardened controls". Pardon my skepticism, but proof or GTFO. I already have access to ZeroMQ, RabbitMQ, Mosquitto, Californium, and plenty more. And they all are open source under reasonable licenses. So can someone please tell me: 1. Why should I trust your claim of security? 2. Why your product is worth money when I can go Open Source for free? 3. Why should I deal w…
The problem with cybersecurity is that you can’t prove a negative proposition. That is, it’s not possible to prove that a system will never be hacked. That said, there are ways of increasing the cybersecurity of a system to the extent that a compentent attacker, i.e. a nation-state actor, will need to commit significant time, personnel, and resources to attempt to mount a serious attack. Most likely they will look elsewhere to attack rather than the network interface that our product protects.
We have achieved a high level of cybersecurity by using several principles (in addition to CIAA): 1) Integrate the cybersecurity capability with the middleware so it is “built in” into the same product. 2) Limit our scope to controls systems messages so as to leverage the highly constrained nature of these kinds of fixed format messages to have an extremely small attack surface. 3) Use logical construction of mechanisms to specify what should only happen, and then rigorously prevents anything but that from happening. 4) Root the security in H/W. 5) Protect the full S/W stack from H/W to the application 6) Enforce an autonomous posture for all components to prevent a “brittle” system architecture, which would lock components together.
As to your specific questions: 1) The only way to evaluate the cybersecurity of a system is through penetration testing. We’ve had several highly competent teams evaluate our technology and have failed to defeat it in any way. You should have your own penetration test teams test all of your systems before you put them into production, and then periodically continue to test them for vulnerabilities. That said, no system is perfectly secure. But, we’ve been accepting systems with poor cybersecuity for quite a while, it’s time to raise the bar on what is acceptable cybersecurity. 2) You are free to choose open source or any product. The problem with current technologies is that they were designed before the kind of high-level cybersecurity we expect today was understood. These existing technologies are wed to their current protocols which can’t be patched to make them more secure. Only a redesign from scratch will do that, which is tantamount to abandoning their current protocols. 3) Vendors provide a product with features that are useful. That’s why we use them. Control of the technology is needed to ensure the proper implementation of the principles outlined above. 4) You shouldn’t. See answer to question 1) above. We need to earn your trust. In a sense, cybersecurity is a conspiracy of trust. Without trust there is no security.
Some further details are provided on the website: www.cognoscentisystems.com
I would be happy to answer any other questions you may have.
David Viel
Re: ControlMQ – Secure communications for control system applications
#10Nowhere on their page do I see a reference to anything doing actual control. No mention of integration with Allan-Bradley, or Siemens, or GE, or any other actual control system. If your not securing the link between the PC based portion of your control network and the part thats actually controlling things what's the point.
The technology is built up in layers. The base technology we call SecureSieve. We used this to build the first product, ControlMQ, which is a message oriented middleware for use with controls type systems. There are many applications for a MOM middleware such as robotics, medical devices, automation, custom controls, defense, aerospace, etc. We are using the ControlMQ middleware to build the gateway adapters.
Some further details are provided on the website: www.cognoscentisystems.com
I would be happy to answer any other questions you may have.
David Viel