Keeping your data secure is really important – to you and to us.
Security is often thought about in terms of secrets – making sure that only authorised people can see particular data. But confidentiality is only part of the story – you also need to think about integrity and availability too. It’s also good to think about ‘defence in depth’ – building up multiple layers of protection so that if there is a problem with one layer, others will help you out.
If you ask ‘is a system secure’, you’re asking quite a complicated question, and it’s helpful to break it down.
Firstly there’s the server, which holds all your data. Is it physically secure? Our servers are in a secure server centre near Portsmouth, with biometric access controls. Very few people are allowed in.
In other words, our server is not easy to get to.
Then there’s electronic walls. Firstly, all the data and programming code is encrypted on the disks, so without the master password it’s all gibberish. Secondly, there are two firewalls on our servers. (A firewall is a way of stopping computers talking about things they shouldn’t. For example, our database servers only do database things – so they don’t need to do any emailing. So another computer trying to ‘talk email’ won’t be allowed. Twice).
So, when you use Lamplight you’re sending and receiving information from our server over the internet. Normally, the internet isn’t the most private of places. If you look at a website whose address starts ‘http://’, then everything you see (and send) is available to anyone who happens to be ‘listening in’ to what you’re doing. It’s like sending postcards backwards and forwards – anyone who happens to see it in transit can read it all.
Now you might think that’s pretty unlikely. Who’s going to be listening in on your web browsing? It’s actually not that hard – a couple of years ago people surfing in coffee shops were getting their accounts hacked… There’s an article about it on PC World here – but to give you an idea, it starts:
I hijacked someone’s Facebook account with Firesheep. It was incredibly easy.
And this is why https is essential. That little ‘s’ stands for secure and it means that all the information travelling over the internet is encrypted (jumbled up) so that anyone listening in will only hear gibberish.
More and more sites use https – even Google searches. You really shouldn’t use any site that doesn’t use https if the information on it is at all confidential. Lamplight only uses https in the application.
Lastly there’s your computer. A good thing about web-based systems is that you don’t have lots of confidential information sitting on your computer. Unless you download it, in which case you should really think about encrypting your computer’s hard disk, if you haven’t already (all our computers are).
There’s some other things about the application (ie the Lamplight software) that you might like to know about (though we’re lapsing into technicalities):
- we use industry leading components (Zend Framework, Yahoo User Interface)
- security is built in from the ground up, not added later.
- passwords are salted and hashed using most recent best practices
- all forms include hashes to prevent CSRF (Cross-site request forgery) attacks
- all input is filtered and output escaped to prevent XSS (cross-site scripting) attacks
- application code is outside of the web directory
- we only use SSH with PPK and non standard usernames to access the server
- Lamplight servers communicate with one another across a separate private network
- external data is filtered prior to use
- servers are regularly updated
Https is not difficult to set up. If it’s not available, and your data is even slightly confidential, then don’t use the system. In our view it’s just too important to ignore.
Good password storage.
There’s been a few examples in the news recently about lists of passwords and usernames being stolen and used. ‘Salting and hashing passwords’ is best practice (and really easy to do) and means that if the password database is compromised, it’s basically going to be impossible for someone to work out what your password is. Tesco might get into trouble over this from the Information Commissioner’s Office (ICO). What to look out for: if you can request your password by email, and the system sends you your old password (i.e. not a new one), it’s not salting or hashing passwords.
Preventing CSRF and XSS attacks
These are the most common ways that web applications get hacked – and if there are vulnerabilities it’s likely that all your data is at risk. But it’s not so easy to spot problems with this without actually trying to hack a system. It might be worth asking ‘what do you do to prevent CSRF and XSS vulnerabilities’ (answers above in the bullet points).
External data filtering
If a system uses data from external sources you need to be really careful that doing so does not introduce vulnerabilities. For example, we filter all the address data we get in the postcode lookups so that if the external address database was compromised, it wouldn’t introduce a vulnerability into Lamplight. What to look out for: external data can be all sorts of things – images, videos, maps, computer code (harder to spot), comparison data… If you notice anything like that, ask where it’s hosted (and if it’s not on their server, it’s a problem). Maps can be particularly problematic – pretty, but if you’re mapping ‘where my service users live’ there’s a good chance you’re sending Google (or whoever) a list of your service users’ home addresses.
It’s no good having a highly secure system that’s offline half the time – you need your data available.
- We have multiple servers doing the same jobs, which help things carry on if something goes wrong with one of them
- Our server provider offers a 100% SLA (they promise that the servers will be available for 100% of the time)
- We carry out maintenance and upgrades out of office hours to avoid any disruption
- Daily backups are taken and stored securely.
Data integrity – is your information trustworthy – is something we can only help with. There are simple things we do, like recommending drop-downs and postcode lookups, to help you ensure that the data added is accurate. And all fields are stamped with the date and person updating them.
Security needs to be built in from the outset. Trying to add security to a system afterwards is like trying to add a shell to an egg yolk. We think that as all our programming is done in-house, we avoid a ‘prototype – iterate – sign off’ development approach, which can lead to security considerations becoming an add-on. It also means that we have more incentive to take security seriously: if we fail, so does our business. Outsourced developers may not have quite the same imperative.