
ControlMQ – Secure communications for control system applications - dwviel
http://www.cognoscentisystems.com/
======
kefka
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
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

~~~
kefka
I flagged it because I saw this as a hand-wavey "magic code" combined with a
website filled with market-ese. I've been long enough in this industry to
smell this at a distance. But I see the [DEAD] was rescinded. Ill be willing
to rescind my flag since a rep of the company is here (you).

_________________________________

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

It really has to do with multiple things here. First, is a new crypto
implementation. That sets of major alarms with me, no matter who writes it.
Especially so being infrastructure, this should be open source and publicly
accessible for review.

Secondly, you're using a new IP protocol. Full stop. This should be absolutely
IETF standard, reference design, full engineering review, kind of code. I see
none of that. I would get not having gone this route if you're trying to get a
new protocol spun up with a reference design. I'm thinking of IPFS, where
everything's open and done in public on GitHub and IRC. In my opinion, they're
going on the route of getting an IETF standard in a different way (of utmost
transparency and collaboration).

_________________________________

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

You want to play this game? Sure, I'll bite. How do you know you don't have a
protocol error baked in at the definition of how your stuff works? Sure, you
all were smart enough to build it, and some pentesters you hired said it was
OK. The basic idea with RFC's was that everyone, collectively across the world
could collaborate on how a protocol would work, or not. Failure domains could
be identified and caught before a full standard was made. Have there been
errors in these base protocols? Sure have. But they collectively have been
fixed.

How do you plan to have peer review of your __protocol __, let alone your
implementation? Hope and prayer, I guess. And when it comes to infrastructure,
that 's nowhere near good enough for me. I need an open, peer reviewed
protocol with a clear reference example. You can build your middleware and I'd
consider purchasing that for value-add. But "No Way" with regards to the
actual protocol.

_________________________________

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

Absolutely NOT. The other way to prove cybersecurity of a system is to __prove
__it. For example, I can write functions in Erlang that I can prove are
mathematically correct. I can show any input and its related output. I can
probe the state of the system and inspect it at any time. And I can
functionally understand it from a formal aspect.

Your claim is "Oh just pentest it". That's what you have to do for a black
box, but that only _delays_ major problems. For example, there's controllers
on Hard Drives. Only the HD makers know about them, so nobody can do anything,
right? Wrong. Enter Sprite_TM [http://hackaday.com/2013/08/02/sprite_tm-
ohm2013-talk-hackin...](http://hackaday.com/2013/08/02/sprite_tm-ohm2013-talk-
hacking-hard-drive-controller-chips/)

This person figured out how to control all 3 ARM chips, with unknown
instruction sets, from just probing, hacking binaries, and poking at stuff.
Black boxes like what you're peddling __WILL __get hacked. And if they 're
white hats, they will likely tell you. Or, exploits will end up on random Tor
auction site.

The middle ground is a published protocol and reference code to bootstrap. It
doesn't have to be feature-laden. But its the foundation of proper Networking
code. And instead, hand-waviness is claiming "We hired some hackers, so we're
good". That doesn't cut it, especially for critical infrastructure.

_________________________________

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

[https://xkcd.com/927/](https://xkcd.com/927/)

Oh, also, MQTT specifies absolutely nothing about payload type. Technically, a
publish to a MQTT broker can be a cryptographic payload, a DVD image, a
boolean, or anything. The spec allows __anything __to be put in as a publish.
From there, it would be trivial to extend MQTT to require a cryptographic
signature. Mosquitto supports plugins that could verify data authenticity.

And there's also RabbitMQ (AMQP) with forward-and-store. Similar extensions to
it are available as plugins. What I see here, is a strawman of "Something
something security" and pushing an untested, unfounded, unknown protocol for
IoT and industrial devices, and operating on the "Hope and Prayer" principle.

_________________________________

> In a sense, cybersecurity is a conspiracy of trust. Without trust there is
> no security.

I disagree with this as well. I shouldn't have to "Trust". That's what "Proof"
is about. Proof would allow me to accept the code, even if you are a bad actor
(I don't believe you are, I only think your goals are misguided). If the
foundations are solid, it wouldn't matter what you say, if anything.

~~~
dwviel
You bring up many valid points.

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.

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?

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.

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.

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?

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.

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.

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.

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.

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.

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.

~~~
kefka
My comment was too long, as deemed by HN. So I posted it here.

[https://pastebin.com/hLBbqk24](https://pastebin.com/hLBbqk24)

~~~
dwviel
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”?

------
theamk
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
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
Reply to your message edits:

> 1) UDP leaks information, thereby violating the C in CIAA.

Which information? Properly encrypted UDP only shows destination IP and port
number. Your protocol shows destination IP and protocol number (99) -- since
very few people use it, protocol 99 is as distinct as UDP port.

Moreover, if you are concerned with UDP port leak, you can just use a random
destination port on server, or masquerade as some other UDP protocol. There is
no such option with current ControlMQ system

> TCP is subject to the SYN resource exhaustion attack, and is connection
> oriented which is brittle.

You do know about SYN cookies, right? And you know that SYN flood is easily
defeated now -- for example, out of 5 most significant DDOS attacks in 2016
([https://www.tripwire.com/state-of-security/security-data-
pro...](https://www.tripwire.com/state-of-security/security-data-
protection/cyber-security/5-significant-ddos-attacks-2016/)) , none used SYN
flood.

> Both are vulnerable to packet replay attacks, which is a particularly
> troubling problem for controls.

Any control connection should use encryption. Every popular encryption method
(including TLS and QUIC) protects against replay attacks.

> 2) The pen testers that evaluated our technology we believe to be highly
> competent.

Well, all I have is front page quote, and I see the words "We were unable to
[...] observe [...] the message traffic" and "TCP and all the UDP ports only
list that they are open/unfiltered". This apparently means they could not even
use wireshark to observe the IP message traffic -- they just ran "nmap" and
found not ports. This is pretty sad for a pentester. I would expect to see
mentions of DOS attacks and fuzz testing.

For example, what happens if I just start sending random packets to your
daemon? How many packets per second it can handle before it fails over? What
if I compromise a client, extract a session establishment key from it
(assuming you have one), and start to establish new sessions? how many will
your server handle before failing?

~~~
dwviel
Good points.

The port number typically indicates a service that is publicly known and
repeatable. This is leaked information, as each service will have a unique
port number. The IP protocol of 99 is used for all communications so no
differentiation of network traffic can be made using this information.

SYN cookies can be a solution, but it has limitations, and to overcome those
limitations requires changes to the TCP protocol. It is also preferable not to
use TCP for controls in order to avoid the coupling caused by connections. The
network between components may also be unreliable thus causing the need for
regular reconnections.

Replay attacks protection by TLS, etc uses sequence numbers which expects a
continuous connection. There is the setup phase that must be taken into
account and then the entire series of packets from that point on can be
replayed. The goal is to run on unreliable networks so connections would
constantly need to be reestablished.

We consider DOS attacks to be attacks on the network rather than the
component.

The number of packets/sec that the daemon can handle is computer resource
determined. But, >1000/sec is typical in our testing on commodity H/W. It has
never failed due to load in thousands of hours of testing.

If a client (first peer) is compromised then it can send any message it wants
to the second peer with which it is configured to communicate. But, only
properly formed, valid range messages will be accepted. Let’s say that the
receiving component controls a motor that has a valid engineering range of 0
-1000 RPM. If a nefarious command came in to spin to 2000 RPM that would be
rejected. The server (second peer) is not connection based so it will handle
whatever packet arrive at the rate it can, and drop the rest on the floor.

So, overall we believe it is simpler and less error prone to use our protocol
then set up all these complicated extra configurations.

~~~
theamk
I was going to type in the long, point-by-point response, but then I saw this:

> Replay attacks protection by TLS, etc uses sequence numbers which expects a
> continuous connection. There is the setup phase that must be taken into
> account and then the entire series of packets from that point on can be
> replayed.

WHAT? You do know that you cannot just "take setup phase into account" in TLS
unless you have both server and client secret keys, right? There is the whole
"key exchange" step make it impossible?

If you write stuff like this, for god's sake, do not design encryption
protocols. I am horrified about what your code does if you do not know/don't
understand key exchange concept.

~~~
dwviel
Yes, but the packet replay protection is due to the sequence number of the
packet that happens after the session is established.

BTW, our technology uses pre-shared keys.

~~~
theamk
> Yes, but the packet replay protection is due to the sequence number of the
> packet that happens after the session is established.

The TLS does not use pre-shared keys. Instead, every time a client establishes
a new connection, there is a "key exchange" phase. Here is a simplified
explanation:

1\. client generates a random number, does some math on it, encrypts with
server's certifcate, and sends to server;

2\. server generates another random number, does some math on it, and sends to
client.

3\. after more math (see
[https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exc...](https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange)
), both client and server get the session key. If the exchange was not
tampered with, both client and server get the same session key.

4\. client and server exchange messages encrypted with session key. If they
both have the same session key, they will be able to decrypt the message
properly; otherwise, the connection is closed.

5\. Now client can send a command, such as "open door"

The reason replay protection works is because every time session is
established, the server will choose a different random number in step 2. So if
you try to replay, then step 3 will generate different session keys, and step
4 will fail.

Once the connection is established, there is a separate counter for replay
protection, but it does not have to be complicated -- because we know that the
session key is unique to this session alone.

This is how TLS / DTLS / QUIC do replay protection. Do you agree that these
protocols are fully replay-protected?

~~~
dwviel
Yes, I agree that TLS provides replay protection on a suitably reliable
network. Don’t know about DTLS or QUIC but I will look further into these. We
didn’t really look to much at TCP and TLS, etc. because early on we made
design decisions to have components adopt an autonomous posture and work with
unreliable networks, as can often be the case for controls. That led us to
reject all connection based network protocols such as TCP to avoid the
coupling it creates, and to create a very simple, one step protocol for
robustness and simplicity. But, I can see where use of TCP and TLS could be
useful, even for us, in some cases. To some extent this is a design philosophy
that is biased towards simplicity. I’ve noticed that in the software industry
there is a bias towards complexity. Almost a need among some to built “Rube
Goldberg machines” for everything. Each time a new issue is raised the
solution is to add new functionality or feature to handle it until the system
is a complex monstrosity, instead of reevaluating the whole enterprise from
first principles in light of new requirements. Our concentration is on design.
As I like to say “Code is nice, but design is everything.”, and its corollary
“No amount of code ever made up for a poor design.” Our concern was to remain
compatible with standards to the extent needed to remain switchable and
routable on Ethernet and IP networks, but to reduce the problem of controls
messaging to the simplest possible level while retaining a high level of
security.

~~~
theamk
Look, you keep saying "on a suitably reliable network". Where do you get this
stuff? TLS replay protection is always present and does not depend on network
reliability at all. You might not _establish_ TLS connection if your network
is super bad, but it does not mean replay is possible.

Can you PLEASE tell me how unreliable network allows TLS replay (or DTLS
replay, or QUIC replay -- they all do key negotiation)

------
dkhenry
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
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

------
preya2k
This website is horrible.

~~~
dwviel
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.

------
jarboot
How does stuff like this get to the front page?

------
dwviel
Can my post get "unflagged" now?

------
tmsldd
How is it different from zeromq?

~~~
dwviel
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
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
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
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.

------
aespinoza
Why is this in the front page ?

