Difference between revisions of "GPII Security Plan"

From wiki.gpii
Jump to: navigation, search
(Tasks)
m (User accounts section)
Line 329: Line 329:
 
|  
 
|  
 
| https://github.com/strongloop/loopback-example-access-control
 
| https://github.com/strongloop/loopback-example-access-control
Additional see, https://docs.strongloop.com/display/public/LB/Controlling+data+access. Loopback appears to be the only framework with a robust acl functionality  
+
Additional see, https://docs.strongloop.com/display/public/LB/Controlling+data+access. Loopback is one framework offering robust acl functionality  
 
|-
 
|-
 
| User roles
 
| User roles

Revision as of 18:10, 5 April 2016

Security framework

Background

For discussion of anonymous access and managing multiple GPII tokens per user, see:

Identified Privacy Levels:

  • 0: Using ready-made, immutable, preference sets
  • 1: Anonymous, customizable preference sets
  • 2: Basic user account information, ability to change preferences, provision tokens, reset passwords
  • 3: GPII integrated with "institutional" and OS-level accounts and login
  • 4: Private or security-sensitive preferences such as JAWS macros, (probably not APCP)
  • 5: General-purpose settings synchronization (for any application setting or other highly personal data--documents, etc.)

Authentication processes GPII currently has:

  • Key-in/login -- requires a token and no further authentication
  • Retrieval of preferences by local flow manager from cloud based flow manager -- requires only token and no further authentication, though preferences are filtered according to the privacy policy associated with the token
  • Editing of privacy policy (/privacy-settings) -- requires username and password
  • Retrieval of preferences over OAuth 2 (UIO case) -- requires username and password
  • Add new preference set (First Discovery Tool) -- requires authentication of the client itself (First Discovery Tool)
  • Currently editing of preferences (PMT) does not require any authentication (this needs to change)

Tasks

Task People Status Notes
Create APCP risk assessment framework Adewale In Progress Shared a Cyber Security Risk Frame work (CSF) spreadsheet for HIPAA with team during the Security call on 03/15/16. Intent is to continue to build on the framework and leverage as guidance for informing our privacy control areas relative with GPII controls\functionalities in play.
Catalog American Job Center Assistive Technologies Sandra In progress 18-Mar-2016: Have completed NVDA and ZoomText. Taking a break to catch up with other tasks. Location: https://drive.google.com/drive/folders/0Bzk83ip2K5sqOW1rVDJNVGxEZ3M
Catalog user preferences applicable for APCP project (5 years) Alejandro
Capture payloads within GPII Cindy https://github.com/cindyli/gpii-payloads/tree/GPII-1646
Identify and document applicable legal regulations (such as HIPPA)
Improved security-related logging
Identity Management Adewale In Progress The IBM GPII team is investigating StrongLoop as a solution to address user and identity management functionality and access controls tasks for the GPII. Additionally, we are looking into a potential interoperability concern with the Loopback framework for the GPII and how easily it integrates Strongloop with the GPII kettle infusion framework. As such, Gabriel is working on a simple proof of concept with a GPII server component authenticating using StrongLoop on Bluemix. He'll follow up with the level of effort and estimated time to have this done during our architecture call on Tuesday.
Identify/define user roles "Role Based Access Controls" (RBAC); Users, Administrators, Systems

Keying in and Authentication

Task People Status Notes
Identify actions in GPII that make changes to a users computer or data Such as keying into a system or retrieving preferences.
Determine for each action identified above, what level of authentication (if any) is appropriate For example, actions involving preference sets would require checking that access to, modification of, or deletion of that preference set is allowed. Or, is a token sufficient to retrieve a user's preferences and apply changes to their computer system. We might enable access to some information if you have keyed in but for others we could require a stronger authentication.
Define access policies for retrieval and modification of user preferences from the machine running GPII In the current hybrid Flow Manager implementation, knowledge of the GPII token is enough to retrieve the user preferences without further authentication (though preferences are filtered in the cloud according to the user's privacy settings). In the past we had considered using OAuth 2 Resource Owner Password Credentials and requiring the local Flow Manager to provide user username and password to get an access token before retrieving preferences.
Design "Anonymous" usage Usage of the system without identifying who users are. For example, by using bearer tokens (tokens with the preferences encoded directly in them).
Implement a robust identity system Which can be integrated with institutional identity systems via LDAP, etc.

Authorization server

Task People Status Notes
Review the authorization code and access token generation strategy Make sure that the generation strategy results in unguessable tokens.
Authorization codes should be single use and have a limited lifetime
Review the login session cookie lifetime For the Privacy Settings page
Review the access token lifetime Currently access tokens lifetimes are infinite. We should limit their lifetime.
Separate lifetimes for access tokens and "authorization decisions" In the current data model, the access token is stored as part of the "authorization decision" and the only way that an access token would not be valid would be if the authorization was revoked. I think that we will want to give these different lifetimes so that an access token might expire while the authorization is still good (and could be used again with a refresh token or by asking for another access token).
Support refresh tokens?
Devise a plan for multiple solutions with overlapping capabilities A user may be using a device with solutions available with overlapping capabilities, such as NVDA and Jaws. The match maker will pick one of them (I think). However, the user may have chosen to share their preferences with only one of them. If the match maker picks the one they have not shared with, then their preferences will not be enacted. Maybe filter solutions seen by the match maker to those that the user has shared with. Or some closer integration between privacy settings and match making.
Review the endpoints exposed by the AuthServer and remove any not needed Such as /access_token_for_gpii_token added for GPII-1066

Cloud Based Flow Manager

Task People Status Notes
Move Auth Manager responsibilites out of Cloud Based Flow Manager Refactor the Cloud Based Flow Manager to separate out Auth Manager responsibilities. Right now the filtering happens in the Cloud Based Flow Manager, with direct access to the oauth datastore.

Local Flow Manager (Hybrid)

Task People Status Notes
GPII-1265 Support multiple simultaneous users when doing preference filtering [REVIEW 4]
Provide robust means for verifying the identity of a locally-installed Flow Manager Provision a Flow Manager secret at installation (instance-specific). Register the Flow Manager instance with the Authorization server. Administrator UI for revoking of Flow Manager instances. Provide the Flow Manager secret when preferences are requested. Check the Flow Manager secret on the services it uses.
Provide the end-user with an interface to authorize and deauthorize Flow Manager instances We will need to do work initially to design the user experience for managing access (for example what happens when a user uses a machine that they have not authorized for the first time -- this could be token specific, for example Token A [public usage token] is authorized for use on any Flow Manager, but Token B [more sensitive token] can only be used on authorized Flow Managers)

OAuth 2 Clients / Solutions Registry

Task People Status Notes
Secure workflow for adding and editing solutions As solution entries include instructions for running processes on end-user’s computers
Solution management UI Work will include UIs for: Account system for solution owners, Solution registration, Revoke solution OAuth 2 client secret, Generate a new OAuth 2 client secret
Integrate with the solution registry

Retrieve OAuth 2 client data: Solution id (client_id), name, client_secret, redirect_uri. We could compute the available preferences from the capabilities and capabilitiesTransformations. Consider whether this work requires improvements to the solutions registry format - harmonise this with last year's (August?) discussion about improving solutions registry entries re. new device reporter implementation and handling of lifecycle. Deal with alarming redundancy caused by our confusion about whether, e.g. MobileAccessibility is deployed on device (OS) "web" or device "android".

Data storage

Task People Status Notes
GPII-1274 Implement CouchDB storage The work was started but has been put on hold
Secure password storage
Authorization codes should be single use and have a limited lifetime
Use a central GPII account system for managing user accounts See https://issues.gpii.net/browse/GPII-1280 and https://github.com/the-t-in-rtf/gpii-express-user/blob/master/src/docs/api.md
Implement read only preference sets To support immutable pre-configured preferences

Preferences editing

Task People Status Notes
Secured editing of user preferences Including OAuth 2 based access (such as for UIO) and access from applications running on a user's device (such as the PMT/PCP)
Update any clients of existing non-secured APIs to use new secured APIs

Privacy settings

Task People Status Notes
GPII-1058 Implement OAuth2 /available-authorized-preferences
GPII-412 The system should have the ability to define rules for filtering an NP set based on application accessing it Antranig Can close now?
GPII-1240 Add a default privacy policy to be used for solutions that a user has not explicitly authorized [REVIEW 4]
Protect Privacy Settings endpoints with a Cross-Site Request Forgery (CSRF) prevention mechanism See https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet
Ajaxify the Privacy Settings page The list of services is currently built as HTML on the server and we want to switch this to a json list retrieved using ajax. Produce client-based tests which will then become easier to write (since server can be mocked more easily)

User accounts

Task People Status Notes
Register new users Adewale https://github.com/strongloop/loopback-example-access-control

Additional see, https://docs.strongloop.com/display/public/LB/Controlling+data+access. Loopback is one framework offering robust acl functionality

User roles
Provision users
Associate GPII token with account
Revoke tokens
Password reset
Support multiple preference sets and tokens per user At the moment we have one gpii token per user. We have discussed to extend it so that a single user could have multiple tokens in order to support tokens with different preference sets that could be used in different circumstances/devices/applications to retain privacy and/or anonymity. For example, one token with less sensitive info that could be used in fairly public situations and another with more sensitive preferences which might only be used in cases where the user has a higher degree of trust in the device they are interacting with. Also, if a user left USB stick connected to the computer, the token associated with the USB can be revoked. Work will include design, UI implementation, and data model updates.
Token roles
Provision tokens

Local machine security

Task People Status Notes
Secure communication between components on the local machine (such as user listener to flow manager) We need to make sure that we are talking to who we think we are -- for example, if a system is running a malicious service (say run by another user), we shouldn’t talk to it -- we should only talk to services that we can verify and trust (same machine, run by current user). Only process requests that we can trust -- for example we don’t want untrusted users or processes logging users out of GPII.
Run GPII processes with the minimum privileges that they can Any end-user machine GPII processes should be run with the minimum privileges that they can (to minimize damage should the code be exploited). We could make use of Operating System provided mechanisms for process restrictions such SELinux or AppArmor. Some GPII actions will require elevated privileges and we will need a solution for handling those actions. Examples: system configuration changes that require elevated privileges or installing software. An example to look at on Windows would be to see how Mozilla separates and coordinates the Firefox browser (user process) from the Firefox updater (elevated privileges).
Ensure that the code has not been modified (hacked) after installation
Protection against settings corruption/injection attacks Though one could argue that this is outside the scope of the GPII: that if a solution's settings are files on the filesystem, then any program running with suitable privileges could modify those settings (not just the GPII) and that the solutions should be responsible for validating their own settings. The important thing here, I think, is that the GPII is a vector, or conduit, by which settings arrive on the user’s machine. This would be particularly sensitive if a solution includes generic scripting ability -- then GPII could deliver arbitrary scripts to an end-user’s computer. https://issues.gpii.net/browse/GPII-1049
Assess risks of information gathered by the Device Reporter and sent to the Cloud Based Flow Manager

Integration

Task People Status Notes
Provide preferences retrieval and editing inside UIO
Integrate the GPII with operating system login I think we have discussed both using the GPII as a login mechanism to log users into operating systems and about having GPII personalization present at the operating system login screen.

Deployment

Task People Status Notes
Where does HTTPS terminate?
Encrypt storage?
Denial of service mitigation/planning
Create staging and other environments DevOps, Staging, Production
Patch management for software being used Such as Node.js, CouchDB
Vulnerability scans

Bugs

Task People Status Notes
GPII-1300 Selecting to share all applicable solution settings in fact shares all settings in Hybrid Flow Manager (not just everything applicable to the solution)
GPII-1072 Using the browser back button after logging out from the privacy page takes you back to the privacy page
GPII-1076 the access_commonprefs_editingkeyboardecho transformation for mobile accessibility returns a value for undefined input
GPII-1078 Security panels can disappear offscreen

GPII Issues to be reviewed

Are these issues still relevant or can they be closed? If they are still relevant, how should they be updated to fit with the current architecture?

And we have a number of issues filed for Trusted Flow Manager secrets: