CIS14: How I Came to Share Signals and Learned to Love my Identity System

728 views

Published on

Andrew Nash, Confyrm

A look at how operational notifications can be aggregated, processed and shared in ways that increase the resiliency and trust of your identity ecosystem.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
728
On SlideShare
0
From Embeds
0
Number of Embeds
30
Actions
Shares
0
Downloads
14
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

CIS14: How I Came to Share Signals and Learned to Love my Identity System

  1. 1. How I Came to Share Signals & Learned to Love my Identity System Andrew Nash, Confyrm Inc. andrew@confyrm.com @winemaker
  2. 2. Identity Ecosystem … Confyrm, Inc Attribute Exchange Attribute Providers Identity Providers Relying PartiesUser Authorization Manager Validation Service Verification Service Trust Eval Service Authentication Service Personal Date Store
  3. 3. When the Ecosystem happy path fails … Operational events occur that are not accounted for by identity protocols In aggregate, we all know more … … than any one single entity or view point Could we … share operational events that enhance the integrity of the ecosystem and protect the user while providing privacy controls…? Confyrm, Inc
  4. 4. Google knew before AOL 7/2/13 Commercial in confidence – do not redistribute
  5. 5. The Account Reset Pattern Confyrm, Inc
  6. 6. Trusted Communications Channels —  Only communications paths are: —  Email —  SMS —  Assumed level of Trust —  “real security” for high value accounts devolves to controls on trusted channels —  Every IAM mechanism leverages them: —  Username / Password —  Multi-factor Authentication —  Biometrics —  SSO Technologies Confyrm, Inc
  7. 7. New nomenclature … Confyrm, Inc IDP A Email Svc RP x IDP B RP x RP z IDP A Email Svc Event Parsing Service Signal Multicast Service SIgnal Manager Signal Recipients Event Publishers
  8. 8. Signal Manager —  Trusted intermediary —  Shields Account Identifiers & Event Publishers —  Real world identities out of scope —  Identification is limited to Account Identifiers —  Not usernames —  PII is not stored or shared —  Policy based event distribution/transformation —  Events are artifacts of operational identity ecosystem
  9. 9. Confyrm Sygnal Manager Confyrm, Inc fp { e } = s events signals policy
  10. 10. Event Notifications - ATO Confyrm, Inc an@gmail.com an@gmail.com an@aol.com an@BofA.com an@gmail.com an@aol.com BofA AOL Google an@gmail.com an@ BofA.com an@ aol.com f p { e } = s Sygnal Manager
  11. 11. Event Notifications – Password Change Password := new_password an@gmail.com an@gmail.com an@eBay.com eBay Google an@gmail.com an@ ebay.com f p { e } = s Sygnal Manager Confyrm, Inc
  12. 12. Account Query Confyrm, Inc an@gmail.com an@gmail.com an@eBay.com an@aol.com an@Yahoo.com eBay Yahoo! Google an@gmail.com an@ gm ail.com an@ aol.com f p { e } = s Sygnal Manager an@aol.com AOL an@aol.com
  13. 13. Recent Events —  OIX UK Govt Shared Signals Whitepaper, Sept ’13 —  Google Shared Signals Presentation —  October Internet Identity Workshop —  UK IDAP Shared Signals Discovery Project —  Event & Signal Catalogues —  Architecture, Service API and IDP Integration —  Privacy & Legal Frameworks —  Alpha project late Summer —  NSTIC Shared Signals Project —  Selected as finalist from 42 submissions —  Final set selected in Sept Confyrm, Inc
  14. 14. PROTECTING THE IDENTITY ECOSYSTEM Identity Ecosystem Collaborate to Protect Maintain Integrity
  15. 15. Shared Signals in IDAP Context Confyrm, Inc Verizon MyDex DigIdentity Post Office Experian IDPs IDAP Hub f p { e } = s Sygnal Manager Verizon MyDex DigIdentity Post Office Experian UK Email Providers
  16. 16. To Anticipate Some Questions … •  Events are Account level activities •  Events & Signals are very simple structures : •  AccountID, EventType •  AccountID, SignalType [, PublisherClass] [, Priority] •  Event Publisher & Signal Recipient AccountID are different •  Signal Recipient AccountID is already known •  Does not use transactional information, authentication activities, session activity or application activation Confyrm, Inc
  17. 17. Confyrm, Inc
  18. 18. Signal Processing —  Loosely coupled Input and Output event streams —  Asynchronous event notification eliminates polling overheads —  Policy controlled signal handling —  Event transformation —  Signal urgency —  Delivery thresholds —  Signal content —  Obfuscation techniques —  “All Clear” reset notifications —  Signal Types: —  Password reset —  Account recycling —  Account takeover —  Account suspension —  Configurable signal classes —  Optional User Notification (policy based) 7/2/13 Commercial in confidence – do not redistribute
  19. 19. Use Cases —  Account Takeover —  Password Change —  Account Reuse —  Recent account creation —  Mobile device purchase —  Stolen identity – cross IDPs Confyrm, Inc
  20. 20. ATOs are a fact of normal life Confyrm, Inc
  21. 21. Risky Account Changes and Account Quality Adam Dawes (adawes@google.com) IIW October 2013 http://goo.gl/MpTVyG
  22. 22. IDP’s core value is to protect account securityAlready provide sophisticated systems for authentication •  Risk analysis •  Login challenges •  Multifactor authentication
  23. 23. What are the security risks for being a Relying Party?Account with IDP has been compromised o  Credential theft §  Password reuse §  Phishing §  Malware §  Unauthorized machine access §  Account recovery Account is abusive o  Spammy o  Hijacked
  24. 24. Big Account Changes are a risk for RPs Password change at IDP 1.  User gets hijacked but doesn’t know it 2.  Hijacker logs into site/app via federated login (and sets up a mobile app) 3.  Hijacker starts abusing user’s account on RP 4.  User discovers they have been hijacked; changes password on IDP 5.  Hijacker still has valid session on RP and continues to abuse account Security best practice: on password change, RP should revoke: •  All cookies for active web sessions
  25. 25. Big Account Changes Challenges There are other IDP events that an RP should know about •  Suspected hijacking [prompt for password change next login] •  Account recovered •  Account deleted •  Account suspended •  Account recycled •  OAuth revocation of App •  Expired token
  26. 26. •  Google is RP for many Google Apps customers via SAML o  Enterprises frequently require their users to change password (and sometimes detect an employee’s account was hijacked) o  Enterprise/School accounts are not usually “accounts for life” and eventually get terminated •  Google is “RP” to other mail providers for accounts o  Account recycling - Hotmail, Yahoo! etc. •  Are there already patterns we can follow? o  When do we revoke OAuth access to Gmail mobile app when an account is deleted? o  Are there mechanisms for this already specified in SAML? §  SCIM can signal an employee has left the company, is that a start? Google would like to be subscriber of changes too
  27. 27. OIDC Session Management is not enough If the RP keeps login state synced with IDP, that should work right? •  Not all RPs or IDPs want to have their session state synced •  Mobile apps use OAuth, don’t see session state changes. Which session would you want to tie it to anyway? •  Hijacker can sign up for subscriptions (or other background activities) on RP that do not track session state
  28. 28. Google to provide pub/sub feed for account changesPublish “risky events” to RP endpoint when Google detects them •  Site registers notification URL •  Site receives notifications for users where it has an active OAuth grant

×