2023-11-02 Meeting notes

@Craig McNally 

@Julian Ladisch 

@Axel Dörrer 

@Ryan Berger 

@Chris Rutledge 

@Jakub Skoczen 

@John Coburn 

@Skott Klebe 

?

Anything Urgent? Review the Kanban board?

Team

• SECURITY-9: Secure setup of system users by defaultCompletedPreview

  • @Craig McNally  will investigate/reach out to devs for:  edge-courses, edge-fqm, and mod-consortia

    • Created story for mod-consortia and linked it to SECURITY-9

    • edge-fqm/edge-courses:  the edge-common-spring framework apparently has a runtime dependency on the folio-spring-system-user library (due to dependency injection?).  I've reached out to Taras to see what we can do about this, but he's on vacation.  Circle back next week.

      • No update from Taras yet.  @Craig McNally will check with him and report back in Slack.

  • @Axel Dörrer will do the same for the other 4

    • Has created some, e.g. MODCON-114: Secure setup of system users by defaultClosedPreview

    • mod-caiasoft, edge-dematic, edge-inn-reach, edge-dcb still don't have JIRAs.

• We reviewed several isues.

• Started to review the SECURITY issues filed yesterday, but ran out of time.

  • @Julian Ladisch will continue to take a first pass at these and we will revisit next week.

10-15 min

Critical & High Vulnerabilities Identified by EBSCO scans

Team

• EBSCO has started using a commercial tool (Prisma) for vulnerability scanning.

• This is needed for LoC / FedRAMP compliance.

• The most recent scan has found numerous vulnerabilities related to outdated dependencies

  • Many are related to Spring and will be addressed when teams upgrade to Spring (3.2.x?)

    • I believe this is planned for Quesnelia.  Need to double check though.

  • Excluding those we're looking at ~20 Critical and ~130 High vulnerabilities

  • The open question is whether or not any of these should be embargoed.

• Critical (the ~20 are some combination of the following in various modules):

  • While these are probably P1s, I don't see anything that screams "must embargo".  Let's discuss.

    • org.yaml_snakeyaml - https://nvd.nist.gov/vuln/detail/CVE-2022-1471

      • We triaged this a while ago, see SnakeYaml SafeConstructor

      • If there are modules which Prisma found and Snyk missed, maybe we should embargo those JIRAs since this is an older vulnerability and is therefore more likely to be exploited.

      • We need a list of modules so we can make an assessment.

      • Create an umbrella JIRA, listing the affected modules.  We can then create module-specific JIRAs as needed.

    • org.apache.commons_commons-text - https://nvd.nist.gov/vuln/detail/CVE-2022-42889

      • We need a list of modules so we can make an assessment.

      • Create an umbrella JIRA, listing the affected modules.  We can then create module-specific JIRAs as needed.

    • com.fasterxml.jackson.core_jackson-databind - https://nvd.nist.gov/vuln/detail/CVE-2018-14721

      • This one is less clear to me.  Need to dig into it and discuss

      • Applies to:

        • mod-licenses

        • mod-oa

        • mod-service-interaction

        • mod-agreements

      • From @Julian Ladisch : jackson-databind (CVE-2018-14721): I've investigated both the master branch and the Orchid release branch of the four modules mod-agreements, mod-licenses, mod-oa and mod-service-interaction. Running cd service; ./gradlew dependencies shows that jackson-databind 2.13.4.2 is used. Snyk also reports this version. This is a fixed version. Prisma's version resolution is wrong.

    • org.apache.logging.log4j_log4j-core - https://logging.apache.org/log4j/2.x/security.html#CVE-2021-44228

      • Applies to:

        • mod-bulk-edit

        • mod-aes

      • Both of these modules have been archived/deprecated.  No need to do anything here.

• High

  • Similar analysis is complete.  How would we like to weigh in on whether or not these should be embargoed?

  • See SECURITY-12: CVE-2023-4586 Netty TLS hostname validation. Analysis of vulnerabilityCancelledPreview through SECURITY-26: CVE-2023-5072 org.json:json OOM. Analysis of vulnerabilityCompletedPreview

• EBSCO/EPAM are awaiting our feedback and will create JIRAs for all of these.  Grouping vulnerabilities into fewer JIRAs where applicable

Time permitting

Advice for handling of sensitive banking information

Team

From slack conversation, I think I've gathered the following:

• In this case (bank account and transit numbers), the information is highly sensitive.  

• Highly sensitive information should:

  • Be stored in it's own table

  • Accessed via a dedicated API

  • Protected by a dedicated permission

  • Encrypted in the database, not only on disk.  

    • This could mean either:

      • Explicitly encrypting/decrypting in the application layer and storing the encrypted data in postgres

      • Utilizing postgres extensions/modules to encypt certain columns, e.g. via pgcrypto (see https://www.postgresql.org/docs/current/encryption-options.html)

Let's review and discuss before providing this feedback to Raman.

@Axel Dörrer also suggested that defining classes of sensitivity could help teams determine which techniques are applicable in various situations.  I agree having some general guidelines on this would be helpful.

• regular data

• low sensitive - permission based on same API

• high sensitive - permission based on dedicated API

It would probably help to provide concrete examples of data in each class.  This can be a longer term effort, we don't need to sort out all the details today.

Today:

• Next Steps:

  • Clearly define/formalize the various classes

    • Come up with concrete examples of each class

  • Build out guidance

    • Come up with concrete examples of how to protect each class of data.

  • Consider storing some classes of data outside of postgres altogether - e.g. in secret storage.

    • What would be the guidance we provide to teams for this so we don't end up with each team doing things differently?

    • SecretStore interface and existing implementations are currently only read-only.  They would need to be extended to allow for creation/mgmt of this information.

  • Craig to start a conversation in slack about this.

    • Seeking a volunteer to generate a draft document for us to review at a later meeting.