The infamous Murphy’s Law states that “Anything that can go wrong, will go wrong”. Having an up-to-date security policy helps ensure that there are steps in place to prevent a catastrophe and that you can react responsibly if and when things do go south.
In part 2, we discussed how to increase the chances that the software you use is developed by trustworthy people and organisations. But what exactly is your role in communicating and reacting responsibly to issues that arise with your own products and services?
Having a security policy in place (and enforcing it) will allow you to more effectively:
- Communicate how security issues can be responsibly disclosed to you and how you plan to address them.
- React to vulnerability reports and security incidents in a timely manner, disclosing them to your users when appropriate.
- Implement a Content Security Policy (CSP), adding a layer of security that helps protect your site and mitigate attacks.
Put a Security Policy in Place #
A security policy is, in the most general sense, a document that states how an organisation plans to protect its product or service and deal with breaches. A security policy may be public, private, or a combination of both, and should exist as a living specification that is continuously updated and tweaked as technologies, vulnerabilities and security requirements change.
It depends, of course, on the type of product or service you offer and to whom, but a simple security policy can consist of the following parts.
- What you currently do to protect your product/service.
- How you deal with breaches in your security.
- How others can report security issues and disclosures.
Here’s our Security & Privacy Policy, in which we primarily explain how security is handled for our plugins. CodeKnight’s security policy is a good example of how security is handled in relation to web development projects.
Help Us, Help You #
One way of leveraging lots of pairs of eyes on your products and services is by making it easy and obvious to others how they can help you improve them. Our advice is to create a public and accessible security policy, that preferably includes at least the following:
- An email address for reporting vulnerabilities. Make sure that these emails are automatically forwarded to a technical person with the skills (and time) to identify and distinguish between real security issues and less relevant (or fake) ones.
- A description of how security issues should be reported, as well as what should be included in the report. If you use encrypted email then you can provide a PGP key so that messages including sensitive information can be sent encrypted.
- A list of security issue types that you will respond to (and possibly those you won’t), as well as a timeframe in which a response can be expected.
The best place to put this is on a dedicated page of your website. Alternatives include a security policy on GitHub, a security.txt file on your website, or one of the various bug bounty programs available.
I once discovered that a web development agency had incorrectly configured one of our plugins, leaving a security vulnerability open in their site. Due to the nature of the vulnerability, it could only be exploited by us, but I nevertheless reported it to them immediateley, explainging the problem, the risk and the solution. However, it took sending several emails over the course of 2 months to actually receive a response and eventually have them fix the issue. This is not unusual, security researchers are often met with no response when they disclose vulnerabilities to companies. For more on this, listen to the fascinating podcast series linked below.
Responsible Disclosure #
Security researchers are constantly looking for exploitable vulnerabilities. Ideally, on finding one, their first point of contact should be through your security policy. With responsible disclosure, the vulnerability report is made privately but full details are published once an update has been made available and sufficient time has passed. This allows you to protect your users and at the same time give credit to security researchers.
Try putting yourself in the shoes of a security researcher. How would you react to finding a security flaw in a website or web app that you use? Be sure to also read up on OWASP’s vulnerability disclosure processes.
Bug Bounty Programs #
Some organisations offer bounties (monetary rewards) for bugs and security issues that are responsibly disclosed. While this may be appropriate for some businesses, the overhead and attention it draws may make it unappealing for yours.
Our take is that it is wise to state that you reward serious vulnerability disclosures on a case-by-case basis, provided they follow your guidelines. You can browse and search for bug bounty and vulnerability disclosure programs at disclose.io.
Incident Response #
One of the most critical courses of action in the case of a vulnerability report or a security breach is a quick response. If a vulnerability is reported privately then you usually have sufficient time to react and address it. However, if a vulnerability is publicly disclosed then you are up against the clock to fix the issue, release an update and communicate the urgency of the situation to the people it affects.
If you discover a security breach then the first critical step is to contain the damage. This may require drastic action such as locking down access to administration areas, APIs or even to the public site. Next, you need to evaluate the damage – have user accounts or security keys been compromised, has sensitive data been revealed, have assets been stolen? Secret exposure is perhaps the most sensitive of security breaches and must be dealt with accordingly.
Keeping Logs #
Don’t delete your log files arbitrarily, as they are the breadcrumbs that will help you uncover issues with your site, including exploits. Craft 4 stores logs in files named after the day of the week, so log files shouldn’t get too unwieldy due to file size and it becomes much easier to quickly track down an issue that occurred on a specific day.
If you use a logging service then make sure you know how many days of data retention are included in your plan. These services are generally not intended for long-term storage, so you may want to combine them with long-term storage of Craft’s log files.
Sample Security Policies #
Craft CMS’s security policy exists in the security section of its GitHub repo, conveniently located right next to the source code and issues tabs.
CodeKnight’s security policy describe’s how web development projects are handled, with a transparent insight into the technologies and service providers used.
Umbraco CMS’s security policy is both approachable and thorough. I especially like how they are transparent about when penetration testing was last performed by an external security company.
SnapShooter’s security policies outline what measures they take and how they, as a backup solution provider, handle security practices including storing sensitive information and secret keys.
Tesla’s product security page includes a PGP key for encrypting reports containing sensitive information on its website.
Content Security Policy (CSP) #
Now comes the technical part of this article! While a security policy provides you with a strategy, a Content Security Policy can be applied at the web browser level, which explicitly states which content sources can be trusted, thereby thwarting threats from unknown or untrusted sources.
Content Security Policy (CSP) is a layer of security that helps to detect and mitigate certain types of attacks, including Cross-Site Scripting (XSS) and data injection attacks. While this might seem like an implementation detail, a CSP can be considered, as the name would suggest, part of your website’s broader security policy.
To enable CSP, you can either have your web server return a HTTP header or output a meta tag in your HTML. The CSP essentially tells the web browser what types of resources it may and may not load when visitors browse your site.
For example, say we wanted to allow videos from Vimeo to be embedded on our site using an iframe, but from no other source (except for our own site, of course). We can express this as follows using the Content-Security-Policy header.
Now if a visitor to our site views a page that contains an iframe with player.vimeo.com as the source (or a self-hosted source as represented by 'self'), the video will play just fine. If, however, they visit a page that contains an iframe with www.youtube.com as the source, the browser will block that request and the iframe will remain empty. This results in a very fine-grained way of defining trusted sources.
The CSP specification provides a range of directives that control the locations from which certain resource types may be loaded, as well as a range of allowed values.
While a CSP is an excellent way of mitigating attacks against your site, it can also feel quite restrictive. In the example above, what if we wanted to allow our content authors to embed videos from Vimeo, Youtube and any other video streaming service? We could create a safe list of video streaming services that are allowed, which seems like common sense, but that list needs to be maintained over time.
Implementing a CSP is, as described above, relatively straightforward. You can either use a HTTP header or a meta tag. A HTTP header is generally recommended and is required when using Report Only mode, which is invaluable for testing. If using a static cache such as Blitz with server redirects (so that requests are never handled by Craft) then you should consider using a meta tag, so that the CSP is included within the cached page.
Managing and testing a Content Security Policy can be a pain. Fortunately, the free Sherlock plugin provides you with a settings page in which to configure your CSP. Below is the CSP that this site currently uses, which you’ll find in a meta tag if you inspect the source code.
Perform Regular Security Audits #
In part 4, we’ll discuss the importance of performing regular security audits. Remember how you used to have fire drills in school? They weren’t just a reason to get out of class, although that was a major bonus.
It is only by regularly performing a security audit that you will be able to know whether everything you have done to secure your site and implement your security policy has been worthwhile. If you don’t have the capacity or skills to perform an audit yourself then bring in an external company to do it. External audits are often recommended over internal ones, as skilled people looking at your site from the outside are bound to see it differently and you are guaranteed to learn a ton from them.
Part 4 of this article is coming eventually, but don’t let that stop you from drafting a proposal to perform a security audit today!
Learn More #
Get comfortable, sit back and listen to this fascinating three-part podcast series on data breaches and responsible disclosure:
The LinkedIn Incident, Guild of the Grumpy Old Hackers and Victor.
