The news that a the UK hosting company VAServ lost 100,000 web sites all at once is devastating for the organisations involved. It appears that many cannot be recovered and a considerable number do not have recent backups.

From the temporary status page dated 10th June:

The event was widely reported:

• Webhost Hack Wipes Out Data for 100,000 Sites
• Webhost Denies Poor Passwords Led to Catastrophic Hack
• U.K. Web Hoster, Customers Scramble After Attack Deletes 100,000 Sites

Particularly sobering is the news that the CEO of LxLabs, implicated as the developers of the software that was hacked, has committed suicide:

• LxLabs boss found hanged after vuln[erability] wipes websites
• Web Hacking Incident Database (WHID) 2009-45: Outcome: Death

Even if you don't have a formal disaster recovery plan, at least make sure you have backups of all your site code, database and other data.

Hardening the underlying server operating system is an important fundamental task to help protect your web applications.

For example, the Payment Card Industry Data Security Standard (PCIDSS) requirement 2.2 states:

Two United States organisations producing guidance in this field are:

• Security Configuration Benchmarks from the Center for Internet Security (CIS)
• Security Content Automation Protocol (SCAP) Checklists from the National Institute of Standards and Technology (NIST) Computer Security Division (CSD)

These are detailed documents and all the recommendations may not be appropriate for your own situation.

This week a friend contacted me about his business website. It seemed his company had paid for both a .co.uk and .com domain name, but the latter was not currently mapped to her site.

It seems the web developer wasn't being co-operative and she was asking for some advice. It appeared that neither domain were registered in my friend's company's name—both named the developers. This makes things much more difficult if the developers are slow to respond to change requests, or fail to renew your domains, or you fall out with them or they go out of business.

But I came across another example on Wednesday. I had to drive through London and later in the day I went to pay the £8.00 charge using the congestion charge online payment service from Transport for London.

I looked at the SSL certificate's details and was very surprised to see the organisation named on the certificate (known as the distinguished name field for organization) was not "Transport for London" but "Cobweb Solutions Ltd", presumably this company.

Whilst this may not be contrary to the SSL Protocol Specification, it is contrary to expectations and good practice. If this were a retail website (where you choose to buy rather than being obligated to pay!), would a cautious potential customer trust the site? The information has also given away vital clues to a malicious user on the software development company and thus perhaps possible approaches to breach the system. Cobweb Solutions' own site has a shopping basket/e-commerce system that has a similarly attributed secure certificate:

Like domain names, your own website SSL certificates, regardless of SSL certificate type should be in your own organisation's name, not anyone else's. In fact this also usually makes the proces of purchasing a certificate simpler.

On my friend's domain name issue, she has contacted the relevant domain name registrars using their disputes process to ask for the details to be updated. She is also checking whose name is on the web hosting contract.

There have been some good discussions recently on the security of cloud computing services. Are you using or considering using external cloud computing for data storage or to undertake business functions?

A recent post A follow-up on SaaS & Cloud Risk reminded me to raise the topic here. The posting highlighted comments on The Register regarding Multi-site Bug Exposes Cloud Computing's Dark Lining included one by Raife Edwards:

Does this affect you? Not sure? Does your business use any of the following (the categories and terminology overlap)?

• software as a service (SaaS)
• platform as a service (PaaS)
• infrastructure as a service (IaaS)
• hosted application
• application service provider (ASP)
• cloud computing
• online office application (e.g. Microsoft Business Productivity Online Standard Suite, Google Docs)
• external web mail (e.g. Hotmail, Gmail, Live Mail)
• peer-to-peer services (e.g. Skype)
• online backup and synchronisation (e.g. Iron Mountain, iDisk, Live Mesh)
• other people's content included directly into your software applications (e.g. news feeds, maps)
• third party online service (e.g. address lookups, payment gateways).

If so, perhaps answer these three questions. Does it matter...

• if someone else deletes, or an unauthorised person views, your data?
• in which geographic location your data are stored?
• if your data or service are unavailable for more than 10 minutes?

If you answered "yes" to any of the above, take time to consider what the effects would be if any of your data was stolen or the service was unavailable for an hour, a day or a week. The considerations are very similar to any other business decision, but it's easy to forget the trust we are placing in another party.

The key security issues to review are software liability, right to audit, service level agreement (SLA), security testing plans, authentication policies, intellectual property, storage locations, system isolation, data encryption in transit and at rest, backup and recovery, archival, support, complaints procedure, contract jurisdiction and legal compliance. If you have cyber liability insurance, you will also need to check whether these cloud services are covered.

In Part 2 (of 2) on Tuesday, I'll highlight some more recent cloud computing issues and provide links to additional discussions.

Update 27th November 2009: See also Cloud Computing Risks.

E-consultancy.com has many excellent online marketing and e-commerce resources, and I read the blogs and forums regularly. The following posting appeared on the forum a couple of days ago:

This cry for help worried me. Although the forum replies were helpful, it did make me wonder how many other web site owners have no idea where their web site is hosted.

If this is really the case here, it probably means the owner doesn't have all the resources to rebuild the site elsewhere and possibly is without back-ups of the data. And what about the intellectual property ownership? It's something which all developers should be discussing with their customers. My first suggestion would have been to contact the development company. A cursory examination of the source code reveals:

This company even showcases the site:

Now, we have no idea of the background and cannot guess if there is anything amiss. But the site is a card payment enabled e-commerce site, and surely the owner has had to comply with the Payment Card Industry (PCI) Security Standards Council's Data Security Standard (DSS)? Knowing where your web site is hosted would be one of the earlier things to discover.

Let's hope it's sorted soon.

Setting up a web server incorrectly can be difficult to change later. Isolating the operating system from web site files and other data using separate partitions or physical devices needs to be done during server commissioning.

It would be usual to have at least three partitions on a typical web server:

• The operating system
• The web site files (scripts and static files such as images and style sheets)
• Server logs

This allows you to restrict permissions - so that if the web site is compromised, it is harder to access the operating system files, and to ensure that logs don't grow excessively and use up all the available space.

Your own data - the database and perhaps other files - should be stored seperately. If possible this should be on other servers, but if not, on a separate partition.

If you allow any user uploaded content, you should also consider storing this on another separate partition, and in any case, never in sub-directories of the web site root. This is to prevent direct access to possibly malicious file content by directly requesting the address in a browser and to ensure the files are stored in an area with limited permissions.

In my post earlier this week on Server Login Protection, I mentioned how file transfer protocol (FTP) is commonly used, and should not be. A data breach this week hints that FTP was the method of access that lead to the data theft.

The Breach blog reported a breach involving Gloria Jean's Coffees' e-commerce site. Their privacy and security statement aludes to higher standards:

The notification letter to the New Hampshire Department of Justice in the United States (US) says the company:

But the strange thing is that it is an e-commerce site and that some of the data stolen was credit card information - card number, name, address and card verification value (CVV), also known as the card security code (CSC) - obtained by modification of the application scripts on the web server. In other words, inbetween the encrypted transfer (using SSL) to the web server and before sending this by an encrypted method to the payment gateway.

Enforcement of the Payment Card Industry (PCI) Data Security Standard (DSS) is much further advanced in the US. So either the site wasn't compliant in which case large fines are winging their way towards Gloria Jean's Coffees Corp, or the auditors may have missed something important here.

See also the related Keeping Up-to-Date with Security Breaches.

The login usernames and passwords for access to the server(s) hosting your web site or application must be protected. If someone has access to your web site's files or the server's operating system, they can potentially alter, delete, copy or add anything they want.

This means every person who requires access having a unique login, and the process of identifying the person and authentication should occur over an encrypted channel (e.g. virtual private network (VPN)). Conventional file transfer protocol (FTP) should never be used, and the service should be disabled or uninstalled in the same way as any other un-necessary service. The FTP log in process is not secure and can lead to the details been stolen and sold to criminals.

Put restrictions on as many of these as possible:

• Who can log in
• What they need to know/have/be to log in
• From where can they log in
• What they can access once logged in

Passwords should be forced to expire, be complex (e.g. length, mixture of case, alphanumerics) and do not allow password re-use (changing a password back to one used recently). Ensure you:

• Change all usernames and passwords when your web site goes live
• Log all failed and successful login attempts
• Log what is done by users
• Review the logs frequently
• Review all user accounts periodically and their permissions
• Revoke accounts promptly which are no longer needed

Watch out especially for accounts used by external or temporary staff, as these can sometimes be forgotten about. Avoid giving access if you can - upload approved modifications yourself for example - at least you will have a record of what has been altered.

I'll include one of my favourite illustrations: the ICRA (formerly the Internet Content Rating Association) web content label generator tool, allows you (or your developers, designers, etc) to give ICRA your own FTP details:

"What happens next?" indeed.

If a web site is unavailable, this will affect everyone who tries to use it. Availability is a usability issue.

A web site being "down" can have the same effect as if someone cannot do what they want, it takes them too long, it leaves them frustrated or it is prone to the introduction of errors.

There are sometimes good reasons for downtime. The servers may be having software updates applied (patching). Depending on the requirements, some organisations may close a web application down during backing up, during a data update or during a change to the application.

Unavailability may also be due to excessive server loading, network connectivity problems, equipment failure or due to an attack by malicious users. If you have to take a site down for repair, your users are being denied use of the service.

Where possible try to minimise planned (scheduled) downtime and monitor the uptime semi-continuously (checking for text on some web pages or important transactions every 5 minutes, from more than one external location). For planned outages, I recommend you inform users well in advance and provide a meaningful message screen - not just a default error page.

A common way malicious hackers try to obtain information about how your website works is to generate errors and see what is displayed. It is particularly important to stop these giving away information that might help someone break into your web site, but equally you should make sure these pages are not advertising someone else's products and services.

When a web site is developed and then set up on the web server(s), it is possible to define customised error pages for all sorts of unusual events like application errors, internal server errors and, the one most people will recognise, not found. The latter is sent back when a page or other file's address is requested but does not exist. The web server sends a response status code of 404 which means "not found" and the text from whichever document has been set for this. By default many sites will return text which gives away the operating system and web server software:

But some hosting companies rather naughtily hope to gain revenue from people typing the wrong address, following an old link or clicking a dead link on another page. Instead of showing a page from your own web site, or the default web server message, they display an advert for themselves and/or adverts for other web sites. These may neither be what you expect, nor want to be associated with. Here is one from a UK limited company's web site:

Check you own web site by typing an address like:

http://[your host name]/123456doesnotexist

or something similar. Hopefully, you will see a page in the style of your own web site with an apologetic message, and not anything else. If not, speak to your developers (or hosting company) and ask them to "add custom error pages for all possible web server errors" and make sure they are your own design. Also ask them to "ensure errors return the correct HTTP response status codes" - this is especially important for correct indexing by search engines.

Here's an example showing how to do it correctly from the British Library:

If you have more than one domain, host name, or also have an HTTPS address, check them all separately. This advertising could also exist on domains you have purchased, but are not currently using for a site.