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?

Like many other document and files on your web site, PDFs can leak information in more than one way. Apart from the normal content, there is often meta data, information from previous versions and sometimes, links to internal resources.

On Wednesday, the Financial Services Authority (FSA) reported they had acquired a list of 38,000 names, addresses and telephone number that boiler rooms were using to target potential investors in worthless shares. The FSA wrote a letter to all the people listed. They also published the letter's outline format as a PDF. Unfortunately four enabled hyperlinks in the document do not reference the www.fsa.gov.uk website as intended, but instead a file on someone's computer, probably at the FSA.

Oh dear. Nothing too serious this time, but everything that is published should be checked for validity before release, and verified after publication. This should include all information, not just the normal visual content. The FSA should know better. Publishing to print (e.g. the letters) removes some of this additional information where publishing to an electronic format (e.g. PDF) doesn't always. All publishing should follow standard procedures and approvals processes should include checks for additional information.

Embedded data may leak business information (e.g. previous changes, authors' comments, file paths, account names, intellectual property) or personal data (e.g. location data, names), and possibly give malicious users information that will help them exploit the organisation's systems.

Also, some good news for the FSA, it has survived the change of government.

Special Publication (SP) 800-122 Guide to Protecting the Confidentiality of Personally Identifiable Information (PII) has been published by the US National Institute of Standards and Technology (NIST). Are you using personal data on your web site?

SP 800-122 provides a useful read for people responsible for assessing privacy and for those designing and implementing privacy controls within information systems and business processes. Importantly it mentions web applications which are increasingly being used as part of business processes. By their nature, data will pass through systems more exposed to public threats.

In the UK, the best starting point for advice is the Information Commissioner's Office guides and other resources, especially the Data Protection Guide and the pages and reports on building privacy in. However, SP 800-122's impact classification methodology, lists of safeguards, examples and scenarios are useful whatever your jurisdiction.

But do note, the definitions, requirements and obligations in NIST SP 800-122 of course relate to US legislation and not to the UK Data Protection Act 1998. In particular they don't cover all eight UK data protection principles. Apart from background reading, they can therefore also be of use for UK organisations considering, or who already have, customers or some other presence in the US.

Thinking of creating a mobile phone application for your business? A major privacy failure with an iPhone application has been reported on the Zero Day blog and is a useful case study.

All iPhone apps have to be approved by Apple to "protect consumer privacy, safeguard children from inappropriate content, and avoid applications that degrade the core experience of the iPhone". But the application Quip from Addy Mobile Inc provides provided unlimited photo texting with the slogan "Why pay more for MMS? Don't you pay enough for your iPhone already?". Well, many of the application's users are paying for it now.

It seems the images (typically photos) were stored on a publicly-accessible web site, with the only access "control" being a random directory (folder) name five characters long—something that is easily iterated through to find photos and breach their customers' privacy. What makes it worse is that many of these messages and images were also turning up in public search engine results leaking sensitive information.

I was unable to find any privacy notice or privacy policy from the company:

The cached search results indicate the images are being stored using Amazon Web Services (AWS) S3. This is not a cloud computing specific issue. It could just as well be on a web site hosted by the company itself. The Quip web site (http://www.quiptxt.com), Quip message site (http://www.quiptxt.com) and Quip S3 image repository (http://quipimg.s3.amazonaws.com) are all currently offline. The comany issued a statement via Reddit. As the Zero Day blog says, these vulnerabilities would have been trivial to fix and protect the confidentiality of users' message text and photos. Using any of common sense, threat modelling, risk assessment or security verification should have identified the problems. I'm sure lawyers in the US will be circling. Since Apple approved the application, let's hope they are ready in case the lawyers knock on their door as well.

Addy Mobile Inc may itself be unavailable soon.

The Ponemon Institute has realeased its latest survey of UK data losses.

The findings of the 2009 Annual Study: Cost of a UK Data Breach indicate that personal data losses ("breaches") are still increasing in cost (per record). The report discusses the growth of data breaches due to malicious attacks and botnets, how prevalent these are compared with other losses and the relative costs. The report also presents comparitive data for losses involving third parties, and for organisations who have experienced their first data loss.

Although we hear a lot about lost or stolen devices (laptops, USB sticks, mobile phones, etc) and malicious/criminal attacks, the most common primary cause for the losses was negligence.

The recent news that the German government is considering buying stolen personal data of its citizens who it suspects of tax evasion is worrying. This sort of activity may fuel personal data theft by leavers and disgruntled employees.

The report is available in PDF format.

Strange as it might seem, some people publish, usually unwittingly, detailed information about the structure of their databases by revealing SQL (Structured Query Language) code.

I don't mean in error messages (which should of course never be displayed to web site users):

Nor in the generated web page source code (you wouldn't do that would you?):

Nor even when it's in a URL (I won't ask):

No, what I mean is when the code is simply indexed and appears on the site's own web pages (often as search result listings), and which then sometimes subsequently picked up by Google, Bing and so on:

So what's going on here? Without more information, I can only surmise, but I think these web sites are using catalogues (pre-built registers or collections) to index the web pages. However some of the pages have static content and others are dynamically built using database queries. So the indexing tool is recording the text from the scripting language rather than what is generated "at run time" to the web site user. These scripts should not be indexed, and thus leaked, in this way; instead the static results need to be merged and ranked with appropriate links to dynamically-created pages. If I search a dictionary web site for "query", I don't want a link to a page that has this in the code, I want the actual pages that define or reference the word "query".

The danger of automated indexing, is that it can include all types of unforeseen files in its catalogue, including backup and old copies of files, unless the indexing strategy is considered carefully:

Having the SQL displayed in this manner makes it much easier for someone to compromise the data, damage the site or its users.

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:

And now have electronic versions:

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:

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

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.

This weekend the clocks change as we revert from British Summer Time (BST) to Greenwich Mean Time (GMT) at 02:00 BST on Sunday 25 October 2009 and the clocks go back, giving an extra hour.

What does this mean for web site security? Does running 01:00 to 02:00 twice matter? Well some brave web application owners will be disabling their systems like this online bank:

And, I don't think it's just being done as a finale to the current Energy Saving Week. Most people, quite rightly, won't be taking this rather severe step. Another millennium bug anyone? The date/time should be considered rather like other untrusted user input. Most problems will probably fall into the "business logic" category such as:

• Failure of time-based logic where dates are being compared.
• Assumptions of uniqueness in time-stamped output (e.g. by a single-threaded process).
• Running tasks again leading to possible:
  • loss of data due to overwriting
  • duplication of exports or emails
  • creation of inaccuracies in management information.
• Chronological ordering anomalies leading to other faults.

It's not just banks and other financial organisations that may have difficulties.

The time change may expose some other vulnerabilities that only exist at changeover time and/or during the next overlap hour.

• Circumvention of brute force attacks on user authentication mechanisms.
• Increased risk due to extension of a session's validity where local time is recorded.
• Failure in data validation routines for time-related comparisons.
• Incubated vulnerabilities where a time-related aspect causes the attack to be possible.
• Denial of service due to extension of account lock-out.
• Using time as a loop counter.
• Additional errors caused by any of the above leading to information leakage.

Recording the offset of local time to GMT/UTC and synchronisation should certainly be done, but may not resolve the time overlap issues. The effects on long-running "saga" requests might be especially difficult to determine. Time dependencies need to be specified and considered through the development lifecycle. Perhaps the bank is right after all?

A friend forwarded me a wine offer from his bank. But the email from his bank included additional information meant to verify the authenticity of the sender.

The bank included the last part of his postcode in the body of the message as well as his title and family name. If those were meant to be for verification purposes, why did it suggest he forward the email to someone else?

Yes, the forwarded email has all the verification details embedded in it. No, it's not the username and password, but it's everything someone would need to construct a phishing email that would be very hard to distinguish from a real one.

This has the feel of using a security measure as a marketing gimmick. Mixing marketing emails and those necessary for servicing a bank account is a difficult balance, but this is way off the mark.

Privacy Notices Codes of Practice is being launched today by Richard Thomas, the Information Commissioner.

Apart from the minor concern that Richard Thomas had included his signature in the document, the draft looked like it would be a very useful code of practice for most small-to-medium organisations including local government and professional organisations. One issue I raised at the time was the potential for aggregation of data to have more meaning than the individual parts, and that this should be considered in privacy notices so that users are aware of any potential problems. Some of the web form examples included didn't necessarily include other (non-privacy related) good practice such as for web accessibility and web usability. There was also some lack of clarity over the use of the word "security", e.g. "Security and Privacy Statement", which I hope has been corrected.

The explanation of fairness, and good and bad examples paper and web form layouts in the draft from the Information Commissioner's Office (ICO) were particularly helpful.

I'm looking forward to seeing the final version.

Update 10:30 hrs 12th June 2009: The ICO has published a press release and the final Privacy Notices Code of Practice.

Update 14:20 hrs 12th June 2009: The final version has incorporated over 60 suggestions as a result of the public consultation, including the issues of aggregation and use of the word "security". Watch out for legislation relating to Assessment Notices and dealing with failures to act on Assessment Notices.