The regulator for premium rate services (PRS) in the UK, PhonepayPlus (PpP), has issued new consolidated guidance for when premium rate is used as the mechanism for application-based payments.

Application-Based Payments provides guidance relating to the obligations in the PhonepayPlus Code of Practice (as a PDF). The guidance is not binding and does not form part of the Code of Practice, but instead provides information on how compliance with the Code can be achieved.

The guidance is concerned with outcomes from the Code:

• Transparency and Pricing - [2.2] "That consumers of premium rate services are fully and clearly informed of all information likely to influence the decision to purchase, including the cost, before any purchase is made."
• Password Protection and Security - [2.3] "That consumers of premium rate services are treated fairly and equitably." and [2.4] "That premium rate services do not cause the unreasonable invasion of consumers' privacy."
• Complaint Handling - [2.6] "That consumers are able to have complaints resolved quickly and easily by the Level 2 provider responsible for the service and that any redress is provided quickly and easily."
• Method of Exit - [2.3] That consumers of premium rate services are treated fairly and equitably.

The guidance suggests how pricing and other key information should be presented before downloading an application & for purchases within an application, information where a service can be accessed on more than one device or channel, fermium services, how to provide a method of exit, consumer consent to charging, password protection and practices for handling complaints. It also discusses misleading promotions and virtual currencies, and most importantly that mobile-based payment service providers should ensure their services are compatible with every technical platform and/or device on which they are promoted.

One issue in particular is worth highlighting. Paragraph 7.2 of the guidance says that if malicious software (malware) is found, then a tribunal under the Code may not be likely to consider any proof of consent for charging to be robust enough.

If you are developing applications that rely on premium rate charging mechanisms, read the guidance with care. PpP has sharp teeth. In a recent case unrelated to this guidance, two companies were each fined £100,000 for placing adverts for premium rate services on typo-squatting hostname websites which looked like other popular websites.

Even if your applications do not fall within the controlled PRS covered by PpP, there is still a lot of useful good practice information for other consumer services in the Code and related guidance documents.

Following a consultation process earlier this year, the European Payments Council has published the first edition of a white paper on mobile payments.

The European Payments Council (EPC) supports and promotes the creation of the Single Euro Payments Area (SEPA). In this white paper, the EPC sets out to present an overview of mobile payments (contactless and remote) for SEPA, and the initiation of of payments via the mobile channel leveraging existing SEPA payment instruments—SEPA Credit Transfer (SCT), SEPA Direct Debits (SDD) and SEPA for Card Payments. Whilst this is not a technical document there is some mention of the security aspects.

The paper describes the business rationale for mobile payment services, example usage scenarios and the business & technical aspects for mobile contactless (proximity) card payments. The payment scenarios include access to premium web content using credit card payments and also direct debit subscription services. If you are scoping out usage scenarios for future services which may involve mobile payment, the descriptions and diagrams are invaluable. Further implementation guidance is expected in due course.

A second edition of the white paper is due in the first part of 2011 that will contain more detailed information about mobile remote payments.

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?

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 recent proposed revision of the policy on web tracking technologies for US federal web sites by the Office of Management and Budget set out four principles regarding user analytics and tracking.

• Adhere to all existing laws and policies (including those designed to protect privacy) governing the collection, use, retention, and safeguarding of any data gathered from users.
• Post clear and conspicuous notice on the website of the use of web tracking technologies.
• Provide a clear and understandable means for a user to opt-out of being tracked.
• Not discriminate against those users who decide to opt-out, in terms of their access to information.

The document recommends avoiding outsourced tracking and outsourced data analysis—issues not thought about by many organisations. Just because a third-party service is cheap, doesn't necessarily mean it's the appropriate method to use. I'm less convinced about the example of using cookies to record opt-outs.

The proposed revision attracted a well-considered joint response from the Center for Democracy & Technology and the Electronic Frontier Foundation. They suggested three additional principles.

• Limit use of tracking data.
• Limit retention of tracking data.
• Obtain third-party verification.

The response also referenced their May 2009 Open Recommendations for the Use of Web Measurement Tools on Federal Government Web Sites which recommended the following:

• Use data only for measurement.
• Prominently disclose.
• Offer choice.
• Limit data retention.
• Limit cross-session measurement.
• Obtain third-party verification.

Whilst none of the final guidelines will be mandatory outside the US federal sector, the issues raised are worth consideration by all commercial and non-commercial web sites. For example, the recommendations and principles above could be used to help guide a privacy impact assessment of an organisation's own use of web analytics and tracking technologies.