2021-11-09 Security Subcommittee Meeting Notes

SECCOM weekly scheduling/timing

We start every Tuesday at 1 PM UTC (currently 2 PM CET)

done

Outlook invitation update was sent as well as an e-mail informing about the meeting to start in 5 minutes. 

Istanbul security improvements - press reelase proposal

Security is part of the ONAP DNA. The community continued to improve the security of the platform by continuing the migration from Java 8 and Python 2 to Java 11 and Python 3. Approximately 550 security and code quality issues in the ONAP developed code were fixed.  Additionally, open source dependency upgrades removed nearly 700 known vulnerabilities. In the effort to shift security further left, a proof of concept was performed that integrates security and code quality tests into the merge process. Unused and unmaintained repos were removed from the release. Finally, a uniform set of security events to be logged and data about the events were defined and will be staged into ONAP beginning with the Jakarta release.

ongoing

Requirements Subcommittee session 

Requirements Subcommittee session held yesterday:

• Jakarta SECCOM requirements presented (Bob, Amy, Pawel), no specific comments received

ongoing

PTL meeting update

Software BOMs presentation by Muddasar.

Feedback from Krzysztof Opasiak

ongoing

To be further discussed next week.

TSC meeting update

• SECCOM presentation on Istanbul achievements by Amy

• Nov 15 PTL meeting as a new date for Istanbul release sign-off

• Nov 18th – presentation of non-functional requirements to TSC

ongoing

ONAP code quality improvement 

Update from Toine – ok from the team, questions to be clarified.

ongoing

 Kevin to be contacted

Weekly and daily testing by Integration team

• Weekly: https://logs.onap.org/onap-integration/weekly/onap_weekly_pod4_istanbul/2021-11/05_20-31/

  • framework-artifactbroker – java version both 8 and 11

• Daily: https://logs.onap.org/onap-integration/daily/onap_daily_pod4_istanbul/2021-11/08_13-01/

Open

ongoing

Are the filebeat containers included in the release?

Kubescape comparison

https://docs.sonarqube.org/latest/user-guide/security-hotspots/

This is for security testing - results to be compared. Exception file support under consideration as might not be supported at the very first step.

ongoing

Integration with exception file to be developed.

Quality improvements in Istanbul release

• sdc

  • Security hotspot : 1

  • Bug Major : 100

• aai

  • Security hotspot : 97

  • Bug : 74

  • vulnerability : 29

• dmaap-messagerouter-dmaapclient

  • Security hotspot : 10

  • Bug blocking : 17

  • Bug critical : 63

  • Bug Major : 119

completed

Hot spot definition

• A Security Hotspot highlights a security-sensitive piece of code that the developer needs to review. Upon review, you'll either find there is no threat or you need to apply a fix to secure the code. Another way of looking at hotspots may be the concept of defense in depth in which several redundant protection layers are placed in an application so that it becomes more resilient in the event of an attack.

• Vulnerability or Hotspot? The main difference between a hotspot and a vulnerability is the need of a review before deciding whether to apply a fix:

  • With a Hotspot, a security-sensitive piece of code is highlighted, but the overall application security may not be impacted. It's up to the developer to review the code to determine whether or not a fix is needed to secure the code.

  • With a vulnerability, a problem that impacts the application's security has been discovered that needs to be fixed immediately.An example is the RSPEC-2092 where the use of cookie secure flag i.

• Why are Security Hotspots Important? While the need to fix individual hotspots depends on the context, you should view Security Hotspots as an essential part of improving an application's robustness. The more fixed hotspots there are, the more secure your code is in the event of an attack. Reviewing Security Hotspots allows you to:

  • Understand the risk – Understanding when and why you need to apply a fix in order to reduce an information security risk (threats and impacts).

  • Identify protections – While reviewing Hotspots, you'll see how to avoid writing code that's at risk, determine which fixes are in place, and determine which fixes still need to be implemented to fix the highlighted code.

  • Identify impacts – With hotspots you'll learn how to apply fixes to secure your code based on the impact on overall application security. Recommended secure coding practices are included on the Hotspots page to assist you during your review.

• Source: https://docs.sonarqube.org/latest/user-guide/security-hotspots/

Reviewing requirements by SECCOM as part of the process. 

E-mail was shared with Catherine. Waiting for a feedback.

ongoing

Kubernetes hardening

Muddasar and Bob provided some feedback to NSA team related to logging requirements

OUR NEXT SECCOM MEETING CALL WILL BE HELD ON 16th OF NOVEMBER'21.