ONAP Security sub-committee Presentation - PowerPoint Presentation

ONAP Security sub-committee Presentation- Casablanca Focus - 2018-06

2 Presentation purpose Inform of Casablanca Expectations from a security perspective Inform of “what’s on” and “what’s coming” in the ONAP security sub-committee Receive your feedback.

3 “What’s done”, “What’s on” and “What’s coming” What’s Done Casablanca S3P for security Certificate and authentication support via AAF What’s Happening Secure communication to xNF aka 5G use case security VNF package security recommendation using SOL005 (VNF package) Recommended protocols “pluggable” authorization Static code scanning Secure communication between ONAP components with/without ISTIO What’s Coming Security Review of xNF requirements ONAP attack vector analysis (aka threat analysis) Secure infrastructure scanning (Norad) Next level of VNF package security …. Secure communication with/without ISTIO Vulnerability Management Procedure

4 Casablanca S3P Update Proposed Update Project-level requirements Level 0: None Level 1: CII Passing badge Including no critical and high known vulnerabilities > 60 days old Level 2: CII Silver badge, plus: All internal/external system communications shall be able to be encrypted.All internal/external service calls shall have common role-based access control and authorization.Level 3: CII Gold badge  ONAP Platform-level requirements per release Level 1: 70 % of the projects passing the level 1 with the non-passing projects reaching 80% passing levelNon-passing projects MUST pass specific cryptography criteria outlined by the Security Subcommittee*Level 2: 70 % of the projects passing silver with non-silver projects completed passing level and 80% towards silver levelLevel 3: 70% of the projects passing gold  with non-gold projects achieving silver level and achieving 80% towards gold levelLevel 4: 100 % passing gold.

5 Casablanca S3P Update Proposed Update Area Priority Min. Level Stretch Goal Level Description (abbreviated) Security High Level 2 - 70% of projects passing silver;non-passing meet 80% ofRequirements towards silverCryptographic – allProjectsAll 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

6 S3P learnings Don’t leave the known vulnerability analysis until the end – incorporate it as part of the monthly project work If we have an vulnerability in our code, we need to fix it in 60 days.

7 CII Badging Silver level challenges “Bus factor” of 2 or more An automated test suite MUST be applired on each check-in to a shared repo Project must identify specific coding style guides for primary languages; Must enforce its coding styles if there is a floss tool to do so. Should we have this in general for ONAP? Project Should avoid using deprecated or obsolete functions where FLOSS alternatives are availableThe project MUST cryptographically sign releasesHow to do in toolchain?How to make key available?

8 VNF package security TSC approved recommendation to follow SOL004 VNF package security. Timing not approved at TSC

9 Recommended and not recommended protocols Link: https://wiki.onap.org/display/DW/Recommended+Protocols Summary: All communication between applications should be encrypted Recommend TLS v1.2 Cipher suit recommendationsSSHDMaaPPFS (perfect forward security)

10 Secure Communication to Network Functions aka: security enhancements for 5G use case Link: https://wiki.onap.org/display/DW/Secure+Communication+to+Network+Functions Purpose: Derived from the 5G Use case discussions. Look into what is required for secure communication between the network functions. Still Work in Progress ONAP PNF VNF DCAE Controllers Scope Assumptions on Cert management Communication between network functions and DCAE Communication between network functions and controllers SSH Resulting requirements on projects 5G Usecase coversInitial bootstrapping of connected xNF and ONAPSecure communication and authorizationIncludes CM access of ONAP -> xNFAlso xNF-> ONAP

11 5G summary – main takeaways Different use of CA in testing/integration and production Avoid username/password TLS for security of TLS connections Except: except for NF certificate enrollment over CMPv2 Recommendations on certificate chaining: Root CA, Sub CA, End-entity ONAP capable already ONAP shall support both TLS and SSH as the transport protocol for NetConfTLS preferredVES Security (to be discussed)

12 Secure communication to xNF (aka 5G UC security) [ cont ] Summary: ONAP components and NFs shall support at least 3 levels of certificate chaining; Root CA, Sub CA, End-entity.  Note:  This is already supported in ONAP When certificates are used, LDAPv3 shall be supported as the primary method of authorization of a NF in ONAP.When certificates are used, HTTP shall be used as an alternative method of authorization of an NF when LDAP is not available.LDAPv3 format or HTTP format shall be used to access file repositories of TLS certificates.LDAPv3 and HTTP formats shall be supported for checking the revocation status of TLS certificates.When SSH/SFTP is used, public key authentication shall be supported by NF to authenticate ONAP access; password authentication is not recommended to be used SSH/SFTP access into the NF. ONAP shall support both TLS and SSH as the transport protocol for NetConf.  TLS shall be the preferred transport protocol for NetConf.It shall be possible to specify the configuration management protocol supported by a NF at design time (NetConf/TLS, Netconf /SSH, Ansible/SSH or Chef/SSH).If a configuration management protocol is not specified for a NF, ONAP shall try NetConf/TLS first as the default. Still Work in Progress

13 Secure communication to xNF (aka 5G UC security) [ cont ] Summary: ONAP components and NFs shall support at least 3 levels of certificate chaining; Root CA, Sub CA, End-entity.  Note:  This is already supported in ONAP When certificates are used, LDAPv3 shall be supported as the primary method of authorization of a NF in ONAP.When certificates are used, HTTP shall be used as an alternative method of authorization of an NF when LDAP is not available.LDAPv3 format or HTTP format shall be used to access file repositories of TLS certificates.LDAPv3 and HTTP formats shall be supported for checking the revocation status of TLS certificates.When SSH/SFTP is used, public key authentication shall be supported by NF to authenticate ONAP access; password authentication shall not be supported for SSH/SFTP access into the NF. ONAP shall support both TLS and SSH as the transport protocol for NetConf.  TLS shall be the preferred transport protocol for NetConf.It shall be possible to specify the configuration management protocol supported by a NF at design time (NetConf/TLS, Netconf/SSH, Ansible/SSH or Chef/SSH).If a configuration management protocol is not specified for a NF, ONAP shall try NetConf/TLS first as the default. Still Work in Progress

14 Secure communication to xNF (aka 5G UC security) [ cont ] Summary: Initial PNF Certificate Enrollment Occurs during Plug-n-Play (PnP) according to 3GPP TS 32.508.PNF uses its vendor certificate for identity, authentication and authorization to the CA. Vendor Root certificate must be pre-provisioned in the CA.  This procedure is outside of ONAP (unless the CA is the ONAP CA used for development and testing).Initial VNF Certificate EnrollmentFollows ETSI standards: SOL002, SOL003, SOL005, IFA006, IFA007.Two options are supported. Option 1:  PKCS#12 container can be installed on the VNF at instantiation time.Out-of-band pre-provisioning with the CA is necessary to generate the PKCS#12 bundle before the VNF is instantiated.Option 2:  VNF can perform certificate enrollment with a One Time Password (OTP).The OTP, which is a Pre-Shared Key (PSK), is generated by the CA, along with a Reference Number (REFNUM) and provisioned on the VNF at instantiation.After instantiation, VNF performs certificate enrollment via CMPv2; VNF includes the REFNUM in the Certificate Signing Request (CSR); PSK is used to sign the CSR.  See RFC4210 Appendix D.4 Out-of-band pre-provisioning with the CA is necessary to generate the PSK and REFNUM before the VNF is instantiated.  This is just one part of the larger network planning exercise that must be completed before a gNB is deployed. Still Work in Progress

15 Secure communication when using ISTIO Link: https://wiki.onap.org/display/DW/Secure+communication+recomendation+when+ISTIO+is+used Proposing: Co-existence of ISTIO CA and AAF CA ISTIO CA using AAF CA Testing via experiment before creating final recommendation Still Work in Progress

16 Pluggable Authentication and Authorization Link: Chapter 7: https://wiki.onap.org/display/DW/ONAP+security+Recomendation+Development To address the requirements for plugging into different service providers User-level security infrastructures: Goal 1: Alternative Authentication and Authorization security providers can be integrated without requiring customization of the underlying ONAP code. Goal 2: Align with the existing AAF project, so as to promote re-use and to avoid duplication/fragmentation of the security architecture. Goal 3: Minimize the operational effort required to configure and patch microservices.Goal 4: Provide a solution that minimizes the development impact on microservices written in Clojure, Python etc as well as JavaGoal 5: Support human and non-person entities interacting with the ONAP applications at run-time. Leverages the CADI/AAF approach that is in ONAP Still Work in Progress

17 Pluggable Authentication and Authorization Terminology: Subject - An entity requesting to perform an operation upon the object. The subject is sometimes referred to as a requestor. The subject may be a human or a non-person entity. User - Any subject that interacts with a system. Non-person entity - A subject that is not a human.Role - 1. A business responsibility that an employee or contractor fulfills. 2. A level of privilege assigned within a resource. 3. A defined set of user accounts for a job function Still Work in Progress

18 Pluggable Authentication and Authorization Pattern: CADI/AAF Authentication / Authorization Still Work in Progress Flow: REST request arrives containing token (or x509 cert subject) CADI filter intercepts request and retrieves token: 1.If protocol is configured for caching, CADI checks for match in cache No match – validates token with supported authentication provider. validation result is cached. If token is not valid, request is rejected.Retrieves authorizations from AAF Caches resultAuthorization filter performs admit/reject via authorization policy:The filter compares the authorizations retrieved by CADI with the configured requirements for the invoked method/URI pattern.If the authorizations are satisfied, the filter admits the request. Otherwise the request is rejected with a 403.

19 Pluggable Authentication and Authorization Pattern: CADI/3 rd Party Authentication and Authorization provider Still Work in Progress Flow: REST request arrives containing token (or x509 cert subject) CADI Filter is configured to extract tokens from one or more locations – e.g. headers, X509 cert subjectIf protocol is configured for caching, CADI checks for match in cacheNo match – CADI is configured to forward tokens to external security microservice with AUTH* interface. Security Microservice implementation validates token with Authentication ProviderSecurity Microservice implementation retrieves authorizations from Authorization ProviderSecurity microservice returns authorizations in standard format CADI Filter caches result3Authorisation filter performs admit/reject via authorization policy:The filter compares the authorizations retrieved by CADI with the configured requirements for the invoked method/URI pattern.If the authorizations are satisfied, the filter admits the request. Otherwise the request is rejected with a 403.

20 Pluggable Authentication and Authorization Pattern: Authentication and Authorizatoin from Cached Results Still Work in Progress Flow: REST request arrives containing token (or x509 cert subject) CADI Filter is configured to extract tokens from one or more locations – e.g. headers, X509 cert subject*Checks for match in cacheMatch found, identity is valid. Checks for matching authorizations in cacheMatch foundAuthorizations added to requestAuthorization filter performs admit/reject via authorization policy: The filter compares the authorizations retrieved by CADI with the configured requirements for the invoked method/URI pattern.If the authorizations are satisfied, the filter admits the request. Otherwise the request is rejected with a 403.

4) Get roles and permissions for “ABC” Pluggable Security Service 1) Login to Portal 2) Authenticate and authorize “ABC” 5) Roles and permissions ABC 7) VID access granted 8) Create VNF 9) Get roles and permissions to ensure “ABC” can “Create VNF” 11, 14, 17, 20) Authenticate in CADI using certificates (CertMan) send mechid and requested resource to AAF for authorization, return Oauth token to application where it is cached – initial invocation only. 10) Call MSO 13) Call A&AI 16) Call SDN-C Token Service (OAuth, JWT, etc ) 12, 15, 18, 21) Authorization okay, return token. External Authenticator 6) Access VID 3) “ABC” authenticated 19) Call AnyApp UI Authentication/Authorization (External Authenticator & AAF) API Authentication/Authorization (AAF) CADI & AAF Integration AAF Policies Other Policies CADI ONAP Portal CADI VID CADI MSO CADI AAI CADI SDN-C CADI Any App

AAF Capabilities ONAP Applications CADI Framework Certificate Management Fine-Grain AuthZ AuthN Basic Auth CSP Certificate Development Design/Configuration CADI & AAF Integration Step 1: Integrate CADI framework into all ONAP projects Deliver via community in Casablanca release Note: CADI is integrated with AAF by design Step 2A: API Delivery plan (post CADI deliverable) Configure certificate management and certificate-based authentication Define app roles and privileges in AAF or other policy engine Work performed by application SMEs Step 2B: UI Delivery plan (post CADI deliverable) Integrate new UIs to ONAP Portal Define user roles and privileges in AAF or other policy engine Work performed by application SMEs 22 Security Microservice (proposed for Casablanca)

23 Pluggable Authentication and Authorization - Identified Impacts - To ONAP clients (internal or external): (development) Need to integrate client with Authentication Provider to retrieve credential. Note - this could be abstracted via a call to Auth * configured with a re-direct if required? (development) Client needs to provide tokenised credential in REST request to A&AI.To ONAP Services:(development) Need to include the CADI and Authorisation Filters in their filter chains.(deployment) Need to configure CADI client.(deployment) Need to configure authorisation requirements per URI, per service. Note that this can be as fine or coarse as the service provider's project requires.(development) All new or modified microservices need to use the secured REST client to invoke other microservices for seamless and secure propagation of identity and authorisations. Still Work in Progress

24 Pluggable Authentication and Authorization - open issues - Open Issues What happens in the case where there is an overlap between a protocol that CADI already supports and the generic Security Service config? How do we avoid conflicting/confusing configuration for the deployer (and the associated risk of leaving a gap/vulnerability)? We need to agree on a common/preferred representation for the authorisation token(s).Agree behaviour when no token is present/authentication fails - largely aligned.Next StepsComplete Use casesAgree schedule/roadmap for work items (what can be done in Casablanca/after Casablanca) Review/refine proposal with Seccom/TSC. Still Work in Progress

25 ONAP Credentials ONAP_User Credentials ONAP ExtAPI Credentials ONAP Component Credentials ONAP Foreign Credentials

26 Impact Summary Area Impact Comments CII Sliver Badging All projects https://wiki.onap.org/display/DW/CII+Badging+Program?src=contextnavpagetreemode Some issues to solve in tooling Known vulnerability analysisMid/High on all projectsStart EarlySecure communicationProjects to use CADI to get certs Pluggable authentication and authorizationProjects to use CADIUse tokenized credentials (client)Need a session with PTLs to explain in detail how to use VNF Package SOL004 securityVNF SDK, SDC,Agreed at TSC in Q1; timing not agreed at TSC.Secure communication to xNFs (Security for 5G Use cases) DCAE, APPC, VFC?AAF (getting certs)https://wiki.onap.org/display/DW/Secure+Communication+to+Network+Functions?src=contextnavpagetreemode

CII Silver Badging Requirements of Concern June 2018

29 CII Silver Badging – “Bus Factor” [ bus_factor] The project SHOULD have a "bus factor" of 2 or more. (bus factor is the minimum number of project members that have to suddenly disappear from a project ("hit by a bus") before the project stalls due to lack of knowledgeable or competent personnel.) Does each ONAP project have at least two project members with sufficient knowledge of the code?

30 CII Silver Badging - Testing [ automated_integration_testing ] An automated test suite MUST be applied on each check-in to a shared repository for at least one branch. This test suite MUST produce a report on test success or failure. [test_statement_coverage80] The project MUST have FLOSS automated test suite(s) that provide at least 80% statement coverage if there is at least one FLOSS tool that can measure this criterion in the selected language. Many FLOSS tools are available to measure test coverage, including gcov /lcov, Blanket.js, Istanbul, and JCov. Note that meeting this criterion is not a guarantee that the test suite is thorough, instead, failing to meet this criterion is a strong indicator of a poor test suite. Can the ONAP projects support the requirements for testing on each check-in?Can the ONAP projects develop code and create test suites with 80% statement coverage?

31 CII Silver Badging – Enforcement of Coding Style Guides [ coding_standards] The project MUST identify the specific coding style guides for the primary languages it uses, and require that contributions generally comply with it. [ coding_standards_enforced ] The project MUST automatically enforce its selected coding style(s) if there is at least one FLOSS tool that can do so in the selected language(s). Are the ONAP projects following coding style guides today?Can this be enforced for Casablanca?

32 CII Silver Badging – Removing Deprecated Interfaces [ interfaces_current] The project SHOULD avoid using deprecated or obsolete functions and APIs where FLOSS alternatives are available in the set of technology it uses (its "technology stack") and to a supermajority of the users the project supports (so that users have ready access to the alternative). Will this requirement result in substantial code rewrite?

33 CII Silver Badging – Cryptographic Signing of Releases [ signed_releases] The project MUST cryptographically sign releases of the project results intended for widespread use, and there MUST be a documented process explaining to users how they can obtain the public signing keys and verify the signature(s). The private key for these signature(s) MUST NOT be on site(s) used to directly distribute the software to the public. Are there plans to support release signing? How difficult is it to enforce?

34