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