2023-11-09 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?).  

    • folio-spring-system-user is used for login API calls. 

    • We should probably ask that edge-common-spring is updated to remove the dependency on folio-spring-system-user.

      • @Craig McNally  will follow up with Taras and get the story created...  Also ask about the other modules (dematic, caiasoft, etc.) see below.

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

<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?

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.