Vulnerability disclosure policy

Testing for vulnerabilities

If you want to actively test our systems for vulnerabilities, you must:

• Only test systems that are in scope of this policy
• Use a test, or other non-production, environment if it is available to you
• Only test vulnerabilities using your own accounts, or accounts that you have permission to test with.

You must not:

• Perform testing likely to:
  • provide you with access to someone else’s data
  • delete, destroy or corrupt anyone else’s data
  • affect other users, for example denial of service and brute-force attacks, spamming
• Use automated scanners/fuzzers
• Test systems outside the scope of this policy.

How you can help us

• Provide the IP address from which you performed the testing so that we can view logs related to your testing
• Clearly identifying your traffic, for example by including a unique custom HTTP header such as X-York-CVD:<youremail@address>
• If you are attempting to demonstrate root level access, please use touch /root/<uniqueid>
• Provide us with detailed information about the vulnerability to help us confirm it, for example:
  • The URL or DNS name of the product, service or system
  • If the vulnerability is in code that we distribute and the version number
  • A description of the vulnerability
  • The steps needed to reproduce the vulnerability, plus any proof-of-concept code
  • Any relevant screenshots
  • Details of the web browser and operating system used during testing
  • How you prefer to be contacted
  • Any current plans you have to disclose the vulnerability.

What we'll do

Upon receiving your report, we will:

• Respond and acknowledge your report within seven calendar days
• Ask for any additional information we need to investigate your report
• Work with you to confirm the vulnerability, the extent to which it affects us, and let you know how long we think the vulnerability will take to fix. Our aim is to fix vulnerabilities within 90 days of confirmation
• Notify you when the vulnerability has been fixed
• Where appropriate, release information about the issue to our members, partners, or the public to help others determine if they are affected by the vulnerability, and if so, what they need to do
• Review what went wrong and update our practices and processes to improve our products and services
• If you wish, acknowledge your assistance to the University on this page
• Promise not to take legal action against you for accessing (or attempting to access) our systems, as long as this policy is followed and you do not cause foreseeable harm
• Treat your report as confidential, treat your data according to our data protection policies, and not pass your personal data onto any third parties without your permission

Issues not considered security vulnerabilities

There are some issues that we may not consider to be security vulnerabilities, but you can still report them to us. We will respond and inform you why we do not consider it to be a security vulnerability. These are largely non-exploitable vulnerabilities or configuration issues, for example:

• Missing security headers that may be best-practice but do not impact on the security of the system in this instance
• Support for older, but non-exploitable, protocols and cipher suites such as TLS 1.1
• Fingerprinting/version detection
• Out of date software, with no exploitable vulnerability.

Communicating with us

Confidentiality

If you are worried about the confidentiality of information sent to the University as part of this process, we recommend you send the information to us using PGP/GPG.

Working through a third party

You may prefer to work through a third party such as a CSIRT team. We may work with other CERTs and CSIRTs if we need to collaborate with a wide variety of organisations or coordinate the release of information. You can decide to work through a third party for any reason, even after contacting us directly.

Remaining anonymous

You may wish to report something to us entirely anonymously. We are happy for you to do this, but it may make it difficult for us to confirm the vulnerability and to acknowledge your efforts if we are unable to contact you. We may also fail to identify activity if you are anonymous, for example, if you do not wish to provide us the IP address used to test our systems.

Scope of the policy

This policy is under active development. We are using a limited scope to help us explore what works well and what does not. The scope of the policy will change over time.

Systems in scope

The fully qualified domain names of the systems within scope are listed below. Subdomains not explicitly listed are in-scope ONLY if they are hosted in the IPv4 range 144.32.0.0/16 or the IPv6 range 2001:0630:0061::/48.

• york.ac.uk

Systems not in scope

• All systems not explicitly mentioned as in-scope
• Yorsearch
• Check in

If you are unsure as to whether a system is in scope, please contact us first.