Risk management for TTN

21

Actually, you are now fully engaged in the process of risk analysis, and I am very happy to see how well you do. What happens here is that I “invented” a threat: maintenance. The vulnerability is that a gateway in maintenance is not able to relay messages sent by life saving devices. We can accept that risk, or insure ourselves against it, or do something against it.

Now, we already have done the next thing: we came up with a control: temporarily install an alternate gateway. What is good to see is that you try to poke holes in that control: will the community adhere to that rule, will they accept the policy?

My instinctive answer here would be “yes, because otherwise they should not be part of this community”. But that may be a bit harsh, especially since I just started to work on awareness of RA in this community and so I should be a bit careful not to scare you away from the food. So let’s soften that statement a bit and say “yes, because we will make it easy for them to do so”.

So, for example, we could build a number of spare gateways and if somebody wants to do maintenance provide one of these to him on a temporary basis. Or we could hire a minivan, put a portable gateway aboard, with a nice long antenna that you set up to temporarily replace the gateway. All that the guy or gall that wants to do maintenance has to do then is to sent a message to the proper queue :nerd: (or an email, app, phone call, you name it), receive confirmation that it is accepted and by (strongly procedural) magic the aforementioned van appears in front of his house on the set time, he can do his maintenance and Ole Jones lives :ok_hand: - et voila.

I strongly resent the idea that we, volunteers, would not be able to create a network that is AS robust - and perhaps even more robust - than that of our commercial peers. I say we can, but also: that that requires some form of RA / ISMS, some creative thinking, not trying to re-invent wheels (so dang it, use the frigging standards) - and support by our members here.

22

And to add something that is also of great importance: it would be fully acceptable to decide NOT to install a spare gateway and live with the risk - as long as you can somehow prove that it was a conscious decision, based on proper RA, and that the BOG hence is fully responsible for the death of Ole Jones, but consciously has decided that it would be if that ever happened…

23

I suggest you take a moment to examine the TTN Manifest, it clearly states:

This implies (at least to me) you accept the risk of gateways/network not being available for any reason. So a potential user of the network should accept this risk, not burden the community with it. Few of the kickstarter backers and current gateway owners will accept additional responsibilities that have not been communicated upfront. Community members ‘donate’ LoRaWAN packets by installing a gateway. None of them signed up for the administrative overhead and responsibilities you are suggesting.

With regards to ‘maintenance’, keep in mind most gateways will be connected using residential internet access which is subject to its own maintenance schedule and service levels. You can’t expect gateway owners to know when maintenance is scheduled as not all providers communicate this clearly. And what happens when there is a major outage at a provider or a power outage in a city? Do you expect a gateway owner to find a way to register the gateway is down? Or immediately buy a new gateway when the current one dies?

Sorry, you are asking for something (I deem) beyond the scope of a community network. If you want to have an SLA, contact one of the commercial providers. If you just want to analyse the risks involved in using the current network, feel free.

2 Likes
24

Hi, Jac, good to see you.

Firstly, thank you for pointing me to the TTN manifest. That, to me, is legalese. Useful stuff that allows the BOG (if there is any here, is there?) to be able to squirm away legally from what I feel are ethical responsibilities. Ole Jones died - pity, but hey, we had a great time building a “network” and look, here is a manifest that says we were not to blame that it was not up.

The manifest is, in as far as I am concerned, in contrast with TTN’s main web page. Take a look at how our network presents itself, for example, open up the main web page. It says:

    We are a global community of more than 4000 people over 60 countries building a global Internet of Things data network. We use a long range and low power radio frequency protocol called LoRaWAN and for short range Bluetooth 4.2. The technology allows for things to talk to the internet without 3G or WiFi. So no WiFi codes and no mobile subscriptions.

Nowhere is there even a suggestion that TTN should not be used for applications for - say - saving or supporting elderly (or other folks). It’s a slick, neat web page, that just as well could be that of a professional Telco. It really succeeds in convincing me that I should use TTN .

But is TTN reliable? Can it be trusted? Well, the page goes to some lengths to at least strongly suggest this. E.g. scroll down a bit where you’ll find this:

    Our goal is to make the network architecture as decentralized as possible and avoid any points of failure or control. We already have a community of 10 developers writing network software and equipment firmware.

(my bold).

So, though formally you are right, and I fully appreciate the need to legally cover our behinds, I believe that the SPIRIT of TTN is (and if not: should be) that we WILL do our utmost to provide a reliable service.

Good risk analysis can help us to do just that. It is surprising what even a basic analysis sometime can do for the various security aspects. Risk analysis is like the proverbial reason a car has brakes: it’s not to stop the car - it’s to allow it to go faster where it can, because there is a control in place that allows it.

Yes, I will analyse the risks involved using the current network, of course I will. But I would really LOVE to be able to report that efforts have been made to improve that network, and let’s face it: nobody may like it much but risk analysis is one of the best ways to achieve that goal. I hope to be able to report that efforts have resulted in a more robust and secure FREE, volunteer driven network.

Even if Ole Jones is poor - and so can not pay for the service - he still might find it of great value to have access to a free, robust, reliable network.

BTW: if we really are not willing or able to make our network safe and robust, we should at least announce this loudly on the TTN front page, e.g. a banner that says “This network should NEVER be used to safeguard animals or people”. That’s also a control, and it’s a cheap and effective one. I really hope we don’t need to use it, as I believe we can do much better.

25

Thanks! I was writing along these lines when your reply popped up. I think TTN is above all a project to learn if it is desirable and feasible to have a citizens network. In this wicked world your considerations are very valuable imho.
Pieter

1 Like
26

Thank you, Pieter. You may be right, this may well be “just” a project to learn if it is desirable and feasible to have a citizens network. But that only would underpin my argument that we should invest in setting up a ISMS or similar framework - as a citizens network, IMO, should be robust, reliable, safe, not (just?) a hacking place for hobbyists.

All within realistic bounds - so, yes, in the early stages we will allow more risk (and pretty please, let’s be LOUD about these risks if they might lead to loss of human or animal life) - but by having some kind of ISMS we will have installed a control that forces us to reconsider risk often, and forces us to consciously decide on what risk is acceptable - to us. And by providing insight in our processes and their outcome, our users can decide if they feel that we do a good job or not.

27

I am not stating I would not like to see a robust and secure network because I would. And a lot effort is going into making it the best it can be while adhering to the manifest. My point is, when I joined this community and connected a gateway to the network a year ago no one suggested (and luckily no one involve in running the network does suggest so now) that I would have to adhere to SLAs, maintain an administration, plan outages etc etc.

I joined a free network where the back-end will be a robust as possible, data as save as feasible and use is free as well. And for me, free is not financial, I’m willing to provide financial support for the back-end if required, but I do want freedom as in not wanting all kinds of administration and other hassle.

Soon over a thousand gateways will be making their way to kickstarter backers in over 40 countries. Do you really think those backers want to perform risk analysis, have to consider what the impact of their gateway being off-line is for the network and work on continues improvements? I think the majority backed this project to get their hands on this new and exiting technology in an affordable way.

Like I said before, feel free to perform an analysis on the network as is. It should provide us all with an insight into risks involved and allow the users to make informed decisions on when its use is appropriate.

  1. Where on the front page does it say this network can be used for this? BTW, I don’t think it is required to add that warning, anyone designing for those use cases should be well aware of the limitations of the technology used in their design and make their own decisions accordingly. Everyone agrees LoRaWAN will suffer packet loss which is perfectly acceptable for a lot of uses, it is not acceptable for ‘panic’ buttons or alarm systems. Those solutions demand reliable end-to-end communications. It is no coincidence (modern) alarm systems have redundant communication links to the back-end.
  2. Where do we say we do not make the network safe and robust? The core team designed the back-end to be as save and robust as possible. However they are unable to resolve issues inherent in the technology. One of them being LoRaWANs use of the ISM band which many other users use, so collisions and packet loss are inevitable. Accept the limitations and choose appropriately.
3 Likes
28

Firstly, please note that I did NOT say we should introduce SLAs or paper work. Given the tone of resentment in here when such things are discussed I severely doubt that to be the proper controls at this moment.

Proper risk analysis is always done within a scope and it has a number of inputs, amongst them the culture and ethics of the organisation. Given what I’ve read here so far and given the short timespan that TTN exists, I think it is safe to say we’re a startup. Introducing a control like SLA’s and/or lots of paperwork simply does not work in that phase!

Actually, introducing such controls NOW would probably either reduce the number of volunteers whom rather find themselves a new hobby - hence introducing risk of unavailability of the network. Or they would simply ignore the control, introducing a false sense of security, which in itself is a risk! So you would be increasing risk by implementing such impopular controls and I would strongly advise against it.

In short: if a control is bound to fail, you don’t reduce risk implementing it, so don’t implement that control.

That being said… before one can even consider the first control, one has to have a clear picture of the dangers there might lurk (the threats), how severe it would be if a threat became reality (and in my trade one typically looks at aspects like confidentialy, integrity an availabilty of information), from that weigh the danger using some agreed on method and then, only just then, can one discuss controls needed to reduce risk.

I am sure that some form of informal risk analysis is already done by many volunteers. Take for example the case of installing a gateway at home. If it is put outdoors, some may feel that the cabling should be put in metal pipes to prevent rascals from cutting cables. Others may install a UPS or battery so when the power is cut off the gateway can be brought down in a controlled way (some run on PI’s and cold reboots can harm them). Some may even have created a 4G backup router in case their commonly used cable / xDSL ISP fails them. All very good controls to reduce weaknesses.

But given that we don’t have any means of monitoring what goes on in all these heads - thank Goodness for that! - let alone decide if what goes on in there is sufficient to reduce the risks to acceptable levels (and what are these acceptable levels) - we need a way to learn from others and improve our network doing so.

I say we at least need a body that discusses risk, and tries to reduce it. The body could gather data from volunteers (e.g. compile a list of controls the volunteers applied and against which weaknesses these controls work), could gather lists of threats and controls from others sources (standards are available), choose a method and then do a risk analysis for a limited scope, e.g. for the gateways. If our gateways are more robust, so will our network be. Little steps, but steps nevertheless.

If that is a success, we can broaden the scope. What say you?

29

The need for metal pipes depends on the placement of the gateway. If a gateway is placed on top of a 10 story commercial building the chances of rascals getting there to cut gateway cables is slim. The chance of someone unplugging the power supply or network connection might be ten times larger. So everything needs to be seen in context.
Creating a check-list gateway owners can (not must) use to evaluate risks would be helpful as it alerts them to a potential risk and next allows them to decide if it is acceptable or not.

Defining acceptable levels will be hard as different users will have different requirements, leading to different acceptable risk levels. You can not take the strictest requirements and apply them to the entire network as that would unduly burden some (large) part of the network with requirements only applicable for what might be a niche application.

The learning from others part is in place with the LABS section and the forum. Anyone wanting to share can use those means to put the information out there. Others are free to follow the advice, ignore it or improve on it…

That could be a starting point. To be really useful for users I think the back-end should be part of the analysis as well. As nodes and applications will vary wildly depending on the implementation they will be a challenge, however generic guidelines and a check-list should be doable.

Like I said before, I don’t mind a risk analysis, I would welcome it. When it comes to reducing risk, let’s not jump the gun and first see what an analysis yields.

30

It is important to me to get “the nod” from key players in TTN, and at least here in Groningen you are certainly one, at least in my book. So, your remark “I don’t mind a risk analysis, I would welcome it.” made me very happy :slight_smile:

Now, let’s see, what would be the best approach? Is there a group of key players that we can gather somewhere (the Big Building comes to mind, but I can offer access to various other locations) to do a kick-off?

31

If you don’t know who the key players are then how can you start on the risk assessment? - this is one of the challenges of decentralised organisations? Any risk assessment should take account of the use of open sourced software in a non-commercial structure - TTN is not a telco.

If this “risk mapping group” has access to information such as the resilience and architecture used in TTN and they don’t share this then there are issues as to transparency and agency.

I for one feel the first steps prior to any risk assessments is public disclosure as to ownership and details of the non-open source elements of the TTN architecture, together with clear plans and intentions on open sourcing hardware and software of, for example, the new TTN gateway.

32

I was not aware we were using proprietary code, John, but perhaps that could be seen as a risk, and hence could be considered by what I for now will call “TTN/RACOM” - the risk analysis committee of TTN.

We also utterly agree on the impossibility to do a group based risk analysis if you don’t know whom they are :slight_smile:.

Now, the key players for TTN are listed on its front page, but perhaps they aren’t (all?) the proper ones to approach. But they certainly need to be informed of any efforts we make to introduce risk analysis here. Actually, I fully agree with you that we should be open, transparant, report frequently to whom it may concern, and that most certainly are our volunteers. Proper communication should be a main concern of TTN/RACOM.

Maybe the best approach is to simply arrange a kick off meeting, see who shows up, and even if there are only 2 people present - we then have established TTN/RACOM, which then does research, issues a series of proposals, and after acceptance (or lack of comments) it can go from there and start risk analysis for TTN.

Almost everything we do in this respect would be better than not doing anything, even if TTN/RACON is a total failure, we then at least know what NOT to do w/regard to introducing risk analysis.

I would rather see that a broader selection of specialists would gather in that committee, e.g. one for the back-end, gateway, nodes etc. - and let’s not forget a person that is skilled in risk-analysis, perhaps a person that is aware of legal and regulatory principles. But I’m not picky, as long as we have a group that is able and willing to think about threats, weaknesses, controls etc. I say we should simply go ahead.

If there are better ideas, I for one am all ears!

33

(End of the posts that I moved from “Elderly care LoRaWAN products”.)

1 Like
34

Thank you Arjan, very kind. Would it be possible to add a new category ‘risk management’ and put this thread in there?

35

My apologies for not replying to this topic. We our in hyperfocus mode to get the Kickstarter products to the community ASAP so this one slipped through.

My 2 cents.

  1. This is very relevant and this way of approaching is important.
  2. We need to be pragmatic. Our organisation is here because we act very lean. We try things first before we make solid solutions. I would love to see it applied here as well.

Proposal:
Should we start with creating a list on the wiki that addresses all the risks. Then sort them by priority. Brainstorm mitigation per risk. Create a short term plan for that.

Would that be an idea?

3 Likes
36

Thanks for replying and acknowledging the importance of RA for TTN :blush:

I love the idea of being lean and fast, of doing by doing. Your approach strongly reflects the TTN culture, which is essential to make anything we do work. So, yes, your approach may well work!

But, though risking to be the killjoy of my own party, we need to consider a few important things before we can dive rght in. They are:

  • which scope to choose; e.g. will we consider the entire TTN infrastructure, or the backend, or the gateways, the nodes - or perhaps focus on the volunteers, the organisational structure etc. - please note: that would be our starting point, we can pick a bigger scope after we have proven that we have created something that works within the initially stil limited scope;
  • engage (and where needed: educate) the community. We must ensure that all that cooperate within TTN are aware of this initiative,they should know they are very important players to help make this come true. We should ensure they know who(m) to address with comments, feedback, ideas etc.
  • establish some type of "body of governance" for RA related issues. I have suggested we set up TTN/RACOM - the TTN Risk Analysis Committee. RACOM would be responsible for compiling everyting necessary to allow the relevant parties to perform risk analysis. Given that setting up an ISMS and/or performing risk analysis requires specific knowledge that not everybody in here will have, you'd need some experts to assist you (yes, I'm volunteering). Also, we need to have a few people that are seen as key players in TTN - people whose opinion weighs in, and when decisions need to be made can be decisive without offending the volunteers. I therefore hope that you or one of the other TTN key players will take a seat in the board of that body (more would be welcomed, of course).

What do you say?

37

To be completely honest, I’m happy that there are people who enjoy doing these (IMO boring) things, setting up committees, etc, so that I don’t have to :slight_smile:

1 Like
38

Well, assuming that many in here don’t like to do “boring” stuff like RA- I believe that we should gather the few that do, give them a sufficient profile and responsibilities, and trust them to come up with a plan to reduce risk. That would be TTN/RACOM, The Things Network Risk Analysis COMmittee.

TTN/RACOM would invite opinions and suggestions of volunteers about risk related matters, and discuss these both openly in our forums / wiki and in formal committee sessions (of which notes will be made available).

One of the mission statements of TTN/RACOM would be to establish standards, processes, controls, and other measures to reduce risk, that are acceptable by the community. Perhaps some voting system should be used to allow registered and contributing volunteers to vote on them. Once decided upon by a (2/3?) majority the measure would become mandatory for all to implement or adhere to.

Yes - mandatory. Yes, we will check. Those who can’t or won’t agree - alas - can not be part of the TTN network anymore. Enforcing this is of key importance, because for many controls and measures the weakest link determines the strength of our network.

Now, a few may frown upon such seemingly harsh statements - isn’t what I just wrote clashing with the presumed “freedom” we all like so much here? I say it isn’t: you’re already used to similar harshness on the technical level. E.g. like it or not, but if you want to be part of TTN you’ll have to agree to their technical standards and their terms and conditions and API’s too. You can mutter, dislike it, but that’s how it is: once agreed upon, they are binding.

Now, before we spend a lot of time discussing this, I believe that the essential question here is: key players, maintainers of the TTN backbone: would you be prepared to block volunteers that do not conform? Because if you aren’t, all we can do is give some advice, but we won’t be able to CONTROL the security and robustness of our network.

So, what do you say?

39

I think it would be a real error to apply such models to the TTN project.
This is not how open source projects are developed. If there is an attempt to implement this people will turn away, and fork the project and run private networks and maybe peer with TTN.
38 Messages about risk management and noone has even started working on a list of risk factors.
Applying formalised procedures designed for hierarchical organisations with directors and shareholders won’t work IMO.
Using models for other decentralised projects (such as Linux kernel development) might lead to better results.

2 Likes
40

Thanks for your comment, John.

The 38 posts in here simply indicate that a lot of thought and knowledge is being put in, and I believe that is exactly what we need in this phase. Actually, I had hoped for more posts - provided I would not have to write them and that they would help us answer at least the major questions: about scope and how to create a working management system for RA (the BOG question).

You seem to suggest a BOG like used by the kernel developers. I know that in olden days a certain mr Torvalds was seen as THE key player and if you had convinced him of the need to implement something (in some way) - that would be how it would be done. I was always slightly annoyed by that - seems to be very undemocratic - but OTOH his virtual dictatorship has sufficed to bring Linux to where it is now. I’m not a kernel developer and haven’t kept track of how their governance developed - surely they replaced it with something better, right - so I would be very happy to hear how major decisions are made and how you’d envison their (current) methodolgy to work for TTN Risk analysis.

Apart from the questions about governance there still is the question of scope. I believe that we should start with focus on a certain part of TTN, as probably trying to oversee all off TTN and do a risk analysis for all processes and infrastructure would be a bit too much to chew of for now. What often helps is asking the question: “what do you see as the most important part of your infrastructure?” - often the answer to that question indicates where most risk should be reduced.

Are it our gateways? Kersing suggested starting there, I guess because we have a LOT of gateways, so we have a lot of attack surface there. Or should we focus on our backbone?