[Fiware-security] TR: Comments on Security Architecture Description Chapter

[BISSON Pascal]

Dear Colleagues,

I'm just forwarding you this email I got from our Juanjo who as FI-WARE CA reviewed our Security Chapter contribution to D2.3a Architecture Specifications.

I'd like here each of the task leads and GE owners to process those comments promptly not to delay any more release of D2.3 from the perspective of our Security Chapter.

Comments have been enough detailed by Juanjo to be addressed by each GE owners as follow.


1.1   Monitoring GE (Thales - Daniel/Philippe/Pascal)

1.2   Context-based security & compliance GE (Atos - Antonio)

1.3   Identity Management GE (NSN - Robert)

1.4   Privacy Management GE (IBM - Anja/Michael)

1.5   Data Handling GE (SAP - Slim/Francesco)

1.6   Optional Security Enablers/Services (SAP - Slim/Francesco)

Counting now on each Task leads & GE owners to process those comments asap.

Best Regards,
Pascal

De : Juanjo Hierro [mailto:jhierro at tid.es]
Envoyé : mardi 21 février 2012 05:07
À : BISSON Pascal; GIDOIN Daniel
Cc : jhierro >> "Juan J. Hierro"
Objet : Comments on Security Architecture Description Chapter

Dear Pascal and Daniel,

  Please find below the comments on the Security Chapter.

  While for the rest of the chapter, things are progressing way and you have made a good effort, I have to say that the status of the Description regarding the Identity Management GE worries me a lot.

  Don't hesitate to formulate any question or doubt you may have.

  Cheers,

-- Juanjo


1. Major comments

1.1  Monitoring GE

  The Architecture Description is relatively well aligned with the guidelines provided for the Architecture Description deliverable except for the "Design Principles" section (contents placed in that section seems to be there because there was no other good places to place them).    Once we fix the contents of the "Design Principles" section, I would start carrying up a final peer review (looking into this GE more closely than what I have been able to).

  In a first approach, it seems a little bit strange that the structure of the section regarding "Main concepts" equals the one for "Main Interactions".   I would expect that the "Main interactions" section would be structured into sections linked to the different processes that take place during Security Monitoring, but maybe their description can be structured in terms of components involved.    On the other hand, it seems like description of some main interactions (Service Level SIEM) could be further elaborated including some sequence diagrams.   There is also no reference to specific interface names and specific operations but I guess this GE will be mostly used by administrators/operators of a FI-WARE Instance who will make use of the User Interface of related admin tools instead of applications which make use of APIs.

  Some figures may need to be converted to follow FMC notation.


1.2 Context-based security & compliance

  It seems like the Architecture Description of this GE follows the guidelines provided but there is a mismatch in the table of contents ...  The section titled "Main Interactions" looks like it should be titled "Context-based security & compliance architecture" while the sections under "sequence diagrams" within the "Basic Design Principles" section would actually fit better as contents of the "Main Interactions" section.   Contents of the remaining of section "Design Principles" look more like the detailed description of data exchanged in some of the interactions described in the sequence diagrams ...  however, the relationship is not so explicit because the text in the descriptions of sequence diagrams does not always include a reference to the request/response being issued.   I see to alternatives to deal with this editorially:

 *   Add the names of the specific operation request / responses within the sequence diagram descriptions and then endup the "Main Interactions" sections with a subsection titled "Basic Data Structures", elaborating on the detailed description of arguments linked to operation request/responses being referred in the interactions.
 *   Add the names of the specific operation request / responses within the sequence diagram descriptions and enrich then with text describing the data structures linked to those operation request/responses (e.g., "<entity-x> invokes the <op-name> request passing the <description-of-argument-1>, <description-of-argument-2> and <description-of-argument-n> as arguments")

  Probably the first option is easier to implement and I would recommend it.

  The figure on the Architecture should be converted to follow FMC notation.


1.3 Identity Management GE

  While this is one of the core GEs in the Security Chapter, the description is rather poor.   The "Basic Concepts" section doesn't say anything relevant and the "Main Interactions" section is merely a sequence of pictures with no explanation (btw, figures do not follow FMC conventions) .    I don't understand what "Design Principles" we are trying to describe with contents on that section.


  Improvement of the Architecture Description for this GE requires urgent and immediate attention.


1.4 Privacy Management GE

  It is stated that this GE doesn't go for the first release, but providing some info about what is expected in future releases is necessary.   In this respect, the info provided is helpful and I would consider this GE properly covered.


1.5. Data Handling GE

  I would review writing of the example scenario.  Some comments (part of them editorial, but I have decided to compile all them together here):

 *   First bullet, I guess that explaining that the Clique social network has been developed within the PrimeLife project doesn't add any value.
 *   Also first bullet, we introduce the role of "Data Controller" ... I guess it would be nice to introduce the concept of "Data Controller" someway in the paragraph of the Description section (section previous to the example).   Would it match the backend part of the "Data Handling GE" ?
 *   Third bullet:
    *   you refer to the "PrimeLife Privacy Tuner" ... is that a tool linked to the Data Handling GE ?   If so, I would use the term "Data Handling Privacy Tuner" instead.   Would "PPL Privacy Tuner" work, given the fact that use the term "PPP Privacy Engine" in the fourth bullet ?
    *   you say: "This tuner is a graphical tool used to edit Privacy preferences in PPL language defined in the deliverable" ... is the usage of the term "deliverable" appropiate here or is it the result of copying&pasting from some document in the PrimeLife project ?
    *   my understanding is that one of the things Alice would be able to configure using the Privacy Tuner would be what domain would be allowed to access data ... (or what rules will determine whether a domain would be allowed to access data).   If this is correct, I would mention it to establish a better link with what is being said in the fourth bullet.  This would make the example easier to follow.
 *   Fourth bullet:
    *   where is the PPL Privacy Engine running ?  My understanding is that it runs on Alice's machine but if so, please say it explicitly.
    *   simply editorial: should be "Alice's machine" instead of "Alice machine".
    *   you say: "the engine will enforce the access control rules related to the requested data".   If I understand it right, these access control rules would refer to rules setup by Alice using the Privacy Tuner ... If this is correct, I would mention it.   Something like: " the engine will enforce the access control rules related to the requested data that were programmed by Alice using the PPL Privacy Tuner"
    *   you say: " If the domain is allowed to access this data the engine match the privacy policy of the website with the preferences of Alice" ... where are the preferences of Alice configured ?   My understanding is that it is also through the Privacy Tuner.   If this is correct, I would mention it.   Something like: "If the domain is allowed to access this data the engine match the privacy policy of the website with the preferences of Alice, also configured through the PPL Privacy Tuner"
 *   Fifth bullet ... It is said: "Alice has the possibility to decide if she accepts or refuses to send her data".   If my understanding is correct, it should not only be that.  She should also be able to validate the privacy policy of the website (i.e., which data would be sent and what will it be exclusively used for).   If so, I would mention it explicitly.
 *   Sixth bullet ... I believe it would be nice to explain where both the sticky policy and Alice's data will be stored.   You refer to "the server" but ... what is that server ?   Will it be in the server where the backend of the Data Handling GE is running ?  If so, mention it explictly.   It would be worth mentioning, btw, maybe not in this bullet but somewhere, where can such Data Handling GE backend be running.   Does it necessarely have to be collocated in the backend of the Clique portal ?   Could be somewhere else, providing its functionality "as a Service" ?   If it may go somewhere else, provided "as a Service", then I would explain this is a possibility.
 *   Eight bullet ... (just editorial) You say: " The policy engine of clique.primelife.eu will match the privacy policy of travel.example.com with the sticky policy related to the e-mail of Alice (step 8), and will check if the sticky policy allows to forward for the purpose of statistics for example" ... I guess it would be better to say "... (step 8), checking if the sticky policy allows to forward Alice's e-mail address for the purpose of statistics, for example."
 *   About what we describe in the last bullet ... how it is prevented that the travel agency doesn't make a wrong usage of Alice's data ?   Could it be someway ?   If so, it would be worth explaining ...

  There is no section on "Basic Concepts".   Probably it would make sense to translate some of the content in the Appendix here (if you decide to move everything, just the reference would be kept at the end).   I would also suggest to elaborate on the following concepts:

 *   PPL and PPI
 *   PPL Privacy Tuner tool
  Figure on Architecture should be adapted to follow FMC notation.   On the other hand, it would be nice to illustrate there:

 *   What is the role of the Privacy Tuner ?  Please try to illustrate it
 *   Is the left big grey box a description of the architecture linked to the "PPL Privacy Engine" ?  If so, name it accordingly.   Otherwise ... what components would be linked to the PPL Privacy Engine ?
  Main interactions after the Architecture figure:

 *   You describe interactions in terms of operations described in some sort of description of a RESTful binding.   This doesn't follow the reference example provided as guidelines.   As a result, it is too austere and doesn't elaborate on who invokes an operation, for example.  Sequence diagrams would be useful.
 *   The suggested structure for the "Main Interactions" section is fine though:
    *   Data subject side:
       *   Managing PII
       *   Managing Preference Groups
    *   Data controller side:
       *   Uploading resource data and policy
       *   Uploading PII
       *   PII downstream usage request for a single PII

1.6 Optional Security Enablers:

  I understand the Architecture Description of these enablers, and particularly adaption to published guidelines, is under way.  Therefore, I will wait until they are more elaborated.


2. Minor comments (some editorial):

2.1 Monitoring GE

2.1.1 Service Level SIEM:

 *   I would recommend explaining what SIEM stands for

2.2 Data Handling GE

 *   I may be wrong but it seems to me like there is something missing or wrong (from an editorial point of view) in the following sentence: "It supports integrated data handling, in particular through two-sided detailed data handling, that takes into account specific preferences/policies expressed using the PPL language, based on XACML".
 *   It would be nice to describe what PPL stands for, the first time this acronym is used.   Same for PII.





-- Juanjo



-------------

Product Development and Innovation (PDI) - Telefonica Digital

website: www.tid.es<http://www.tid.es>

email: jhierro at tid.es<mailto:jhierro at tid.es>

twitter: twitter.com/JuanjoHierro



FI-WARE (European Future Internet Core Platform) Chief Architect



You can follow FI-WARE at:

  website:  http://www.fi-ware.eu

  facebook: http://www.facebook.com/pages/FI-WARE/251366491587242

  twitter:  http://twitter.com/FIware

  linkedIn: http://www.linkedin.com/groups/FIWARE-4239932

________________________________
Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/old-fiware-security/attachments/20120221/e60ba983/attachment.html>