Purpose of the Activity

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)

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)

Meeting Notes and Current State of the Discussion:

Meeting from 02. April 2020

Meeting from 19. March 2020

Meeting from 05. March 2020:

Meeting from 19. March 2020

Open Source Project Documentation Examples:

Eclipse Jetty
- https://www.eclipse.org/jetty/
- Nice features
  - Security Reports includes a table of all known CVEs affecting Jetty and the release in which the vulnerability was fixed: https://www.eclipse.org/jetty/security-reports.html
  - Documentation contains a section on how to configure security in Jetty: https://www.eclipse.org/jetty/documentation/current/
    - Authetication and Authorization
    - Limiting Form Content
    - Aliased Files and Symbolic Links
    - Secure Password Obfuscation
    - Setting Port 80 Access for a Non-Root User
    - JAAS Support
    - SPNEGO Support
    - Session Management
    - Logging
- Observation: Jetty is a very mature project and has put a lot of time and effort into their documentation
Ubuntu
- Ubuntu Release Notes
  - Lists updated packages
  - Lists security improvements
  - Lists known issues
  - Includes instructions for reporting bugs
- Known vulnerabilities are reported at on the Ubuntu Security Notices page: https://usn.ubuntu.com/
- Ubuntu native security features are documented in the Ubuntu guides
  - Example: Ubuntu Server Guide - Chapter 7, Chapter 9 (https://help.ubuntu.com/lts/serverguide/serverguide.pdf)

ONAP Wiki

ONAP Security Docs -- Discussion