🔒 Cybersecurity for lawyers

• Secure your DNS: it's critical
• Host your server (physically) in a suitable jurisdiction
• Keep your software up to date
• Encrypt traffic between your visitors and your website
• Configure your site to be as secure as you can
• Take regular backups, automatically
• Be careful with contact forms and text entry fields
• Control who can post content to your website
• Your firm's website and Tor
• Assess third party Javascript before embedding it in your site

If you have your own website, there's a very strong chance that you have your own domain name too.

The domain is the bit which your visitors remember (probably something linked to the name of your firm) but the Internet works on numbers.

The Domain Name System — the “DNS” — is the technology which converts the domain name to the right numbers, so that someone who types your domain name into their browser gets connected to your website.

The DNS is the equivalent of a phone book (for those of you old enough to remember phone books): someone puts in a name, and it gives back the right number. This all happens behind the scenes, very quickly.

If someone gains control over the DNS for your domain, they can control what number gets given back to a would-be visitor.

Importantly, if they can change the number, it means that they can redirect your visitors any number they want, including one controlled by them. They can redirect visitors away from your website and, worse, receive email intended for you.

Losing control over your website is damaging, but losing control over your DNS is far worse.

Make sure you have admin control over your DNS settings, and do what you can to avoid being locked out of them:

• Use a strong password.
• If your provider supports it, enable two-factor authentication.
• If you can set a recovery email address in case you get locked out of your account, do so, and make sure it is set to a different email account which only you can access.

If you have to give a third party (such as an IT service provider) access (for example, to change a setting), see if you can limit the access you give them.

If not, and you have to give them your password, change the password once they have made the changes.

Different countries afford different protections, so host your website on a server in a country which affords you sufficient protections.

If you are using a third party to host your website, they should be established in a safe country too.

Mythic Beasts offers UK-based hosting at reasonable prices.

The more complex the software stack on which your website is running, the greater the opportunities for bugs or exploits.

Keep an eye on updates to the software, and test and deploy quickly. You are probably better of enabling automatic updates if this is an option. There is a risk that an update might be incompatible with something you are doing with your site, and so automatically upgrading might cause problems, but you are more likely to have problems if you do not update your software.

If you are using a third party to run your website, or you are hosting it on someone else’s platform, check out their policy on applying software updates. If you can, enter into a service level arrangement which sets out how and when they patch their servers, at both the operating system level and the application level (i.e. the web server software itself, as well as the software on which that web server software runs).

Just as you would look for a padlock on a website you are browsing, offer the same to your potential clients, so that traffic to your website is encrypted.

Set up your server so that visitors can connect to your website securely.

Exactly how you do this depends on how your website is set up, but it usually entails:

• installing a digital certificate. Doing this is easy and cheap (free, if you use Let’s Encrypt, for which there is the excellent certbot tool for configuration and management).
• changing your web server's configuration, to load the certificate and offer an encrypted connection.
• opening an additional port in your firewall, to allow traffic on port 443.

If your website hosting provider offers “automatic SSL” or “automatic TLS”, this is probably a way to set up an encrypted connection.

If you run your own server, the easiest way to get this up and running is to use a free Let’s Encrypt certificate, which you can install through the certbot tool.

A common failing when using an encryption certificate for a website is failing to renew it. If you do not renew it before it expires, visitors to your website will see an error message, which you do not want.

LetsEncrypt certificates expire after three months, and, if you use certbot to install a LetsEncrypt certificate, it should handle renewals automatically. If you supplied an email address as part of the configuration process, you should get an email shortly before the certificate expires; for the first renewal at least, keep an eye on the site at the time the certificate expires, to check it has renewed automatically correctly.

If you do not have a LetsEncrypt certificate, you will need to remember to buy a new certificate from whichever company is providing your certificate, and then download it and install it on your web server.

In addition to setting up your server to offer an encrypted connection, make a further change so that visitors are automatically redirected to the secure version of your site.

This means that, even if they access the insecure version of your website (http:), they will be automatically redirected to the secure version (https:), without them needing to do anything.

If you use certbot to install a LetsEncrypt certificate, it will ask you during the installation of your first certificate if you want it to make the changes to your web server's configuration to do the redirection automatically. If you do not know what you are doing, this is probably a sensible thing to do.

You can increase the security of your site, and lessen the risk of malicious or inadvertent compromises, by configuring the information which your site sends to a visitor in the background. These are not changes to the content of your pages, but rather some initial, behind the scenes, instructions.

The easiest way to start is to visit securityheaders.com or observatory.mozilla.org and put in your site's URL. It will assess your site, based on this background information, and give you a grading. More helpfully, it tells you (roughly) what you need to do to improve.

You implement these changes by configuring the “headers” which your web server sends, and you can normally do this either by changing your web server's configuration, or else on a directory-specific basis through using a special file in the directory, called .htaccess.

Make sure you test your site thoroughly after making changes, to make sure things work correctly. This is especially true if you load things (such as font, or images, or plugins) from third party locations, and lock down your settings (such as the “content security policy” header) to restrict what can be loaded from where. The easiest way of testing your site is by using TorBrowser, as this will ensure you are not loading content from your normal browser's local storage.

Ensure you have an accessible, tested backup of your firm's website. If you update your site regularly, consider automating your backups, so that you don't have to think about it (if you have to think about it, you'll probably forget to do it).

If your hosting provider decides to close shop unexpectedly, or your website gets hacked, you can get back up and running far more quickly if you have a tested backup available.

If you let people fill in forms, or submit information via your website, make sure you restrict their ability to enter things which would be problematic (such as loading content from other servers, or wiping your database). Example.

This is known as “sanitising inputs”.

If you've developed your own website, it's up to you to get this right. If you've outsourced the development, check with your web developer that they have this covered off.

Limit who can post content to your website as much as possible.

Give every person who can post content their own unique username, and the most restrictive set of permissions which let them do their job.

Make sure that access is encrypted.

If your web host offers it, enable two-factor authentication.

This is different from using Tor to protect your own browsing.

Unless your hosting provider has blocked it, your website is accessible by people connecting to it through Tor.

On the downside, this is a potential route for attacks, as tracking the origin of malicious traffic is made far harder.

However, if you value the ability to connect to websites via Tor, to protect your privacy, and particularly if you want to make your site available to potential clients who are accessing from a place where they cannot use the normal Internet to access it, permitting access via Tor may be sensible.

If you do want to block access for Tor, you'll need to have a regularly-updated block list, covering all the points at which traffic breaks out of the Tor network; these points are known as “exit nodes”.

A separate issue to whether you permit users of Tor to connect to your website is whether you make your website, or a parallel version of it, available within Tor.

For example, you can access decoded.legal's website directly within Tor:

dlegal66uj5u2dvcbrev7vv6fjtwnd4moqu7j6jnd42rmbypv3coigyd.onion

You can also access this site directly within Tor:

h7isucmawckzflxhipflydxvxpaytk5fozfk5immffg66rhboc74yxyd.onion

(If you try this, and it doesn't work for you, it probably means you are not connected to Tor, or you are not using a browser which recognises .onion domain names. It won't work in a normal web browser.)

It is not difficult to make your site accessible within Tor and it offers an added degree of privacy protection for your prospective clients.

If you let a third party run scripts when someone loads your website, you are exposing your visitors to the risk that those scripts are malicious or doing something unwanted. It is alleged that this was the mechanism used by criminals to compromise British Airways' website.

You may be able to use some server-based security settings (such as the Content Security Policy header) to lessen this risk.