Today I came across a useful marketing-related discussion of common e-commerce trustmarks.

Which E-commerce Trustmarks Are Most Effective? describes a study of twenty different security-related trustmarks that cover SSL certificates, payment card merchant identity, business accreditation and that all-embracing term "security".

The 150 US respondents identified which logos they recognised, and then ranked them according to level of "reassurance". Very few trustmarks were actually recognisable, but those that were appeared to provide some level of increased trust. Of course, the top three (PayPal, Verisign and McAfee) are different types of thing — a payment service provider, an SSL certification authority and a site information security scanning service. Maybe it doesn't matter what service you provide as long as it is recognisable?

The blog post also lists other ways to increase user trust, and suggests that good checkout design can trump trustmark logos.

No mention of browser SSL indicators, security labelling, national reputation or HTTP security headers! And neither are having lots of credit card logos displayed nor "PCI DSS compliant" beside a PCI SSC logo which of course aren't trustmarks, but are used as such by some organisations.

Maybe UK customers would respond differently?

This year's most important North American application security event will be held during September in Minneapolis, USA.

The training and conference is being organised by the OWASP Minneapolis-St. Paul chapter (OWASP MSP). They kindly asked if I'd write the first blog post on the AppSec USA 2011 web site about the the forthcoming 10th anniversary of OWASP's founding. I wrote the post in January, but the event announcement was only made this week. The web site is now live, and the call for presentations and training open.

Oh, and I should mention OWASP's other application security conferences & events including AppSec Europe 2011, Dublin in June. I am hoping to submit training and presentation proposals for both of these.

Following my posts about Security Labelling, the effect of Location and Trust .UK, I read about an early draft of proposed privacy labelling icons.

Privacy policies can be a nightmare and some bright people got together to discuss ideas and this lead to a workshop in London earlier this year.

Well, there are now some suggestions for privacy icons which would help users understand the purposes of use, with whom it is shared and how long it is kept for. These could complement well written privacy notices.

Many of the issues with the proposal are discussed in the project's blog posts and associated comments. The largest obstacles I see are where different "policies" apply to different user roles and mis-labelling by site owners, even if they participate. In the former, customer data may be held for longer than other visitor data, and employee data may be help for decades (and may be required by law). All sites will want "good labels" and it might be easy to say the privacy labels apply to some users/some processes, and yet not label the other uses. The definition of "intended use" is also open to interpretation — an issue currently being discussed by the US Federal Trade Commission. However, I think this is a great initiative and encourage you to get involved.

On a related topic, remember the UK ICO's consultation on its draft Data Sharing Code of Practice closes tomorrow.

On the second day of AppSec Washington DC 2010, I had a particularly difficult choice to make concerning which session to attend after the first break.

In the end, I went to Dan Cornell's talk about Application Portfolio Risk Ranking (slides) as I thought it was most relevant to my "day job". It was a great presentation and it's worth asking Dan for a copy of his spreadsheet if you are interested, but it meant I missed Jeff Williams' talk about Website Security Facts Labelling (slides).

I mentioned initiatives in this area from 2002 onwards in my previous blog post about Software Assurance Labelling. Having now read the presentation slides and related discussion on OWASP mailing lists, I can see Jeff Williams' ideas have moved forward significantly. He has even produced a Security Facts Tool to help build demonstration security facts labels, for example:

Well, that's a long label. The concept is based on his earlier work, and research on related consumer labelling examples from other industries (see presentation slides). The label includes information about what major modules and code libraries are used, the platform components, interfaces and connections, what types of sensitive data are collected, processed, stored & transmitted. But it also suggested that it should include some concept of how security risks have been reduced—in this case, whether the risks in the OWASP Top Ten 2010 have been addressed, and what common security practices are in place in the development lifecycle using those defined in the OWASP Software Assurance Maturity Model. The label might benefit from having the target site/application name recorded.

But the key finding from his research was the precise content of the label does not really matter that much. In his words:

Whatever you think about the appropriateness of the items included, one area where I think this labelling could be used immediately is in procurement. Organisations will often ask potential bidders for examples of previous work. The design agencies/software houses could be asked to complete the security facts label for whichever web products they choose to showcase—they should have this information available, they can use the tool quickly to produce a label and it's not going to become released to the public domain. The acquisition team will then have greater knowledge of the technologies and processes used, to help make more informed decisions about software choice instead of "does it look nice". The actual specification and contract will need to be more explicit about security, but for examples of previous projects, this would work very well.

So the concept is to make security concrete and visible—see the final "Security in Sunshine" slide at the end of the presentation slides. And, contribute your ideas and feedback.

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?

Having just mentioned the Home Office Cyber Crime Strategy, it's interesting to note the resurfacing of the "dispute" this week between Facebook and the UK's Child Exploitation and Online Protection Centre (CEOP).

Following further discussions in which CEOP flew to Washington DC to meet Facebook representatives, Facebook has continued to reject putting the CEOP Report "button" on user profile pages. It just seems strange that CEOP seem to be making this such a deal-breaking issue. CEOP's work is very important and should be supported; the media however seem to have identified that the "button" will solve all the internet's ills, and CEOP don't seem to be disagreeing with this idea.

After all, Bebo has been displaying the button for some time, but there doesn't seem to be any reference to CEOP at all on Bebo's safety pages, nor on the home page, sign-up pages or privacy statement. And you have to strain your eyes to spot it on other pages:

If the button's design and text have any meaning, rendering them so small they are illegible is pointless, and undermines the effort. Even CEOP's own page on Bebo has the same tiny button and no larger version.

Children and other people need consistency to identify its purpose. The CEOP buttons on various sites link to different sub-domains (ceop.police.uk, www.ceop.police.uk and www.ceop.gov.uk). Good practice would be only to use a single consistent domain and to enforce SSL to confirm the identity of the CEOP site and to ensure the information received hasn't been modified in transit.

The button's design seems to have changed since first introduced at the end of 2009. Is it "Report Abuse", "Click CEOP", "CEOP Report" or something else? This is the button on Childline:

and on Bully Aware:

Even Childline doesn't have the button on many pages. Facebook does seem to be trying, and it is perhaps its market leading position that has attracted all this intense interest from CEOP. I'm all for educating people, especially children and new users, about internet privacy, security and personal safety (and the CEOP advice is great), but is putting a highly-branded button on every page the right answer? I can foresee news stories "I thought it was safe because there was a CEOP Report logo on the page". Organisations should be judged on what they achieve, not whether they support every initiative by others in every country they operate. If Facebook get it wrong, they deserve to get into trouble. Apparent brand pushing doesn't help.

Let's get good advice into privacy notices, help pages and terms of use. And make sure it's easy for users to report possible problems and threats (personal or otherwise). And let's avoid the sort of legal mumbo-jumbo CEOP include in their sign-up form (yes, the form and submission really weren't over SSL, unbelievable) for organisations that want to use the CEOP Report logos, as opposed to those who might add them from copies elsewhere or to tempt people to web sites hosting malware or dubious goods and services. "Help I've been bullied" might otherwise quickly turn into "help my computer's been taken over and I've lost all my pocket money".

On Wednesday I attended the Information Commissioner's Office (ICO) Personal Information Online Conference 2009 at which the ICO launched their consultation on the new Personal Information Online Code of Practice.

Manchester and Salford gave us a beautiful sunny day for the event which briefed delegates on the ICO's approach to data protection and an outline of the collaborative process used to develop the draft code of practice. Iain Bourne, Head of Data Protection projects, noted that fewer than hoped public sector organisations had been involved to date, and they would like more feedback from this sector in particular during the consultation phase that ends on 5 March 2009.

My first impressions are this will be a useful document for organisations without staff dedicated to data protection or compliance, especially once the examples and SME checklist are added. The structure and content are still a little raw, but probably about right for the start of a 12-week consultation process. Areas where I am already considering providing feedback are:

• local storage of personal information (not just cookies)
• verification of protection
• suppliers, sub-contractors and staff
• monitoring and anomaly detection
• transmission of personal information
• inclusion of third party content in web sites
• using cookies to enforce an opt out
• additional reference materials.

The full text and consultation document is available as a PDF.

Feedback on the Personal Information Online Code of Practice can be provided using the ICO's consultation portal with further background available in the related press release.

The results of the Internet in Britain 2009 survey by the Oxford Internet Institute highlights people's usage and concerns about the internet and web sites.

Some aspects of the report relating to e-commerce, trust, fraud and privacy are summarised below.

• Confidence in the Internet and the commercial services that it offers remains high.
• Use of the internet is leading to greater trust in the technology as a source of information and medium of communication and services.
• Since 2007, people are now just as concerned about credit card fraud, and the right to anonymously express opinions, but less concerned about the threat of computers and the internet to privacy.
• Negative experiences of the internet are not as great as portrayed in the media.
• The survey examined what personal information people are willing to provide when registering on websites.
• A general desire for greater regulation of the internet.

Read the report for the methodology, full information and detailed analysis. The report also provides useful data on internet penetration and usage patterns such as for web 2.0 and mobile technologies.

In this month's PC Pro magazine, Davey Winder commented on the Information Security Awareness Forum (ISAF) concerning their recommendation to have "report abuse" links on web sites.

In his column titled "Stupid Security" in the Online Security section of Real World Computing, he says there are too many "click this" links on most sites and that a report abuse link on a fake site is likely to give you a fake answer. Very true.

But that doesn't get away from the problem that people still need to have somewhere to go to ask for help, to query account entries, to answer concerns or to report suspicious emails and web pages. That's why we have phone numbers printed on credit cards, bank statements and even on web sites.

The ISAF and its member organisations are doing more than many others, including their excellent Directors' Guides, and they didn't deserve this. Perhaps PC Pro will become a member and contribute to the effort to promote and improve information security awareness.

Do people understand tab grouping in Internet Explorer version 8 (IE8)? This was a new idea introduced to collect together and identify tabs originating from the same source.

Note this isn't grouping based on the web site (domain name)—it's grouping from which other tab you clicked. The group colour is selected randomly, so yesterday's blue might be today's yellow.

My concern with tab grouping is not the concept, but the use of colour. Not because of the accessibility difficulty that some people may have distinguishing between colours, which is partially addressed by Microsoft in a tab naming convention, but because the colours can lead to confusion about SSL certificates. Take this example with four tabs open, the first tab selected and a current Extended Validation (EV) SSL certificate in use:

1. Bank No X online banking login (domain A / SSL)
2. Bank No X information page (domain B / non-SSL) opened using a link on page 1
3. Bank No Y home page (domain C / non-SSL)
4. Bank No Y business banking login (domain D / SSL) opened using a link on page 2

What does green mean? How about if we have an invalid SSL certificate and the tab group is green:

Confusing? Yes. It can lead to this type of misunderstanding:

Helping people to identify and reject invalid SSL certificates is important—IE8 users are being put at a disadvantage by Microsoft. I'd like to see tab grouping turned off by default for now, and some other indicator of tab groups used instead of distracting colour-coding. Perhaps, since new tabs are always opened adjacent to their 'parent', even something as simple as this mock-up might suffice:

Is this easier to understand? What do you think?