2022-01-27 Meeting notes

Date

Attendees


Goals

Discussion items

TimeItemWhoNotes

Recap on Log4shellAll
  • Time to make the fixes took to long
    • Consider to make a person from the core platform responsible to drive these fixes
    • Someone from stripes team should be the same for front end issues
  • It was not clear what release is needed to be fixed. LTS is needed to be defined
    • New group has been set up to define this
    • Should reach out to the new group for the status and see if they want somebody from the security team → Jakub Skoczen has take this on
    • Need support statement for other releases
  • Took too long to respond
    • When is the security team responsible to react? On direct messages or should we scan several channels? ← Need to define this more clearly to the Charter
    • Should be a group effort
    • Need to provide some guidance to community questions / concerns
  • Postpone retrospective board until Craig is back

Today's discussion:

  • When one of us is alerted to a security issue, we should raise it in our internal slack channel and start a discussion/triage.  Once the risk and impact have been assessed we should communicate to the interested parties that the security team is aware of the problem and that additional guidance will be forthcoming (ideally with some timeframe).
    • Where will the communication be sent?
      • for log4shell we wrote to a number of different slack channels:  #sys-ops, #development, #releases, etc.
      • #sys-ops channel, others as needed.
      • the applicable/appropriate slack channel(s).
        • To be determined during triage/acknowledgement discussions/meetings.
    • How is the triage performed?  On slack?  Hold an ad-hoc meeting?  Something else?
      • Should be handled on a case-by-case basis...
        • in some cases we'll have a CVE and the impact/risk is pretty clear.
        • In other cases we might need to do some research
      • Really the how depends on the situation, but slack and ad-hoc meetings will work most of the time.
    • When do we owe an ack?
      • Always send an ack to the reporter ASAP 
      • Additional communication depends on the risk/impact...
        • P1s - ASAP
        • P2s - If people are asking about it, we send out an ack.  If not, can be handled via board review.
        • > P2 - explicit acknowledgement not required.  Can be handled via usual board review.
    • When do we owe additional guidance?
      • P1 - ASAP, but sooner (2 business days - subject to change)
      • P2 - No later 1 week
      • > P2 - no expectation of explicit guidance - researching may be delegated to dev teams, etc.
      • If the security team doesn't have additional guidance to provide within this timeframe, they will send out a message with an update.
        • e.g. we're still researching and will provide additional guidance soon.
    • Who will do the communication?
      • Someone on the security team - who depends on the availability of the security team members.
        • Sort this out on a case-by-case basis.

ACTION:  Axel Dörrer  to work this into the FOLIO Vulnerability and Remediation Policy and the security team will review the draft once ready.

5 min

Update on FOLIO-3317 - Getting issue details... STATUS  

Axel
  • Some progress here, but not across the board... Check back next week.

*Review the Kanban boardTeam
Nothing urgent will come back to that next meeting


3 minUpdate on polkit Julian

Two JIRAs were filed, and already closed.  We're not vulnerable.

Action items