1. ONAP Security Requirements ONAP Virtual F2F, December overall requirements - security by design
Stephen Terrill, et al.

2. S3P Area Priority Min. Level Stretch Goal
Level Description (abbreviated)
Security
High
Level % of projects passing silver;
non-passing meet 80% of
Requirements towards silver
Cryptographic – all
Projects
All internal and external communication possible to encrypt
Level 2
•0 -- none
•1 – CII Passing badge + 50% test coverage
•2 – CII Silver badge; internal communication encrypted; role based access control and authorization for all calls
•3 – CII Gold
Replacement of “jackson” libraries
GSON is a comparable package and a replacement strategy for ONAP. 
[Requirement] All projects MUST migrate from the Jackson Data Processor packages to the GSON packages unless the Jackson dependency is inherited from an outside project such as ODL.
Ability to turn on and turn off Secure communication. Secure communication is on by default.

3. VNF Package Security VNF Package Security: Follow SOL004 security
Impacts: SDC, VNF SDK

4. 5G Use Case Security Description Project
AAF CertMan is able to be initialized as a RA to the service provider (SP) CA
AAF
AAF is able to execute the scenario to obtain an initial authentication key (IAK) and Reference Value (RV) from a SP CA on behavior of a VNF using CMPv2 protocol as specified by RFC 4210
AAF provides and API tha allows SO (or some ONAP components) to trigger the IAF/RV scenario execution and returns the IAK, RV and CU URL
DCAE supports VNF authentication using the certificate and an identity list; HTTP username/password not required, but basic auth is still supported for backward compatibility
DCAE
DCAE replaces storage of passwords with storage of hashes
Suport for NetConf/TLS
Controller support for NetConf over TLS as an option for Configuration Management (CM) of the NF. Until supported, one of the other supported CM protocols could be used (Ansible/SSH, Chef/SSH, NetConf/SSH) or alternately, delay CM from ONAP until NetConf/TLS is supported.
APPC, SDNC, VFC, CCSDK.

5. 5G Use Case Security Description Project FTP/TLS for bulk PM DCAE
VES with certificate based TLS authentication.

6. Security by Design - Proposal
SECCOM Actions:
Create ONAP component security guidelines; initially based on VNF requirements. (Due: ONAP developers F2F).
Static code scanning tool
M1:
Identified known vulnerabilities to address/remove in the release with jira tickets
Prioritize exploitable ones.
CII badging level to commit
M2:
Updated status of known vulnerabilities
M3:
Network (Communication) policy (which components to communicate to) deliver to OOM/Integration
Open port information (deliver to integration) (internal/external)
M4:
CII badging
At commit:
80% Test coverage of committed code (new code)
Vulnerabilitie analsys of new libraries brought in and plan.
(static code review, however that has to be in place first).
(action to bring this into the toolchain).

7. Proposal for known Vulnerability Review for subsequent releases
Project Responsibility
M1 – Using Casablanca known vulnerability review tables document how each vulnerability (exploitable or not) will be removed from the project code base
Prioritization of package replacement
Packages containing exploitable vulnerabilities
Packages with vulnerabilities that cannot be exploited within the project
Use oparent.pom where possible
M2 – Vulnerability review table
Jira tickets submitted for each package replacement
Vulnerability review tables much match the NexusIQ reports for M2; PTL must indicate the date of the NexusIQ scan in the vulnerability table
PTL MUST review the NexusIQ scan reports for their project each week and add any new vulnerabilities
SECCOM will review and provide feedback if requested by PTL
M3 – Same as M2
M4 – Vulnerability review tables complete
SECCOM will review the tables for RC0
PTL MUST continue to track the NexusIQ reports and add any new vulnerabilities to the table
PTL MUST notify SECCOM of any new items in their reviews until Release
Every week – PTL MUST review the NexusIQ scan reports for their project and update table with any new vulnerabilities

8. Support for secure communication (feedback appreciated)
Pluggable authentication /Authorization /Certificate management framework should be part of ONAP architecture (AAF, ISTIO plug-in)
ONAP should allow service providers providing their own pluggable architectures
ONAP will adopt ISTIO as certified reference architecture – considering current performance/footprint problems.
In Dublin time frame to work towards ISTIO reference architecture which is integrated to AAF RBACC and certificate management . TBD plan , hosting project and resources
Retain current AAF approach for Dublin at this stage.
Provide per component guidelines how to allow pluggable security with BWC to existing security implementation
Dublin being the target , but in timelines will not be met , El Alto as the official release for this change
The Short term for Casablanca maintenance release is to support opt-in option to disable AAF for development , and to allow easy certificate generation process.
Default is secure communication is ON.