Data Protection Developer Policy

Along with the points outlined in the Data protection policy below are some specifics to follow.

Devices at work

Computers and laptops should be be locked with a password, the password should be known to NDP if access to the computer is needed in your absence. It’s also advisable to encrypt the drive if installing the operating system from new.

At the end of the day ensure your machine is shutdown. If you require your machine to run overnight for development reasons make sure the screen is locked. It’s a good idea to have screen lock auto on after 5 mins.

Your personal devices

The use of personal computers for work is strongly discouraged. The reason for this is due to our strong policy on deleting data locally. This mainly means local dev versions of site. If you are using a personal computer for work, it’s imperative you treat the data the same way you would whilst on your work machine in the office and also destroy data.

Another reason we discourage the use of personal computers for work is down to breaches. If there is a critical data breach we expect you to wipe your machine. If you work a lot a home, request a device you can use at home rather than use your own machine.

Tablets and phones should have screen locks on. If you are using your own phone for work emails and messaging you must be able to locate/lock your phone should it go missing.

Passwords.

If you are writing it out, you are doing it wrong.

When using passwords, and in fact all data, take a moment to stop and assess the safety of what you are doing. Is it safe to message the agency password on slack? No, it’s not. If someone is asking for access for something like a site or system that requires a password, be more helpful and point them to the place where they can already view the password or set up an account themselves.

Passwords for systems (google,basecamp etc)

You must choose a secure password for access to the systems covered in your company induction. From time to time we will ask you to change your passwords. Don’t share your passwords with anyone else, verbally or via email.

Agency passwords/Last pass

We use Last Pass to manage passwords between developers. This allows us to grant access to developers without exposing the actual password to everyone. We don’t want passwords to live site written down or stored in cache, so Last Pass is a good tool for password management.

Kat will be rolling out last pass soon and we will be giving instructions on how to use it.

Github and bitbucket

All client repo’s should be private.

NDP repos can be public but should not contain passwords. Most of the NDP repos are private now.

You can use your own github or bitbucket account and we will add you to the NDP team

Site building and development

Scope and security briefs.

If you are starting a new piece of work or being added to a project, ensure you know the security specifications and outlines. This can be found in the scope and or contract.

If you aren’t sure, stop and ask for a proper security briefing via a project manager.

Different clients will have different security specs so it’s important to know your development practice is fulfilling the necessary obligations.

Site users and User 1

When building sites, the main User 1 account should have a secure password, when it’s set it should also be noted in a place complying with the sites security specifications. By default we store credentials in google docs under Site Access documents.

To make management easier, it is recommended you create your own admin account via user 1. This way you can use your own memorable password.

Remember when working locally you can gain access to the sites user 1 account by using the command ‘drush uli’.

API credentials

API information should be treated the same as login passwords. These should be kept in accordance with the sites security specifications, as a default this information should be kept on google docs in the sites Site Access document.

Working with branches

Always practice good housekeeping with branches, make sure branches no longer in use are deleted both in origin and remote, if you’re not sure if you can remove a branch, check through the log and raise it with developers who have been committing.

When doing large pieces of work, it may be useful to fork a repository, it’s important to make sure these are private forks and can be accessed by only you and those you give access to. After merging back to the origin, destroy your forked repo.

Data management

Avoiding to copy data to removable media is essential, but also, try to avoid transferring data to team members. If you need to, use a secure transfer service like wetransfer.

Drush sql-sanitize

When dealing with data on sites, it’s important to remember that we may have sensitive user data on there. So it’s essential to make the data safe to work with. This will rewrite all of the user emails and passwords, by default to"user+[uid]@localhost" and "password" respectively.

Email reroute

When on development, staging and local sites you will need to use email reroute to stop the site sending out emails.

Stage file proxy

Regarding public and files, we recommend using the stage file proxy module. Using this module you are able to link to files directly on a URL via an absolute path or by download the file from the live URL when requested. This method will avoid you having large public and private file assets locally which may contain sensitive data

Breaches

At present, the best way to raise breaches is to email our data officer, Kat Elliot at [email protected]. In your email please include a description of the breach and any supporting links or evidence.

Completion

After the completion of your work it’s necessary to remove any data you have been working with. It’s recommended you delete the database and repo from your machine along with any files.

If using a Virtual machine/Vagrant you should use the command ‘vagrant destroy’ to remove your local dev environment.

Monthly wipe

It’s a good idea to reset your system each month. This way you can be sure your computer is clear of sensitive data. This doesn’t mean completely reinstalling your OS, but clearing VMs, databases and files.