2020-06-02 Security Subcommittee Meeting Notes (under construction)

Owned by Paweł Pawlak
Last updated: Jun 04, 2020
2 min read

Please find below the Minutes of Meetings and recording for the  SECCOM meeting that was held on 2nd of June 2020.

Jira No

Summary

Description

Status

Solution

Jira No

Summary

Description

Status

Solution

 

SECCOM Non functional requirements for Guilin release 

Wiki to be updated by each requirement leader by 27th of May. Additionally Jira requirement Epics will have to be created.

Java and Python upgrades were putted in the separate requirements..

Following the SECCOM meeting on 17th of March we agreed on the following draft requirement:

  1. common place for data - all applications should generate logs that can be collected by Kubernetes (rtarget for G release)

  2. common format for data - format of minimum data that we want that is usefull (target for H release)

All logs from applications should be stored in STDOUT.

3 kind of logs: debug, regular and auth. They have different types of information.

For centralized logs collection STDOUT might not be sufficient, so there should be continuation from there to some external system.

Natural channel would be syslog and then to send it somewhere else. 

Ongoing

Natacha to add Fabian;s requirements.

Krzysztof and Tony to update theirs as well.

 

Synch with Architecture Subcommittee.

No presentation scheduled this week at the Architecture Subcommitteee meeting for Service Mesh PoC.

 

 

 

Security Guideline Documentation 

Hrarald is very occupied. and proposed to run meeting once content update is possible.

 

 

 

CII Badging requirement

Tony shared REQ-223 from Frankfurt release.

Assurance case. Built on top of other security requirements. Documentation security is one of the basis - what consumer of the project may or may not expect from the project.

Assurance case takes basic requirements and presents in a way: this is how we implement it , in other words: what shouldhappen, it does happen.

AAF is a good  example. Thanos is applicable to many ONAP projects.   

We shoud have a general document on ONAP security within next few months.

Distinction between run and design time. In the run time a lot of discussion within ONAP. In the design time which is very project specific they need to share what they did.

3 types of ONAP applications:

  • facing ONAP user

  • fully internal (just communicating with other ONAP components)

  • communicating with VNF

So we have 3 groups of documentations, where most of the stuff will be common.

 

 

 

 OUR NEXT SECCOM MEETING CALL WILL BE HELD ON 9th OF JUNE'20.