This vulnerability disclosure policy applies to any security vulnerability you are considering reporting to us. If you have identified a security vulnerability in our products, services or systems, we would like to work with you to improve these. Please review this policy before attempting to test or report a vulnerability.

We value those who take the time and effort to report security vulnerabilities in accordance with this policy. However, we do not offer monetary rewards for vulnerability disclosures at this time.

Reporting

You can report any vulnerability you discover in our systems by emailing  

In your report please include details of:

• The website, IP or page where the vulnerability can be observed.
• A brief description of the type of vulnerability, for example; 'XSS vulnerability'.
• Steps to reproduce. These should be a benign, non-destructive, proof of concept. This helps to ensure that the report can be triaged quickly and accurately. It also reduces the likelihood of duplicate reports, or malicious exploitation of some vulnerabilities, such as sub-domain takeovers.

What to expect

After you have submitted your report, we will respond to your report within 5 working days and aim to triage your report within 10 working days. We’ll also aim to keep you informed of our progress.

Priority for remediation is assessed by looking at the impact, severity and exploit complexity. Vulnerability reports might take some time to triage or address. You are welcome to enquire on the status but should avoid doing so more than once every 14 days. This allows our teams to focus on the remediation. We will notify you when the reported vulnerability is remediated, and you may be invited to confirm that the solution covers the vulnerability adequately.

Once your vulnerability has been resolved, we welcome requests to disclose your report. We’d like to unify guidance to affected users, so please do continue to coordinate public release with us.

Guidance

You must:

• Always comply with data protection rules and must not violate the privacy of Cyse's users, staff, contractors, services or systems. You must not, for example, share, redistribute or fail to properly secure data retrieved from the systems or services.
• Securely delete all data retrieved during your research as soon as it is no longer required or within 1 month of the vulnerability being resolved, whichever occurs first (or as otherwise required by data protection law).

You must not:

• Break any applicable law or regulations
• Access unnecessary, excessive or significant amounts of data
• Modify data in Cyse's systems or services
• Use high-intensity invasive or destructive scanning tools to find vulnerabilities
• Attempt or report any form of denial of service, e.g. overwhelming a service with a high volume of requests
• Disrupt Cyse's services or systems
• Submit reports detailing non-exploitable vulnerabilities, or reports indicating that the services do not fully aligwith “best practice”, for example missing security headers
• Submit reports detailing TLS configuration weaknesses, for example “weak” cipher suite support or the presence of TLS1.0 support
• Communicate any vulnerabilities or associated details other than by means described in this policy
• Social engineer, ‘phish’ or physically attack Cyse's staff or infrastructure
• Demand financial compensation as a condition to disclose any vulnerabilities

Out-of-scope vulnerabilities

• TLS/SSL configuration weaknesses (e.g., weak/insecure cipher suites, renegotiation attacks)
• Vulnerabilities obtained via the compromise of a Cyse customer or Cyse employee accounts
• Denial of Service (DoS / DDoS) attacks against Cyse systems or services
• User interface bugs or typos
• Login / logout CSRF
• Missing HTTP security headers that do not lead directly to a vulnerability
• Presence / absence of DNS records
• Password, email and account policies (e.g: email id verification, password complexity)
• Lack of CSRF tokens in non-sensitive actions
• Attacks requiring physical access to a user's device
• Report the use of a known-vulnerable library (without evidence of exploitability)
• Missing cookie flags without clearly identified security impact
• Open redirects
• CSRF or clickjacking with no practical use to attackers
• CSRF that requires the knowledge of a secret
• Exposed metrics or other type of not confidential data
• Missing best practices, configuration or policy suggestions
• Vulnerabilities that require a man-in-the-middle scenario to be exploited

Legalities

This policy is designed to be compatible with common vulnerability disclosure good practice. It does not give you permission to act in any manner that is inconsistent with the law, or which might cause Cyse or partner organisations to be in breach of any legal obligations.