...
Security sub-committee recommendations can be found here: Security Sub-Committee Recommendations
JIRA project for issue prioritization: https://jira.onap.org/projects/SECCOM/
Next Call:
| Jira | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
2nd Week:
| Jira | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
Backlog (items to be done):
| Jira | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
Backlog
| Identified activity | Activity Description | Status |
|---|---|---|
| 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 resolved | Started, 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. |
...