RFC security policy

[crepererum]

After fixing #3003 and the more or less uncontrolled disclosure of security information, I sat down to write the following RFC. It is not urgent (especially because it is a slightly long text) and might only be a start of a discussion. Feel free to add your comments or criticize it. At a certain point of consensus, I can create a PR out of the material.

Security Policy (draft)

Invenio reached a state where the impact of security holes and possible exploits is not only a problem for smaller project, but for bigger installations worldwide and therefore the organizations using them. This RFC makes suggestions on

• how to handle security bugs of a certain impact level
• which developers should have which permissions regarding the information about unpatched security bugs
• how users, administrators and external developers should report certain types of bugs or the usage of exploits
• how we ensure to be an open project even when dealing with classified information

  Severity Classification

There exist several classifications from different organizations, e.g. CVSS. These might sued the needs of bigger organizations. For Invenio, the following simplified model might work better.

High Severity

Description: A security hole that impacts running installations of released versions of Invenio (e.g. no pre-releases or developer configurations) in a way that it is possible to gain unprivileged access to data, to destroy data, to leak user information, or to render a system unusable with a significant lower effort than usual; all of that on layer that is reachable by endusers.

Examples: bypassing user authentication, remote code execution, XSS, SQL injections, producing very high server load by malformed inputs.

Permissions: Only a small dedicated group of core developers is allowed to retrieve this information. Other people should only be involved if it is crucial for fixing the problem.

How to report: The bug or usage of certain exploits should only be reported to a closed mailing list which is only readable by people of the given permission level.

Disclosure: The patch nodes must contain a remark that it is a security patch for a High Severity problem. There must not be a public disclosure on mailing lists, forum entries, issue tracker or version control system before a certain level of installations is patched. After it is considered safe to release the information, it must be added to the public repositories and an issue with a problem description and solution must be created.

Low Severity

Description: A security problem that does not affect installations directly. This might be the case because it is not the first layer but a backbone system, because it requires a misconfiguration or High Severity bug to be used or because it is a theoretical bug, e.g. when using problems with certain encryption or signature algorithms.

Exmamples: Weak file system permissions in Docker images (requires already a certain level of system access), low quality password hashing (requires database access), weak signature checks for code dependencies (requires MITM).

Permissions: No special permission is required to retrieve the information.

How to report: Using the public issue tracker

Disclosure: During report or downgrade from High Severity. An issue with bug description and solution must be created.

Undecided/Unclear Severity

Description: A security problem with unclear impact.

Exmamples: Malformed input that could increase the server load but with unevaluated level, the slightly guess that over multiple levels a XSS attack might be possible but without demonstration.

How to handle: Report and handle as High Severity and downgrade if needed.

FAQs

Who attacks public research?

There are many potential attackers. The author does not mention certain scenarios because this might lead to discrimination or unfounded suspicions against people, organizations, groups or states.

Disclosure

The author works as a Invenio developer but does not think that he must be part of High Severity team.

Open Questions

• Should the contact to the closed mailing list be encrypted? If so, how? (e.g. shared PGP key, Schleuder)
• Should there be a special invenio-security-announcement mailinglist to prepare administrators for a critical patch? We have to assume that at the point we release the patch we also disclose the security bug, so there might be only a small time window between patch release and first exploit.
• Should there be a Medium Severity level? If so, who has the permission to read it? (e.g. all core developers) Differentiation to High Severity required.
• Is this method to complicated? If so, how can we simplify it while archiving a suitable security standard.
• Should this document be located at GIT top-level or as a usual part of the documentation? If using the latter approach, we should add a pointer from the README.rst or as as SECURITY file.

[lnielsen]

Related to #1799 and recent discussion on documentation of community processes.

Django has an excellent security policy that can be used as inspiration: https://docs.djangoproject.com/en/1.7/internals/security/

I think the most important to document in a security policy is:

• How to report security issues.
• How we deal with a reported security issue (i.e. what is our workflow).

Currently we have unwritten processes but it would be good to get them down on paper. Also, I think we can wait with technical implementation details such as if we sign/encrypt messages, until the workflow is fully defined and documented.

I.e. I'm +1 for adding a security policy.

[crepererum]

The Django policy looks good to me. It (more or less) reflects the proposed version in a good written and "proved to work" form. We might want to use it as a baseline.

[lnielsen]

Part of documentation update.