2019-10-18 - System Operations and Management SIG Agenda and Notes

• Any Introductions ? No.
• Note Taker: Ingolf will take some notes.
• Action Items → not reviewed today

Harry reports that there was a security flaw in Q3.2. One could get full access to the system. The issue was in Okapi, not in one of the modules. Harry informed the SysOps SIG about the flaw. He says, those institutions who are running a FOLIO instance right now have at least one delegate in the SysOps SIG. The bug was critical and had been fixed within one hour, so it was necessary to inform all implementers/SysOps immediately.

The FOLIO Security issues Policy Group - This incident raised the question how FOLIO will handle emerging security issues in the future. There was the call for establishing a FOLIO security policy. A working group of the Technical Council formed. This group has so far met twice. Stephen, Ian Walls, Jo and Ingolf are members of that group. So there is enough communication going on between this group and ours; we don't need a formal liasion or so. The wiki site of the group is Security Issue Policies and Processes group wiki site . The group also communicates via a Slack channel, #security_policy_group.

A trusted group of people - One first though was that emerging bugs should not be disclosed to the public, but to a group of trusted people. So far, the wiki is open to everyone, in the spirit of an Open Source project. Anton offered to use the security policies of the Jira and lock down security issues accordingly, so that only a selected group of people will have access. The question will be, of course, who will be members of this group.

Who will be in the trusted group - Harry has no objections that the SysOps SIG members can become members of that trusted group. Ian Walls suggests that the campuses might have security programs and students involved in these programs might work in that group. This idea is appreciated by the group (SysOps). Phil points out that Cornell has security professionals on Campus and that one might use this as a springboard to get these people involved. Stephen mentions that also TAMU and probably any bigger university has these security professionals on Campus. Stephen says he himself continues to advocate for that position. In general, the group favors the idea to have a group of experts at hand in the FOLIO project, in addition to external professionals.

External professional experts - Stephen proposes to engage a professional firm or a group of information security professionals to set up and enforce a FOLIO security policy. He says it's a complex matter and off the cuff, nobody in the SysOps SIG was able to stand in for that position (of a security professional) or name someone from their institution. We should not go off cowboying on this. Stephen points to the links that he added in the discussion of the TC Security Issue Policies group: https://www.first.org/global/sigs/vulnerability-coordination/, https://en.wikipedia.org/wiki/Common_Vulnerability_Scoring_System and https://www.iso.org/standard/72311.html .

Assessment - One fist thing to do in case of a new know bug is to assess the bug; what is in the "blast radius" of this defect ? Are there remediations to this bug that can be done immedialtely ? Scoring, remediability and disclosure of the bug needs to be handled by a dedicated group of experts.

The discussion seemed to yield that there are at least two trusted groups needed: One with experts who are able to fix the bug, and anotherone with experts to assess, evaluate, review or "score" the bug. And there needs to be communication between these groups. The communication lines need to be clearly defined (who gets told what by whom and when ?). This sounds like we also need someone who monitors the activities of the group / the groups.

Common Vulnerability Scoring System - One of the mentioned links is about a Common Vulnerability Scoring System - CVSS. This is an open industry standard of accessing the severity of the vulnerability of computer systems. It groups the risk assessment by several attributes (complexity, authentication, confidentiality, integrity, availability etc.) and defines scores for several levels (simplest level classification would be: low, medium, high) in each attribute/category. Although this system is very complex, the group unanimously agrees that at least parts of it should be adapted as a FOLIO Security vulnerability scoring system (called "triage and risk assessment" by the TC working grouo).

In general, the group agrees that security issues must not be made public immediatley, in order to minimize risk and give implementers time to fix the problem before it comes into the public focus. The basic question is: Who gets told what and when ?

Policies of other big Open Source projects - Several members of this group have experiences with or knowledge about the security policies of other Open Source projects - Koha (Ian Walls), Drupal, Silver Strive, Apache Struts, Linux (Jo), to name only a few of them. The FOLIO security concept should borrow concepts from these projects. The wiki site Security Issue Policies and Processes contains an extensive link list to the security policy pages of these projects.

Security Assessment of FOLIO - Ian Hardy points out that there will be a Security Assessment of FOLIO (as whole), a group will be hired for this. We should review the charge of this external assessment to inlucde not only an assessment of the FOLIO code, but an include recommendations for FOLIO security policies. The group welcomes this procedure.

FOLIO Bug Statistics Dashboard

FOLIO Quality Dashboard

Harry

Anton

Harry reports about the FOLIO Bug Statistics Dashboard, which was presented yesterday in the Product Council meeting. He shows that the number of reported bugs still grew faster than the number of resolved bugs. This is due to several reasons. One is the go-live of Chalmers, which usually makes a lot of bugs pop up to the surface. Anotherone is the recent Bugfest. Finally, in the early stages of go-live of a large project, it is ususal the the number of reported bugs grows.

In later times, it is expected that the number will not grow so fast anymore and that more and more bugs will be resolved. Also, it is expected, that the severity of the defects will decrease in the course of time.

In the UI module, there a more bugs, while in the newer modules, there are only a few.

Subsequent to Harry's presentation, Anton presents the FOLIO Quality Dashboard. This shows a code coverage of about 60-70% percent for older (or larger?) modules like Users, but code coverages of more than 90% for newer modules (e.g. the ERM modules). It is, however, not necessarily true that modules with better code coverage are subject to reporting less or less severe errors.

Anton asks us to please send Bugfest testers. All of us should send people from their institution's staff as Bugfest testers to Anton. The next Bugfest will be Mid-December.

Ingolf thanks all for contributing to this meeting. Ingolf will be on the FOLIO hbz/GBV/VZG face-to-face meeting on Wednesday and Thursday next week. Among the topics of this meeting will be a get-together of the SysOps people (from hbz and GBV), Reporting and Privacy - GDPR.

Ingolf encourages all to send him agenda items for next week's Friday session by mail or via the chat.