dft street manager doc 0006 security overview

Security overview

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

Data flow

TODO data flow diagram Steven/Ali/Phil

Authentication and authorisation

TODO diagram Steven/Ali/Phil

TODO Registration Phil

TODO critical national infrastructure Phil

Connection between components

TODO Steven/Phil

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.