(disclaimer: I started typing this as a short response but it turned into a somewhat longer mail that has some project promotion. I hope i can blame the fact that I have been working on project phase proposals for the last few days) On 10/10/18 1:21 PM, Peter Steinhäuser wrote:
In my opinon a solution would be handling the IoT (and other devices) potential security threads at the home gateway with a strict, user controlled access policy. That would at least reduce the possible effect. There are the SPIN project and other initiatives that try to adress the issue although I haven’t seen something completely convincing, yet ;)
We are still working on SPIN, though within SIDN Labs SPIN is transfering more into a platform to do this type of research with (e.g. measuring iot devices). I am less involved with evolving SPIN as a home security platform concept and getting it into routers, and have handed that part over to a different department (since it's not my expertise or experience), and they are talking to others about partnerships for deployment. We do, however, want to work on some things that you mentioned here. We are currently working on a MUD implementation (somewhat separate of SPIN but it does fall within the project); I think this could be used as a user-controlled access policy, even if the manufacturers won't support it or go the 'i need all access' route as they are wont to do. I know others are working on this as well, as at least one presentation next week will show :) But i think having basic implementations is only the start, and I think it will also require legislation (enforce support to manufacturers) AND a large community effort (overridable, more strict profiles to be set by users) to reach its potential. IMO the final say should be at the user, but it should be automated to a 'secure default' since most users care even less than manufacturers. I also want to look into *making* MUD profiles easier to do. Or, TBH, even possible at all. There seems to be some confusion over the exact format, not to mention that it has been changing quite a bit over the several drafts. Part of this is starting out with live device measurements, based on the work a master thesis student did here recently. In a slightly different route, we also considered making the equivalent of a circuit breaker setup, but for networking (e.g. shut down parts that are shorting). I think this is still interesting, but we have dropped that for now. I do still see potential in ISPs sending hints about bad behaviour that the router can act on. And we are looking into how to do anomaly detection on these tiny devices (or offload it locally, but preferably not to yet another cloud). And, should people also/still be interested in the code part of the project, we released 0.7 this week (bundled with valibox 1.6), which added a local web API for control and network information. Next up on the roadmap are integrating lua-mud and replacing the data collector by something less kernely. Cheers, Jelte