Skip to content

Latest commit

 

History

History
85 lines (52 loc) · 4.25 KB

DINA-Cybersecurity-Guidelines.md

File metadata and controls

85 lines (52 loc) · 4.25 KB

Security guidelines

DRAFT, TBD

Background

This document sets out a set of guidelines about IT security.

The DINA TC views secure software as fundamental, also supporting the confidence of partners adopting DINA software. Security means availability, integrity and confidentiality

Summary

  • Network connections are encrypted
  • Applications and web services pass OWASP10
    • Applications are tested for malicious user input
  • Non-DINA components are hardened as-per component best-practices
  • Docker is hardened
  • other? TBD

Further Details and Explanations

Network Connections Encryption

All network connections including those between internal and external services, must be encrypted if encryption is available.

All applications and web services are to run only https.

For applications, http is redirected to https, but all parameters on the URL are scrubbed (assumed to be compromised) and the redirect is to the entry or default page for the application

For web services, http is redirected to a [403](https://en.wikipedia.org/wiki/HTTP_403) error

Examples:

This hardening can be centralized through dockerization.

Web application and Web Services Security

OWASP10 is a list of the 10 top web vulnerabilities, with associated explanations and mitigation documentation.

Web applications (including web services like a RESTful web service) must pass tests of the Open Source tool, OWASP ZED. Pass means no vulnerabilities are detected by this tool.

  • OWASP10 (and any other reports) MUST not be checked in to github, or attached to issues (we need to agree/figure out how we talk about these reports) TBD Why? How confidential are these?

Tools

TBD: which to use / how to use / when to use?

Dependent Component Security

Application/service may depend on non-DINA Application/service for operation. (E.g. MySql, Keycloak, Solr, etc.)

Application/service dependencies/components should adhere to any other security best practices for that component. For example, MySQL can be secured or hardened using guidelines such as MySQL Database Security Best Practices.

This hardening can be centralized through dockerization. TBD How?

TBD: Agree on same best practices per component

Example list of components and best practices documents (draft)

Docker Security

As docker is a fundamental technology for this project, making it secure is a priority.

TBD Check how up-to-date these are? Which Docker hardening to use (big list)

These same hardening best-practices should also be applied to the host OS (not all of them are possible at the container level).

The host OS is not in the control of the DINA team, so install instructions should strongly suggest these and maybe other hardening best-practices.