Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
183 changes: 126 additions & 57 deletions docs/development/security.md
Original file line number Diff line number Diff line change
@@ -1,58 +1,121 @@
# ILIAS Security Policy

## Table of Contents
* [Reporting Security Issues](#reporting-security-issues)
* [Publishing Fixes for Security Issues](#publishing-fixes-for-security-issues)
* [About this Document](#about-this-document)
* [Responsibilities](#responsibilities)
* [Reporting a Security Issue](#reporting-a-security-issue)
* [Addressing a Security Issue](#addressing-a-security-issue)
* [Process for Fixing Security Issues](#process-for-fixing-security-issues)
* [Security Update Notifications](#security-update-notifications)
* [Security Goals](#security-goals)
* [Security Measures](#security-measures)
* [Contributors](#contributors)

## Reporting Security Issues
[//]: # (BEGIN Reporting)
Please make sure to understand, that treating security issues confidentially is
required to keep ILIAS installations as safe as possible until the issue is fixed.
## About this Document
[//]: # (BEGIN about)
This document describes the cybersecurity policy for the core of the open source

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This document describes the cybersecurity policy for the core of the open source
learning management system ILIAS.

  • This policy is to foster the development of a secure product.
  • It outlines how vulnerabilities should be handled by developers.
  • This policy outlines how security issues and incidents should be reported effectively and how they are handled by the responsible team, the ILIAS Security Group.
  • It includes aspects of documenting, adressing and remediating vulnerabilities and promotes the sharing of information concerning vulnerabilities
  • It outlines regular verification activities and how evidence of compliance is being gathered.

This document is NOT a guideline on how to set up and operate an ILIAS installation
securely. Such instructions can be found in the document /docs/configuration/secure.md

learning management system ILIAS. The document provides information on how security
issues and incidents should be reported and how they are handled by the responsible
team, the ILIAS Security Group.

This document is not a guideline on how to set up and operate an ILIAS installation
securely. Such instructions can be found in [docs/configuration/secure.md](../configuration/secure.md).

[//]: # (END about)

## Responsibilities
[//]: # (BEGIN responsibilities)
ILIAS is published as an open source software by the non-commercial organisation
ILIAS open source e-Learning e.V. Under the Cyber Resilience Act (CRA), the association
regards itself as an open source software steward. The association’s registered office
is in Cologne, Germany. Accordingly, the relevant CSIRT is the German Federal Office
for Information Security (BSI) and the market surveillance authority is the
Bundesnetzagentur with whom the ILIAS association is cooperating.

The ILIAS Security Group is the responsible team for receiving and processing all
reports about incidents and security issues in ILIAS. E-mail contact is security@ilias.de.
The ILIAS Security Group is reporting vulnerabilities and incidents to the single reporting
platform of ENISA.

The ILIAS Release Manager is responsible for packaging and publishing security bugfix releases
in coordination with the Security Group. Once a security release has been published, the
release manager sends a related notification to the admin mailing list.

[//]: # (END responsibilities)

## Reporting a Security Issue
[//]: # (BEGIN reporting)
The following process describes what to do when you have found a security issue in
ILIAS or observed a related security incident. Please make sure to understand, that
treating security issues confidentially is required to keep ILIAS installations as
safe as possible until the issue is fixed.

Please follow the process described in detail below. You will receive an answer
from a member of the ILIAS security group about further steps.

**Do not file an issue in the bugtracker!**

1. Write an email to security@ilias.de about your discovery, containing a
description of the issue with the scenario in which the problem is triggered and
a description of its implications. Please provide all necessary steps to reproduce
the issue. We kindly ask you to withhold full disclosure of the issue until a fix
is ready and the new release has been build and made available to everyone
(full disclosure about 1 week after the new release is published).
2. The Security Group will assign an issue manager.
3. The issue manager will look into the issue and try and reproduce the problem.
4. The issue manager will contact you on behalf of the ILIAS e.V. by email.
We are grateful for any further help/information you can provide during the
analysis and bugfixing process.
5. Depending on the severity and impact of the issue at hand, the developers will
build a new release ASAP or continue with the default roadmap.
6. Optional: We are very interested in giving proper credit for your finding and
from a member of the ILIAS Security Group about further steps.

Important: **Never file a security issue in the bugtracker of ILIAS!**

1. Write an e-mail to security@ilias.de about your discovery. This e-mail has to
contain a description of the issue with the scenario in which the problem is triggered
and a description of its implications. Please let us know if the vulnerability has
been actively exploited and/or a severe incident has happened. Please provide all
necessary steps to reproduce the issue. We kindly ask you to withhold full disclosure
of the issue until a fix is ready and the new release has been built and made available
to everyone (full disclosure about one week after the new release is published).
2. Your e-mail creates a new ticket in our internal ticket system for security issues.
You will receive an automatic e-mail as confirmation of this.
3. In the next step, the ILIAS Security Group will assign an issue manager.
4. The issue manager will look into the issue and try to reproduce the problem.
5. In accordance with the CRA's guidelines, the issue manager gives an early warning
about an actively exploited vulnerability and/or severe incident to ENISA's single
reporting platform within 24 hours of becoming aware of it.
6. In case of questions, the issue manager will contact you on behalf of the ILIAS
association by email. We are grateful for any further help/information you can
provide during the analysis and bugfixing process.

Optional: We are very interested in giving proper credit for your finding and
your support for the project. If you want to, we can include your name and/or
institution in our release notes. We will not publish your name or the name of
your institution without your consent.

[//]: # (END Reporting)
Please note: If you already have a solution in the form of a bugfix for the
reported issue, we would highly appreciate to get it. In this case, please follow
the **Process for Fixing Security Issues** in order to not unnecessarily endanger
existing ILIAS installations. If you don't have access to the corresponding issue
in our internal security tracker please give access to the corresponding patch
files to the issue manager through a secure channel.

[//]: # (END reporting)

## Addressing a Security Issue
[//]: # (BEGIN addressing)
1. As soon as the issue manager has looked at the issue, the manager assigns
a report to the responsible developer in our internal security issues tracking
system and notifies this developer about the issue.
2. The developer analyses the problem and provides a security fix as soon as
possible.
3. Within 72 hours of becoming aware of the vulnerability/incident the Security Group
provides general information and an initial assessment to ENISA.
4. Depending on the severity and impact of the reported and fixed issues, the
ILIAS release manager will build a new release or continue with the default roadmap.
5. In case of a vulnerability that has been reported to ENISA, the Security Group
provides a final report to ENISA no later than 14 days after the security bugfix
release has been made available.
6. In case of a reported severe incident, the Security Group will provide a final report
to ENISA within one month after the severe incident notification.

[//]: # (END addressing)

## Publishing Fixes for Security Issues
[//]: # (BEGIN Publishing)
We are delighted when solutions are offered together with the initial report.
Please follow the **Process for Fixing Security Issues** in order to not
unnecessarily endanger existing ILIAS installations. If you don't have access
to the corresponding issue in our internal security tracker please give access
to the corresponding patch files to the issue manager through a secure channel.

[//]: # (END Publishing)

## Process for Fixing Security Issues
[//]: # (BEGIN Fixing)
The following process MUST be followed to hand in a fix for a security issue:
[//]: # (BEGIN fixing)
The following process MUST be followed to hand in a fix for a security issue. These
rules apply to code authorities as well as to all other developers and contributors.
* Create one patch file per supported branch needing the fix. The patch file MUST
be named "<ilias_version>_<title_of_fix>.patch" (e.g. "9_my-very-important-fix.patch").
To create the patch use `git format-patch` with the option `--stdout` from the branch in which you made the fixes
(e.g. `git format-patch release_9 --stdout > 9_my-very-important-fix.patch`)
be named "<ilias_version>_<title_of_fix>.patch" (e.g. "11_my-very-important-fix.patch").
To create the patch use `git format-patch` with the option `--stdout` from the branch
in which you made the fixes
(e.g. `git format-patch release_11 --stdout > 11_my-very-important-fix.patch`)
to ensure that all commits are in a single patch file, if multiple commits are
needed to fix the issue. To make the application of the patches as easy as possible,
**fixes for security issues MUST not contain any unrelated changes**.
Expand All @@ -66,11 +129,10 @@ the communication.
* The fixes will be applied to the release branches by the release manager before
the release.


[//]: # (END Fixing)
[//]: # (END fixing)

### Regressions
[//]: # (BEGIN Regressions)
[//]: # (BEGIN regressions)

In exceptional cases, security fixes may introduce regressions that negatively impact functionality
or system stability. To address such situations promptly and effectively, the following procedure
Expand All @@ -97,48 +159,55 @@ shall be followed:
* In case of a hotfix, the Release Manager shall inform stakeholders via the appropriate mailing lists
and Discord channels.

[//]: # (END Regressions)
[//]: # (END regressions)

## Security Update Notifications
[//]: # (BEGIN Notifications)
[//]: # (BEGIN notifications)

Please subscribe to our admin mailing list (ilias-admins@lists.ilias.de) to get
notifications about security updates, updates in general and announcements for
ILIAS server administrators. As a general rule ILIAS updates will be published
ILIAS server administrators. As a general rule, ILIAS updates will be published
on the start of a week and will be announced in the middle of the previous week
on the mailing list.

[//]: # (END Notifications)
[//]: # (END notifications)

## Security Goals
[//]: # (BEGIN Goals)
[//]: # (BEGIN goals)

* All ILIAS security issues should be kept confidential until patches for them are integrated into an official release.
* Security issues must be fixed in ALL currently supported and affected versions.
* ILIAS releases which contain patches for security issues should be released as soon as possible.
* All fixed security issues should be documented publicly.

[//]: # (END Goals)
[//]: # (END goals)

## Security Measures
[//]: # (BEGIN Measures)
[//]: # (BEGIN measures)

* All incoming issues (via security@ilias.de) are handled by the Security Group in an internal ticket system (hosted by the ILIAS e.V.), which allows for sending encrypted and digitally signed e-mails to security reporters
* Security issues are entered into a restricted part of the official Mantis platform for ILIAS by the Security Group and then assigned to the authority which is responsible for the affected component.
* The Release Manager is in direct contact with the Security Group to ensure that releases for all affected versions can be made available in a short timespan, ideally on the same day.
* Releases with security fixes are accompanied by an entry in our security blog (at docu.ilias.de) which provides more details on affected and fixed versions of ILIAS.
* All incoming issues (via security@ilias.de) are handled by the Security Group in an internal
ticket system (hosted by the ILIAS open source e-Learning e.V.). It allows for sending encrypted
and digitally signed e-mails to security reporters.
* Security issues are entered into a restricted part of the official Mantis platform for ILIAS
by the Security Group and then assigned to the authority which is responsible for the affected
component.
* The Release Manager is in direct contact with the Security Group to ensure that releases for
all affected versions can be made available in a short timespan, ideally on the same day.
* Releases with security fixes are accompanied by an entry in our security blog (at docu.ilias.de)
which provides more details on affected and fixed versions of ILIAS.

[//]: # (END Measures)
[//]: # (END measures)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Verfication

  • One a year the Security Group will briefly reflect on their process and results. They will provide feedback to the Technical Board, who may choose to suggest changes.

## Contributors
[//]: # (BEGIN Contributors)
[//]: # (BEGIN contributors)

* Robin Baumgartner, sr solutions ag, Burgdorf, Switzerland
* Tim Bongers, CaT Concepts and Training GmbH, Cologne, Germany
* Alex Hartwig, Qualitus GmbH, Cologne, Germany
* David Tokar, WEKA Media GmbH & Co. KG, Kissing, Germany
* Matthias Kunkel, ILIAS open source e-Learning e.V., Cologne, Germany
* André Schweigert, FAU Kompetenzzentrum Lehre, Fürth, Germany
* Lukas Scharmer, Databay AG, Würselen, Germany
* David Tokar, WEKA Media GmbH & Co. KG, Kissing, Germany
* Guido Vollbach, Databay AG, Würselen, Germany

[//]: # (END Contributors)
[//]: # (END contributors)
Loading