ZXIDP Risk Assessment from User Perspective

ZXIDP.org

This risk assessment aims at giving the reader a realistic idea of the types of security and privacy threats involved in using this website. This assessment is not exhaustive, but rather our good faith effort to disclose what we think are the most likely and relevant risks.

  1. Entry points

    1. Shell or root shell (or ssh) administrative login

    2. TAS3 designed management interfaces (none yet)

    3. Product specific management interfaces

      • New user registration (feature to allow anonymous new user to self register)

      • Auto-CoT (fully automatic metadata exchange and trust establishment with anonymous third party SPs)

      • New service registration (feature to allow anonymous 3rd party to register new services)

    4. Web GUI

    5. SOAP web service

      • SSO

      • SLO

      • Discovery query

  2. Data assets

    1. Private keys of the service itself

    2. Circle-of-Trust database

    3. Discovery Registrations

    4. User database

      • User names

      • Authentication credentials (password hash, Yubikey shared secret)

      • User's attribute data

    5. Federation database: name id mappings

    6. Session store

  3. Nonfunctional assets

    1. Privacy preserving through avoidance of correlation handles

    2. User consent and control of data release

    3. Organizational control of data release

    4. Nonrepudiation

    5. Accountability

    6. Credible authentication of users

    7. Credible authentication of system entities

  4. Attacks and mitigation

    1. Too numerous to describe exhaustively in one afternoon *** TBD

    2. Generally the data assets are protected using Unix filesystem permissions against shell and local Unix process access. This, of course, is of little value against root. Therefore deployment MUST use nonroot users for running all TAS3 related processes as well as for most administrative tasks.

    3. The TAS3 designed and product specific management interfaces follow good coding practises (e.g. check for ".." in path) to only allow designed access to the data assets.

    4. Web GUI is coded such that only authorized accesses are possible

    5. SOAP web service is coded such that only authorized accesses are possible

    6. Appropriate crypto layer (such as TLS) is applied in Web GUI, SOAP, and ssh entry points

--Sampo