Versions Compared

Old Version 5

changes.mady.by.user Amy Zwarico

Saved on

compared with

New Version Current

changes.mady.by.user Tony Hansen

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • 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 NameDescriptionOwnerCreatedStatus (open, closed)
Alignment with architecture teamPlacement of security docsHarald Fuchs07 May 2020open
Basic structure of the documentsPossibly based on existing examples, ORAN security, ....Harald Fuchs07 May 2020open
How to track and insert changesJira, 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

Image Added

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

Image Added

  • Meeting from 19. March 2020

Image Added

  • Meeting from 05. March 2020:



Meeting from 19. March 2020



...