2023-11-30 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

• https://folio-org.atlassian.net/browse/SECURITY-9

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

    • We need to figure out if the SYSTEM_USER_NAME specified in application.yaml is actually used, or if it can be removed.

    • See comments above about removing folio-spring-system-user dependency from edge-common/edge-common-spring.

  • PR open and approved for edge-courses, but hasn't been merged yet.  Left a comment in SECURITY-9 asking the dev team lead if there's something preventing a merge.

  • Marked as "security-reviewed" and Accepted

<5 min

Confluence Security Issue (Ransomware)

Team

Anything we want to discuss here?  Do we want to get additional details from Peter?  Invite him to discuss next week?

• Where there any data leaks?  Is there a way to tell?

  • User information/credentials

  • Database connection details/credentials

• @Axel Dörrer will follow-up with Peter.

• Do we want/need to force users to change their passwords?  Rotate/change the DB credentials?

Today:

• Update from @Axel Dörrer :  

  Good news on that issue. Peter has confirmed that Confluences' had just a limited number of allowed operations to Jiras's User Directory , which means we're good regarding leaked user credentials.

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.

• 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.

Today: