2024-02-22 Meeting notes

@Craig McNally 

@Julian Ladisch 

@Axel Dörrer 

@Ryan Berger 

@Chris Rutledge 

@Jakub Skoczen 

@John Coburn 

@Skott Klebe 

5 min max

Tenant Id restrictions (Revisited)

@Julian Ladisch

See slack https://folio-project.slack.com/archives/G013F3AL508/p1708613107682849

if needed schedule a follow-on discussion

25-30 min

Anything Urgent? Review the Kanban board?

Team

• 3 new SECURITY issues related to XSS vulns...

  • https://folio-org.atlassian.net/browse/SECURITY-98 XSS vulnerability in Staff slips

  • https://folio-org.atlassian.net/browse/SECURITY-99 XSS vulnerability in Notes

  • https://folio-org.atlassian.net/browse/SECURITY-100 XSS in Inventory (Holdings/Item -> Electronic Access)

• Our kanban board has a swimlane for "no team assigned".  There's only one Jira there which is essentially a test issue.  I don't see an option for setting the development team on that particular issue.  We need someone to investigate.

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:

@Axel Dörrer to do a first draft as a base for further discussions

Status on pentesting works within Network traffic control group

@Axel Dörrer 

Due to some absences on different reasons the group stalled. Axel will try to reactivate the group.