These were just a selection of quotes that looked good on the web site, particularly the "GREAT JOB!" quote. That's kind of nice to see.
10 karma · joined May 4, 2017
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”?
BTW, our technology uses pre-shared keys.
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.
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.
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.
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.
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.
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
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