GPII Security Plan

From wiki.gpii
Jump to: navigation, search

Security framework

Background

For discussion of anonymous access and managing multiple GPII keys 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, create GPII keys, 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 (Retrieval of user settings by local flow manager from cloud based flow manager) -- requires a GPII key and a client credential. Preferences are converted to lifecycle instructions.
  • PPT requires login and password

Tasks

Task People Status Notes
Create APCP risk assessment framework TBD In Progress (Pending) High priority.

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 Maureen Done Onboarding Status
Catalog user preferences applicable for APCP project (5 years) In progress Onboarding Status

Necessary to classify the privacy level of the data stored for each user preference. The sensitivity of the data determines what regulations or laws GPII should comply with.

Capture payloads within GPII Cindy Pull request Medium priority.

https://github.com/GPII/gpii-architecture-docs/pull/1

Identify and document applicable legal regulations (such as HIPPA) High priority.
Improved security-related logging In Progress High priority.

Audit logging requirements by Adewale Recent audit logging discussion at Washinton DC 2016-12, at line 302-307

Identity Management TBD In Progress (Pending) Needs more discussion on requirements.
Identify/define user roles Needs more discussion on requirements. Part of the identity management system.

"Role Based Access Controls" (RBAC); Users, Administrators, Systems

Authenticate GPII apps before they can request user settings from GPII Cloud Cindy Partly Done High priority.

Part 1:
Working on The umbrella JIRA FPII-2434 that contains 6 subtasks. 4 of them are ongoing for supporting PCP with memory. They are:
1. Auth server: add the support of resource owner password credentials grant: A pull request is under review
2. Secure the existing /untrusted-settings endpoint: In progress
3. Create a new endpoint for updating preferences: Not started
4. Update the local flow manager to use OAuth2 resource owner GPII token grant for retrieving and updating user settings: Not started

Above has been done.

2 subtasks related to the creation of GPII access requester, which is dependent on Steve Grundell's gpii-service work are on hold.: 1. Create GPII access requester module: On hold
2. Integrate task 1, 2 and the local flow manager to complete the workflow: haven't started

Part 2:
Dependent on wireframes from the UX team on how to request and manage client credentials. The UX team likes option 3 on this wiki page

Secure communications between GPII process and Windows service Steve Grundell In progress High priority.

See JIRA comments for the work progress.
Proof of concept: https://github.com/stegru/service-poc

Keying in and Authentication

Task People Status Notes
Identify actions in GPII that make changes to a users computer or data Needs more discussion.

Such as keying into a system, retrieving preferences or editing preferences.

Determine for each action identified above, from users' perspective, what level of authentication (if any) is appropriate Needs more discussion.

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. Or, is a token sufficient to edit a user's preferences?

Define access policies for retrieval and modification of user preferences from the machine running GPII Covered by GPII-2237?

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 Needs more discussion about what the "Anonoymous" usage is.

"Anonymous" usage is the usage of the system without identifying who users are. Two possible use cases so far: 1. Snapsets, or GPII keys that are not associated with any user, such as GPII keys for public experiments. 2. Bearer keys: GPII keys with the preferences encoded directly in them.

Research on approaches to protect the communication between local GPII and GPII cloud Cindy In progress See JIRA comments for the work progress
Implement a robust identity system Needs more discussion about requirements.

Which can be integrated with institutional identity systems via LDAP, etc. 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

Authorization server

Task People Status Notes
Input validation High priority.

Escape things that may cause SQL injection etc

In particular, we should validate the format of GPII keys at endpoints that have them as inputs (e.g., "exactly 22 characters, lowercase alpha + numbers, no punctuation"). We could use a regex or write a validation function.

Apply other general web application best practices Needs more discussion.
Review the access token lifetime High priority.

Currently access token lifetimes is 1 hour.

Add timestamps to track the creation and last update of records High priority.

Done

Devise a plan for multiple solutions with overlapping capabilities Needs more discussion.

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, for example, to allow the match maker to look into the auth database to find the solution that the user has authorized to share so that the match maker can pick the correct solution.

Review the endpoints exposed by the GPII Cloud and remove any not needed Medium priority.

https://issues.gpii.net/browse/GPII-1990

Cloud Based Flow Manager

Task People Status Notes
Move Auth Manager responsibilitis out of Cloud Based Flow Manager Low priority and needs more discussion.

The original idea was to refactor the Cloud Based Flow Manager to separate out Auth Manager responsibilities since the filtering happens in the Cloud Based Flow Manager, with direct access to the oauth datastore.

The recent discussion is considering to reduce http connections among GPII modules, instead, include some modules as sub-components of the flow manager. If this approach also applies to the auth manager, this security item would be no longer valid.

Local Flow Manager (Hybrid)

Task People Status Notes
GPII-1265 Support multiple simultaneous users when doing preference filtering [REVIEW 4] Low priority and needs more discussion.
Provide robust means for verifying the identity of a locally-installed Flow Manager; Provide the end-user with an interface to authorize and deauthorize Flow Manager instances High priority.

Covered by GPII-2237. Provision a Flow Manager secret at installation (instance-specific). Register the Flow Manager instance with the Authorization server. End user and 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.

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, if malicious scripting or instructions are added into the solution registry, they may cause damage to end-user's computers. To secure the workflow to add/edit solutions: 1. ensure approved users and processess/apps to add/edit; 2. prevent the input of malicious instructions.
GPII-1058 Implement the new OAuth2 /available-authorized-preferences to integrate with the solution registry

Right now, the privacy settings UI reads available user-authorized preferences for each solution from json files on the file system at https://github.com/GPII/universal/tree/master/gpii/node_modules/gpii-oauth2/gpii-oauth2-authz-server/public/src/core/available-authorized-preferences. This approach should be replaced by directly retrieving from solution registries.

We could compute the available preferences from the capabilities and capabilitiesTransformations of solution registry. Consider whether this work requires improvements to the solutions registry format - harmonise this with last year's (August 2015?) 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
Secure password storage High priority
Implement read only preference sets To support immutable pre-configured preference sets. Consider to use an indicator to the preference set to ensure nobody can change it, especially for read only GPII keys used by the public, as the malicious modification on these GPII keys can cause damage to many end-users.

Preferences editing

Task People Status Notes
Secured editing of user preferences Including:

1. PPT: a GPII hosted website that allows users to manage all preferences sets in a cloud safe. PPT will directly access preferences via Preferences Server APIs. Preferences Server will be hosted by GPII and run behind firewall. Its APIs will only be exposed internally to other GPII cloud services such as PPT and cloud based flow manager. 2. access from GPII running on a user's device (such as the PSP): The recent discussion shows the communication btw PMT/PCP and the local GPII flow manager will be via electron IPC that is internally secured within one electron app. 3. Tranport the preferences data between the local GPII and GPII cloud: Covered by GPII-2237 See GPII Authorization Workflows

Update any clients of existing non-secured APIs to use new secured APIs Ensure all GPII applications, such as local GPII installation, PSP, Quick Strip Set, are using secured APIs. For example, not sending requests to old end points, or, not directly posting to the preferences server.

User accounts

Part of the user management system. Needs more discussion on requirements.

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
Create users
Associate GPII token with login id/pwd
Revoke GPII keys
Password reset
A GPII key can be associated with any preferences set in a cloud safe https://issues.gpii.net/browse/GPII-3046
Roles of GPII keys Detail?
Create snapsets Detail?
Create user keys Detail?

Local machine security

Task People Status Notes
Secure communication between components on the local machine (such as user listener to flow manager) High priority.

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.

With the use of electron, all GPII components, including PSP/QSS, will be wrapped up as an electron app that will secure the communication among components.

Question: Could the usb or nfc listeners be included into the electron app, or they need to be separate processes?

Run GPII processes with the minimum privileges that they can High priority.

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 Needs more discussion.

As GPII installation includes the source code. Consider the possibility of that, after GPII is installed, the user could unwrap the GPII electron app, modify the source code, wrap it back to an electron app, then use the app to send malicious requests to GPII cloud.

To clarify: what possible attacks could be? Should a signature of GPII application be verified?

GPII-1049 Protection against settings corruption/injection attacks Needs more discussion.

One use case could be that if one day the preference is extended to support scripting as a preference, if an attacker manages to modify a user's preferences to include the malicious scripting, apply these preferences to the user's could cause damage.

The other use case is, if ATs allow executing code to apply certain settings. An attacker could modify one's preference to cause the code to run in the enactment of the settings, similar to the SQL injection.

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.

Assess risks of information gathered by the Device Reporter and sent to the Cloud Based Flow Manager The information collected by the Device Reporter exposes user's device information. Assess how sensitive and private this information is.

Integration

Task People Status Notes
Provide preferences retrieval and editing inside UIO Needs more discussion
Integrate the GPII with operating system login Needs more discussion.

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 Such as the use of snyk to find out the vulnerabilities of node.js module dependencies

Automated Testing Infrastructure

Task People Status Notes
The possibility to set up continuous security testing, such as fuzzing, to auto detect security vulnerabilities. Needs more discussion

Continuous fuzzing testing offered by Google for open source projects are more for released projects instead of in development projects like GPII: https://opensource.googleblog.com/2016/12/announcing-oss-fuzz-continuous-fuzzing.html. Not sure how hard it is to set up our own infrastructure. A reference of in-process fuzzing for chrome components: https://security.googleblog.com/2016/08/guided-in-process-fuzzing-of-chrome.html

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-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: