1 / 18

Towards A User-Centric Identity-Usage Monitoring S ystem - ICIMP 2008 -

Towards A User-Centric Identity-Usage Monitoring S ystem - ICIMP 2008 -. Daisuke Mashima and Mustaque Ahamad College of Computing Georgia Institute of Technology Georgia, USA Partly Supported by I3P. Outline. Background and motivation

trory
Download Presentation

Towards A User-Centric Identity-Usage Monitoring S ystem - ICIMP 2008 -

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Towards A User-CentricIdentity-Usage Monitoring System- ICIMP 2008 - Daisuke Mashima and Mustaque Ahamad College of Computing Georgia Institute of Technology Georgia, USA Partly Supported by I3P

  2. Outline • Background and motivation • Limitations of existing approaches • Design goals for user-centric monitoring • Proof of concept in OpenID setting • Conclusion

  3. Background and Motivation • Increasing threat of online identity theft and misuse • Ranked in the first place for the 7th year in a row in FTC report • Prevention is not perfect • Insufficient attention to Site Authentication Image or SSL icon • Physical theft of a device and removable storage • Malwares • Social engineering • And more… • Monitoring and detection mechanisms are also required.

  4. Existing Schemes: Fraud Detection Systems • Aim to detect fraudulent activities • Misuse of stolen credit card information • Cellular cloning, theft of calling card or cellular phone

  5. Limitations of Existing Schemes • Limited or no user control • Users do not have option to enable or disable monitoring • Privacy concern • Users have no choice about what kind of information is captured and stored on SP • Lack of generality • System is designed in service-specific way • A dedicated system is required for each site

  6. Design Goals • Users must be able to trust the monitoring system • Users should be able to choose an entity that they can trust • Preferably resides on a networked trusted party • Identity usage must be reliably captured and made available to monitoring system • Users should have flexible control over the monitoring system • Legitimate users should be able to turn on/off the monitoring system • Users should have choice about what information is captured and used for monitoring purpose

  7. Design Goals Contd. • Monitoring system must offer generality without lowering effectiveness • By using context information, the monitoring system can handle identity credentials used for accessing general services • Engaging users closely in the anomaly detection process is important. • Make users attentive • Push alert or periodic reports • Provide interface to obtain feedback from user

  8. Overview of Proposed Architecture

  9. Context Information for Monitoring • Who? • What platform a user commonly uses to access online services • OS fingerprinting (nmap, p0f, etc.) • User-Agent in web setting • To whom? • Identifier of a service provider that a user is talking to • Where? • IP Geolocation (MaxMind, Delay-based schemes, etc.) • Whois record • When? • Timestamp of usage • Day of week, week of month, hour of day etc.

  10. Context-based Anomaly Detection • Time • Significant change in frequency of access • Anomalous access pattern • Location • Deviation of geographic location in normal usage pattern • Light-speed contradiction • Device Fingerprint • Unseen device type in the past

  11. Basic OpenID Architecture • Authentication credential for OpenID provider could be stolen by phishing • An adversary could imitate service provider site to retrieve identity credential from legitimate OpenID provider

  12. Proof of Concept in OpenID

  13. Evaluation: Generality • Can support any kind of services that rely on OpenID • No change is required at user side • Can be modified and applied to other types of systems

  14. Evaluation: Performance • Increase of response time is acceptable even when multi-user setting.

  15. Evaluation: Security • Context-based monitoring makes identity misuse more difficult • Risk of phishing attack can be mitigated • Periodic reports help shorten the window of vulnerability • Authentication to control monitoring system must be isolated from OpenID authentication

  16. Evaluation: Usability • Pushing usage summary periodically reduces users’ burden • Context information makes reports or alerts easy to understand

  17. Conclusion • Proposed requirements for user-centric monitoring and identified design goals • Showed a proof of concept in OpenID setting and evaluated it • Future work • Implementation in other types of architecture • Other identity management systems • GUIDE-ME • Email-based system • Explore more sophisticated mechanism for context-based anomalous usage detection

  18. Thank you very much.(mashima@cc.gatech.edu)

More Related