...
- 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 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).
...