Security Disclosure Policy

We at Citizen Ticket are committed to providing a robust, reliable and secure ticketing platform that safeguards our organisers' and our customers' data. We appreciate and recognise the value in contributions that responsible, independent and ethically minded security researchers can contribute to our platform. This document intends to outline the scoping, framework and reporting methods for Citizen Ticket so that we can work with the security researcher community most effectively.

Bounty & Rewards

We are not currently running a bug bounty program. However, we may be able to pay hourly or day rates to vetted security researchers who wish to participate in our programme. Please contact us via abuse@citizenticket.co.uk to discuss compensation before you begin research on our domain.

Scope

Only submit reports where a real impact to Citizen Ticket, or it's user accounts and/or data, would exist as result of the vulnerability.

Do not create an unnecessary amount of data records via our system; limit yourself to only what is necessary to prove the exploit - usually 1-3 records.

Please do not research, or submit reports about:

• Self XSS (where the user can only 'attack' themselves)
• Volumetric DoS attacks
• Discoveries/indications that we do not align with 'industry best practices' but are not necessarily security weaknesses themselves
• Clickjacking

Domains

Please limit your research to staging.citizenticket.co.uk

Reporting vulnerabilities

Please email your vulnerability to abuse@citizenticket.co.uk outlining

• The category of technique/exploitation in the subject line eg. XSS exploit
• The URL affected
• The steps to reproduce the error
• A clear description

Severity Levels

For each report, we will aim to categorise the report into one of 4 levels to signify the potential severity of impact of the reported problem;

Severity Rating	Definition
None	The bug is one or more of the following: was reported incorrectly, no longer exists in production, or does not pose a threat to loss of service, or leakage of data
Low	The bug is one or more of the following: is unlikely to occur in the real world only has the potential to affect a single user or single users' data is contrived, and otherwise would not exist merely exposes metadata (version or similar) about our systems but in & of itself not an access risk
Medium	The bug is one or more of the following; amounts to a real phishing risk whereby abusing our systems access can be gained leaks user data in a non-targeted way causes deletion or modification of user-data in an unappreciated fashion leaks non-sensitive user data in a targeted manner or in bulk causes non-significant disruption to our service
High	The bug is one or more of the following: gains access to a user account in a reproducible manner leaks sensitive user data in a targeted manner or in bulk causes significant disruption to our service

The severity rating given is to our discretion, meaning that we may choose to escalate or de-escalate the severity rating for a particular bug without regard to our definition or not necessarily with given reason.

Our response & commitments

We aim to acknowledge all reports within 7 days of receipt of report. We will also provide you with a bug report reference. If you do not receive a reply acknowledging your report after 7 full days after receipt, please resubmit the report again and contact us via a separate channel of communication, for example via customer support, to request acknowledgement of your report. (Do not resubmit the report itself to the separate channel of communication).

For medium to high severity bugs, within 28 days of acknowledging your report, we aim to put in place a remedy or mitigation addressing the vulnerability. We aim to provide you with progress of our solution within the 28 day time period from acknowledgement. If you have not heard from us by this point, please recontact us via a separate channel for a status update, along with the bug report reference.

For none to low severity bugs, we may or may not provide a timeframe, and we may or may not choose to address the perceived problem. We will, however, acknowledge the report and provide you with our severity rating.

Your responsibilities & commitments

Security researchers must not:

• Act threatening, rude or with otherwise ill-intent to Citizen Ticket the company, or it's employees or staff
• Modify data that is not your own or not clearly segregated & marked as test data Disrupt our production services/systems ever, or disrupt our non-production services/systems without prior obtained consent
• Disclose information uncovered during researching to third parties, for example user data
• Disclose vulnerabilities to third parties or the public without first receiving confirmation from Citizen Ticket that the vulnerability has been mitigated or rectified
• If the vulnerability discovered concerns a third-party library, framework or API, the third party can be notified but Citizen Ticket should not be implied or mentioned.
• If you are unsure, please contact abuse@citizenticket.co.uk for clarification

Security researchers must:

• Act within the confines of the scope set within this document
• Delete all data created and/or retrieved during their research as soon as possible, by the latest at 1 month after the report is submitted

If you are unsure about your responsibilities, actions (prior or planned), please contact abuse@citizenticket.co.uk for clarification.

Legalities

We have put this policy in place to better define our expectations when working with well-intentioned security researchers. However, this policy does not grant permission to anybody to act outside of the laws of Scotland, the UK, or the country of residence of the security researcher, and it does not cause Citizen Ticket to be in breach of its own legal obligations. Particular consideration should be given to;

• Computer Misuse Act 1990
• Data Protection Act 2018
• General Data Protection Regulation (GDPR) 2016

As long as the report is made in good faith, and within scope, and within accordance of this policy, we will not seek to prosecute any security researcher for finding and submitting their report of a security vulnerability,