Page History

Huabing as PTL of MSB joined SECCOM meeting and following OJSI jira was reviewed:

OJSI-204 - MSB exposes unprotected APIs/UIs (CVE-2019-12129) - if MSB is not only a broker but exposes some API that allows to execute some actions - this API should be protected with AA mechanism.

We agreed to document the issue and ask for a waiver for Frankfurt release. Huabing declared to fix this issue in Guilin release.

Huabing will provide a comment with the solution.

Vijay as PTL of DCAE joined SECCOM meeting and following OJSI jira's were reviewed:

OJSI-116 - xdcae-ves-collector exposes plain text HTTP endpoint using port 30235 - prior to Frankfurt release VES collector was using http communication. For Frankfurt VES based on TLS is enabled. In order to preserve backward compatibility http communication is still possible.

OJSI-30 - Unsecured Swagger UI Interface in xdcae-ves-collector - Swagger UI allows to make some calls that contain a lot of information about the service that it is provided unsecured to outside world - no authentication required to access it. for VES TLS authentication is enabled.

OJSI-195 - config-binding-service exposes plain text HTTP endpoint using port 30415 - Jack already submitted the patch to disable the node port, Krzysztof gave already+1 on the review. 

for both jiras (116+30) It was agreed that Krzysztof will check with Morgan and Vijay the impact of changing into TLS at post M4 stage.

We are progressing in a very good direction.

The most important are the issue with CVE assigned - most of them are resolved - just 3 of them in progress (1 SDNC - in worst case admin port will be disabled and 2 APPC - to be followed with Taka).

TSC recommendation is needed. We should identify minimum basline with checklist of security items/best practices that we expect to be met by projects to assess maturity of each component.:

• open CVEs
• no hardcoded passwords
• https only ports exposed

P1:

-Updates of the languages (java from v8 -> 11 and Python 2.7 -> to 3.x) – Interns from LFN could be gained

-Updates of directly dependent software components (Here we are thinking about benefiting from LFN Interns that could support projects in their packages upgrades, in addition the new version of Nexus-IQ is able to display components with direct and indirect dependencies, we should define priorities, release manager should help in coordination between projects)

-Automated security testing – containers not running as root – SDNC example

-Increase the number of CIS Docker Benchmark checks in the Integration healthchecks.

P2:

-Secrets management

-No root access to the DB from main application container Currently we have some pods (i.e. OOF) that require root access to their mariadb-galera instance for main application to work. This is obviously a security issue. Each application should have its own DB account that allows to access only its own DB.

-All config files inside the main container should be ReadOnly There are some weird design like in APPC where main container modifies properties provided by the user at runtime. I believe that application configuration should be read only.

P3:

-Increase of code coverage (to be honest in Frankfurt release it seems that not that much happened – I am not sure if each project proposed % feasible for them and followed the actions to achieve this

-CII badging

P4:

-High Priority SECCOM initiative: service mesh recommendation

-SECCOM initiative: OJSIs to be solved

-SECCOM initiative: https communication

User access management

ONAP MVP

Flow management

Logs management

We shall continue efforts for projects ongoin e.g. connectivity matrix, VNF Security requirments, CMPv2 etc. 

.

Efforts on service mesh to be continued to have a real alternative to AAF which is failing as of today. We hope AAF would be better with new PTL John but service mesh alernative should be explored with: certificates, mTLS, sidecar.

Krzysztof shared his work on removing secrets for Mariadb-galera :

Mariadb-galera

Meeting with Pam was organized by Amy. The best it would be to work on the upgrades around M1 milestone of Guilin release. SECCOM could group vulnerabilities according to criticity into: critical, severe and other groups and provide recommended versions. Support from release manager for coordination between projects is vital. Process for exceptions is in place - in this case project must document why upgrade was not performed, 

https://wiki.onap.org/display/DW/Remediating+Known+Vulnerabilities+in+Third+Party+Packages

Topics proposal:

• Service mesh
• VNF security requirements
• Package upgrade strategy
• Communication matrix
• Password removal continued

As Coronavirus threat is a serious concern, companies to protect their employees starting to ban participation in events like conferences