You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 38 Next »

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 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.

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



Backlog (to be depricated as replace by Jira).

Identified activityActivity DescriptionStatus
Creation of a Vulnerability Response Team

Creation of a Vulnerability Management Procedures and Team.   

Done.  Activity Closed.

Identify an approach to manage and handle known vulnerabilities.  This is specific to the components or libraries that ONAP projects have brought in from external sources. 

Nexus IQ/Sonatype LCM has the ability to identify and display known vulnerabilities of used components.  These used components are in the end part of the ONAP release and it is not desirable to release with known vulnerabilities.

A proposal needs to be created to bring to the TSC to address how to work-through the known vulnerabilities and relate it to the project release plan.

Nexus IQ/Sonatype LCM is ready for use and the results can be made available.

Status: Proposing to TSC

Analyze and make recommendations to the CII badging program

https://github.com/linuxfoundation/cii-best-practices-badge  

This may identify good practices, which could include guidelines.  consider, Ensure least privilege by design), consider how to look at code scaning into the integration processes.

Also look at:

Done.

The security subcommittee recommends a gold level.

Included in the S3P recommendations.

Create CII Badging program ONAP support guide. As part of the S3P, the a number of projects will go into the CII badging program.  A guide to help the projects on common ONAP project issues would be useful. Progressing (See: CII Badging Program)
 CII Badging program hackathone.Organize a hands-on starter session with the CII Badging programe for project memembers Identified 
Identity primary relevant legislation stds to be considered. Identify the main security standards etc that are related to regulatory requirements.  This would be for awareness. 
 Static Vulnerability Scans.

Identify and propose a process for static vulnerability scans 

Information can be found on: https://wiki.onap.org/display/DW/ONAP+security+Recomendation+Development 

Recommendation: Coverity is used, and included as part of the CI/CD tool chain with weekly mails to the PTLs, with seccom support in analysis.

Status: proposing to TSC   

Credential Management 

 Proposed architecture and proposal for handling credentials in ONAP

Information can be found on: https://wiki.onap.org/display/DW/ONAP+security+Recomendation+Development 

 Completed.  Credential management and secret storage service will be part of the AAF project scope..

Credential Management Recommendations to projects Based on the AAF implementation, a recommendation to the projects on how to use the AAF APIs is required and should be document.  It should be developed into the ONAP security Recomendation Development then trasnfered to the best practices for promotion. 
Secure Communication Recommendation  A clear guidance to the projects for secure communication is required.  This  has been part of the discussions regarding credential management, however a clear recommendation has not been produced
VNF package security  The question of handling the security authentication etc for the VNF package has been raised by the VNF SDK project, however it has not been resolvedStarted, Samuli takes the lead
Atack Vector Considerations

wondering if the Security subcommittee would find it helpful to the community to document the various attack surfaces that ONAP has and to identify what, if any tooling, counter-measures, etc exist for each, what has been covered, what is a continued gap, etc.  Such attack surfaces are:

- South-bound interfaces - communication with controllers, EMSs, VIMs, VNFs, etc.  What authentication, authorization, and encryption are or can be put in place for these interfaces?

- East/West interfaces - communication with other orchestrators, VNFCs, etc. ""

- North-bound interfaces - Portal access, External API access, etc.

- Component/Upgrade Security.  How to ensure each ONAP component is an authentic part of the ONAP system?  How to allow, but secure component upgrades?

... etc.  Those are in addition to what we know we are already focused on such as:

- ONAP code vulnerabilities

- 3rd Party component published vulnerabilities (CVEs) 


Given the broad scope of "ONAP Security", would we find it helpful to spell out all the different types of security that we can imagine when dealing with this system, prioritizing what are most important, identifying where we have good/medium/poor coverage of a particular attack-surface and long range plans/aspirations on improving them?

 

Secure communication to External Systems and NFs Describe the proposal for secure communication to external systems and NFs. 


If you want to be involved, please contact Stephen.terrill@ericsson.com 


Note: if you would like to change the contents of this site, please contact Stephen Terrill.


  • No labels