Risk management for TTN

fortean · November 21, 2016, 10:14am

Yesterday I was informed that the Dutch TTN team (whom designed / run the back-end) is currently way to busy to properly support this initiative. Without proper support it’s impossible to do a proper RA, let alone do something with the outcome of it. Which is IMO, the main reason to do RA.

In more formal terms: we currently don’t have management support, folks.

Also: a number of volunteers have expressed concern about this initiative. Some feel that it is against the culture here, which is a more pragmatical, technology driven culture. Others feel that my preferred methodology is simply not adequate for the phase we’re currently in. However, I’ve not seen any proposals for an alternate methodology to guarantee results. Sure, we could create a list of risks in the wiki, but apart from the questions about scope and methodology, if we don’t have support from folks to do something with the results, it’s all rather pointless.

@kersing and I have contemplated about this last night, we still see some light at the end of the tunnel (and hope it’s not the headlight of the approaching train). Our idea is to reset the scope to gateways - this is a domain @kersing is very familiar with (and I know a bit about it myself).

We will start compiling (stealing) a list of threats, set objectives, then work out possible controls. We may, in the process, decide on a methodology to weigh risks against each other, probably a semi-quantitative method. The result will be an ADVISORY list of control objectives / controls, which can be used by volunteers that run a gateway.

@kersing and I haven’t decided on much yet but will keep you posted. I welcome your input / feedback and if possible help / suggestions.

CurlyWurly · November 21, 2016, 1:58pm

Interesting points raised and IMO, this should tracked somewhere.
I guess one way to mitigate risk right now - is for individuals to take ownership of the risks by:
1 - Owning and managing the gateways that your devices will use
2 - Being responsible for the end to end security that your solutions use

One benefit ofthe above approach would be extensive saturation cover, which should move the “risk” emphasis onto other areas e.g. (techniques on how to stop spoofing).
Perhaps some sort of detection system smay be need in the future, which automatically checks how many gateways cover certain areas.

In the end, this is the begining of an interesting IoT ride!

julian · November 30, 2016, 10:19pm

Apologies for coming into this a bit late. From the perspective of what we are doing in Manchester this is really important especially as the ownership/liability of infrastructure both physical and digital is complicated. So we have to consider everything from network security to lightning protection and RF interference. What is great about TTN is that it is giving a lot of people experience of having to learn about these issues. What I can see happening in Manchester is that a legal entity will evolve out of it which hopefully will be a cooperative of all people involved. This will help win the support of the less risk averse public bodies but it will also give us a basis to put formal systems in place.

The work that we are doing with the Fire Service is a case in point we are developing prototype services, but there is no way that they could get beyond the prototype stage as there is all level of certification needed that requires proper RAs, compliance and standards of service. The reason why the Fire Service was interested though was because it was a) very inexpensive to participate and b) got them into a mode of thinking that wouldn’t really available if it started with standards first.

The compromise that is evolving though is creation of the free TTN network and in parallel maintaining a network with SLAs.

fortean · December 5, 2016, 10:20pm

@Julianlstar Thank you for the informative post.

Indeed, the importance of proper risk analysis can hardly be overestimated.

One of the newest developments is the publication of a series of documents about IoT security by the trade organisation of mobile telecommunications operators, the GSM Association (GSMA). The overarching document is the “IoT Security Guidelines Overview Document” Version 1.1, dated 07 November 2016. The GSMA also provides a Service Ecosystem Document, an Endpoint Ecosystem Document and a Network Operator Document. These documents provide - as their title suggests - a bonanza of best practices.

The GSMA also provides a self-assessment checklist, which enables various players in the IoT field to self-assess the conformance of their products, services and components to the GSMA IoT Security Guidelines. You can’t be ‘certified’ by the GSMA, but you can do a self-assessment, send it to the GSMA and they will review it (simple adminstrative checks). When all is found to be complete they will publish a statement on their website that you have completed the self-assessment and the name of the contact person in your organisation. As of now, there are no parties that have published a self-sessment yet - but that’s hardly surprising given the publication date of the documents (Nov 7th 2016).

The guidelines point out that ”almost all IoT services are built using endpoint device and service platform components that contain similar technologies to many other communications, computing and IT solutions. In addition to this, the threats these different services face, and the potential solutions to mitigate these threats, are usually very similar, even if the attacker’s motivation and the impact of successful security breaches may vary.”

Like in ISO27001, the importance of doing proper risk analysis is pointed out early on in the overarching document. The guidelines suggest breaking down the IoT infrastructure into components, then evaluate the risks associated with each component and then determine how to compensate for them (set controls). Even how the risk analysis should be done is indicated: “each risk shall be assigned a priority, to assist the implementer in determining the cost of the attack, as well as the cost of remediation, and the cost, if any, of not addressing the risk.” The checklist explicitly mentions the use of a ‘standard’ RA methodology and suggests CERT OCTAVE.

Apart from procedural guidance, there is also some very pragmatical guidance on e.g. physical security, and corresponding questions are in the self-assessment. Just to give you an idea, this is the set on Tamper Resistant Product Casing of endpoints (e.g. TTN gateways):

7.3 Use Tamper Resistant Product Casing
7.3.1 Do your endpoints use tamper resistant casing?
7.3.1.1 Our endpoints implement tamper resistant security controls.
7.3.1.2 Our endpoints contain circuits that invalidate NVRAM when a casing is opened.
7.3.1.3 Our endpoints contain Sensors that blow security fuses when abnormal conditions (e.g. light, temperature or voltage range) are detected.
7.3.1.4 Our endpoints contain Sensors that trigger an alert when a physically static device’s location is moved.
7.3.1.5 Our endpoints uses Epoxy covering for core circuit components.
7.3.1.6 Our endpoints raise Alerts when either internal or removable components are removed from the device.

So, apart from the NIST guidelines which are quite flimsy IMO, we now have a more substantial document to aide us - and it underwrites the importance of RA.

The main difference between ISO27001 and documents like these is that ISO27001 requires a management system (the ISMS) to be in place. The ISMS is based on continuous improvement (the well known Deming cycle, PDCA). Guidelines like that of the GSMA do not require this.

I-Connect · February 12, 2017, 4:07pm

Hi, wow big topic, lot of “process” text

For me it is an important topic as I came across it while searching the term SLA as I am intending to start developing and selling solutions using the TTN as “backbone” and I want to be able to give a clear answer to my future customers on the chance of (planned) outages.

For my own devices, software, gateway availability/coverage I can/should make the assessment myself but for software within the gateway and the TTN backend I would need input from TTN as this is not within my influence.
Is there any statement on this last part? Or is it currently only based on “best endeavors” and if so is it the intention to change this in future?

What the content of my statement to my customers exactly is is not important as long as it is the truth setting the correct expectations (although it would probably hamper my sales a bit if I have to say there is no up time guaranty at all… )

I do realize the product TTN is still very new and other areas probably have priority at the moment ( I hope so as I am waiting for my gateway ) but I think the suggestion of @Wienke to start this in a pragmatic way is very good. Is this already started? Maybe I missed this in the topic…

Regards,
Jeroen

ps
Not sure if it is the right comparison but take linux, still open source but look at how many business critical SAP systems are running on it these days. I guess at some point in time they also started with risk management somewhere being able to state/safeguard it is a reliable product…?

fortean · February 12, 2017, 6:15pm

Hi, Jeroen, very happy to see your response.

I’m not familiar with the internal processes and procedures of SAP, but yes, at a given point somebody must have done a form of risk assessment to determine if Linux would be a sufficiently stable and maintainable product to release SAP on.

It is certain that SAP is currently using an ISMS for their business, which involves selecting a methodology for risk assessment and treatmeant. See this quote from the SAP website www.sap.com/corporate/en/company/quality.html:

Certificates

We are also certified according to ISO 27001

One of the main issues with TTN’s “network” is the lack of a responsible party (a “Body of Governance”) that does risk acceptance on behalf of the community / network, including prescribing mandatory controls that need to be implemented and/or adhered to by all.

I am currently writing a dissertation about this, and one of the observations I have is that TTN consists of a kazillion entities, mostly seemingly totally unaware of risk, or if at all, then very biased towards their personal interests. The interests of actual users, and especially he interests of commercial organisations that want to use TTN are NOT represented by TTN, in my not really humble opinion.

This strikes me as odd - as TTN presents itself as a catalyst to stimulate new businesses. I can’t imagine any serious business that would say “Sure, you can buy this service / product from me, but I won’t give you any guarantees about its availabilty, as I’m working with a network that does not either.”.

I have suggested setting up a RACOM (Risk Analysis COMmittee), which could consist of (volunteer) specialists from the community, and which would have the means to enforce the controls they deem to be necessary for proper maintenance, uptime and security of the network.

I’m actually writing a dissertation about this, and one of my recommendations is indeed to set up such an entity. This should be endorsed and facilitated by the TTN foundation. This because they TTBOMK holds the rights to the name “The Things Network” and hence can decide - as can be done in a benevolent dictatorship as @Wienke once described it to me - whom are allowed to say they are part of The Things Network and whom not. This also probably requires a more formal agreement between TTN and the currently roughly 8000 entities that make up TTN.

Only if you have an entity that actively monitors the security / quality of TTN and is allowed to introduce controls to establish a proper baseline can we have a commercial grade network, that may indeed be used by businesses to build on.

I-Connect · February 12, 2017, 7:42pm

Hi Fortean,

Thx for the reply. It seems you have a lot of knowledge on the subject.

But I can image this/you can a bit “threatening” for an enthusiastic (mainly technical?) group of people that are currently very busy creating their new product with all the best intentions.They probably have a pile of technical work still to do and maybe worried at the moment to take on the full fledged risk assessment wow you are stating.

But anyways, with these posts the think process is starting, I hope we can make a pragmatic and common sense approach. I see a lot of products becoming overly expensive and cpmplex because of all the regulations and legislation around it pushing it way beyond the 80/20 rule into a quality level that is maybe never needed.

that TTN consists of a kazillion entities

Not sure if this is correct. Isn’t The Things Network (TTN) just that group of enthausiastic people? Maybe you meant to refer to IoT or Lora?
So maybe scope is not as big as we think and can we start with a reasonably small scope (TTN back-end and gateway software?) that can be overseen.

I am no expert on the topic but willing to give my input/help if needed/wanted.

Regards,
Jeroen

fortean · February 12, 2017, 8:38pm

Hi, Jeroen, thanks for the compliments.

I have studied Information security management for years and have advised companies about it (professionally). So, yes, I know a bit more about it than the average Joe.

I’m aware of the “threatening” aspect of my posts, but to be frank: I’m not here to win a popularity contest. Either the community consists of sufficiently professional participants to understand what I wrote, and hence understand or at least discuss the need for RA - in which case they clearly understand that I’m not a threat - or they don’t. In the latter case, I can be pleasing and comforting as much as I want, but that won’t help either.

My remark “TTN consists of a kazillion entities” refers to the parties that host all kinds of gateways and the few enabling legal entities, e.g. TTN foundation. In as far as I know no gateway hosting party has signed any formal contract with TTN and many of them run a gateway or other piece of hardware as they feel fit. For example, I host a gateway that @kersing has build. Knowing him, it probably is a fine gateway, but there are no guarantees. Yesterday, the wife inadvertedly triggered the test button on the RSD, causing a power-out. The gateway went down too. I’m quite sure I’m the only guy running a TTN gateway for miles, so probably the wife caused a local network outage all by herself . We do not have controls in place to prevent such outages.

No, in as far as I know the TTN foundation is NOT the leading entity. They facilitate the actual entities (legal entities, users) that make up TTN, but do NOT control them (yet). And as much as I like the idea a decentralised network from an engineers point of view , but from a risk managers position it’s a bad idea.

I-Connect · February 12, 2017, 9:12pm

: I’m not here to win a popularity contest.

Not sure if you are dutch but we have a saying that freely translates to “if there is no friction/rubbing there will be no shine”

only guy running a TTN gateway for miles, so probably the wife caused a local network outage all by herself

So true but way out of the “circle of influence” of TTN. Shouldn’t each entity think of the risks only within their own scope? This would be what I am looking for. I only need it from the TTN, I myself need to think about coverage (and the lack of it as I know it is a decentralized network), power, gateway availability etc for my sevice/application, Only thing I need to know is will my message that has entered a gateway go via the TTN backend and is routed (to again another parties application).

fortean · February 12, 2017, 10:07pm

Actually, the circle of influence of TTN could certainly include RSD triggered power outages, for example by making it mandatory that TTN gateways (or their power supplies) have a backup battery and are able to store messages for a while, which could be relayed still when the power / network connection returns. Or by ensuring that there are at least two gateways reachable everywhere (at least make that a formal objective). Etcetera.

As you see, there are many controls one can think of. The discussion about probability and impact should be held by the BoG responsible for RA, e.g. RACOM, and if the community (represented by RACOM) feels that, say, a backup battery is needed, than ALL need to install one, period.

Note that it would be perfectly acceptable to have the RACOM decide not to have such backup facilities, e.g. if they felt the impact or probability (or both) was/were neglible. If TTN would publish such findings of RACOM, at least outsiders would have a way to figure out how (un)reliable the network really can be expected to be.

By having any party that hosts a TTN gateway sign a contract with TTN in which they promise to adhere to the “common controls” subscribed by RACOM, we’d be on our merry way to establish a reliable network.

fortean · January 7, 2018, 2:49pm

Folks, time for an update.

You haven’t heard of me for quite a while - I’ve been busy.

Firstly, I’m proud to announce that I was accepted in the degree of Master of Science, with distinction, in Information Security. My dissertation - which can be downloaded from my LinkedIn profile - presents research on the organisational and technical structure of a public, volunteer driven Internet of things infrastructure (volioti), The Things Network (TTN). Last July, when I got notice, I was also informed that my project ranked as one of the best and was asked to come over to London and present my project there, which I did. It was very well received.

This dissertation could never have been written without the existence of TTN, and so thanks to this community are in place, methinks. I specifically want to thank @kersing for his valuable help and assistance: thank you Jac!

My dissertation provides an analysis of the current state of information security / risk management for the TTN volioti - well, actuall, the state it was in in May 2017 - and demonstrates the expected importance of volioti for tomorrows societies and the potential high risks involved. It provides motivation to introduce a more formal information security / risk management system for volioti. Suggestions are provided on how to improve information security for (the TTN) volioti, revolving around establishing a TTN volunteer based committee that will work on a sector specific standard for volioti, based on ISO 27001; a process to be guided by - and providing a use-case for – ISO 27009. Standards that might be used for volioti have been considered and applicable controls have been researched.

Then, last year I was approached by a group of information security specialists with the question if I’d consider presiding a Chapter of (ISC)² in the Netherlands. The international (ISC)² community consists of 130.000 certified information security specialists, see http://isc2.org. Chapters are the local workforce of (ISC)². I accepted and have been the President of the Dutch Chapter since then (see https://chapter.isc2.nl). We now have 500+ registered members.

One of our activities is to organise events, which are frequented by our members and also by other information security savvy people.

Our next event will be held in February and will have IoT as it’s theme. I will present my findings w/regard to TTN there. I have also invited @johan to come over to tell our audience about the current state of affairs w/regard to security at TTN. I hope Johan will accept. If not, I hope that somebody else from this community will do this, as I think it is very important to show both sides of the medal and more specific: engage the information security community in our work.

You can write a mail to president@chapter.isc2.nl and we will arrange things.

So far my update, may this year be the year in which TTN flourishes as a predictable network!