Versions Compared

Old Version 1

changes.mady.by.user Dave Kelsey

Saved on

compared with

New Version Current

changes.mady.by.user David Kelsey - STFC UKRI

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Video conference

...

meeting of the WISE SCIV2-WG

4 13 May 2016 at 1413:00 UTC

Agenda

...

•Mandate of the working group
•Additional work topics
•Next steps and timetable
•Meeting logistics
•Next meeting

 

Slides shown by DaveK  Kelsey4may16.pdf

  • Minutes of last meeting (4th May 2016)
  • Look at SCI version 1 document and discuss questions raised by Adam Slagell
    • What are we trying to accomplish beyond creating the self-assessment, and did we meet those goals?
    • Do we need to extend the scope of the document, or should we focus on getting more impact from the first document (especially if we didn’t meet all our goals the first time)?
    • What does it mean to get acceptance by the DII’s, and have we achieved that?
    • Depending on where these lead, we might conclude that what we really want is more organizations doing the self-assessment and to have these results published centrally or otherwise. I could see that certainly helping those of us looking for resources or justification for the different components of our security program efforts.
    • Taking this hypothetical further, if that is our goal, a reasonable next step is to develop a guideline for the assessment. 
  • Comparison with Sirtfi V1.0 and ISO27002 (Alf Moens)
  • Next steps
  • Next meeting

 

Minutes 

Present: Eli Beker, Linda Cornwall, Dave Kelsey (Chair), Stefan Leuders, Alf Moens, Ian Neilson, Vincent Ribaillier, Mischa Salle, Adam Slagell (Vice-chair), Romain Wartel, Eric Yen.

Apologies: Sven  Warren Anderson, Bob Cowles, Sven Gabriel, Ian Neilson, Hannah Short, Von Welch, Eric Yen.

 

1. 1413:05 UTC - DaveK Dave welcomes all to this kick-off meeting of the SCIV2 working group and shows slides (above). The agenda is agreed (slide 2).

2. Mandate of the working group (see slide 5).

DaveK starts by presenting some background information on the SCI activity (see slides 3 and 4)

RomainW: How will we keep the working group real and connected to the currently existing operational activities and trust groups?
DaveK: via members of the working group and their connections to these activities. We should encourage wide membership of the WG but not demand formal representation.
AlfM: I agree. We are also not competing with other activities, e.g. TF-CSIRT. We should address areas that are not covered elsewhere.

It is agreed that we are defining best practices and building a trust/policy framework - we are very much NOT an operational group!

3. We go "round the virtual table" to allow people to introduce themselves and to say what hat they are wearing (who they represent).
EliB - ISSC (Israel NREN)
DaveK - EGI and WLCG
AlfM - GEANT, NL Surf
VincentR - Idris CNRS security officer, SCI member and PRACE.
MischaS - EGI Software Vulnerability Group (SVG)
AdamS - NCSA and XSEDE
RomainW - CERN, WLCG and various trust groups

4. Back to the mandate and scope. Additonal topics (slide 6).
We agree to create a child page on the wiki where issues of what is in and out of scope can be discussed/developed.
AlfM: I would like to compare the SCIV1 framework with one we have in the Netherlands. And what is the overlap with ISO27000?
DaveK: reminds people that we already have one successful development from the SCIV1 document, namely the work on Sirtfi being done by REFEDS and AARC.
https://refeds.org/sirtfi
https://wiki.refeds.org/display/GROUPS/SIRTFI
The Sirtfi version 1 document was developed from SCI V1 using the Creative Commons copyright.
DaveK: EU H2020 AARC NA3 is also now working on another development from SCIV1 to prepare a policy/trust framework for IdP/SP proxy/gateways bridging research communities to the identity federations.
This was discussed and agreed that it would be very good to avoid all the branching of the SCI document if at all possible.
Can we at some point merge back in with Sirtfi? And the IdP/SP proxy framework?
It may not be possible but we should at least consider that possibility and at the very least make sure we keep in touch with other activities.

Moving on - RomainW: we need to be aware of what is already going on in (and between) the various operational security groups and trust groups and encourage appropriate membership of the WG.

It was agreed that a review of existing communication channels would be a good place to start.

We then moved to a somewhat lengthy discussion about the desirability of including in the scope of the working group, information exchange about the handling of software vulnerabilities
between various infrastructures (a discussion that had previously started between EGI and CTSC). There are lots of different possibilities: sharing the work on assessing and handling a new vulnerability when notified (ie. in producing an advisory), sharing advisories after they have been produced, or even sharing intelligence about an upcoming vulnerability before announcement. Lots of interesting discussion involving how to share information and what to share, e.g. MischaS: EGI is dependent on Globus software and would be useful to receive advance notice and details of any new vulnerability.

In the end RomainW convinced us all that this should be OUT of scope of our working group. It is an operational issue that can be best handled by bi-lateral discussions between infrastructures.

. There were no further comments or corrections to the minutes of the last meeting (4th May 2016) so these are approved.

There were 4 implied actions at the last meeting. So as not to lose these Dave proposes that we use a group "actions" page on the wiki. He will create this.

2. We start to discuss the questions Adam had sent around before the meeting.
In relation to SCI version 1 document:

  • What are we trying to accomplish beyond creating the self-assessment, and did we meet those goals?
  • Do we need to extend the scope of the document, or should we focus on getting more impact from the first document (especially if we didn’t meet all our goals the first time)?
  • What does it mean to get acceptance by the DII’s, and have we achieved that?
  • Depending on where these lead, we might conclude that what we really want is more organizations doing the self-assessment and to have these results published centrally or otherwise. I could see that certainly helping those of us looking for resources or justification for the different components of our security program efforts.
  • Taking this hypothetical further, if that is our goal, a reasonable next step is to develop a guideline for the assessment. 

Adam points out that interpretation of what is required by version 1 is far from clear and proposes that we should perhaps concentrate our efforts on producing a set of guidelines.

BUT before we get too far, Romain encourages us to take a step back on consider our goals again. He reminds us of the history of SCI where we were documenting current best practices aimed very much at potential new infrastructures wishing to join. Subsequently we then realised that the document was also very useful to existing members of the group - as a way of seeing where further improvements were needed. So one important question on our scope: are we aiming to establish trust quickly with a new collaborating infrastructure or are we wishing to assess our own compliance/maturity? Romain says he wishes to use SCI as a way of establishing trust.

Alf reminds us that a number of NRENs are working towards ISO27000 certification. What should we use internally for assessment and what should we use for establishing trust with others?

Eli suggests that we should build a trust matrix - Infrastructure to infrastructure - not individual to individual.

Dave points out that trust between infrastructures is required not only for operational security but also to establish federated identity trust, e.g. will I trust another infrastructure to do authentication of its users to use my infrastructure's resources?

Lots of discussion followed without concluding on a definite clear mandate and goals of the group (we need this for the TNC BoF!) but there did seem to be general agreement that trying to interpret version 1 against our own infrastructures would be instructive and that we might be able to agree easier after trying this (see below).

3. Alf tells us about the comparison he has done of SCI V1 against ISO27002 and the Sirtfi published V1 document (see our documents page). This is not that he wants us as a group to adopt ISO27K but aimed more at seeing how things map and what is missing or in conflict. His initial findings that SCI is very much based on operational security and simple.  SCI is more practical with ISO more on policy and organisation. Alf also notes that the Refeds Sirtfi activity has changed some of the wording in Incident Response. We should consider merging their changes back into SCI V2. We could also consider looking at US NIST requirements and the Trusted Introducer maturity assessment.

Romain encourages us to keep SCI simple - this can then be used when trying to build trust with new infrastructures.

4. Dave shows the current (self) assessment spreadsheet (see documents page). He explains that the sub points lines (numbered e.g. 1.1, 1.2, 1.3) are all sub components of one numbered requirement from the SCI document e.g. IR1 and just correspond to the different requirements expressed so that the assessment is forced to consider each of the requirements in turn - rather than just one statement which may miss some sub-points.

Here again it is agreed that a guidance document would be useful. This could describe exactly what the requirement means and guidance on what sort of documents are needed rather than exactly specifying how to meet the requirements, e.g. how many hours is timely response? needs to be left for each infrastructure to define rather than SCI specifying the number.

5. We agree that the next step should be for members to consider sections 4 (operational security) and section 5 (incident response) of SCI V1 and prepare answers for our infrastructure to these (either a document or the spreadsheet). Discussing these will hopefully assist us in seeing what guidance is required.

 Dave also encourages people to edit the wiki page on scope with further ideas as to what exactly our mandate/goals should be.

6. Next meeting. There will be just one meeting between now and the TNC2016 BoF session. Proposed dates are 31 May, 1 June or 2 June. Dave will send a Doodle poll. The agenda will be to look at the SCI V1 comparisons (section 4 OS and section 5 IR) and decide what to present at the TNC BoF (e.g. an agreed mandate statement)4. Timelines (slide 7)
We need to work towards a firm plan for SCIV2 to be presented at the TNC BoF session (mid June) and later at the WISE meeting with XSEDE in July.
Then we should aim for an SCI document version 2 by the end of 2016.
For the next meeting (13th May) we agree to read and study SCI version 1 and have initial ideas as to what needs to be removed, what needs to be added, what needs to be expanded, what conflicts there are for some stakeholders.5. Next meeting.
Friday 13th May 2016. One hour video conference starting at 13:00 UTC.
Agreed that this "afternoon in Europe" timeslot works well, allowing for both participation from the USA (although West coast is a challenge!) and Asia (where it is getting late in the evening). It was noted that both Wednesdays and Fridays cause problems for some people. Will need to doodle for the next meeting after 13th May.
People were happy to continue using the Vidyo conferencing system.

DaveK: thanks to all for your participation.

Meeting ended at 1514:05 10 UTC

Notes by DaveK - 7 17 May 2016