Page History

Know Secure Design 

Just wording change:

1. This requires understanding the following design principles, including the 8 principles from Saltzer and Schroeder: 

1. Might be better to say something like “This requires understanding the secure design principles, including the 8 principles from Saltzer and Schroeder:” 

Larger comment 

• Those all sound like solid principles. If you wanted to tie this to current USG activities, there is NST’s Secure Software Development Framework (SSDF).  
• https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-218.pdf + https://csrc.nist.gov/publications/detail/sp/800-218/final 
• This document highlights a core set of high-level secure software development practices. 
• For example, for their “Produce Well-Secured Software”, they bring up the suggestion of using forms of risk modeling for assessing the security risk and using standardized security features and services instead of creating proprietary implementation. (It’s just talking at a slightly different level than the Slatzer and Schroeder list) 

Implement Secure Design 

• Our experience has taught us the criticality of documenting the secure design practices and software design/coding standards and code review. The SSDF also provides additional details. 

Crypto Call – Generic 

• Maybe there should be guidance on how to use specifications on implementing secure crypto functions 

Crypto Random - Generic 

(NIST SP 800-90C)

• I think giving the developers a little more guidance about what kind of specification to rate a Random Bit Generator (RBG) on could use this - https://csrc.nist.gov/publications/detail/sp/800-90c/draft 

90C is about putting various pieces together (entropy source and the "pseudo-random number generator" PRNG). 90A has the PRNG algorithms. 90B has testing requirements for entropy sources.

https://wiki.onap.org/display/DW/ONAP+Security+Review+Questionnaire+Template

Muddasar will prepare grade rate assessment proposal.

Welcome on board Alexander from Samsung. Major interests:

• SBOM - SPDX (more uniform and slower in development) vs. CycloneDX (lot of plugins - hard to uniformity consume those SBOMs), SECCOM preference is SPDX and since Thursday it is configured in JJB. One flag needs to be changes from false to true.
• ONAP container image signing - it should be done. But there is not industry de facto standard: 2 projects:
  • Notary v2 may support SBOM https://github.com/notaryproject/notaryproject/blob/main/scenarios.md
  • CoSign under sixdoor includes SBOM into the container

Ticket to be opened by Alexander to LFN-IT - done

https://jira.linuxfoundation.org/plugins/servlet/theme/portal/2/IT-23764# ticket created

E-mail about SPDX SBOM configuration to be shared by Muddasar with Alex.

ONAP Jakarta: Vulnerable Package Upgrades - Amy

Maggie merged the changes on the Wiki. Tony's comment to keep naming convention from headings as it corresponds to Badging questionaire. Most of the changes are usefull. Thank you Maggie!

Muddasar will prepare grade rate assessment proposal.

Tlhansen.us/onap

For dynamic code analysis the answer from projects should be answered Unmet. We have static analysis buit not dynamic.

Jenkins jobs for SonarCloud configured on a weekly basis - licence level we are using.

Linux Security Summit, happening June 23-24 in Austin, Texas + Virtual!
Don't delay - submissions are due Wednesday, March 30. View suggested topics, learn more and submit here https://events.linuxfoundation.org/linux-security-summit-north-america/program/cfp/

• We plan to submit with Amy presentation proposal for Global Security Vulnerability Summit
• Tony’s proposal for Security principles in the implementation.

Amy and Pawel to submit proposal.

Tony and Maggie to provide proposal as well

Meeting with Seshu done. SO would like to use https://www.sonarlint.org/ , Looking for IDE expertise.

https://docs.sonarqube.org/latest/user-guide/clean-as-you-code/ - quality code would be for a new code.

Ticket to be opened to LFN-IT to get clarification on SonarLint licensing.

Maggie will check for IDE expertise.

Details on IDE environment (Dual Studio?) to be provided by Fabian.

Out of band planning for issues and topics, technical debt

Target of 10-20% of development capacity on technical debt. This should be discussed at the planning meetings.

El-Alto release was focussed on technical debt. Now we have Global Requirements implemented and reviewed compliance every release.

We first focussed on Java and Python upgrades, but also to take all of the interfaces to support HTTPs, upgrade direct dependencies, or Sonarcloud findings that are security related that are critical to be fixed. Other activity is code quality improvement.

ODL allignement is managed by Dan who does the upgrade based on what is available on ODL side.

Mainly requirement coming from security point of view are the recurring ones (every 6 months cycle), except for code quality improvement requirement.

Log4j was a good example of out of band planning, extraordinary event that we responded.

The meeting on March 7th was focussed on fixing the issue with Maven which was resolved.

There are no other meetings scheduled.

.

SECCOM MEETING CALL WILL BE HELD ON 5th OF April'22. 

Quality gates for code quality improvements - Fabian's presentation.

5Y review criteria - finalization of the proposal.

SonarCloud fixing with new code focus.