Skip to content

dft street manager doc 0006 security overview

Jump to bottom
stevenalexander edited this page Feb 23, 2018 · 11 revisions

Security overview

Author(s) - Alistair Cowan, Phil Allen, Steven Alexander

Summary threat model

See the notes from the Threat Modelling workshop here.

Registration and authentication

User registration

Users will be registered using a two stage process:

  1. Register lead users in each organisation
    1. Promoter and authority organisations are identified and validated, out of band.
    2. GeoPlace curates identities and contact details of responsible people within organisations, out of band. They will be Street Manager lead users.
    3. Street Manager will deliver single-use, limited-time credentials to lead users via either two contact points (split secrets) or personally to hand.
    4. On the Street Manager site, those lead users will use their single-use credentials to create their own credentials: password and TOTP token (BYO).
  2. Lead users invite other users within their organisation
    1. Lead users will choose whether to apply 2FA to other users in their organisation.
    2. Lead users will use the Street Manager site to invite users by e-mail. Street Manager will generate invitation e-mails containing single-use, limited-time credentials.
    3. On the Street Manager site, those invited users will use their single-use credentials to create their own credentials: password and (according to lead user preference) TOTP token (BYO).

For further details see ODP - Registration and Authentication

User Authentication

For details see ODP - Registration and Authentication

API caller registration and authentication

Registered organisations will be able to attach an authentication token to the header of API requests, which will authenticate and provide authorisation details about the API caller.

Authorisation

For further details see ODP - Authorisation

Connection between components

HTTPS

All communication should be over HTTPS using secure TLSAuth.

Database

Each component which requires database access should use unique user credentials (see below).

Database user access

Each component which accesses a database should do so with specific user credentials with permissions set following the principle of least privilege. Database changes/migrations should be performed using separate credentials as part of the deployment process, so not exposed in the running application.

Common types of attacks

The system should have prevention/countermeasures for attacks described in the OWASP top 10.

  1. A1:2017-Injection - Basic request sanitisation of invalid characters will be performed on all inbound requests (e.g. using express-sanitized) and use of eval(...) will be prevented via linting. All SQL calls will be wrapped using Knex to prevent SQL injection.
  2. A2:2017-Broken Authentication - Implement 2 factor authentication, rate limiting/delays on login endpoints, use strong expiring session tokens that can be validated in application.
  3. A3:2017-Sensitive Data Exposure - All data should be encrypted in transit and rest (TLS and database encryption), avoid logging/auditing sensitive data and avoid storing sensitive data if possible or have sensible archiving policy to reduce exposure.
  4. A4:2017-XML External Entities (XXE) - APIs will use JSON were possible, any SOAP endpoints should use secure processors and all requests will use validation/sanitisation on content.
  5. A5:2017-Broken Access Control - All secured endpoints should identify the roles a user requires to access them (via RBAC) with access failures recorded in logs. Any file download endpoints should not use file paths, instead go via database IDs, so file paths are not exposed or used. Session tokens will be invalidated after logout.
  6. A6:2017-Security Misconfiguration - All security configuration will be done via automation (Infrastructure as Code) not manually. Application of patches will be part of regular releases and monitoring security updates will be part of solution support.
  7. A7:2017-Cross-Site Scripting (XSS) - Request validation/sanitisation will be performed on all requests and all web components will implement CSP to restrict what JavaScript can run on the site. All output values presented to users will be HTML escaped in templates.
  8. A8:2017-Insecure Deserialization - Avoid deserializing objects where possible. In cases where this is required (e.g. SOAP calls) the components doing this should be isolated. Deserialization failures should be logged and endpoints monitored.
  9. A9:2017-Using Components with Known Vulnerabilities - Applications should use current versions of components were possible ("fast-follow" patching) and vulnerabilities should be monitored via an automated check on dependencies (e.g. NSP) performed at commits and regularly.
  10. A10:2017-Insufficient Logging & Monitoring - See Monitoring and Logging details.

File upload

Managing attachments submitted to Street Works is part of the solution. The web components will need to allow users to upload files and view files, images, documents, CAD etc. Full list of supported file types will be in user story.

Files uploaded should have the following checks performed:

  • Validated against supported file type lists (should exclude zip for zip bombs)
  • Validate size to prevent large files
  • Rate limiting on upload endpoints
  • Files should be uploaded first to quarantine zone then virus scanned before being added to main store and allowed to be downloaded by other users
  • A regular virus scan of files should be performed on file store using up to date definitions to catch files which passed initial scan

Data flow diagram

TBC data flow diagram (see here for example).

References

Clone this wiki locally