GPII Security Plan
- 1 Security framework
- 2 Keying in and Authentication
- 3 Authorization server
- 4 Cloud Based Flow Manager
- 5 Local Flow Manager (Hybrid)
- 6 OAuth 2 Clients / Solutions Registry
- 7 Data storage
- 8 Preferences editing
- 9 User accounts
- 10 Local machine security
- 11 Integration
- 12 Deployment
- 13 Automated Testing Infrastructure
- 14 Bugs
- 15 GPII Issues to be reviewed
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
|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.|
|Identify and document applicable legal regulations (such as HIPPA)||High priority.|
|Improved security-related logging||In Progress||High priority.|
|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.
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
|Secure communications between GPII process and Windows service||Steve Grundell||In progress|| High priority.
See JIRA comments for the work progress.
Keying in and Authentication
|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
|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.
|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.|
Cloud Based Flow Manager
|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)
|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
|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".
|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.|
|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.|
Part of the user management system. Needs more discussion on requirements.
|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
|Associate GPII token with login id/pwd|
|Revoke GPII keys|
|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 user keys||Detail?|
Local machine security
|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.|
|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.
|Where does HTTPS terminate?|
|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
|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
|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?
- https://issues.gpii.net/browse/GPII-406 Support User accounts (as opposed to the user token - managing login devices, GPII keys, etc)
- https://issues.gpii.net/browse/GPII-408 Implement a means of indirection between content of login device and user token associated with a preference set
- https://issues.gpii.net/browse/GPII-409 Implement OAuth layer in front of the preferences server and flow manager
- https://issues.gpii.net/browse/GPII-410 Only "approved clients" (i.e. Flow Manager, PMT, PCP) access the Preferences Server directly
- https://issues.gpii.net/browse/GPII-411 Implement Support for anonymous preference sets
- https://issues.gpii.net/browse/GPII-767 Support for per-application security settings
And we have a number of issues filed for Trusted Flow Manager secrets:
- https://issues.gpii.net/browse/GPII-1181 Support secrets installed on flowmanagers making it a more trusted component
- https://issues.gpii.net/browse/GPII-1211 Support trusted flowmanagers (secrets installed on flowmanager)
- https://issues.gpii.net/browse/GPII-1213 Write instructions for setting up trusted flowmanager