In December I mentioned Nominet had begun a policy review jointly with the UK-wide Serious Organised Crime Agency (SOCA), concerning Dealing with Domain Names Used in Connection with Criminal Activity.

Since the announcement in December, Nominet has received over 200 written responses to the brief and also met with some groups to hear their views and concerns. Last month, Nominet invited stakeholders to take part in the issue group and the list of participants has now been announced. Their first meeting will be on the 4th April 2011.

To aid the discussion, Nominet appointed an independent expert to review the responses received to date, summarise them and also set the issue in the appropriate legal context. The background report has been published, and Nominet are seeking feedback on its completeness before the end of next week (31 March). Section 3 lists 13 suggested questions for the issue group to focus on.

The reason I mention this topic again, is because the 19-page background report is really an excellent read, and although not legal advice (of course!), it does give a good insight into some of the most important legal issues of operating a web site in the UK e.g. the diverse range of organisations in the supply chain (or "value chain" as it is referred to in the report), contractual obligations of registrars, extraterritorial effects, and useful reminders about the implications of the Digital Economy Act 2010 and the Terrorism Act 2000.

The report also includes good nuggets of information such has how various agencies interact with Nominet, and that Nominet has "locked" 2,667 domains to date. If you do just two things today, check domains are registered under your own organisation's name and ensure all the details provided to Nominet, and other registries, have been recorded accurately.

Update 24th March 2011: The link to the background report has been altered, following the discovery by Nominet of an error in the original text.

Knowledge of application context is used routinely in mobile applications—for example sensing a user's context (e.g. location and physical actions, time, etc), reducing network usage during periods of inactivity and designing for users. But how does this idea transfer to the server?

I almost called this environmental awareness, but didn't want to cause confusion with discussions about network/server environments. By 'situational awareness' I mean awareness of factors external to the application that might be used to affect its behaviour. In my talk this week about application intrusion detection, I will be discussing how an aspect such as the general risk level to an organisation/application might be used to alter an application's actions (e.g. amount of logging, attack detection thresholds). But this awareness, can be used beyond attacker detection and response.

Information is knowledge and additional awareness of external factors can be used to control changes to the application. An adaptive application can learn change in response to outside factors. And no, I don't mean displaying an intrusive and annoying paperclip that says "It looks like you're writing a letter". Apart from standard functionality the user sees, some ways your application may already be doing this are:

• customising content based on:
  • geo-location information
  • user preferences
  • device type (e.g. mobile), browser and screen resolution
  • typical user behaviour
• implementation of additional delays for failed attempts at authentication
• use of reputation-based systems
• displaying the number/identities of active/logged-in users
• detecting usage of the application by users from a different location than they had used previously (e.g. IP address)
• showing advertising based on users' behavioural characteristics.

But what else can be done? I remember chatting with someone during an unexpected period of severe weather which had disrupted travel in south-east England one morning. They had explained that in situations like this when their call centre was under staffed, they had procedures in place to reduce the length of each customer call, by shortening their own scripts taking out offers for helping with anything else and cross-selling/up-selling. The dialogue script was adapted to the situation. A web application could respond in a similar way during increasing, and higher periods of demand, to increase availability:

• switch to more static content (e.g. change the home page to static HTML rather than a scripted dynamic page)
• swap to lower bandwidth assets (e.g. display photographs instead of videos, use lower resolution photos)
• use third-party servers for some content (e.g. video on YouTube)
• reduce the size of pages and number of page elements by dropping out non-core material (e.g. promotional items, banners)
• increase caching
• delay non-core server intensive activities (e.g. management report generation)
• provide links to printable forms to divert some or all users of a particular online service.

Similarly, if a local (e.g. dynamic PDF creation or chart generation), back-office (e.g. data archive) or third-party service (e.g. payment authorisation, address look-up) is detected as running slowly or has become unavailable, some of the following may be possible:

• switch to cached data
• add a queue to access the function
• slow down the speed at which users can undertake the function
• offer alternative (quicker) ways to complete the transaction
• take the service offline, but offer to email users back when it is available again.

Similar changes could occur in advance of, or during, known scheduled application maintenance periods:

• advanced warning notices to users
• timed count-down to function or application shutdown
• preventing users beginning new tasks which might not be able to be completed before the shutdown
• ability for users to request notification that the service is back up.

The important thing (remember "clippy") is not to change the user experience too noticeably, and where there is a significant change (e.g. download the form instead of doing it online), provide a time-stamped explanation of the change and reasons.

These measures all bring complexity, and it is important they do not introduce additional vulnerabilities to the application. The problems are quite likely to be in authentication, authorisation and session management and need to be identified during security specification and verification processes. The effect on data integrity, including accuracy, also needs to be considered. But the measures are worth considering where the alternative is additional standby staff and increased usage of other channels.

Sometimes when I'm out socially and people ask what I do, the conversation progresses to concerns about their own web site. They may have a hobby site, run a micro-business or be a manager or director of a small and medium-sized enterprise (SME)—there's all sorts of great entrepreneurial activity going on.

It is very common for SMEs not to have much time or budget for information security, and the available information can be poor or inappropriate (ISSA-UK, under the guidance of their Director of Research David Lacey, is trying to improve this). But what can SMEs do about their web presence—and it is very unusual not to have a web site, whatever the size of business.

Last week I was asked "Is using <company> okay for taking online payments?" and then "what else should I be doing?". Remember we are discussing protection of the SME's own web site, not protecting its employees from using other sites. If I had no information about the business or any existing web security issues, this is what I recommend checking and doing before anything else:

• Obtain regular backup copies of all data that changes (e.g. databases, logs, uploaded files) and store these securely somewhere other than the host servers. This may typically be daily, but the frequency should be selected based on how often data changes and how much data the SME might be prepared to lose in the event of total server failure.
  • check backup data can read and restored periodically
  • don't forget to securely delete data from old backups when they are no longer required
• Use a network firewall in front of the web site to limit public (unauthenticated user) access to those ports necessary to access the web site. If other services are required remotely, use the firewall to limit from where (e.g. IP addresses) these can be used.
  • keep a record of the firewall configuration up-to-date
  • limit who can make changes to the firewall
• Ensure the host servers are fully patched (e.g. operating system, services, applications and supporting code), check all providers for software updates regularly and allow time for installing these.
  • remove or disable all unnecessary services and other software
  • delete old, unused and backup files from the host servers
• Identify all accounts (log in credentials) that provide server access (not just normal web page access), such as used for transferring files, accessing administrative interfaces (e.g. CMS admin, database and server management/configuration control panels) and using remote desktop. Change the passwords. Keep a record of who has access and remove accounts that are no longer required and enable logging for all access using these accounts.
  • restrict what each account can do as much as possible
  • add restrictions to the use of these accounts (e.g. limit access by IP address, require written approval for use, keep account disabled by default)
• Check that every agreement with third parties that are required to operate the web site are in the organisation's own name. These may include the registration of domain names, SSL certificates, hosting contracts, monitoring services, data feeds, affiliate marketing agreements and service providers such as for address look-up, credit checks and making online payments.
  • ensure the third parties have the organisation's official contact details, and not those of an employee or of the site's developers
  • make note of any renewal dates
• Obtain a copy of everything required for the web site including scripts, static files, configuration settings, source code, account details and encryption keys. Keep this updated with changes as they are made.
  • verify who legally owns the source code, designs, database, photographs, etc.
  • check what other licences affect the web site (e.g. use of open source and proprietary software libraries, database use limitations).

Do what you can, when you can. Once those are done, then:

• Verify the web site and all its components (e.g. web widgets and other third party code/content) does not include common web application vulnerabilities that can be exploited by attackers (e.g. SQL injection, cross-site scripting).
  • use resources such as the OWASP Top Ten and WASC Threat Classification
  • build security requirements into future developments
• Check what obligations the organisation is under to protect business and other people's data such as the Data Protection Act, guidance from regulators, trade organisation rules, agreements with customers and other contracts (e.g. PCI DSS via the acquiring bank).
  • impose security standards and obligations on suppliers and partner organisations
  • keep an eye open for changes to business processes that affect data
• Document (even just some short notes) the steps to rebuild the web site somewhere else, and to transfer all the data and business processes to the new site.
  • include configuration details and information about third-party services required
  • think about what else will need to be done if the web site is unavailable (does it matter, if so what exactly is important?)
• Provide information to the web site's users how to help protect themselves and their data.
  • point them to relevant help such as from GetSafeOnline, CardWatch and Think U Know
  • provide easy methods for them to contact the organisation if they think there is a security or privacy problem
• Monitor web site usage behaviour (e.g. click-through rate, session duration, shopping cart abandonment rate, conversion rate), performance (e.g. uptime, response times) and reputation (e.g. malware, phishing, suspicious applications, malicious links) to gather trend data and identify unusual activity.
  • web server logs are a start, but customised logging is better
  • use reputable online tools (some of which are free) to help.

That's just the basics. So, what would be next for an SME? If the web site is a significant sales/engagement channel, the organisation has multiple web sites, is in a more regulated sector or one that is targetted particularly by criminals (e.g. gaming, betting and financial), takes payments or does other electronic commerce, allows users to add their own content or processes data for someone else, the above is just the start. Those SMEs probably need to be more proactive.

This helps to protect the SME's business information, but also helps to protect the web site users and their information. After all, the users are existing and potential customers, clients and citizens.

Oh, the best response I had to someone when I was explaining my work: "You're an anti-hacker than?". Well, I suppose so, but it's not quite how I'd describe it.

Any comments or suggestions?

It can be hard to justify business spending when web sites are often viewed as low-value assets. The fact that so much Internet content and services are free, and you can buy a web site for less than the cost of a colour TV licence in the UK reinforces this idea in many small and medium enterprises (SMEs).

Much of my work is related to dealing with security incidents, such as web sites which have been hacked, or where an organisation is having security requirements imposed by their own customers and clients. Often these activities are undertaken late in the project and are therefore less effective, and more costly, than they might need to be.

I adhere to the principle "prevention is better than cure", and encourage the early consideration of security and privacy matters—just like any other business process requirement. It was encouraging to read the useful guidance and pointers on Business Cases For Software Security Initiatives but for many organisations, the issues are too complex and they don't have any supporting data. For those I recommend, as a starting point, concentrating on four types of issue:

1. mandatory compliance issues (e.g. legislative and contractual)
2. problems which can assist theft or fraud
3. security events which would be severely disruptive and possibly put the organisation out of business
4. issues for customer trust and ongoing reputation

It's always organisation specific though. As organisations mature, they can be encouraged to look at wider security issues—but, let's get the basics right first.

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.

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.