...
- Identify which security documentation already exists and where
- Put everything in one place at least as a reference
- Identify gaps and fill those
- Make everything of general relevance available from RTD
Timeline
Initial output for the Guilin release:
- Central document content version 1
- Project template version 1 used by x projects
Activity Register
| Activity Name | Description | Owner | Created | Status (open, closed) |
|---|---|---|---|---|
| Alignment with architecture team | Placement of security docs | Harald Fuchs | 07 May 2020 | open |
| Basic structure of the documents | Possibly based on existing examples, ORAN security, .... | Harald Fuchs | 07 May 2020 | open |
| How to track and insert changes | Jira, Gerrit, other change request tools? | 07 May 2020 | ||
Proposed structure of security documentation and development
The proposed structure for the security documentation splits responsibilities and sources.
- SECCOM team to provide principles and guidelines to be followed and a template for the projects to provide the security essentials.
- Each project can provide more specific information as they see fit
- Non-documentation sources of ONAP security relevance are referenced/linked
The aim is to make information accessible as easy as possible. All released information will be available from readthedocs (https://docs.onap.org).
The development of content is done in the wiki as collaboration platform. At release time the content is transferred to the readthedocs by means of the scripts provided by the documentation project.
The project security docs should consist of two portions:
- Expectations:
What the user can and cannot expect in terms of security from the software produced by the project, that is, the security requirements that the software is intended to meet. It may make include pointers into the project's architecture document.
- Assurances:
The project MUST provide an assurance case that justifies why its security requirements are met. The assurance case MUST include: a description of the threat model, clear identification of trust boundaries, an argument that secure design principles have been applied, and an argument that common implementation security weaknesses have been countered.
Existing security documentation (02. April 2020)
- https://docs.onap.org/en/latest/submodules/aaf/authz.git/docs/sections/architecture/security.html
- https://docs.onap.org/en/latest/submodules/dmaap/buscontroller.git/docs/security/security.html
- https://docs.onap.org/en/latest/submodules/osa.git/docs/index.html
- https://docs.onap.org/en/latest/submodules/vnfrqts/requirements.git/docs/Chapter4/Security.html
- https://docs.onap.org/en/latest/submodules/multicloud/framework.git/docs/specs/multicloud-secured-communication.html
- https://docs.onap.org/en/latest/submodules/aai/esr-gui.git/docs/release-notes/security-issues.html
- https://docs.onap.org/en/latest/submodules/vnfrqts/requirements.git/docs/Chapter5/Heat/ONAP%20Heat%20Resource%20ID%20and%20Parameter%20Naming%20Convention/Suggested%20Naming%20Convention%20for%20Common%20Parameters.html#security-group
- https://docs.onap.org/en/latest/submodules/vnfrqts/requirements.git/docs/changes-by-section-frankfurt.html#vnf-security-vnf-general-security-requirements
- https://docs.onap.org/en/latest/submodules/osa.git/docs/process.html#handling-public-leaked-security-issues
- https://docs.onap.org/en/latest/submodules/dcaegen2.git/docs/sections/apis/ves.html#security
Meeting Notes and Current State of the Discussion:
- Meeting from 02. April 2020
- Meeting from 19. March 2020
...