Presentation is loading. Please wait.

Presentation is loading. Please wait.

Enterprise Architecture 2014 EAAF as a vehicle for LoA Using EAAF processes to incrementally approach InCommon/UCTrust certification.

Similar presentations


Presentation on theme: "Enterprise Architecture 2014 EAAF as a vehicle for LoA Using EAAF processes to incrementally approach InCommon/UCTrust certification."— Presentation transcript:

1 Enterprise Architecture 2014 EAAF as a vehicle for LoA Using EAAF processes to incrementally approach InCommon/UCTrust certification

2 Enterprise Architecture 2014 Background Lots of ongoing discussion around LoA – InCommon Bronze/Silver compliance – UCTrust audits – Among UCTrust, ITLC, ITPS, ITAG, etc. Lack of clarity around “standards” for federation – AYSO – UCPath 2

3 Enterprise Architecture 2014 Silver/Bronze “Omnibus” Requirements Business, Policy and Operational Criteria Credential Issuance and Management.1 InCommon Participant.1 Credential Issuance.2 Notification to InCommon.2 Credential Revocation or Expiration.3 Continuing Compliance.3 Credential Renewal or Re-issuance.4 IdPO Risk Management.4 Credential Issuance Records Retention Registration and Identity Proofing.5 Resist Token Issuance Tampering Threat.1 RA authentication Authentication Process.2 Identity Verification Process.1 Resist Replay Attack.3 Registration Records.2 Resist Eavesdropper Attack.4 Identity Proofing.3 Secure Communication.4.1 Existing Relationship.4 Proof of Possession.4.2 In-person Proofing.5 Resist Session Hijacking Threat.4.3 Remote Proofing.6 Mitigate Risk of Credential Compromise.5 Address of Record Confirmation Identity Information Management.6 Protection of Personally Identifiable Information.1 Identity Record Qualification Credential Technology Assertion Content.1 Credential Unique Identifier.1 Identity Attributes.2 Basic Resistance to Guessing Authentication Secret.2 Identity Assertion Qualifier.3 Strong Resistance to Guessing Authentication Secret.3 Cryptographic Security.4 Stored Authentication Secrets Technical Environment.5 Basic Protection of Authentication Secrets.1 Software Maintenance.6 Strong Protection of Authentication Secrets.2 Network Security.3 Physical Security.4 Reliable Operations 3

4 Enterprise Architecture 2014 Issues Achieving LoA Certification Large number of requirements Possibly unclear to governance what “LoA” really is Difficulty committing to meet all requirements – Scope – Budget – Interpretation of Requirements Overall LoA value to UC not well defined 4

5 Enterprise Architecture 2014 Mapping InCommon to EA Standards Business, Policy and Operational Criteria Credential Issuance and Management.1 InCommon Participant.1 Credential Issuance.2 Notification to InCommon.2 Credential Revocation or Expiration.3 Continuing Compliance.3 Credential Renewal or Re-issuance.4 IdPO Risk Management.4 Credential Issuance Records Retention Registration and Identity Proofing.5 Resist Token Issuance Tampering Threat.1 RA authentication Authentication Process.2 Identity Verification Process.1 Resist Replay Attack.3 Registration Records.2 Resist Eavesdropper Attack.4 Identity Proofing.3 Secure Communication.4.1 Existing Relationship.4 Proof of Possession.4.2 In-person Proofing.5 Resist Session Hijacking Threat.4.3 Remote Proofing.6 Mitigate Risk of Credential Compromise.5 Address of Record Confirmation Identity Information Management.6 Protection of Personally Identifiable Information.1 Identity Record Qualification Credential Technology Assertion Content.1 Credential Unique Identifier.1 Identity Attributes.2 Basic Resistance to Guessing Authentication Secret.2 Identity Assertion Qualifier.3 Strong Resistance to Guessing Authentication Secret.3 Cryptographic Security.4 Stored Authentication Secrets Technical Environment.5 Basic Protection of Authentication Secrets.1 Software Maintenance.6 Strong Protection of Authentication Secrets.2 Network Security.3 Physical Security.4 Reliable Operations Standard 5

6 Enterprise Architecture 2014 Example Standard Password complexity and resistance to guessing – Two complexity levels Technical Requirements – Low: Min 25 bits entropy[1], max brute force chance 1:2 10 [2] – High: Min 30 bits entropy[1], max brute force chance 1:2 14 [2] » [1] “Password entropy” as measured per NIST , Appendix A » [2] Maximum chance to guess (randomly) over lifetime of password Implementation pattern #1: – 6/8 character, mixed type (up/low/num/sym), no dictionary words – 5 guesses allowed every 30 minutes (via lockout/rate limit controls) – Passwords forced to be changed annually Patterns with equivalent entropy and guessing resistance allowed – Exception/Alternate Requirement for PIN-based systems InCommon compliance vs UC utility – Standard text pulled (almost) directly from Bronze/Silver – Phrased to allow application outside InCommon settings 6

7 Enterprise Architecture 2014 Utility outside of UCPath Provides specific assurance to applications – AYSO (redux) – UCPath (redux) Guidance even outside of federated cases – Securing local DDODS databases – Evaluating password reset practices 7

8 Enterprise Architecture 2014 Using EAAF for InCommon Certification 8

9 Enterprise Architecture 2014 BACKUP SLIDES 9

10 Enterprise Architecture 2014 Current and Recent LoA Efforts UCTrust leadership met with Greg Loge (UC IT Auditor) – What is audited? (Bronze, Silver, UCTrust Basic, etc) – Who should audit? (UCOP, campus team, outside vendor) – Program for auditing UCTrust discussions of audit approaches and reqts – Ongoing discussions and estimates – UCSB audit against UCTrust Basic – UCSC and UCB looking to audit against InCommon Silver Discussions at UCTrust, UCPath, ISAAC, ITPS, ITLC ITLC proposed wkgrp to identify ILTI LoA reqts. This EAAF proposed process 10


Download ppt "Enterprise Architecture 2014 EAAF as a vehicle for LoA Using EAAF processes to incrementally approach InCommon/UCTrust certification."

Similar presentations


Ads by Google