Published-06-17-17-2017-08-10 Minutes

Meeting Notes 

Attendees 

Scott Shorter, KUMA – Coordinator (member)

David Temoshok, NIST (member)

Mark Hapner, Resilient (member)

Aakash Yadav, OKTA (member)

Jenn Behrens, KUMA (member)

Andrew Hughes, LC Chair (member)

Ken Dagg, IAWG Chair (observer)

Richard Wilsher, Zygma (observer)

Key discussion items

• Scott made a presentation that included: Scope of the sub-group; Ground rules for requirements decomposition; Requirements Naming Scheme; Requirements Data Model; Work Plan; Timeframe; Participation - sub-group members; Logistics.

• It was commented that there is not a specific priority on the sections, we want all them done and  we should drive towards completion on all.
  
  
• David T reported that NIST is working on a list of requirements pulled from 63A and 63B. Work group would appreciate the contribution. Ken inquired why A and B rather than C. David responded that the task is to find common mappings with GPG44/45 of UK cabinet office, and a range of Canadian government documents.  GPG44/45 correspond to 63A and 63B. Federation as an operational component was beyond the scope of that mapping.  May need to turn to 63C when they get to operational stage of this project.
  
  
• Andrew commented that compliance is the wrong word and suggested ‘conformity’, defined as fulfilling the requirements.
  
  
• Andrew provided a suggestion about the 'assessment methods' piece - Paul Grassi mentioned yesterday on the TFP call that NIST is aiming to produce a 63-3 guidance document in around January 2018. Maybe the 'assessment methods' piece might be dealt with as that material develops.
  
  
• David pointed out that IAF has to date required on qualified assessors to determine the assessment methodology to apply to SAC and documenting assessment methods goes beyond the current scope of IAF, qualified assessors would determine assessment methodologies to their satisfaction. So he asked if this a conscious expansion of the scope of the IAF. Colin responded that we’re trying to clarify more than anything else. May be a need to codify aspects of the assessment methods – middle ground between nothing and fully open.
• David noted that the initial work plan task was to state the requirements into a clearly understandable set of criteria that qualified assessors would be in a position to evaluate.
• Colin stressed that the general objective is to give a general approach and broad guidance.
• Scott commented that we cannot say that these are the required assessment methods because there is not external standard driving those requirements; we are here to identify the requirements in the source documents. We can talk about “potential assessment methods”. Difference between common organizational vs functional criteria in the IAF. Distinction Security assurance requirements and security functional requirements. The guidance is full of functional requirements what CSP shall do, and little guidance how do we know they shall do that. Although the assessor determines the amount of activity, a middle ground would be find some equivalent where potential level of effort could go to verifying different types of of functional requirements. For example explain why is it better third assessment than self assessment.
• Andrew suggested assessment methods is around putting more content into rules for assessment.
  
  
• Richard responded to Mark´s question on who will use the work product, saying that Kantara accredited assessors will use the decomposed requirements work product to judge the service providers.
  
  
• RGW affirmed that CO-SAC contents are not covered by 63-3.
• Ken mentioned that the new document coming from FICAM could necessitate the enhancement of CO-SAC.
  
  

• Ground rules were agreed. 
• DT suggested to include conditional requirements.

• It was commented that conditional controls will take place if you choose a certain authenticator or a certain registration workflow.
• Aakash pointed out that unlocking mobile phone is not considered biometric authentication for example. This requirement applies during the phone unlocking scenario.

• David asked if we’re intending that this will not follow the IAF. Scott clarified that it is not part of our task to work with the current IAF but with the work product we will be able to make a comparison to see where the IAF needs adjustment to the new requirements.

• Andrew suggested that the direct reference methods is useful during this exercise.  An independently named scheme will be useful in the long run, we should be ready to impose a Kantara specific naming scheme.

• Scott shared a data sample: Decomposed Requirements Example.xlsx

• It was agreed that the Google spreadsheet would be the place to compile the work product. 
• It was asked if the edited / decomposed requirements are the same as the service assessment criteria. Andrew responded that the requirements from the source document will be closely linked to the service assessment criteria, by Kantara’s adoption process. The SAC are about how to demonstrate having fulfilled the requirement. Without dictating what assessors must do, this may convey specific tests or evidence. 
• RGW asked how to define an assessment method if you don’t know the solution.  Andrew pointed out that this can point to a policy being in place without the implementation of the policy being validated in the text of the SAC.  Each accredited assessor should be able to achieve the same conclusions, given the same evidence.  If two assessors can’t agree on what nonconformities are, that’s a problem.

• Scott provided the ISO definition of a requirement: Expression in the content of a document conveying objectively verifiable criteria to be fulfilled and from which no deviation is permitted if compliance with the document is to be claimed http://www.iec.ch/members_experts/refdocs/iec/isoiecdir-2%7Bed7.0%7Den.pdf
  
  
• Andrew suggested that “assessment methods” could be “criteria”. 
  
  

• Richard commented that is not yet persuaded that we need assessment methods. Colin responded that depending on the requirement, we may state if the requirement is such that we can repeat it direct from the requirement.  Envision that we would have a category of terms to choose from to show the interpretation of the requirement.
• David comments – Kantara ARB does not assess the methodology that assessors have used to determine conformity to the assessment criteria.  Assessors should indicate their approach in assessment plans in accordance with security review standards, but to date there’s been no methodology for individual assessment criteria reported by the assessor.  If the intention is to have an evaluation of the assessment method that qualified assessors apply, that’s a departure from the way assessments have been done to date.
• Richard pointed out that it could impose an expertise qualification on the ARB. Andrew suggested that we may be overstating the significance of the assessment methods – if something must be assessed a certain way.  RGW suggests we are confusing how something may be required versus how it may be fulfilled.  Ex: CSP SHALL NOT misuse PII. We could have a criterion that shows that there must be a policy statement, we could also require that a credential policy.
• Richard suggested that we strike step three from the plan. Identify the requirements and refine them.  Andrew noted different usage of requirements – for Andrew, the SAC are not the same as the requirements as stated in the standard. Richard said that requirements are normative statements from the source documents.

• David has pulled the normative requirements from 63A and 63B.  Aakash suggested contributing his work on 63C.
• David observed that there are different ways to pull out the requirements and organize them.  Organized by AL for 63A, by generalized authentication approach and specific authenticators in 63B.
• David will look into potential errata on the source documents.
  
  

• It was agreed that Google spreadsheet works with static snapshots.
  
  

• Scott commented that Kantara IAF has encoded assurance levels into each unique criteria, map to what is required for which level, which subset is applicable to at level 2 and 3. 

Tasks for week 1

The Tasks for week 1 are: Identification: Analyze the source texts with the ground rules below to create a list of the requirements, conditions and recommendations.

ACTION ITEMS:

-Mark Hapner volunteered to work with 800-63A

-Andrew Hughes volunteered to work with 800-63B

-Scott Shorter volunteered to work with 800-63C

-David will check with NIST team if he can share the requirements that NIST extracted.

-David will look into potential errata on the source documents.

-Aakash Yadav will share his compilation of A, B and C.