Skip to end of metadata
Go to start of metadata

This is a wiki page that captures the intent and planned/ongoing actions for the support of security coordination in ONAP.

This covers both the organizational setup and the operations of the onap security subcommittee. 

ONAP security organization

The ONAP security work is split into two parts.  The management of identified vulnerabilities, which is handled by the vulnerability management sub-committee and the coordination and identification of necessary security related activities which is handled by the security sub-committee.

Vulnerability management

Vulnerability management covers how to handle the reception of an identified vulnerability through to solution and communication of the vulnerability.  The process is initiated by the reception of an email to onap-security@lists.onap.org.  The vulnerability management procedures can be found here: ONAP Vulnerability Management.

The vulnerability management procedures are executed on by the vulnerability management sub-committee.

Release Vulnerabilities

This lists the vulnerabilities reported for each Release.

ONAP security sub-committee

The ONAP security sub-committee identifies and creates proposals related to security in ONAP.  As one example, it has created the proposal for the Vulnerability management procedures which are now in effect.  The ongoing efforts of the ONAP security sub-committee are now to explore more proactive security activities. 

The email address for the onap sub-committee is:onap-seccom@lists.onap.org with information on how to subscribe found here: onap security sub-committee email subscription.

The ONAP security sub-committee meeting logistics are:

------------------------------------------------------------------------------------------------------------------

ONAP Security sub-committee Operations

General Meeting Agenda:

  • Information Update
  • Topics to advance
    • Walkthrough identified items to suggest. 
  • Backlog update and review
    • Update or add item backlogs 
  • For coming meeting: 
    • Agree topics for the next meeting
  • AOB

Requested Agenda Items: Please feel free to add topics here that you would like to have on the agenda (or send an email to stephen.Terrill(at)ericsson.com).

  • item A 

Security sub-committee recommendations can be found here: Security Sub-Committee Recommendations 

JIRA project for issue prioritizationhttps://jira.onap.org/projects/SECCOM/

Next Call:

Key Summary T Created Updated Due Assignee Reporter P Status Resolution
Loading...
Refresh

2nd Week:

Key Summary T Created Updated Due Assignee Reporter P Status Resolution
Loading...
Refresh

Backlog (items to be done):

Key Summary T Created Updated Due Assignee Reporter P Status Resolution
Loading...
Refresh


If you want to be involved, please contact Pawel Pawlak or Amy Zwarico

Note: if you would like to change the contents of this site, please contact Pawel Pawlak or Amy Zwarico.


  • No labels

5 Comments

  1. Hi Stephen - I would like to suggest a couple of things:

    • Can we also consider the following epic - COMMON-8 - Getting issue details... STATUS ?
    • From a tooling perspective, FOSSology is an open source license compliance software system and toolkit.
      This tool could be useful to ensure that we are not integrating any open source released under GPL, Commercial licenses, etc.
      https://www.fossology.org/
    • CheckMarx is offering a Static Application Security Testing (SAST) product that prevents vulnerabilities in our source code but it is unfortunately not free.
      I have not yet found a similar security open source product.
      https://www.checkmarx.com/Open-Source-Analysis
  2. Hi Catherine,

    Thanks for the valuable suggestions.  First up I think we need to get then vulnerability procedures in place (which is reactive) then look into the more proactive activities like you have suggested.  This will be taken into account when doing so.

    Regards,

    Steve

  3. The Core infrastructure Initiative focuses on the process we should use to ensure code does not have identified security issues.  That is one part of the problem.

    We also need to recommend design and implementation guidelines on how to do this. Sometimes described as Secure Engineering, or Secure by Design. Some guidelines are generic and some language-specific. 

    The OPNFV Securecode is one possible example (there are others, eg Deutsche Telekom's published security and provacy guidelines), the direct links are:

    https://wiki.opnfv.org/display/security/Securecode

    https://www.telekom.com/en/corporate-responsibility/data-protection-data-security/security/security/privacy-and-security-assessment-process-358312

  4. May I ask you to consider the "Authentication and Authorization Framework" as a project to meet some Security requirements? Thank you


  5. It looks like the "Authentication and Authorization Framework" (AAF) is vital to solve the security issue raised here: Re: Installing and Running the ONAP Demos