ONAP El Alto Security So W proposal Pawel

ONAP El Alto Security So. W proposal Pawel Pawlak 12 th June-26 th of September 2019

El Alto So. W proposal to ONAP community 1. Work on OJSI tickets to solve penetration tests findings/CVEs – 60 days ticking clock! 2. Update ONAP environment (java, python, kubernetes, docker, ubuntu, alpine…) to commonly agreed versions 3. Focus on known vulnerabilities by upgrading libraries to commonly agreed versions – coordination with ONAP Release Manager, stakeholders: OOM, Integration, PTLs 4. Focus on known vulnerabilities by replacing libraries with commonly agreed versions and components – coordination with ONAP Release Manager, stakeholders: OOM, Integration, PTLs 5. Update CII Badging answers within release LCM 6. Contribute to ONAP security communication matrix creation 2

El Alto So. W proposal to SECCOM community 1. Support ONAP community in achieving El Alto goals 2. Update Security by Design with: CII Badging gates, https communication update for M 3, revamping of the vulnerability review tables 3. Update Oparent. pom file with SECCOM recommended and consulted versions, including dependency management from Maven 4. Create communication matrix based on inputs from PTLs and validate it with scripts with Integration team – coordinate with architecture team 5. Support Integration team with security testing enhancements 6. Consider security features scope and perform comparative analysis of AAF and ISTIO 7. Design CMPv 2 implementation – stakeholder: AAF 8. Benchmark Nexus-IQ with Whitesoftware for Dan’s project 9. Continue known vulnerabilities management and CII Badging answers reviews 3

Discussion Points at September F 2 F • Everyone in the ONAP community is responsible for securing ONAP, not just SECCOM - CLAMP and Policy are very responsive to security issues • Not all CVEs and OJSI Jiras were addressed in El Alto - Goal: recommend that nonresponsive projects not be included in future releases • Observation that none of the operators are using ONAP in production - AT&T uses ECOMP which is not “ONAP out of the box” • Raise the issue of inactive projects to the larger community - Should inactive projects (no new development, no response to jiras) remain part of ONAP? - What impact does removing a project from a release have on ONAP? - If an inactive component is critical, how can new ownership be found? 4

Discussion Points at September F 2 F • Document the security posture of ONAP in readthedocs. - Provide a list of projects that meet the security expectations and a list that do not • Upgrading and replacing third party libraries - CLAMP is the only ONAP project that has replaced a package with a nonvulnerable package - Release manager must take role in coordinating package upgrades and replacements - oparent • Integration team should own the oparent file update • M 3: SECCOM will provide recommended versions of libraries to be included in oparent • CII Badging • Communication Matrix 5

s