24 October 2014

Hosting

Posts relating to the category tag "hosting" are listed below.

02 July 2010

Web Site Security Basics for SMEs

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.

Photograph of a waste skip at the side of St John Street in Clerkenwell, London, UK, with the company's website address written boldly across it

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).
  • 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?

Posted on: 02 July 2010 at 08:18 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

26 March 2010

Election Debate Data in the Cloud

Debate2010 is an online discussion and debate area, created as a joint project by Salesforce.com and Telegraph.co.uk, intended to gather information on what voters really think during the upcoming UK election campaign.

Screen capture of the Debate2010 website home page at http://debate2010.telegraph.co.uk in a web browser window

The project is built on salesforce.com's Enterprise Cloud Computing platform, Force.com, and it looks like it may use Salesforce Chatter. This will be a further, or new, step by many people into the use of cloud services.

So how have the risks to personal data been presented? Debate2010 is hosted on a Telegraph sub-domain debate2010.telegraph.co.uk which seems to be included in the generic terms of use for "'Telegraph' branded microsites" and and under the registration entry for Telegraph Media Group Limited (TMG) in the UK Information Commissioner's Office's register of data controllers. The registration lists worldwide transfers under "Purpose 4 - Trading / Sharing in Personal Information".

So what about salesforce.com? Salesforce.com provides:

There are plenty of reassurances being given. Debate2010 requires participants to register But remember the TMG is still accountable for the use and protection of the personal data—whether it's in the cloud or elsewhere.

However, it's not clear to me who's getting what information and which terms and privacy statements and security policies apply. It's interesting that TMG hasn't felt the need to update their terms of use (or a privacy statement), even though this microsite seeks political views, is possibly hosted somewhere new and together these might change the business risks. For any web site, the terms of use (and separate privacty notice?) on the actual site should be all that matter, and fully explain to users and participants how their personal data will be used, and by whom.

Posted on: 26 March 2010 at 12:58 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

22 December 2009

Should The Whole Web Site Be SSL?

Britain has some snowy and cold weather at the moment causing difficulty for people getting to shops or going on holiday, and web retailers are likely to be doing brisk trade if they can still deliver before Christmas.

Photograph of the snow-covered landscape around Gatehouse, Northumberland yesterday 21 December 2009

E-commerce sites are often associated with HTTPS (a combination of HTTP with the SSL/TLS cryptographic protocol). There was a time when HTTPS was used only where absolutely necessary due to the additional encryption/decryption overhead it placed on a user's browser (client) and the web application (server). But what's the situation today?

N.B. the padlock symbol or green/blue coloured address bar (depending upon the type of certificate in use) indicating the use of a "secure" web server, does not mean your data is safe; it shows the server identity is verified to a certain extent and that data in transit between your web browser and the web server is probably safe from interception, if it is configured correctly on the server, the certificate has not expired or been revoked, and you can ensure the content you see is on the site the address bar says it is. It also says nothing about how the organisation and partners that handle the data once it has been received by the web server—they might forward it by email, allow third parties to have access to the server, print the data and leave it unprotected, etc.

Almost all web sites have some aspects that should only be accessible over HTTPS. Any sort of data entry form is likely to include personal information and therefore HTTPS should be used to at least protect the confidentiality of the information in transit. User registration, authentication (log in) and any pages that contain confidential information would also be included. Previously, many search engines did not index HTTPS addresses, but since its use was mainly restricted to content protected by some type of authentication and authorisation, this was never much of a concern.

But nowadays, search engines are indexing HTTPS content and a few web sites are only available using HTTPS. Is this a configuration worth following? In a discussion Ivan Ristić described the additional benefits of HTTPS (HTTP over SSL):

... Even with web sites that do not contain sensitive content (no need for confidentiality), you'd still want SSL to provide authentication (are you seeing the correct web site?) and integrity (has anyone modified content in transit?)... Can you have too much SSL? I don't think so.

Issues

So while there are benefits relating to authenticity and integrity, in addition to confidentiality, and dangers to mixing HTTP and HTTPS on the same site due to badly designed authorisation and session management systems, what other issues are there?

Search engines

The most popular search engine robots no longer discriminate whether the content is HTTP or HTTPS, so this is no longer a concern. I am not aware if any adverse effect on search engine optimisation (SEO), other than the effects of changing from HTTP to HTTPS or vice versa which would have to be managed carefully and appropriate permanent redirects set up (also called 301 redirect due to the HTTP response status code of 301 for "moved permanently").

Note that Google, and apparently Yahoo and Microsoft, support the "rel='canonical'" link element and state it can be used for indicating a preference for HTTP vs HTTPS, or vice versa, when pages are available by both. There is also a setting for this choice in Google webmaster tools if you are a site owner. But be careful with allowing both HTTP and HTTPS access to the same page, since this quite often is implemented in a way that adds vulnerabilities to user authentication and session management.

Resources on the server

The server is affected by two aspects—the increased number of requests (see also resources on the client, below) and the overhead of encryption/decryption/building SSL connection. Intermediate proxies should not cache the content and therefore a greater number of requests is to be expected. The additional resources required to serve content using HTTPS are discussed extensively here and in a research paper, i.e. there will be a performance hit, but whether this is a problem depends on your traffic profile, architecture, server utilisation and site's design.

Server side processes

It is possible that any server-side indexing or reporting systems may not support HTTPS and they may need to be updated or configured to work with the different protocol. If you syndicate data to other systems via XML, RSS or web services, these processes will also need to be checked for compatibility.

Traffic management

Network devices that inspect and route internet traffic must be SSL-aware to be able to read and analyse the content. Most modern devices will be able to support this mode of operation.

Client device support

Some devices (e.g. mobile) may not support HTTPS, or HTTPS may not be allowed through firewalls but this is probably less of an issue now. Check if these are issues with your expected users and the devices your site supports.

Address familiarity

Most people will not recognise (or type in) HTTPS addresses and use the common shorthand of the host name (e.g. www.clerkendweller.com) or an alias (e.g. clerkendweller.com) rather than the protocol followed by the full host name. So this would require a redirect from the HTTP address to the HTTPS one, and for many web sites this will be acceptable. For sites of a more sensitive nature, this would have to be handled carefully to protect any session identifiers and still leaves the user potentially vulnerable to a man in the middle (MITM) attack. These are where the redirect is amended and the user taken to a malicious web site instead. If you can rely on users using only the SSL address, perhaps by bookmarking it, you are on safer territory.

Resources on the client

Again there will be a performance hit on the user's client device (e.g. browser of a desktop computer). Much of the time this will not be a problem unless the device already lacks resources (e.g. a mobile device). Then again, due to the lack of caching, more requests will have to be made directly to the server, creating additional lag to download and build content.

Mixed content

Even if all the content from your own site is sent using HTTPS, you may have embedded content such as:

  • client-side web analytics
  • advertisements
  • news feeds
  • widgets
  • images, videos, scripts and other content hosted elsewhere.

These must also all be provided using HTTPS, otherwise the benefit of being HTTPS-only will be lost and users may see "mixed content" warning. But this can be a problem as much third-party content is not available using HTTPS (SSL), notably including Google AdSense, Amazon Affiliates and YouTube. However, Google Analytics does support SSL.

Conclusions and further reading

An all-HTTPS web site provides additional security benefits, but user acceptance and server constraints need to be considered in the site's design and architecture decision making processes. The partial, or full, use of HTTPS (SSL) in a web site needs to be considered carefully during design and development to ensure weaknesses that could be exploited are not built in, and then verified by thorough testing. If you have a heavily consumer-focused web site or include third-party content, some of the choices may have to be on the side of ease of use rather than with the lowest security risk.

"Whole site SSL" should be a serious consideration for "green field" web sites, especially where user authentication is required for any part of the content and for sites where phishing is a major risk (e.g. gaming, web mail, banking). User knowledge and acceptance may be difficult until we see the likes of major banks or large consumer-orientated sites (Google Mail, Google Docs, Twitter, Facebook) use this configuration and and display a warning/educational message to people who go to the non HTTPS site, rather than a redirect.

Posted on: 22 December 2009 at 09:12 hrs

Comments Comments (2) | Permalink | Send Send | Post to Twitter

25 October 2009

From Whiteboard to Web Application

Sometimes finding all the web applications in an organisation can be the difficult part in trying to assess what risks exist.

Transport for London don't just have web sites and, I suspect, an intranet. They have been gradually moving from whiteboards for live underground travel news at tube stations:

Photograph of a transport information board at Great Portland Street station where the information is provided on magnetic tiles and by hand written wipe-dry pens

And now have electronic versions:

Photograph of a transport information board at Farringdon station where the information is provided on an LCD or plasma display

I don't know what technology is being used here, but other information boards have been seen to display web browser error messages leaking network information:

Photograph of a transport information display showing an 'address not found' error message from Firefox

But, what about elsewhere? I saw this on the live electronic advertisement boards at Bond Street station this weekend:

Photograph of an advertisement display board at Bond Street station elevators showing the words 'System Name' followed by a code and what looks like an IP address, written vertically up the portrait-orientated unit

Sorry it's a bit blurred, but I was going up the escalator at the time. Several, but not all the displays had their system names shown rather than an advertisement. It certainly looks like an IP address, but is there a web application inside? I've previously highlighted other information systems and displays that seem to be IP-enabled.

An investigation of your network, examining what is listening on which ports, and correlating this with the actual network traffic, might reveal more web applications than you thought.

Posted on: 25 October 2009 at 18:46 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

04 August 2009

Do You Have SSL Configured Correctly?

Do You Have SSL Configured Correctly? Let me start by saying that "correctly" means "best for you". There isn't a single correct answer, although there are certainly some "don'ts" that apply in every situation.

This information is not about whether to use SSL, and is mainly for your systems folk (or hosting company), but do read on and perhaps gain a better understanding.

Partial screen capture of a report from the SSL Labs Public SSL Server Database showing the host name, IP address, an overall score and part of a bar chart

Ivan Ristić recently announced the SSL Server Rating Guide (draft 10, 21 July 2009) and an associated online assessment tool called the Public SSL Server Database. These had reminded me to post my comments last Tuesday about the slightly related Colour Overload with IE8 Tab Grouping.

The SSL Labs' resources describe, and allow you to check, the SSL configuration of your own, or any other public site that has SSL enabled. The checks span the certificate and three categories of web server configuration settings. Previously, it needed more specialist tools that most people wouldn't have the time or inclination to use.

The rating guide contains much useful information, but will be too detailed for many people. However, do read the "Minimal Configuration Requirements" and pass these on to appropriate person responsible for the configuration and operation of your own web sites. Not every site needs an overall rating of 73 or 85 or whatever. You'll see in Table 6 of the guide, an idea of what might be suitable for a range of web site types.

After all, your competitors, and some customers, have probably already checked your site.

Posted on: 04 August 2009 at 17:56 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

16 June 2009

FTP is not an Option

Many websites are updated using File Transfer Protocol (FTP). Don't do it.

A discussion thread How Do You Store FTP Login Information For Your Clients? highlighted what common practices are, but almost entirely missed the issues of transfer of login credentials over unencrypted channels, privileged access to the whole of the server, account sharing, password and user management.

... [I] also put the info in the client file folders (actual paper client folders) for future reference and sometimes in Outlook business Contact Manager...

It's no surprise that some of the most serious hacks are suspected of being undertaken using compromised FTP accounts.

FTP is not an option. Ask your hosting company or systems staff to disable FTP services and block all traffic to/from your web servers on TCP ports 20 and 21, at your network firewall.

Posted on: 16 June 2009 at 09:28 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

11 June 2009

100,000 Web Sites Lost

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:

We have worked tirelessly through the night and over the last 48 hours to recover as many VPS as possible. However, we have now reached the end of all of our servers, and as such, if your server is not currently up, or not partly up (i.e. it is up but not working due to a configuration issue) then it is unfortunate that you will have lost your data due to this third party attack.

The event was widely reported:

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

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.

Posted on: 11 June 2009 at 09:46 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

26 May 2009

System Hardening

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:

Develop configuration standards for all system components. Assure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards.

Two United States organisations producing guidance in this field are:

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

Posted on: 26 May 2009 at 10:56 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

24 April 2009

Put Your Own Organisation's Name On It

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.

Partial screen capture of a web browser's address bar with the URL https://cclondon.tfl.gov.uk/cclondon/payments/paycharge/pay.aspx and showing part of the web page

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. SSL certificate security information stating the connection to cclondon.tfl.gov.uk is secure and the certificate is issued by Thawte Premium Server CA SSL certificate information stating the certificate name details are 'cclondon.tfl.gov.uk, Cobweb Solutions Ltd, Sydadmin Team, Fareham, England, GB'

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:

SSL certificate information stating the certificate name details are 'shop.cobweb.com, Cobweb Solutions Ltd, Sydadmin Team, Fareham, England, GB'

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.

Posted on: 24 April 2009 at 09:32 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

17 April 2009

Web Application Security in the Cloud - Part 1

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:

IF... you own, and run, your own servers, or systems/software... AND, a "common vulnerability" exists, and is exploited... You MAY be vulnerable... you MAY have a security issue... you MAY be targeted... you MAY not have adequately protected your system... you MAY be hit by the problem... you MAY have issues, and losses... possibly.

If, however, you are dependent upon any, EXTERNAL, single point-of-attack/vulnerable-point... then you WILL be hit... you WILL be affected... you WILL have losses... and you WILL be totally-dependent upon EXTERNAL-interests in "fixing", and recovering... based upon THEIR competence, and on THEIR time-table... and, to suit THEIR perception of THEIR interests.

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.

Posted on: 17 April 2009 at 11:03 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

More Entries

Hosting : Application Security and Privacy
ISO/IEC 18004:2006 QR code for https://clerkendweller.uk

Requested by 54.234.216.180 on Friday, 28 August 2015 at 20:07 hrs (London date/time)

Please read our terms of use and obtain professional advice before undertaking any actions based on the opinions, suggestions and generic guidance presented here. Your organisation's situation will be unique and all practices and controls need to be assessed with consideration of your own business context.

Terms of use https://www.clerkendweller.uk/page/terms
Privacy statement https://www.clerkendweller.uk/page/privacy
© 2008-2015 clerkendweller.uk