Please see the Minutes of Meetings and recording for the SECCOM meeting that was held on 5th of November 2019.
| Jira No | Summary | Description | Status | Solution |
|---|---|---|---|---|
OJSIs summary for El Alto release: | Krzysztof summarized projects and their attitude towards OJSIs security tickets handling: Still 38 OJSI tickets related to HTTP open while we expose only ~20 HTTP ports. We can close almost half as soon as we get the commit hash-id Worst performing projects
Could be improved
Please follow them
|
| Jira | ||||||||
|---|---|---|---|---|---|---|---|---|
|
Initiate a work item for Security Architecture documentation
- secure communication targets for Frankfurt
- Authn/Authz architecture
- PKI
- Communication matrix
Harald has created a wiki page based on F2F meeting
| Jira | ||||||||
|---|---|---|---|---|---|---|---|---|
|
ISTIO work in Frankfurt
-Intel completed a POC for ONAP4K8S profile and will continue that for R6
-SDNC fix for the 3 remote code execution vulnerabilities through integration with AAF
-Release management help projects manage OJSI resolution – determine resource needs, track progress, raise issues
Need Release Manager support for both activities
| ONAP security maturity assessment | Discussion held at the last PTL call yesterday PTLs claim that are missing qualified security experts Idea of SECCOM badging provided per project and per release – discussion point SECCOM is perceived as group of people pushing PTLs and community to do some security related stuff while it should be the other way around: PTLs are asking SECCOM how they could improve their security. SECCOM is not about project management and motivating people to do the security. We should introduce security badging or levels for ONAP projects and sit down together and define what are the requirements for each and every elevel, present those requirements to the projects and at the end of each release to perform the asessment and publish on the release of the project page the list of the projects with their current security status. KPIs defined with release security maturity should be used. CII Badging combines multiple areas, including security. To ny proposed cathegorization of CII Badging questions in the security domain to see what would be the scoring for projects within identified cathegories. As Natacha has stated, CII Badging is not exhaustive list of all security requirements. Krzysztof mentioned that several topics are not covered within CII Badging – like is project exposing anything else that Restful API? And most of the projects are exposing DBs outside their cluster or access restriction on all interfaces, or usage of AAF for users management. So Krzysztof confirmed that from his perspective CII Badging is a starting point and we should define 3-4 security levels. Amy suggested that we should target to projects on what they need to concentrate on. Between release manager, SECCOM and TSC we should decide which requirements are specifically important for the release. Krzysztof shared a point of view that SECCOM presents requirement to TSC and PTLs and then PTLs are trying to fulfill the requirements, when they believe that they are ready to achieve an another level of security requirement for SECCOM badge, they just come to the SECCOM meeting and present what they have done and how they fulfill it for the new level. Then SECCOM checks that and decide whether badge can be delivered. It was proposed and agreed that we document this proposal and come back to PTL and TSC meetings for a feedback and approval. This change is targeted for the G release. | It was agreed to continue discussion in 2 weeks time frame. SECCOM members are requested to provide their feedback. | ||
| Increased tests code coverage for future ONAP releases | Pierre's proposal: -define, for each project, the core parts that need intensive testing (an API sensitive project might prioritize API testing so that all are covered, hardened, so that said APIs are robust) -concentrate coverage on those areas, even if coverage is lower on other parts, so critical parts are better covered and tested. This might improve OJSI resolution (and/or reduce findings), and better focuses the effort on testing based on available resources. This would be even better if we could tell Sonar which parts of the code are the critical ones | It was agreed to continue discussion in 2 weeks time frame. SECCOM members are requested to provide their feedback. | ||
| Synch meeting with Architecture Subcommittee | The meeting is scheduled today (5th of November at 4 PM UTC+1). Scope for the discussion: -Ingress controller (Krzysztof) -Security architecture document (Hampus) -ISTIO/AAF discussion (Hampus/Srini) | As Natacha is not available, we will cover communication matrix topic for the next synch meeting. | ||
Vulnerability management update | Still waiting for inputs from some projects. Conclusion: in order to decrease the size of the vulnerabiliity tables, the easiest way is to keep the latest versions of components. | |||
Frankfurt SECCOM requirements | Most of the projects already updated their descriptions | To be further confirmed if all descriptions are present. | ||
Nexus-IQ vs. Whitesource benchmarking | Strange results for vulnerabilities – to be consulted with Renan – still waiting for his feedback and Dan’s assessment completion for effective/ineffective | |||
| ONAP customized ODL compilation | ODL – Dan contacted Luis for customized package – for both El Alto and Frankfurt releases ONAP is using OpenDaylight Neon SR1. So, Dan would like the distribution that ODL provides for ONAP custmomized version based on the Neon SR1. | |||
SECCOM meetings timeline | AAF and Architecture Subcommittee timing dependencies to be taken into account, some SECCOM members prefer this modified slot (due to daylight savings change) |
-Known vulnerabilities analysis - ongoing
-Synch with Portal team on their components upgrades – it seems that only few were upgraded – feedback from Portal team received under jira ticket.
-OJSI tickets tracking – Jim/Pawel/Krzysztof/Amy
- OJSI Dashboard - Krzysztof
- Krzysztof investigating the optimal way to incorporate the test
-CII Badging updates – first positive feedbacks
-Communication matrix – ongoing exchanges with Vijay – Krzysztof’s scripts would be very helpfull (both local host and external world)
-Recommended upgrades – see presentation
-Nexus IQ vs. Whitesoftware
- Waiting for Dan’s feedback for effectice/ineffective
- Waiting for Renan’s analysis for WS results – work ongoing
- LFN is willing to add all ONAP projects under WS jenkins jobs
-ODL synch meeting was finally organized on 10th of October – MoM were prepared and shared with participants: 1. Dan shared the link to ONAP ODL MVP, 2. Luis will now compile the package based on MVP scope to avoid potential issues with licensing.3. Once ODL customized package is shared with ONAP (Dan), Jessica will work on preparation of Jenkins jobs with Nexus-IQ scanning, 4.Once it is done Amy will create vulnerability tables and we will organize a next call with ODL team to review findings, discuss priorities and assess whether it is ODL or upstream vulns.
-What do we do with MSB or other kind of projects? – security implications…
- Meeting with Huabing from MSB was done – action was agreed on his side to contact VFC and Multicloud projects to synch on
Action with TSC was taken! List of projects with lack of reaction on security best practices to be provided.
Alpine recommended version
Jonathan suggested to have Alpine with JDK 11 embedded.
E-mail was sent to Morgan and Brian for consultancy.
Synch call with SDNC for OJSIs
| View file | ||||
|---|---|---|---|---|
|
...