Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Jira No
SummaryDescriptionStatusSolution

Meeting with Huabing - OJSIs update

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

OJSI-204MSB 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.

Comment for this Jira was updated.

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.


Meeting with Vijay - OJSI update

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

OJSI-116xdcae-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

Comments for those Jiras were updated.



It was agreed that Krzysztof will check with Morgan and Vijay the impact of changing into TLS at post M4 stage.


Meeting with Seshu - summary



Guilin SECCOM priorities - review

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

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

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

List was already presented to PTLs, no specific feedback. Next to be presented to TSC.

.

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.


SECCOM chair and vice chair electionsConfirm that the correct voting member for your company is on the Security Sub-committee Members listStill waiting for Kenny's feedback Kenny was asked to provide his feedback during the last PTL call - he promissed to respond. Once scheduling is known, will be sent to SECCOM distribution list. 

Secrets encryption

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

Mariadb-galera

In ProgressOngoing work with SO.

VNF Security RequirementsAmy asked for +2 for the reviewed items.Jiras to be updated with comments (+2s) from Pawel and Samuli.Amy will work on getting right privilege for gerrit.

Scripts for automatic Jira tickets creation for direct dependency components upgrades

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, 

In progress

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


Upcoming F2F meetings

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

In Progress


 OUR NEXT SECCOM MEETING CALL WILL BE HELD ON 17TH OF MARCH'20


...