DCAE Security Enhancement

https://wiki.onap.org/display/DW/Security+Levels

Level Definitions

• • 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 using CADI framework.
    • 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 level
      • Non-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 level
        • internal/external system communications shall be able to be encrypted
    • Level 3: 70% of the projects passing gold 
      • with non-gold projects achieving silver level and achieving 80% towards gold level
    • Level 4: 100 % passing gold.

Minimum Levels (Dublin)

• Platform Level 2
• Additional recommendations: 
  • All projects SHOULD migrate from the Jackson Data Processor packages to the GSON packages unless the Jackson dependency is inherited from an outside project such as ODL.
  • All projects SHOULD provide the ability to turn on and turn off Secure communication. Secure communication is on by default.

DCAE Dublin Security level

------------------------------------------------

EPIC to track DCAE S3P target for security (Casablanca)

 -- 

DCAE will add following enhancement

Buscontroller integration for dynamic topic provisioning and AAF based role setting.  

Securing api/interface and authorization via AAF/certificate (Need further clarification/support from Security/AAF team -  1) CADI library not available for Python 2) Consistent solution for AAF integration not identified (security proposal has many items WIP) 3) Process of AAF certificate distribution in K8S for components not defined and esp for components interfacing with external to ONAP

Impacted Components: VES Collector, DeploymentHandler, InventoryAPI, ConfigBindingService

-Require AAF certificate to be installed by platform (Done in R3)

-Components leverage cert to support API’s via HTTPS (DH, CBS)

-Dependency on AAF library support from python

-Integrate with AAF CADI client for RBAC* (inventory API, VESCollector and HV-VES only)

Affected Component/Project : CLAMP (by DH), xNF (by VESCollector), CLAMP (by Inventory), All MS (by CBS)

Hostlevel certificate vs container/service level?

Secure DMAAP connection

      Impacted Components : Dmaap plugin, Deployment, blueprints for all MS

Impact from other project moving to AAF (requires clients to present AAF TLS certificate)

• Policy Handler (Policy)
• Inventory API (SDC distribution)
• PRH (by AAI, SO)
• TCA (AAI)