search

w3c / wot-security

a repo exclusively for security to better manage issues and security considerations for WoT
https://w3c.github.io/wot-security/
18 stars 22 forks source link

Security review of Lifecycle model and diagram #169

Closed mlagally closed 3 years ago

mlagally commented 4 years ago

Please review the lifecycle model we are working on from a security perspective:

mlagally commented 4 years ago

@mmccool : Please add also Clerley from Connexxus

clerley commented 4 years ago

I will review

zolkis commented 4 years ago

Please use https://github.com/w3c/wot-architecture/pull/478 for commenting on the text document, and this issue for commenting on the diagram.

clerley commented 4 years ago

I do not have access to the Google Drive link. I have requested access. I have reviewed the text and did have a few questions. Please, see w3c/wot-architecture#478 for my comments.

clerley commented 4 years ago

Very rarely the manufacturer will also be responsible for destroying the "Thing". Would it make more sense to have the arrow going from "Maintenance" to "Destroyed"? Usually the "Service Provider" or "Device Owner" will destroy the "Thing".

There is an asterisk in the "Service Provider Key: set *" . What does it mean? Can we add that to the legends?

I think the legends in R1 and D3 are backwards. From Operational you stop the service and go to Maintenance. Once the maintenance is complete, service is resumed.

zolkis commented 4 years ago

Very rarely the manufacturer will also be responsible for destroying the "Thing". Would it make more sense to have the arrow going from "Maintenance" to "Destroyed"? Usually the "Service Provider" or "Device Owner" will destroy the "Thing".

The reasons the arrow is from Maintenance state to Destroyed are the following:

I think the legends in R1 and D3 are backwards.

Indeed, I corrected. Thank you!

zolkis commented 4 years ago

There is an asterisk in the "Service Provider Key: set *" .

Right, that was because I copied the state text from the other (previous) diagram - which is not obsoleted, it's still valid. For now actually I have deleted the asterisk.

clerley commented 4 years ago

Oh, I see! I was looking at it incorrectly. I thought the manufacture was the actor and not the state. It makes more sense now. Before the device can be disposed, it must be reset back to the manufactured state so that staled information can be wiped out.

mmccool commented 4 years ago

I think the lifecycle has been stable for a while now (and merged) and perhaps ready to close. Let's ask @zolkis about the status and see if we can close this.

OliverPfaff commented 4 years ago

Tried to review https://github.com/w3c/wot-security/issues/169 but could not access https://drive.google.com/file/d/1E7dF65r8i1rx5ykJujMYe14RYPOvXAPf/view (asked for granting access but not yet have access). Moreover https://github.com/zolkis/wot-architecture/blob/lifecycle/proposals/lifecycle-model-proposal-zolkis.md results in a 404 error

ereshetova commented 4 years ago

@OliverPfaff try again for this link: https://drive.google.com/file/d/1E7dF65r8i1rx5ykJujMYe14RYPOvXAPf/view , I have given you the rights now via your Siemens mail

zolkis commented 4 years ago

Hi,

I have given access, but should not be bound to my permission. The link has changed: https://github.com/zolkis/wot-architecture/blob/master/proposals/lifecycle/lifecycle-model-proposal-zolkis.md (lifecycle stuff got its own dir).

Best regards, Zoltan

From: Oliver Pfaff notifications@github.com Sent: Monday, August 17, 2020 10:53 AM To: w3c/wot-security wot-security@noreply.github.com Cc: Kis, Zoltan zoltan.kis@intel.com; Mention mention@noreply.github.com Subject: Re: [w3c/wot-security] Security review of Lifecycle model and diagram (#169)

Tried to review #169https://github.com/w3c/wot-security/issues/169 but could not access https://drive.google.com/file/d/1E7dF65r8i1rx5ykJujMYe14RYPOvXAPf/view (asked for granting access but not yet have access). Moreover https://github.com/zolkis/wot-architecture/blob/lifecycle/proposals/lifecycle-model-proposal-zolkis.md results in a 404 error

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/w3c/wot-security/issues/169#issuecomment-674722978, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAHTFWWK5VNEYDGIQMUDLA3SBDOWNANCNFSM4M53ZVEQ.

OliverPfaff commented 4 years ago

Thanks for giving access. Some comments:

  1. RFC 8576 (https://tools.ietf.org/html/rfc8576#section-2) does a pretty decent job in elaborating the lifecycle of a thing in IoT. The RFC 8576 lifecycle model is also accepted by OT communities - with some minor modifications/extensions. The WoT lifecycle model seems to re-use and refine the IoT lifycycle from RFC 8576. However this remains implicit. Consider to make it explicit (in e.g. an accompanying text)

  2. User data should be qualified as optional (can be assume to be present in "Consumer IoT"; can be assumed to be absent in "Industrial IoT"; should be optional when "Consumer IoT" as well as "Industrial IoT" cases are to be covered by the WoT Thing lifecycle)

  3. Factory reset should not point back to the actor "Manufacturer" (is a product feature that is shipped with the Thing but which is under control of the owner/user i.e. its usage has little to nothing to do with the actor "Manufacturer"; the link R2 could be confusing/misleading)

  4. Similarily for R3 (R2/R3 are understood to be under control/responsibility of the user/owner i.e. should be associated to them)

  5. Revisit the term "service provider"; is known from IT; could be confusing/misleading. The suggestion is to consider the terms Thing user/owner and distinguished human users as well as legal entities as user/owner

  6. Differentiation of properties on the levels "Providers" and "Applications" could be more clear e.g. Configuration data

zolkis commented 4 years ago

@OliverPfaff I agree with the comments, thanks!

RFC 8576

That was one of the inputs for this work and it is explicitly stated in the md file. It also came up during the common workshop with T2TRG. Also, this model is very close to the T2TRG model, while works with other protocols as well (OCF etc).

However, keep in mind these will all be inputs to the text that enters the Architecture spec - so these comments should apply to that to-be-defined section in the Architecture spec and we need to keep it in mind.

About the terms, they are overloaded multiple times - I expect the Architecture doc will contain the right term definitions.

mmccool commented 3 years ago

Recommendations (from Security Review, these were reviewed and written during the 2020.08.32 security TF):

  1. Make relationship to RFC8576 explicit.
  2. Be more careful about the definition of "user data" as there are various legal issues here. We may want to define this functionally as "Data added during operation" and maybe call it "operational data". Likewise there could be "manufacturer data" and "installer data". Generally, name the data after the state that creates it. Note that PII data could be added in multiple states, eg "operational" and/or "installer". The current lifecycle has appropriate states and operations (reset to factory state) to allow deletion of this PII data as needed for privacy management. Perhaps this could be more explicit however ("reset to manufacturer state deletes all installation and operational data").
  3. Resolve confusion with R2 link; the manufacturer is not the actor that performs a factory reset.
  4. Resolve similar issue for R4.
  5. Need to carefully distinguish "roles" from "entities". The confusion here can be resolved if it is realized the "owner" could ALSO be the "service provider". We could make this clearer by including the word "role" in each of these names, eg. "service provider role" and "user role". Converse when we want to talk about specific entities we can use "entity".
  6. Use "Application configuration data" and "Service provider configuration data".

Some of the above does make things more verbose; a reasonable tradeoff for clarity.

mmccool commented 3 years ago

Please put future comments into issue https://github.com/w3c/wot-architecture/issues/533 so they are all in one place and the Architecture TF is sure to see them. Closing this issue (because the stated goal, to review the lifecycle and provide feedback, has been done) but once the architecture doc has been updated, we may need to do future work to update our guidelines. Suggest we do that once the arch doc goes to CR so the target is stable.

mmccool commented 3 years ago

Closed since review done. Discussion should move to linked Arch issue.