Thrive is delighted to have been certified to the Cyber Essentials Plus accreditation by Wolfberry on the 1st April 2016.
Cyber Essentials is a government backed scheme that aims to help organisations implement basic levels of protection against cyber-attack; demonstrating to their customers that they take cyber security seriously.
The scheme is available at two levels:
Cyber Essentials: an independently verified self-assessment. Thrive carried out an assessment against the five basic security controls and a qualified assessor then verified the information provided.
Cyber Essentials PLUS: having achieved the basic level of accreditation, Thrive then applied for the higher level of assurance awarded by the PLUS version. A qualified and independent assessor examined the same five controls, testing that they work in practice by simulating basic hacking and phishing attacks.
The five basic controls within Cyber Essentials were chosen because, when properly implemented, they will help to protect Thrive against a range of internet-based attackers. The five controls are:
- Boundary firewalls and internet gateways
- Secure configuration
- Access control
- Malware protection
- Patch management
As part of the Cyber Essentials Best Practice, Thrive will aim to undertake the Cyber Essentials re-accreditation each year.
Backing for the Cyber Essentials accreditation from the government is strong. From 1st October 2014, Cyber Essentials became a minimum requirement for bidding for some government contracts which involve handling personal information and providing certain ICT products and services.
To further demonstrate our commitment to security, we also check our website is following industry best practices with the following tools:
SSL Labs gives us an "A"
SecurityHeaders.io gives us an "A+"
HTTP Observatory gives us an "A+", with 125 points.
However we also realise that certification and tests only cover the basics.
So from a technical point of view, these are the extra steps we take to protect your data:
To reduce the risk of attack, we only store the information we need. At no point does our website store, or have access to, payment information. And student data is kept as anonymous as possible (e.g. not using student names).
Any time a person requests information from our website, it checks that they have permission to do so. This includes preventing members from seeing each others data, and stopping basic accounts from being able to access data/features that they should not be able to (privilege escalation).
We always use HTTPS, with a good configuration, to ensure that data is encrypted when it's being sent over the internet.
To ensure that browsers always use an encrypted connection, we use the HTTP Strict Transport Security (HSTS) header.
We protect ourselves against any Certificate Authority issuing a HTTPS certificate for our website to someone malicious with the use of HTTP Public Key Pinning (HPKP).
We do not store passwords in plain text. This is an extra level of defence just in case our database was to be compromised. Instead we use the bcrypt hashing algorithm, so that the passwords cannot be identified (even with a brute force approach to guess each password).
We also enforce a maximum number of login attempts per IP address (this is higher than normal, at 60 attempts every 30 minutes, as we often have a room full of delegates all trying to login at the same time). Additionally we keep an eye on the failed login attempts when reviewing our access logs.
All user/admin uploaded files (e.g. images) are put into a folder where code execution is disabled, and the images are re-saved to reduce the risk that these files might contain malicious content.
To further protect against the user/admin uploading a file as one type (e.g. an image), and the browser seeing it as another type (e.g. JavaScript), we send the X-Content-Type-Options: nosniff header.
The server automatically applies security patches every day. We realise there is a small risk that a patch may result in the website becoming unavailable, but it ensures that security vulnerabilities are patched as soon as possible.
The server is configured to only run the services needed, with the most restrictions as possible. This includes only allowing certain types of connections, administration login only by authorised SSH Keys (not passwords), accounts having very limited access, etc.
All data is sent to our database via a process known as Prepared Statements (or escaping as needed), which protects against SQL Injection. This is defending against a type of attack where someone could access or modify the data we store.
All data displayed on the website is encoded appropriately; this is typically done though HTML and URL encoding, which protects against Cross Site Scripting (XSS) attacks.
As an additional layer of defence, we also use a very strict Content Security Policy, where we are proud to not include any of the "unsafe" statements (i.e. we do not use inline JavaScript or CSS). We also have a "default-src" of "none", so we can white-list the sources and features we use (typically limited our own website), and we set the "referrer" policy to not expose sensitive data from the URL (not that we put any sensitive data in the URL).
If you log in to our website, we will generate a session for you, where the unique token is stored in a cookie (query strings are potentially vulnerable to session fixation and information leakage attacks), and we use several other mechanisms to protect against other session based attacks (e.g. changing the token every 5 minutes, and storing a random key in the session so we know we generated every token).
Once logged in, we also protect against a kind of attack where a malicious website could cause the victims browser to perform actions on our website (e.g. edit or delete a student). This is known as a Cross Site Request Forgery (CSRF), and we block these malicious requests by setting a random value in a cookie, and repeating that value in every form (so that every request that attempts to modify something, we can check that the values match).
To further protect against CSRF attacks, we are using the SameSite Cookie Attribute, so that malicious requests from other websites do not include certain cookies (depending on the request type, and the cookie).
In regards to cookies, we always set the HttpOnly and Secure attributes, so that they are only used on HTTPS connections, and not available to JavaScript (this is vitally important for the Session Token). We also enforce the Secure attribute by using the "__Host-" prefix for their name.
And finally, to protect against Click Jacking attacks, we use the "X-Frame-Options" header to either DENY (default) or SAMEORIGIN, and the "frame-ancestors" directive in the CSP header.