Contact details

Contact our team on [email protected]

We welcome your feedback or suggestions on this policy to ensure that it is clear, complete and remains relevant.

Introduction

Oak National Academy (“Oak”) appreciates investigative work into security vulnerabilities which is carried out by well-intentioned, ethical security researchers. We are committed to thoroughly investigating and resolving security issues in our platform and services in collaboration with the security community. This document aims to define a method by which we can work with the security research community to improve our online security.

This policy is designed to be compatible with common good practice among well-intentioned security researchers. It does not give you permission to act in any manner that is inconsistent with the law or cause Oak to be in breach of any of its legal obligations, including but not limited to:

• The Computer Misuse Act (1990)
• The General Data Protection Regulation 2016/679 (GDPR) and the Data Protection Act 2018
• The Copyright, Designs and Patents Act (1988)

Oak will not seek prosecution of any security researcher who reports, in good faith and in accordance with this policy, any security vulnerability on an in-scope Oak service.

Scope

We welcome reports of vulnerabilities in our products and services as part of our Bug Bounty Scheme where they meet the following conditions:

• They have not been previously reported or have not already been discovered by our own internal procedures;
• It can be demonstrated that there would be a real impact to us and/or our users should the vulnerability reported be exploited by a malicious actor. The existence of a vulnerability does not necessarily demonstrate that such a potential impact exists: theoretical impacts will not be considered as within the scope of the scheme.

The following security issues are currently not in scope, so we ask that you do not report them:

• Volumetric/Denial of Service vulnerabilities (i.e. simply overwhelming our service with a high volume of requests);
• TLS configuration weaknesses (e.g. "weak" cipher suite support, TLS1.0 support, sweet32 etc.);
• Reports indicating that our services do not fully align with "best practice" (e.g. missing security headers or suboptimal email-related configurations such as SPF, DMARC etc.);
• Issues surrounding the verification of email addresses used to create user accounts;
• Clickjacking vulnerabilities;
• Self XSS (i.e. where a user would need to be tricked into pasting code into their web browser);
• CSRF where the resulting impact is minimal;
• CRLF attacks where the resulting impact is minimal;
• Host header injection where the resulting impact is minimal;
• Network data enumeration techniques (e.g. banner grabbing, existence of publicly available server diagnostic pages);
• Reports of improper session management / session fixation vulnerabilities.

How to report a vulnerability

Please read this document fully prior to reporting any vulnerabilities to ensure that you understand the policy and can act in compliance with it.

If you discover an issue which you believe is an in-scope security vulnerability, please email [email protected] and include the following:

• The website or page in which the vulnerability exists.
• A brief description of the class (e.g. "XSS vulnerability") of the vulnerability. Please avoid including any details which would allow reproduction of the issue at this stage. Further detail will be requested, over encrypted communications.

In accordance with industry convention, we ask that any report provide a benign (i.e. non-destructive) proof of exploitation wherever possible. This helps to ensure that the report can be triaged quickly and accurately whilst also reducing the likelihood of duplicate reports and/or malicious exploitation for some vulnerability classes (e.g. subdomain takeovers).

Please ensure that you do not send your proof of the exploit in an initial, plaintext email if the vulnerability is still exploitable.

You are able to encrypt your messages to our team using PGP. The public key is available at: https://www.thenational.academy/.well-known/pgp-key.txt

Please also ensure that all proof of exploits are in accordance with the following guidance;

Security researchers must not:

• Access unnecessary amounts of data. For example, 2 or 3 records is enough to demonstrate most vulnerabilities (such as an enumeration or direct object reference vulnerability);
• Violate the privacy of Oak users, staff, contractors and systems. For example by sharing, redistributing and/or not properly securing data retrieved from our systems or services;
• Communicate any vulnerabilities or associated details via methods not described in this policy or with anyone other than your dedicated Oak security contact;
• Modify data in our systems/services which is not your own;
• Disrupt our service(s) and/or systems; or
• Disclose any vulnerabilities in Oak systems/services to 3rd parties or the public prior to the Oak that those vulnerabilities have been mitigated or rectified. This does not prevent notification of a vulnerability to 3rd parties to whom the vulnerability is directly relevant, for example where the vulnerability being reported is in a software library or framework – but details of the specific vulnerability of the Oak system must not be referenced in such reports.

We also request that any and all data retrieved during research is securely deleted as soon as it is no longer required and at most, 1 month after the vulnerability is resolved, whichever occurs soonest.

If you are in any doubt, including the status of any third party to whom you wish to send notification, please email [email protected] for advice.

Our response

We will endeavour to acknowledge your initial email within 48 hours of receipt.

Following this initial contact, our team will work to triage the reported vulnerability and will respond to you as soon as possible to confirm whether further information is required and/or whether the vulnerability qualifies as per the above scope, or is a duplicate report. From this point, necessary remediation work will be assigned to the appropriate Oak teams and/or supplier(s).

Priority for bug fixes and/or mitigations will be assigned based on the severity of impact and complexity of exploitation. Vulnerability reports may take some time to triage and/or remediate. Whilst we welcome you enquiring on the status of the process we ask that you please limit this to no more than once every 14 days, as this will help our team focus on the reports as much as possible.

Our team will notify you when the reported vulnerability is resolved (or remediation work is scheduled) and will ask you to confirm that the solution covers the vulnerability adequately. We will offer you the opportunity to feed back to us on the process and relationship as well as the vulnerability resolution. This information will be used in strict confidence in order to help us improve the way in which we handle reports and/or develop services and resolve vulnerabilities.

Sadly, due to our funding structure, we are currently unable to offer any paid bug bounty programme; nor can we provide gifts to those who report security issues to us. However, we can offer to include reporters of qualifying vulnerabilities on our acknowledgments page and we will ask for the details you wish to be included.