IAWG Meeting Notes 2013-05-02

Owned by Former user (Deleted)
Last updated: May 15, 2013

Kantara Initiative Identity Assurance WG Teleconference

Call not at quorum

 

Date and Time

Agenda

    1. Administration:
      1. Roll Call
      2. Agenda Confirmation
    2. Discussion
      1. ALx_CO_ISM_#80 and ALx_CO_ISM_#90 (Ticket #287119)
        1. what is the scope of the audits specified?
        2. how was the frequency of the audits decided?
      2. Agile IAF - report re: FICAM's direction with components (Andrew)
      3. NIST 800-63 comparison update (Richard)
      4. NIST 800-162 - Guide to Attribute Based Access Control (ABAC) Definition and Considerations (Draft)
    3. AOB
    4. Adjourn

 Attendees

  • Myisha Frazier-McElveen
  • Bill Braithwaite
  • Scott Shorter

As of 14 January 2013, quorum is 4 of 7

Non-Voting

  • Ken Dagg
  • Rich Furr

Staff

  • Andrew Hughes

Notes & Minutes

Discussion

ALx_CO_ISM_#80 and ALx_CO_ISM_#90 - Ticket 287119
In section 4.3.3 CO_ISM - Information Security Management, CO_ISM#80 and CO_ISM#90 
require Internal Service Audits and Third-Party Audits at specified frequencies 
(either 24 or 12 months depending on AL and type of audit).

The rationale for changing from 24 months (independent audit) to 12 months was based 
on the idea that there must be a certified ISMS for LOA3, and in that ISMS there is 
most likely to be the requirement to conduct it each year.

I think these criteria could use an edit - there seem to be some parts that are unclear.

AL[2,3,4]_CO_ISM#080 do say Internal Audit every 12 months
AL[3,4]_CO_ISM#090 say independent audit every 12 months


At least three issues arise:
1) At AL3 and AL4, the criteria appear to require a Third Party audit as well as an 
Internal Service audit every 12 months.

2) The scope of the audits in both criteria could use some clarification. Do internal 
and 3rd party audits have the same scope? If so, then why do both? If not, then what 
should each focus on?

3) If the scope is the ISMS only, would it be sufficient to provide evidence that a 
part of the organization conducts regular reviews, tests and assessments of the ISMS 
and its effectiveness - rather than explicitly calling out the 'internal audit function'?

What is the scope of the audits specified?

How was the frequency of the audits decided?

We need to either change the guidance, or change the rule, to be more clear

  • This becomes more of a problem in AL3 - AL3 says two different audits for ISMS, and that those audits might be of different scope, but that's just a suggestion not guidance; this is ambiguous enough to be open to an unacceptably wide interpretation
  • another interpretation is that you have to do both independent AND internal audit once you are at AL3, which seems excessive; this is different for AL2
  • the reason there is an internal and independent is that for AL2 and 3, ISM 80, seems to be a set of assumptions (see change log for v3)
  • suggest having an internal audit alternating with an external audit every year
  • holding the conversation until RGW is available to discuss

 

Agile IAF - report re: FICAM's direction with components (Andrew)
  • What is the nature of the assertions of the information that flows from party to party?  What are the core services within a Trust Framework?  The concept of components is considered interesting and useful by many.
  • What is the function of a Trust Framework relative to trusted identity info or trusted attribute information?  When you have untrusted attribute information, the trust framework provides certified processes that validate that raw data, and because it is evaluated by a trust framework, it becomes a trusted source of data.  At some point, the data has to make it in to an IdP's database, and that is the interesting action for a trust framework - the processes that onboard information in to a system
  • the models we have now are data flow diagrams and will be breaking them down to assign to different standard services; the idea is to come up with a way to determine when you can trust information and how it might be combined within a trust framework to create other trusted information
  • Anil John and Cathy Tilton (Daon) were invited to the ARB this week to discuss what FICAM's plans and vision is for the component model for trust frameworks; the industry trend is to go to componetized models; the ARB has not had a touch base with FICAM to make sure that FICAM is going in that direction as well.  Anil confirmed that that direction is reasonable to pursue, though he does share the concerns about if you are going to be a FICAM-certified CSP it has to be an end-to-end service.  Having each part evaluated separately then combined in a smart way is acceptable.  It is up to the TFPs to offer service options to applicants to our applicants; all FICAM will look at are the end results (which gives us room to be innovative in how we offer assessments and approvals, as long as a full CSP is a full CSP)
    • since there is no consistend, agreed upon interface between components, that is a challenging area; FICAM will not offer an opinion or guidance on that; the TFPs have to determine how service components interoperate - Kantara has said the applicants have to figure out and tell us what they are doing so we can approve the approach, but other TFPs may require a specific way to interop
    • Did Anil define what they mean by "end result"?  Is it a process or an assertion?  When FICAM considers a CSP, they only consider the CSP as a full-assessed CSP containing all the service components it needs
  • FICAM will be offering a trust mark in the future down the road to help deal with confusion around "FICAM-certified"

 

NIST 800-162 - Attribute-based Access Control
  • doesn't see anything that would impact the IAF stack other that it is something that the government might say a certified CSP should be used for this kind of access control; this could have more impact on the work of the Attributes in Motion WG and how attributes are being used and relied upon;
  • Should ask FICAM how they see certifed CSPs being incorporated to this model?  Depending on market forces, thsi could drive FICAM to reconsider how they accept CSPs
  • On page 23 (Figure 10), there is a good graphic representation of what we're talking about and how it might link to the Agile IAF effort
  • Note that the provenance of an attribute doesn't matter until it hits the boundary of a trust framework model
  • there is going to be interesting discussions around this, and those discussions do seem to be converging

 

AOB

  • Andrew: who is going to IIW and IDESG next week?  Bill Braithwaite (IIW), Scott Shorter (IDESG)

Next Meeting