[Fiware-security] FIWARE: Security Architecture Description Chapter - VERY URGENT

[GIDOIN Daniel]

Dear GE owners, asset owners, dear All,

Following the comments of Pascal and Juanjo, a lot of changes have been made (thank to every boby)  but it is still work  to comply with these expectations.

Thank you to proceed as quickly to these changes. Dealine: Friday, March 2 at noon.
There will be no audio conference Friday morning.
I prefer this time be utilized so that we keep our deadlines. The final document is delivered to the commission Monday
In particular (Highlight in yellow):


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).
  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 (My opinion:  Overview must be enriched - Daniel)   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.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.
My opinion (Daniel):
DB anonymiser: Basic Concepts missing  & Basic design principles to be developed
CSS- Secure Storage Service: to be developed
Morphus antivirus: Basic design principle to be developped



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.



De : BISSON Pascal
Envoyé : mardi 21 février 2012 11:07
À : fiware-security at lists.fi-ware.eu<mailto:fiware-security at lists.fi-ware.eu>
Cc : BISSON Pascal; GIDOIN Daniel; LELEU Philippe
Objet : TR: Comments on Security Architecture Description Chapter
Importance : Haute

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/old-fiware-security/attachments/20120301/71adc8d0/attachment.html>