Versions Compared

Key

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

...

Jessica will perform SBOM creation - it is in her to do list.

Tony;s friend posted on Github tool that will look into Debain packages.

Presentation to Governing Board in SBOM topic.

Security logging in R-Alliance.

Jira No
SummaryDescriptionStatusSolutionSecuring connection between the Helm Client and Remote Helm Repository (Ramesh/Liam)a subject name

Helm charts to be held locally and these are the only repos you can pull HELM charts from.

Connection authentication services (option 1 and 4) and (option 2 and 3) configurability of destination supported, like a white list. Those 2 layers of security are a better option than single one of them.

Use of HTTPS = authenticated repo that HELM chart would be pulled (consumed). Once authenticated restrictions apply while K8s pulling from repo. Client needs to authenticate the repo that is pulling from. 

Service mesh can handle secure communication and authentication and authorization policies.

Begin with HTTPs connection. From the subject field from the repo would have a subject name that would be validated against white list. So first autheticate (HTTPs) and then authorize (white list). 

It is also crucial to ensure that to push HELM chart to the repo is under control (authentication and authorization. 2 way TLS: client doing a POST would be authenticated by the repo and authorization at the repo level would have to be done based on the subject field of the cert that was passed by the client. 

Mutual TLS enablement to standard client side.

ongoing

Need to address 2 points to avoid supply chain substitution attack:

  1. how do I autheticate I pulled from the right repo.
  2. How can I validate that the repo I pulled from is on my white list.
Byung will discuss service mesh option with Sylvain and OOM team on WednesdayTSC update

Security improvements in ONAP recognized by LFN Governance Board. Big thanks and kudos to SECCOM team, PTLs and all contributors! Over 7000 vulns fixed!

https://security.lfx.linuxfoundation.org/#/

Majority (over 99%) discovered with NEXUS-IQ scans, none? raised by end user.

Documented process: ONAP Vulnerability Management




Process for Security review question for the period of last 5 years
 

Scope to be proposed by Tony and Muddasar (with wider E2E coverage). 

NIST proposal that needs to be reviewed: 

https://csrc.nist.gov/publications/detail/sp/800-53a/rev-5/final

started

Next discussion in 2 weeks time frame.

Pawel to recheck with Catherine for her feedback.








https://jira.linuxfoundation.org/plugins/servlet/theme/portal/2/IT-23423

Log4j upgrade

Log4j Target version 2.17.1 was released. It provides a fix for a vulnerability: https://cvelogging.mitreapache.org/cgi-binlog4j/cvename.cgi?name=CVE-2021-44832.2.x/changes-report.html#a2.17.1

Following tickets opened:

  • AAI-3431 - AAI status (4 components with log4j) COMPLETE
    • aai-graph-admin, aai-resources, aai-traversal, aai-common : log4j <2.17.1 Direct dependencies updated
  • DMAAP-1704 - DMAAP status (1 component with log4j) COMPLETE
    • dmaap-messagerouter-messageservice: log4j <2.17.1 Direct dependencies updated
  • SDNC-1655 - SDNC status (1 component with log4j)
    • sdnc-oam: log4j 1.2.17 Direct dependency -> Dan created a ticket for an upgrade in Istanbul with low priority (https://jira.onap.org/browse/SDNC-1591) – “data-migrator needs to be migrated from log4j to log4j2 - which mostly entails just updating properties file and command line arguments in run script. Note: data-migrator is not currently used”. I have increased priority to high and added fixed version: Istanbul Maintenance release + comment under the ticket on the need to migrate to log4j-core 2.17.1.
  • VNFSDK-827
  • With Istanbul maintenance release branches and CLM Jenkins jobs configured in jjb file, next round of log4j focussed scans and analysis.
  • Demo of CLM scans for Istanbul Maintenance was done. - VNFSDK status (1 component with log4j)
    • vnfsdk-ves-agent: no scans for Istanbul branch -> as per Kanagaraj’s email sent on 24th of August, he mention that vnfsdk-ves-agent is not an active VNFSDK repo, so I have sent him an e-mail today to configure his jjb file accordingly.
  • Restricted Wiki for Istanbul Maintenance release created
  • CVE creation: no need to do it, simply we will document in the Release Notes repos that were impacted and fixed (direct) and document transitive dependencies. CVE is raised for vulnerability discovered in the code.
  • ONAP CVEs opened so far: https://docs.onap.org/projects/onap-osa/en/latest/osalist.html
ongoing

To check with Jess statuses of the tickets that were recently closed.

CLM scans per each project to be done by 4th of February.


Update of https://lists.onap.org/g/onap-security/members - updated listList of the participants to be was updated with Maggie. Krzysztof was removed.doneStill waiting for Krzysztof's feedback.CVE creation for ONAPKrzysztof proposed he will issue CVE for ONAP vulnerable to log4j release. ongoingTrying to reach out Krzysztof. If someone else knows the process, help is welcome (Muddasar might help as plan B).

Log4j CVEscould be checked here: https://mvnrepository.com/artifact/org.apache.logging.log4j/log4j-coreongoingSonarcloud API documentation

Following our last discussion ticket was opened to LFN IT (https://jira.linuxfoundation.org/plugins/servlet/theme/portal/2/IT-23519 ) to get the SonarCloud updated API documentation

ongoingTicket to LFN IT to be commented by TonySBOM creation Jess created a ticket whichis in progress but now occupied with Nexus3 issue.ongoing

Security logging next steps

Bob presented phased approch for security logging which was consulted with SECCOM team.

ONAP Security Event Management

ongoingMeeting on Friday at 3 PM UTC to be organized  by Amy to have a working group session with Fiachra, Toine, Sylvain.

ONAP quality gates 

Quality asessment mainly for the submitted code (=delta)

  • Integrate tests with CPS
  • SO PoC
ongoing

Pawel to recheck with Seshu.

Pawel to point Toine.

SBOM generationongoing

Link to be shared by Tony.

no update

Waiting for a feedback from Seshu.


SECCOM MEETING CALL WILL BE HELD ON 1st 8th OF FEBRUARY'22. 

Security logging next steps - timeline

Quality gates for code quality improvements - continuation of the discussion.

SBOM next steps - status update with DCAE.




Recording: 

View file
name2022-02-01_SECCOM_week.mp4
height150


SECCOM presentation:

View file
name2022-02-01 ONAP Security Meeting - AgendaAndMinutes.pptx
height150