p8 Exec Summary
The recommendation from the reviewers stated as "An alternative approach, starting from the perspective of attempting to understand the threat surface presented by the EMI software stack, followed by a consideration of “what it means to be secure in the grid” might reveal a number of additional dynamic and behavioural security issues that could additionally need to be resolved." was considered. This recommendation points towards performing a risk assessment on the infrastructure hosting the EMI software. The EMI Security area has already participated in the WLCG risk assessment process and there is currently an EGI Security risk assessment ongoing. The results of
these may be considered by the EMI management for any changes to the work plan.

Would adding a summary of the initial findings related to middleware based on the TEG report [1] be appropriate for your document? The final version of EGI's Security Risk Assessment is also available [2].

[1] http://rwartel.web.cern.ch/rwartel/security_teg/WLCG%20Risk%20Assessment.pdf
[2] https://documents.egi.eu/public/RetrieveFile?docid=863&version=17&filename=EGI-InSPIRE-D4.4-final.pdf

p8 Executive Summary
There are cases where the schedule has fallen behind due to circumstances beyond the control of the Security Area groups or unforeseen extra work (e.g. release process).

p14 Status of AAI
The workload involved in
migrating the build (within the ETICS system) of other critical components (in this case Argus) has
again been underestimated. As the overall build priorities within the project have not been changed
the developers earmarked for STS development are still solving build system problems.

p29 Port products to additional platforms
The continued risk foreseen for this objective is the observation that, similar to the experience of the
release of EMI-1, porting to other platforms on the current build system is non-trivial. Developers
scheduled to start other work are delayed due to overrunning porting tasks.

These statements are difficult to defend/justify with EC reviewers and can lead to misunderstanding within EMI. See comments in odt.

We have been asked to include more technical information in the deliverables. I know this is may look like "padding", anyhow, do you think any of these could be added as annex

EMI Common XACML Authorization Profile v.1.1
Common Virtual Organization Attribute Profile version 1.0
Other security-area diagrams/tech specs we can include?




-- FloridaEstrella - 04-May-2012

Edit | Attach | Watch | Print version | History: r1 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r1 - 2012-05-04 - unknown
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    EMI All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright &© 2008-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback