The underlying problem is that CANbus was designed by automotive engineers and not network security people.
A good point. Another way of phrasing the problem I think is:
Systems are too often specified, designed and tested entirely in terms of their positive capabilities, rather than their negative capabilities. In the networked remote security environment, we need a design process that guarantees both.
In other words, most of our design process up to now has been all about "what a system CAN DO". But securing a system from to intelligent attackers is about what that system CAN'T do, even in the worst case. And since the number of things a Turing-complete computer with an always-on connection to the Internet CAN buut SHOULDN'T do is potentially infinite, that can be really difficult.
Tests generally only cover the positive features. It's hard to achieve complete test coverage by trying every possible combination of bad input (though fuzzers seem to be doing quite well at finding vulnerabilities, and it's embarrassing that amateurs keep finding bugs that the professional developers didn't.)duplicate finder Typing seems to be more useful in limiting capability, but our current type systems are very limited - for example, in most OO languages, the type system only guarantees that the call signature of a method is correct; it doesn't give any way of describing any other invariants that should be preserved during the computation; and the entire architecture of OOP is based on methods with side-effects which scales really badly to concurrent processing.
I think we've reached the limit of what can be safely achieved with loosely-typed imperative side-effectful OO languages like C++. These languages give us enormous power to create positive capability, but very little in the way of assuring negative capability. I'd like to think that Haskell or Erlang might be a way forward, but I've yet to wrap my head around either of them. I'm hoping we can eventually get something simpler, that allows creativity where it's needed but also lets us place hard limits on what unexpected interactions can arise.
That is really scary indeed. I do not want to imagine the future.
Slashdot Mirror
The underlying problem is that CANbus was designed by automotive engineers and not network security people.
A good point. Another way of phrasing the problem I think is:
Systems are too often specified, designed and tested entirely in terms of their positive capabilities, rather than their negative capabilities. In the networked remote security environment, we need a design process that guarantees both.
In other words, most of our design process up to now has been all about "what a system CAN DO". But securing a system from to intelligent attackers is about what that system CAN'T do, even in the worst case. And since the number of things a Turing-complete computer with an always-on connection to the Internet CAN buut SHOULDN'T do is potentially infinite, that can be really difficult.
Tests generally only cover the positive features. It's hard to achieve complete test coverage by trying every possible combination of bad input (though fuzzers seem to be doing quite well at finding vulnerabilities, and it's embarrassing that amateurs keep finding bugs that the professional developers didn't.)duplicate finder Typing seems to be more useful in limiting capability, but our current type systems are very limited - for example, in most OO languages, the type system only guarantees that the call signature of a method is correct; it doesn't give any way of describing any other invariants that should be preserved during the computation; and the entire architecture of OOP is based on methods with side-effects which scales really badly to concurrent processing.
I think we've reached the limit of what can be safely achieved with loosely-typed imperative side-effectful OO languages like C++. These languages give us enormous power to create positive capability, but very little in the way of assuring negative capability. I'd like to think that Haskell or Erlang might be a way forward, but I've yet to wrap my head around either of them. I'm hoping we can eventually get something simpler, that allows creativity where it's needed but also lets us place hard limits on what unexpected interactions can arise.
That is really scary indeed. I do not want to imagine the future.