Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Need a glossary - definition of relevant terms
  • Dedicated channel for reporting security issues 
    • email to security@folio.org
    • form?  
    • both?  Creates an issue in JIRA automatically?
    • Directly in JIRA?
    • Multiple ways!
    • Needs to be clear how this is done.
  • Security team needs to be formed 
    • Who comprises this team?
    • Distribution of security issues to wider (trusted) audience 
      • How do you get onto this distribution list?
      • Immediate(?) notification of the community (limited detail w/ score or risk level) 
      • What level of detail are we disclosing here?  Full disclosure; Access to the reported issues?
      • Julian Ladisch disagrees with keeping security issues private that are in third party software (PostgreSQL, vert.x, linux kernel, ...) that FOLIO uses and where a vulnerability has been published because anyone can take FOLIO source code and check whether it uses third party software with known vulnerabilities. FOLIO should immediately disclose those issue on issues.folio.org; then the general public can watch how FOLIO handles it.
    • Triage and risk assessment?  Any good examples of criteria - ( low / moderate / high ) risk or impact?
      • https://en.wikipedia.org/wiki/Common_Vulnerability_Scoring_System
      • Investigation - reproduce reported issue, assess scope
        • A working proof of concept (PoC, exploit) that runns runs against a full FOLIO installation is not required to reproduce the issue, a unit test or code review is sufficient. Often it is more easy to fix the issue than writing a PoC. An issue is valid and should be fixed if it cannot be exploited in the current FOLIO version but may become exploitable in future versions.

        • App-specific, or system-wide?
        • Frontend or backend?
        • Hosting or Software? 
        • Is it possible that sensitive information (e.g. PII) is exposed?
        • Priv. escalation issue?
        • Affected versions?
      • Retroactively assess risk of previously reported security issues - practice and will give an idea of how it works with the types of things that might be reported
      • risk/impact → priority mappings
    • Involve responsible team...
      • Try to limit audience if possible
      • All modules NEED to have a responsible team
    • Security team works with responsible team to come up with workarounds / band-aids
      • Communicated to wider (trusted) audience
    • Full disclosure - needs to be defined, as well as other levels of disclosure
      • A fix is available
    • Release a fix
      • Backport - how far back?
        • Security team advises which versions should be fixed
        • Which versions are fixed needs to be part of notifications (obviously)
        • Outside the scope of this group:
          • Bug fix release cycle? - Proposal coming soon - next sprint review? 
          • LTS versions?
  • Idea: hire a consultant to help come up with the scaffolding for this?
    • Will we get this sort of feedback from the security audit (TBD)?

...