7 ms·

ControlMQ – Secure communications for control system applications

9 points by dwviel 9y ago

preya2k 9y ago
This website is horrible.
- dwviel 9y ago
  Thanks. We built it ourselves. We’re not web developers. We just wanted to get info out there. If we get major funding, we’ll spend big on a fancy website.
tmsldd 9y ago
How is it different from zeromq?
- dwviel 9y ago
  Great question. Some issues with ZeroMQ: It uses TCP/IP which has security issues that can lead to resource exhaustion. The SYN is sent but the sender never acknowledges the reply, so the server simple keeps the resource reserved waiting for the sender to get back to it. It leaks information in the message even if fully encrypted. Just the size of the message in a control system usually tells you what it is. It doesn’t protect against packet replay, which is particularly serious for control systems. An attacker can just sniff some messages, which are fully encrypted, authenticated, validated, etc., and save them for later. Then, when needed, resend them to reenact the former actions. E.g. “open valve” message is captured. Later, the “open valve” message is resent to, once again, open the valve, even though the legitimate user may have closed it and expect it to be closed.
  - theamk 9y ago
    Note: that answer is mostly incorrect. 1. While simple TCP/IP implementations have SYN flood issues, there are plenty of ways to mitigate them, including SYN cookies and third-party firewalls and load balancers. In fact, the SYN flood mitigations are so good, that most modern attacks are either raw traffic, or higher-level connections. 2. TLS pads your messages to block size (for example, 16 bytes). If your message size varies by a bigger amount, just pad all of your messages manually. This takes 2 lines in modern scripting languages. No need to switch to all-new suite. 3. This is just outright wrong. If you have messages which are "fully encrypted, authenticated, validated", then it means you run ZeroMQ with either TLS or CurveZMQ. Both of them have full protection against replay attack.
    - dwviel 9y ago
      Great comments. 1. See my reply to theamk above 2. The padding is good, but it needs to be the exact same size for all packets, which implies always using the biggest size. 3. See my reply to theamk above. We are expecting to run over unreliable networks that may have intermittent dropouts, so connection based solutions would require repeatedly reestablishing the connections, which would be cumbersome. The replay attack protection only exists within a connected sequence. Overall we think that our solution is simpler and less error prone to configure, and can operate over a wider range of conditions than existing solutions with fewer constraints.
      - theamk 9y ago
        1. Your reply was "SYN cookies can be a solution, but it has limitations, and to overcome those limitations requires changes to the TCP protocol." Can you tell me more about these limitations? I thought the SYN cookies work pretty well. And they are pretty simple to setup -- in fact, they need no setup at all, as they are already enabled by default in the recent distributions. 2. Right, so how does your protocol solve a padding problem? Why won't this method work with ZeroMQ? 3. As I was saying above, this is still wrong. Both TLS and CurveZMQ are protected against replay attack.
dkhenry 9y ago
Nowhere 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.
- dwviel 9y ago
  Great comment. The kinds of industrial controls that you mention are the long-term goal for the technology. We are working on a gateway adapter for some of the most common industrial protocols, such as ModbusTCP, and hope to have a product out early next year. 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
kefka 9y ago
Wow. 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 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.
- dwviel 9y ago
  Thanks for your thoughtful comments. Yes, I can understand your skepticism, and that is a good sign that you don’t believe whatever folks are just saying. That is particularly good in the cybersecurity field as claims that are unsubstantiated are often made. 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
aespinoza 9y ago
Why is this in the front page ?
jarboot 9y ago
How does stuff like this get to the front page?
theamk 9y ago
They have re-implemented entire network stack above IP layer. They start from raw IP (protocol 99), and then added "AES, SHA, RSA, and elliptic curve". So 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....
- dwviel 9y ago
  Yes, we have found that the set of Internet Protocols were designed before the kind of security we expect today were appreciated. You are correct that we are not professional crypto people. But, crypto is just the starting point for cybersecurity that is a necessary but not sufficient condition for a secure system. What we did was start with crypto, and related technologies like cryptographic hashes, secrets, etc. and built a secure messaging system using the principles mentioned above. This has so far shown itself to be highly successful. Hi, The reply buttons have apparently been disabled. I guess cybersecurity is too controversial for HN ;) I will reply here instead. @theamk 1) UDP leaks information, thereby violating the C in CIAA. TCP is subject to the SYN resource exhaustion attack, and is connection oriented which is brittle. Both are vulnerable to packet replay attacks, which is a particularly troubling problem for controls. 2) The pen testers that evaluated our technology we believe to be highly competent. We are open to having the pen testers (US only) of your choice test our technology. @pritambaral Yes, see the quotes on our website. And we do in house testing as well. We are happy to have pen testers (US only) try to defeat the system.
  - theamk 9y ago
    Glad to hear from authors! Question 1: So how is your solution better than UDP/QUIC or TCP/TLS? Yes, you have to properly tune and use protocols, by padding the data properly, and by setting up DDOS mitigations. Still, it will be much less work that writing a new protocol from scratch, and it will be better than your protocol in every single aspect. Question 2: What do you mean "highly successful"? I did not see anything in the whitepaper (but I have not read it very carefully), and the website has two quotes from hilariously incompetent pentesters. Do you have any other evidence of success?
dwviel 9y ago
Can my post get "unflagged" now?

9 points by dwviel 9y ago

preya2k 9y ago

This website is horrible.

dwviel 9y ago
Thanks. We built it ourselves. We’re not web developers. We just wanted to get info out there. If we get major funding, we’ll spend big on a fancy website.

tmsldd 9y ago

How is it different from zeromq?

dwviel 9y ago
Great question. Some issues with ZeroMQ: It uses TCP/IP which has security issues that can lead to resource exhaustion. The SYN is sent but the sender never acknowledges the reply, so the server simple keeps the resource reserved waiting for the sender to get back to it. It leaks information in the message even if fully encrypted. Just the size of the message in a control system usually tells you what it is. It doesn’t protect against packet replay, which is particularly serious for control systems. An attacker can just sniff some messages, which are fully encrypted, authenticated, validated, etc., and save them for later. Then, when needed, resend them to reenact the former actions. E.g. “open valve” message is captured. Later, the “open valve” message is resent to, once again, open the valve, even though the legitimate user may have closed it and expect it to be closed.
- theamk 9y ago
  Note: that answer is mostly incorrect. 1. While simple TCP/IP implementations have SYN flood issues, there are plenty of ways to mitigate them, including SYN cookies and third-party firewalls and load balancers. In fact, the SYN flood mitigations are so good, that most modern attacks are either raw traffic, or higher-level connections. 2. TLS pads your messages to block size (for example, 16 bytes). If your message size varies by a bigger amount, just pad all of your messages manually. This takes 2 lines in modern scripting languages. No need to switch to all-new suite. 3. This is just outright wrong. If you have messages which are "fully encrypted, authenticated, validated", then it means you run ZeroMQ with either TLS or CurveZMQ. Both of them have full protection against replay attack.
  - dwviel 9y ago
    Great comments. 1. See my reply to theamk above 2. The padding is good, but it needs to be the exact same size for all packets, which implies always using the biggest size. 3. See my reply to theamk above. We are expecting to run over unreliable networks that may have intermittent dropouts, so connection based solutions would require repeatedly reestablishing the connections, which would be cumbersome. The replay attack protection only exists within a connected sequence. Overall we think that our solution is simpler and less error prone to configure, and can operate over a wider range of conditions than existing solutions with fewer constraints.
    - theamk 9y ago
      1. Your reply was "SYN cookies can be a solution, but it has limitations, and to overcome those limitations requires changes to the TCP protocol." Can you tell me more about these limitations? I thought the SYN cookies work pretty well. And they are pretty simple to setup -- in fact, they need no setup at all, as they are already enabled by default in the recent distributions. 2. Right, so how does your protocol solve a padding problem? Why won't this method work with ZeroMQ? 3. As I was saying above, this is still wrong. Both TLS and CurveZMQ are protected against replay attack.

dkhenry 9y ago

Nowhere 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.

dwviel 9y ago
Great comment. The kinds of industrial controls that you mention are the long-term goal for the technology. We are working on a gateway adapter for some of the most common industrial protocols, such as ModbusTCP, and hope to have a product out early next year. 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

kefka 9y ago

Wow. 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 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.

dwviel 9y ago
Thanks for your thoughtful comments. Yes, I can understand your skepticism, and that is a good sign that you don’t believe whatever folks are just saying. That is particularly good in the cybersecurity field as claims that are unsubstantiated are often made. 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

aespinoza 9y ago

Why is this in the front page ?

jarboot 9y ago

How does stuff like this get to the front page?

theamk 9y ago

They have re-implemented entire network stack above IP layer. They start from raw IP (protocol 99), and then added "AES, SHA, RSA, and elliptic curve". So 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....

dwviel 9y ago
Yes, we have found that the set of Internet Protocols were designed before the kind of security we expect today were appreciated. You are correct that we are not professional crypto people. But, crypto is just the starting point for cybersecurity that is a necessary but not sufficient condition for a secure system. What we did was start with crypto, and related technologies like cryptographic hashes, secrets, etc. and built a secure messaging system using the principles mentioned above. This has so far shown itself to be highly successful. Hi, The reply buttons have apparently been disabled. I guess cybersecurity is too controversial for HN ;) I will reply here instead. @theamk 1) UDP leaks information, thereby violating the C in CIAA. TCP is subject to the SYN resource exhaustion attack, and is connection oriented which is brittle. Both are vulnerable to packet replay attacks, which is a particularly troubling problem for controls. 2) The pen testers that evaluated our technology we believe to be highly competent. We are open to having the pen testers (US only) of your choice test our technology. @pritambaral Yes, see the quotes on our website. And we do in house testing as well. We are happy to have pen testers (US only) try to defeat the system.
- theamk 9y ago
  Glad to hear from authors! Question 1: So how is your solution better than UDP/QUIC or TCP/TLS? Yes, you have to properly tune and use protocols, by padding the data properly, and by setting up DDOS mitigations. Still, it will be much less work that writing a new protocol from scratch, and it will be better than your protocol in every single aspect. Question 2: What do you mean "highly successful"? I did not see anything in the whitepaper (but I have not read it very carefully), and the website has two quotes from hilariously incompetent pentesters. Do you have any other evidence of success?

dwviel 9y ago

Can my post get "unflagged" now?