NSTIC IDESG Functional Requirements status report from FMO
•
1 like•1,068 views
Slides from the Atlanta (12th) IDESG plenary, on progress towards the IDESG Functional Requirements for supporting implementable NSTIC principles. From the IDESG Framework Management Office (OASIS).
Recommended
Recommended
More Related Content
What's hot
What's hot (9)
Similar to NSTIC IDESG Functional Requirements status report from FMO
Similar to NSTIC IDESG Functional Requirements status report from FMO (20)
More from James Bryce Clark
More from James Bryce Clark (8)
Recently uploaded
Recently uploaded (20)
NSTIC IDESG Functional Requirements status report from FMO
- 2. 2 Thursday: Functional Requirements • This program assumes you know why IDESG is focusing on Functional Requirements. See our brief into from Wednesday afternoon, and the IDEF plan: http://j.mp/IDEFsept2014 • Four Committees (Privacy, Security, Standards and UX) have shipped preliminary sets. http://j.mp/reqtssumm They match up moderately well to the Derived Requirements and NSTIC strategy document: http://j.mp/reqtsderive • Now what?
- 4. 4 You Are Here (not a complete picture, but illustrative) 6/30/2014 12/31/2014 6/30/2015 12/31/2015 6/30/2016 Strategy & IDEF Plan Committee Requirements Committee Requirements Committee Requirements P P P P P P … TFTM work TFTM 3rd party assessment planning UX 3rd party assessment planning Other (?) 3rd party assessment planning Standards adoption policy Std StdStdStd StdStdStd StdStdStd … Other Projects … P TFTM self‐assessment planning UX self‐assessment planning Other (?) self‐assessment planning Committee Requirements Committee Requirements Committee Requirements TFTM work Iterated Requirements Iterated Requirements Iterated Requirements StdStdStd Enabling projects Enabling projects Enabling projects … Enabling projects Enabling projects Enabling projects Preliminary set; self‐assessment Full set; 3rd party assessment
- 5. You Are Here Strategy & IDEF Plan Committee Requirements Committee Requirements Committee Requirements P P P P P P … TFTM work TFTM 3rd party assessment planning UX 3rd party assessment planning Other (?) 3rd party assessment planning Standards adoption policy Std StdStdStd StdStdStd StdStdStd … Other Projects … P TFTM self‐assessment planning UX self‐assessment planning Other (?) self‐assessment planning Committee Requirements Committee Requirements Committee Requirements TFTM work Iterated Requirements Iterated Requirements Iterated Requirements StdStdStd Enabling projects Enabling projects Enabling projects … Enabling projects Enabling projects Enabling projects Preliminary set; self‐assessment Full set; 3rd party assessment Staff help Staff help 6/30/2014 12/31/2014 6/30/2015 12/31/2015 6/30/2016
- 6. You Are Here 6/30/2014 12/31/2014 6/30/2015 12/31/2015 6/30/2016 Strategy & IDEF Plan Committee Requirements Committee Requirements Committee Requirements P P P P P P … TFTM work TFTM 3rd party assessment planning UX 3rd party assessment planning Other (?) 3rd party assessment planning Standards adoption policy Std StdStdStd StdStdStd StdStdStd … Other Projects … P TFTM self‐assessment planning UX self‐assessment planning Other (?) self‐assessment planning Committee Requirements Committee Requirements Committee Requirements TFTM work Iterated Requirements Iterated Requirements Iterated Requirements StdStdStd Enabling projects Enabling projects Enabling projects … Enabling projects Enabling projects Enabling projects Preliminary set; self‐assessment Full set; 3rd party assessment Staff help Staff help Staff help Staff help
- 7. You Are Here 6/30/2014 12/31/2014 6/30/2015 12/31/2015 6/30/2016 Strategy & IDEF Plan Committee Requirements Committee Requirements Committee Requirements P P P P P P … TFTM work TFTM 3rd party assessment planning UX 3rd party assessment planning Other (?) 3rd party assessment planning Standards adoption policy Std StdStdStd StdStdStd StdStdStd … Other Projects … P TFTM self‐assessment planning UX self‐assessment planning Other (?) self‐assessment planning Committee Requirements Committee Requirements Committee Requirements TFTM work Iterated Requirements Iterated Requirements Iterated Requirements StdStdStd Enabling projects Enabling projects Enabling projects … Enabling projects Enabling projects Enabling projects Preliminary set; self‐assessment Full set; 3rd party assessment Staff help Staff help Staff help Staff help Staff help
- 8. You Are Here 6/30/2014 12/31/2014 6/30/2015 12/31/2015 6/30/2016 Strategy & IDEF Plan Committee Requirements Committee Requirements Committee Requirements P P P P P P … TFTM work TFTM 3rd party assessment planning UX 3rd party assessment planning Other (?) 3rd party assessment planning Standards adoption policy Std StdStdStd StdStdStd StdStdStd … Other Projects … P TFTM self‐assessment planning UX self‐assessment planning Other (?) self‐assessment planning Committee Requirements Committee Requirements Committee Requirements TFTM work Iterated Requirements Iterated Requirements Iterated Requirements StdStdStd Enabling projects Enabling projects Enabling projects … Enabling projects Enabling projects Enabling projects Preliminary set; self‐assessment Full set; 3rd party assessment Staff help Staff help Staff help Staff help Staff help Staff help Staff help Staff help
- 9. You Are Here 6/30/2014 12/31/2014 6/30/2015 12/31/2015 6/30/2016 Strategy & IDEF Plan Committee Requirements Committee Requirements Committee Requirements P P P P P P … TFTM work TFTM 3rd party assessment planning UX 3rd party assessment planning Other (?) 3rd party assessment planning Standards adoption policy Std StdStdStd StdStdStd StdStdStd … Other Projects … P TFTM self‐assessment planning UX self‐assessment planning Other (?) self‐assessment planning Committee Requirements Committee Requirements Committee Requirements TFTM work Iterated Requirements Iterated Requirements Iterated Requirements StdStdStd Enabling projects Enabling projects Enabling projects … Enabling projects Enabling projects Enabling projects Preliminary set; self‐assessment Full set; 3rd party assessment Staff help Staff help Staff help Staff help Staff help Staff help Staff help Staff help Staff help Staff help Staff help
- 10. You Are Here 6/30/2014 12/31/2014 6/30/2015 12/31/2015 6/30/2016 Strategy & IDEF Plan Committee Requirements Committee Requirements Committee Requirements P P P P P P … TFTM work TFTM 3rd party assessment planning UX 3rd party assessment planning Other (?) 3rd party assessment planning Standards adoption policy Std StdStdStd StdStdStd StdStdStd … Other Projects … P TFTM self‐assessment planning UX self‐assessment planning Other (?) self‐assessment planning Committee Requirements Committee Requirements Committee Requirements TFTM work Iterated Requirements Iterated Requirements Iterated Requirements StdStdStd Enabling projects Enabling projects Enabling projects … Enabling projects Enabling projects Enabling projects Preliminary set; self‐assessment Full set; 3rd party assessment
- 11. 11 Functional Requirements: successive passes over time • By January 2015: first‐pass draft • By June 2015: first baseline set, and a self‐ assessment program • After June 2015: iterations and improvements of that set and that program • By June 2016: second full set, and a third‐ party assessment program • After June 2016: iterations and improvements of that set and that program
- 12. 12 Functional Requirements: various things IDESG could discuss • Talk About the Project of Doing Requirements (Where it Fits Into the IDEF) • Talk About the Content Quality of these Requirements (Prelim Feedback) • Talk About Next Steps for Developing the Requirements
- 13. 13 Functional Requirements: various things IDESG could discuss • Talk About the Project of Doing Requirements (Where it Fits Into the IDEF) • Talk About the Content Quality of these Requirements (Prelim Feedback) • Talk About Next Steps for Developing the Requirements
- 14. 14 Functional Requirements: the first pass • First we’ll review them: Do they cover the topic? Are they feasible? • Then, we’ll share some FMO observations about what’s in the early set and what’s not. • Then, we’ll share some early feedback from stakeholders. • Then, we’ll discuss how IDESG wants to proceed from here.
- 19. 19 Functional Requirements: the early set • Draft SECURITY Requirements • Draft STANDARDS Requirements • Draft PRIVACY Requirements • Draft USER EXPERIENCE Requirements http://j.mp/reqtssumm Thanks again to all four committees for “bringing it” These four committees aren’t the end of the search pattern
- 20. 20 Draft SECURITY Requirements 1. Service providers in the ecosystem follow recognized information security standards, frameworks, and/or appropriate practices. 2. Each account credential pair is uniquely identifiable for authentication purposes. 3. The confidentiality and integrity of identity data (e.g., attribute values) is protected during the execution of all identity functions and across the entirety of the data lifecycle (collection through destruction). 4. Credential and token issuance processes protect against unauthorized disclosure and/or reproduction. 5. Users are able to authenticate the source of all token and credential data received from service providers.
- 21. 21 Draft SECURITY Requirements 6. Credentials and associated tokens are granted to the appropriate and intended user(s) only. 7. There are clear processes, policies, and procedures in place for the execution of identity functions. 8. End users have access to the policies and procedures in place for the execution of identity functions. 9. The confidentiality and integrity of authentication data are protected. Data (such as passwords and passphrases) used for authentication are never stored in plaintext. 10. User control of the token is proven during the authentication process. 11. Users must be able to choose authentication mechanisms that are stronger than single factor passwords and passphrases and are commensurate with the level of risk associated with the transaction.
- 22. 22 Draft SECURITY Requirements 12. Service Providers have established policies, procedures, and processes in place to maintain availability of services. 13. Where cryptographic solutions are used, key management policies and practices are established and used consistent with industry standards and best practices. 14. Processes for the reissuance and/or recovery of credentials and authentication tokens are commensurate with the original process and procedures followed during registration and credentialing core operations, including identity assurance procedures. 15. Transactions and security events (to include the execution of identity functions) are logged in a manner that supports system audits and, where necessary, security investigations. Timestamp synchronization and granularity are appropriate to the level of risk associated with the environment, sector, or transaction.
- 23. 23 Draft STANDARDS Requirements 1. Entities shall be capable of accepting external users authenticated by 3rd parties. 2. Entities shall issue credentials and/or assertions that conform to IDESG adopted standards and are capable of being utilized by multiple 3rd parties. 3. Entities that perform Identity Ecosystem core operations and functions that support transactions requiring digital identity, authentication, and/or access control shall utilize technologies to communicate and exchange identity and/or attribute related data that conform to IDESG approved standards. 4. Entities shall employ documented, publicly available business policies and processes for identity management functions such as account recovery, identity proofing, identity vetting and liability that are employed in the transmission, receipt, and acceptance of data between systems.
- 24. 24 Draft STANDARDS Requirements 5. (BP1) Entities should utilize solutions and technologies that allow for identity account portability. a. Identity Providers and Attribute Providers SHOULD provide an easy to use method to allow individuals to switch to a new provider(s). b. Identity Providers and Attribute providers SHOULD provide individuals a mechanism to link their Relying Party accounts with their new provider(s). c. Relying Parties SHOULD provide individuals with a mechanism to associate multiple credentials to a single account. d. Relying Parties SHOULD provide individuals with a mechanism to have a single account per credential. e. Service Providers should utilize solutions and technology that allow for affordable identity account portability, when established open standards are available.
- 26. 26 Draft PRIVACY Requirements 1. Organizations shall limit the collection and transmission of information to the minimum necessary to fulfill the transaction’s purpose and related legal requirements. 2. Organizations shall limit the use of the individual’s data that is collected and transmitted to the specified purposes of the transaction. 3. Organizations shall limit the retention of data to the time necessary for providing and administering the services and transactions to the individual end‐user for which the data was collected, except as otherwise required by law. 4. Organizations shall provide concise, meaningful, timely, and easy‐to‐ understand mechanisms to communicate to end‐users how they collect, use, disseminate, and maintain personal information. 5. Organizations shall minimize data aggregation, including linkages across transactions. 6. Organizations shall provide appropriate mechanisms to enable individuals to access, correct, and delete personal information.
- 27. 27 Draft PRIVACY Requirements 7. Organizations shall determine the necessary quality of data used in identity assurance solutions based on the risk of that transaction, including to the individuals involved. 8. When terminating business operations or overall participation in the Identity Ecosystem, organizations shall, while maintaining the security of individuals' information, transfer it upon their request and destroy it unless they request otherwise. 9. Organizations shall be accountable for conformance to these requirements, and provide mechanisms for auditing, validation, and verification. 10. Organizations shall provide effective redress mechanisms for, and advocacy on behalf of, individuals who believe their rights under these requirements have been violated. 11. Where individuals make choices regarding the treatment of their information (such as to restrict particular uses), those choices shall be automatically applied to all parties downstream from the initial transaction. 12. Organizations shall, where feasible, utilize identity solutions that enable transactions that are anonymous, anonymous with validated attributes, pseudonymous, and/or uniquely identified.
- 28. 28 Draft PRIVACY Requirements 13. Organizations will request individuals’ credentials only when necessary for the transaction and then only as appropriate to the risk associated with the transaction or only as appropriate to the risks to the parties associated with the transaction. 14. Participation in the Identity Ecosystem shall be voluntary. 15. Privacy controls should be situated as low in the technology stack as possible. 16. Organizations shall clearly indicate to individuals what personal information is mandatory and what information is optional prior to the transaction. 17. Controls on the processing or use of individuals' information shall be commensurate with the degree of risk of the processing or use. 18. Identifiers shall be segregated from attributes whenever feasible.
- 30. 30 Draft USER EXPERIENCE Requirements 1. Information presented to users should be in plain language, which is clear and easy to understand. 2. All choices, pathways, and solutions should be available and clearly identifiable by the user. 3. The system shall make reasonable accommodations to be accessible to as many users as is feasible. 4. The system should have a way to collect user feedback on site usability, while conforming with the other high level requirements. 5. The system should provide opportunity for redress: an easy way for users to report errors, complaints, etc., while preserving user privacy.
- 32. You Are Here 6/30/2014 12/31/2014 6/30/2015 12/31/2015 6/30/2016 Strategy & IDEF Plan Committee Requirements Committee Requirements Committee Requirements P P P P P P … TFTM work TFTM 3rd party assessment planning UX 3rd party assessment planning Other (?) 3rd party assessment planning Standards adoption policy Std StdStdStd StdStdStd StdStdStd … Other Projects … P TFTM self‐assessment planning UX self‐assessment planning Other (?) self‐assessment planning Committee Requirements Committee Requirements Committee Requirements TFTM work Iterated Requirements Iterated Requirements Iterated Requirements StdStdStd Enabling projects Enabling projects Enabling projects … Enabling projects Enabling projects Enabling projects Preliminary set; self‐assessment Full set; 3rd party assessment
- 34. 34 Functional Requirements: feedback Early observations from FMO (This is not a substitute for TFTM’s or the Plenary’s later formal review) • Missing topics? • Quality of content • Harmonized meanings • Who’s being addressed?
- 35. 35 Functional Requirements: feedback Early observations from FMO Missing topics / coverage issues • Pseudonymity / anonymity? • Do we adequately address identity theft via stolen PII? • “Use our standards from the standards registry” … which is empty • How do these apply to vertical industries?
- 36. 36 Functional Requirements: feedback Early observations from FMO Quality of content • MUST, SHOULD and MAY, etc. • Length and compound statements • Testable statements
- 37. 37 Functional Requirements: feedback Early observations from FMO Quality of content • Length and compound statements Privacy # 19: Organizations shall, upon any material changes to a service that affect the prior or ongoing collection, use, dissemination, or maintenance of users’ personal information: a) provide clear and conspicuous descriptions of the changes and their impacts on users in advance, and b) with respect to previously collected personal information, provide users with compensating controls designed to mitigate privacy risks that may arise from the material changes, which may include seeking express affirmative consent of users in accordance with relevant law or regulation. In the event that users elect to terminate the service, organizations shall meet other stated requirements on termination and retention.
- 39. 39 Functional Requirements: feedback Early observations from FMO Quality of content • Length and compound statements Privacy # 19: Organizations shall, upon any material changes to a service that affect the prior or ongoing collection, use, dissemination, or maintenance of users’ personal information: a) provide clear and conspicuous descriptions of the changes and their impacts on users in advance, and b) with respect to previously collected personal information, provide users with compensating controls designed to mitigate privacy risks that may arise from the material changes, which may include seeking express affirmative consent of users in accordance with relevant law or regulation. In the event that users elect to terminate the service, organizations shall meet other stated requirements on termination and retention.
- 40. 40 Functional Requirements: feedback Early observations from FMO Harmonized meanings • Who is the “user” or “end user”? • What is the “Identity Ecosystem”? Privacy # 8: When terminating business operations or overall participation in the Identity Ecosystem, organizations shall, while maintaining the security of individuals' information, transfer it upon their request and destroy it unless they request otherwise. • Glossary may be useful here
- 42. 42 Functional Requirements: feedback Security Committee early review • Security Committee asked the FMO to seek stakeholder feedback on the draft requirements. • A broad review, like formal surveys or focus groups, is possible, but • Couldn’t be launched in late December • Might be a good thing to do more broadly (output from more than one committee) • Security Committee wished to discuss it further • So we sought approval for a shorter informal set of feedback exercises • We’ll return on Friday to larger scale possibilities
- 43. 43 Functional Requirements: feedback Security Committee early review • Roundtable with the NSTIC pilot project participants: informal discussion • Limited interviews with IdMs, RPs and other stakeholders across a range of entity sizes • Nonattribution ground rules: what do you really think? (“Chatham house rules”) • Structured questions: http://j.mp/SecReqQs https://www.idecosystem.org/filedepot_download/1809/1641
- 44. 44 Functional Requirements: feedback Security Committee early review • Some are outcomes, not processes Security # 6: Credentials and associated tokens are granted to the appropriate and intended user(s) only. • How does this map to the requirements I already face? (HIPAA, FFEIC, FIPP, CSA, etc.) • Are these immediate, entry‐level requirements or aspirational plans? • What’s the source, and how do I get there? Security # 5: Users are able to authenticate the source of all token and credential data received from service providers.
- 45. 45 Functional Requirements: feedback Security Committee early review • Many of the draft requirements appeared to reviewers to be current best practices, or within conventional reach, but they see others as either too vague or too ambitious • Would help focus customer expectations in unregulated industries • “Some kind of tool set, in the form of benchmarks or a test harness or similar, would be very helpful to make this real for those considering it” • Applying these criteria is a resource decision
- 46. 46 Functional Requirements: feedback Security Committee early review • There may be multiple methods for fulfilling a requirement • “You need some ‘big names’ to take the pledge.” • What a prospective adopter will ask: • Is it measurable? • Is it feasible? • What’s the remediation? • What’s the governance?
- 47. You Are Here 6/30/2014 12/31/2014 6/30/2015 12/31/2015 6/30/2016 Strategy & IDEF Plan Committee Requirements Committee Requirements Committee Requirements P P P P P P … TFTM work TFTM 3rd party assessment planning UX 3rd party assessment planning Other (?) 3rd party assessment planning Standards adoption policy Std StdStdStd StdStdStd StdStdStd … Other Projects … P TFTM self‐assessment planning UX self‐assessment planning Other (?) self‐assessment planning Committee Requirements Committee Requirements Committee Requirements TFTM work Iterated Requirements Iterated Requirements Iterated Requirements StdStdStd Enabling projects Enabling projects Enabling projects … Enabling projects Enabling projects Enabling projects Preliminary set; self‐assessment Full set; 3rd party assessment
- 49. 49 Functional Requirements: various things IDESG could discuss • Talk About the Project of Doing Requirements (Where it Fits Into the IDEF) • Talk About the Content Quality of these Requirements (Prelim Feedback) • Talk About Next Steps for Developing the Requirements
- 50. 50 Functional Requirements: various things IDESG could discuss • Talk About the Project of Doing Requirements (Where it Fits Into the IDEF) • Talk About the Content Quality of these Requirements (Prelim Feedback) • Talk About Next Steps for Developing the Requirements