On 10 Oct 2018, at 12:21, Peter Steinhäuser <ps@embedd.com> wrote:

I think we have to live with the fact that there are many vendors that don’t care about security as long as it does not affect their revenue stream.

And live with the fact that some vendors won’t care about security even if it did affect their revenue stream.

On 10 Oct 2018, at 13:21, Peter Steinhäuser <ps@embedd.com> wrote:

Naming & Shaming can raise awareness but will unlikely help a lot solving the issue in general. I think we have to live with the fact that there are many vendors that don’t care about security as long as it does not affect their revenue stream.

Think is partially a question on who you shame them to and which name you use. Reputation could be made into one of the drivers for consumers, but I fear that the real problematic space is with the low cost generic OEM items that get branded and sold in a million different varieties. Industry itself might be easier, but also probably far less of a problem area to begin with. Also because there appears to be a bit more awareness growing with regards to risk and compliance with (existing) regulations. And then of course there is the risk of naming & shaming itself. Things might backfire in that you actually trigger policy measures that also have impact on “the good ones” or, given the stakes are quite high and lots of money gets put in these “solutions”, there will be legal pressure on the messenger. Especially if you aim to address end users and the retail market places. How hard would you need to push to get a product out of the market this way? And what if you succeed? Also not sure how RIPE would fit in this picture. You could of course position the community as a place to collect issues and verify them by means of discussion, but would that be something this Working Group would be willing to engage in? MarcoH (RIPE NCC, but in this case just thinking out loud)

On 10 Oct 2018, at 13:02, Peter Steinhäuser <ps@embedd.com> wrote:

I don’t think it’s RIPE’s and this working group’s purpose to get into the name & shame game. In my opinion we should define technical solutions that can be applied to address the security issues introduced by insecure devices.

This is a wonderful idea Peter! Consider yourself volunteered! :-) Would you like to help develop this suggestion, for instance by proposing how the WG could define these solutions? Maybe you could put together an outline for a BCP or something like that. It would be great if the WG could produce a RIPE document on this topic.

On 10 Oct 2018, at 14:15, Peter Steinhäuser <ps@embedd.com> wrote:

Sure - to be honest I’m not very familiar with standarization body’s procedures but willing to learn ;)

Which is where we as RIPE NCC can help as well, although my guess is that with a BCP you get to bypass most of the formalities described in the Policy Development Process, but that decision lies with the co-chairs of this group. Regardless of the process, in our role as secretariat we can look into ways to facilitate this discussion and how to document and best publish the outcomes. MarcoH

On 10 Oct 2018, at 13:15, Peter Steinhäuser <ps@embedd.com> wrote:

...

This is a wonderful idea Peter! Consider yourself volunteered! :-) Indeed :D

Excellent!

...

Would you like to help develop this suggestion, for instance by proposing how the WG could define these solutions? Maybe you could put together an outline for a BCP or something like that. Sure - to be honest I’m not very familiar with standarization body’s procedures but willing to learn ;)

There’s not much to learn Peter. RIPE doesn’t develop standards. In the sense that IEEE or IETF develops standards. RIPE sometimes develops policies, usually on the allocation of numbering resources. These policies are produced though the process defined in RIPE document 710: https://www.ripe.net/publications/docs/ripe-710. Anything can become a RIPE document, not just policies. The process is simple. Someone just says to the NCC “please publish this as a RIPE document”. And it is done. For this case, I think we want something that reflects a consensus view of the WG. If you can produce an initial draft or outline and post it to the list, we can discuss that, make changes and go through a few iterations of the document. Hopefully we then end up with something that has broad acceptance from the WG. At that point, someone takes the finished article to the NCC and asks for it to become a RIPE document. Over to you...

On 10/10/18 13:40, Peter Steinhäuser wrote:

...

There’s not much to learn Peter. RIPE doesn’t develop standards. In the sense that IEEE or IETF develops standards. RIPE sometimes develops policies, usually on the allocation of numbering resources. These policies are produced though the process defined in RIPE document 710: https://www.ripe.net/publications/docs/ripe-710.

Anything can become a RIPE document, not just policies. The process is simple. Someone just says to the NCC “please publish this as a RIPE document”. And it is done.

For this case, I think we want something that reflects a consensus view of the WG. If you can produce an initial draft or outline and post it to the list, we can discuss that, make changes and go through a few iterations of the document. Hopefully we then end up with something that has broad acceptance from the WG. At that point, someone takes the finished article to the NCC and asks for it to become a RIPE document.

Over to you...

Got it - will prepare an initial draft.

A volunteer is worth 10 pressed men. Give me a shout if you want proof/sanity checking Nigel

(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