Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 23 Next »

Overview

Recent events have shown that formal policies and processes need to be put in place for handling of security issues.  This spans the entire process, including but not limited to: reporting a bug, triage and risk assessment, implementing fixes, cutting releases, and making announcements.  The plan is to form a group to discuss and draft these policies/processes and present them to the Technical Council (TC).  

Who

The aim was to comprise this group with diverse representation to get as many viewpoints as possible.  At the same time we're aiming to keep the group on the small side to keep things moving, mitigate scheduling conflicts, etc.  

NameRepresentation
DevOps
Developers
Developers
SysOps
SysOps
Tech Council / Developers
Developers
Platform PO / Acrhitects
SysOps
UI Developers
UI Developers
Tech Council / Architecture
FOLIO Implementation
Peter MurrayTech Council / Open Source Community

When

Each Monday Starting October 7, 2019 - 11:00 - 12:00 ET in the "#security_policy_group" slack channel.

Security Policies and Processes.ics

How

Details are still TBD but so far the plan is to try to meet next week (10/7) and go from there.  Ideally we can come up with a rough draft or outline from this first meeting with most of the high level decisions being made, and schedule additional meetings to refine as needed.  

Proposed agendas:

10/7/2019 (Kickoff)

  • Introduction & Goals (5 min)
  • Quickly review the very high-level proposal from the TC (5 min)
  • Create a bullet list / outline of policies & processes (~40 min)
  • Start formalizing the outline into one or more policy documents (time permitting)

10/14/2019

  • Review comments left in the notes section and refine
  • Goal:  Have a strawman in place to review for on 10/21

What

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

  • There should be a security team for FOLIO who can review and assess impact ('blast radius')
  • That team decides things like
    • how public/private details of vulnerability are
    • urgency of action
    • Solicit input into specific actions to be taken
  • Determine what the communication channels and timings are for all activity
  • Likely a private/closed list for public installations to receive information about vulnerabilities
  • Establish public policy for Security/Vulnerability patches
  • Also determine which releases are supported going forward.

Notes

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

Links

Several links have been shared already in various conversations about this - these might be helpful as models or just as reference.

  • No labels