...

• Review the revised document
• Discuss feedback from TAMU's security professional (if available)
• Goal:  Address feedback and add final touches before presenting to the TC

11/11/2019

• 30m - Vetting Trusted Parties
• 30m - Accompanying recommendations - Related things that don't belong in the policy document, but we want to formally suggest to the TC and/or Security Team (once formed)
  • Public-facing documentation: reporting process, policy document, etc.
  • Highlight the need for a support policy
  • Any volunteers to pull this together?
• Goal:  Address these two remaining issues and wrap things up.

What

Proposals/options taken straight from the TC meeting notes - a place to start:

...

• 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?
      • Sign up with security@duke.edu vs joe.shmo@duke.edu ? 
      • needs to be clear how to get on this 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 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)?

...