The UK Centre for the Protection of National Infrastructure (CPNI) have published new guidance on understanding and managing the risks from phishing and pharming.

Whilst most readers of this blog won't work on projects considered part of the national infrastructure, that doesn't mean you should ignore good, free advice.

The CPNI document discusses the threats and impacts (on employees, customers, clients and citizens), the modes of attack and possible countermeasures. I'm pleased to see that countermeasures to reduce the likelihood of successful attacks include both technical and cultural measures. Measures to mitigate the effects of successful attacks are also discussed.

Although some of the document is necessarily technical in places, the case studies in Appendix C should make sense to everyone. Remember, this is about business risk, not technical risk. The "I don't understand technical things" argument does not stand up.

Of course, assessing and implementing information security policies and controls is hardly ever simple or quick. But with the government's aim to reduce the number of different web sites this process may be a little easier. It's good to see such guidance, especially when the Central Office of Information (COI) has to date avoided the subject of security in its own web standards and guidelines. In view of the perception that the government isn't keeping up with threats (for example see the response to the petition to upgrade away from Internet Explorer 6), how are the CPNI phishing and pharming countermeasures being implemented by the government?

Knowledge about the degree to which the cultural countermeasures have been adopted within the government sector cannot be adequately measured from outside, and it would be good to see these included in work performed by the National Audit Office. Similarly most of the technical countermeasures would require privileged access to government networks (and permission!). However "use of SSL and TLS" and "signing of digital communications" should be easily observable, without doing any testing, from the outside world.

These two measures have security benefits beyond protection against phishing and pharming. They can assist citizens wanting to verify the identity of, and rely on the integrity of the information they see on what looks like a government web site, or receive in an official-looking email or other form of correspondence, perhaps during a national emergency. These types of event can attract themed phishing attacks for example. I haven't received any official government electronic communications recently apart from reminders from HMRC about tax deadlines and the like, so can't comment on how the sender and data integrity is verified. The tax reminders don't contain any sensitive data, and occur when there are known forthcoming business events or relate to actions undertaken by myself, so correctly don't need the same degree of verification.

But anyone can visit a web site, so what about those? Well, the CPNI web site appears to also be available over SSL/TLS as we'd expect. But, looking at https://www.direct.gov.uk using SSL (now more correctly called transport layer security, TLS) in the Chrome web browser, I was a bit surprised to see:

and this is the same for the prime minister's web site at https://www.number10.gov.uk/. Another possible primary governmental address is https://www.hmg.gov.uk which gives:

Maybe these have been deemed to be acceptable risks. But let's hope the other recommended countermeasures have been implemented.

Early last year I mentioned the security implications of the Web Content Accessibility Guidelines 2.0 and the scope for accessibility testing. I also spoke about whether an accessible web application be secure at the OWASP AppSec EU09 conference.

At that time, I found it fairly difficult to identify many web sites that were making WCAG 2.0 conformance claims.

The US Department of Justice is now seeking comments on proposed rule changes to the Americans with Disabilities Act that might make compliance to Level AA of WCAG 2.0 more widely mandated. A full analysis of the legal implications and timescales are presented on the Outlaw web site. As we see increased take-up in the US, it's likely similar levels of compliance will be required elsewhere.

In my conference presentation, I discussed how some security vulnerabilities could occur if WCAG 2.0 is implemented poorly.

This year I have mentioned web application security programmes, how software vulnerability testing recommended risk-based, application security programmes and generalised results from a survey about web application security programs.

But what are enterprises doing in real life and what are the issues? During the second day of OWASP AppSec Research 2010, Michael Craigue of Dell presented on Secure Application Development for the Enterprise: Practical, Real-World Tips. Although I missed it, people who did attend this track were enthusiastic about it and the video recording has now been published. I watched it last weekend.

Michael described Dell's 10-strong Global Information Security Services group and how it works with 3,000-5,000 developers in internal teams and how their appsec work is built on a published and maintained secure application development standard. Some of the problems encountered at Dell were platform diversity, security expert retention, the need to develop self-help documentation for the low and medium risk projects, lack of good metrics around security awareness training, high overhead of conventional threat modelling and the need to build security into the development lifecyle slowly, and in a business-focused manner.

At Dell, the project risk is calculated from ten factors including data classification, compliance requirements, whether it is externally facing, and the security knowledge of the development team. Interestingly, in the final questions from the audience, Michael mentioned Dell are using Open SAMM to identify gaps, measure how well their security programme is performing and to focus improvement efforts. Even projects that the group does not get involved with directly, are subject to quality checks and audit such as using Control Self Assessments (CSAs), which look for the artifacts required in the self-help documentation, even for low-risk applications.

There is another description of how software assurance practices at Ford in 2009, and recently published on US DHS's best practices web site Build Security In. The Ford programme is quite different. Every application security programme is unique because every organisation's culture, application and acceptance of risk is different.

What is yours like?

My company recently received a leaflet from (HMRC) with an invitation to attend one of their EmployerTalk seminars about payroll and tax including pay as you earn (PAYE). On the way from my hand to the recycling bin, something caught my eye:

Character set encoding problems are very common in web sites and web applications, but it is quite unusual to see this type of thing in print. I suppose the ñ character is perhaps meant to be a dash or tilde of some sort, and some sequence of conversion processes from design to print has changed it into the ñ. Perhaps there was a Mac using Mac OS Roman somewhere in the chain.

Transmitting and display of text in web systems suffers the same manner. Begin by agreeing what character sets will be used for the database application and rendered HTML, and then stick to them. Make sure the character set is defined in the application's configuration and defined as a header with every HTML response.

Oh, and HMRC repeated the mistake further into the leaflet too; so there's a problem with proof reading (testing) too!

Visa Inc has released a guide to Card Data Tokenization Best Practices.

The intention is to provide guidance on using non-sensitive surrogate values (tokens) as a proxy for card data (typically the primary account number or PAN) by merchants, vendors, service providers and acquirers. This in turn can reduce where card data exists, and therefore the scope for compliance with the Payment Card Industry Security Standards Council (PCISSC) Data Security Standard (DSS). The guidance joins other information in Visa'a Cardholder Information Security Program (CISP).

The guidance describes Visa's best practices for the tokenization system, token generation, token mapping, the card data vault (the secure repository that maps tokens to cardholder data), cryptographic key management and the management of historical data.

However the guidance may not generally accepted and is being debated here and here, especially with regards to reversibility of the process and the use of salts when hashing, but Visa are seeking feedback on this first version, and have asked for responses by 31 August 2010 to be sent by email to inforisk@visa.com.

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.

British Standards Institute has released a new draft for public comment (DPC) on the BS 8878 Web Accessibility - Code of Practice.

The BS 8878 Web Accessibility - Code of Practice DPC can be accessed through the draft review system (log in required), and may also be downloaded as an RTF file once authenticated. The new draft standard is based on the current PAS 78:2006 Guide to Good Practice in Commissioning Accessible Websites and explains how to create organisational policies and production processes to identify and remove barriers that unlawfully exclude disabled and elderly people from "web products". In this context, "accessibility" only relates to people with disabilities in the UK (e.g. the Equality Act 2010), and not wider concerns about universal access (e.g. access in poor light, using a small display, noisy environments, using a slow internet connection, etc).

Web products are any website, web-service, or web/workplace application which is delivered to users using internet protocol (IP), on any IP-enabled device, and more specifically:

The guidance for procurement of authoring tools, software, components or web-services (Appendix L) notes that due-diligence discussions on the proposed design should be held with potential suppliers, including detailed technical checks on matters such as security, accessibility, software versions supported and future plans.

If you develop web products, read this draft code of practice now, understand the implications on your development practices and provide feedback before it is finalised.

Comments can be submitted until 30th June 2010. The final BS 8878 is due to be published in November 2010.

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.

An article about the upcoming new regime for the classification and labelling of chemicals reminded me to write about software assurance (i.e. software security) labelling (and since web sites are software). From 1 December 2010, the UN Globally Harmonized System of Classification and Labelling of Chemicals (GHS) comes into force, implemented in Europe by the Regulation (EC) No 1272/2008 of the European Parliament and of the Council of 16 December 2008 on classification, labelling and packaging of substances and mixtures (CLP), amending and repealing Directives 67/548/EEC and 1999/45/EC, and amending Regulation (EC) No 1907/2006.

CLP implications and guidelines are explained by the UK Health and Safety Executive (HSE) but are defined fully in the UN's documentation. The headline chemical labelling indicates the potential damage/harm that can occur, rather than the content/properties of the agent. I like this "impact" approach. Nutritional labelling on the other hand generally tends to focus on ingredients and their properties, but some food labelling is also beginning to attempt to classify low/medium/high fat/saturates/sugars/salt levels, which is more akin to the impact approach.

Jeff Williams (CEO of Aspect Security and Chair of OWASP Foundation) proposed a Software Facts label five years ago at OWASP Appsec Europe. This would be similar to appliance energy usage labels, food nutrition facts label, material safety data sheets or laser safety classes. That idea was taken up by NIST and the Software Assurance Consortium (SwAC) to develop another proposal.

Comment here and here around the same time in 2005 describes some of the challenges. Indeed many more aspects of the software development lifecycle impact upon the creation of secure software. But simplicity is needed in the presentation of such information—perhaps some high-level impact related indicators augmented by the more detailed information for different audiences (e.g. users, operators, administrators, system achitects). SwAC's version seems to be somewhat aimed at software development teams, instead of people in end user organisations, especially those involved with procurement decisions. Whilst some people will want to know the data behind a classification, most businesses and consumers will need something more akin to the CLP headline labels relating to business (or personal) impact as a starting point for their decisions.

• How dangerous is this software?
• How reliable is it?
• How does it affect privacy?
• How does the IT environment affect these?
• How are these affected by changing the default settings?

This a big challenge. Just specifying the privacy practices for a web site can be complex. ENISA's Common Assurance Maturity Model (CAMM) project is trying to define how cloud service providers can be compared to allow users to make informed decisions about the risks. Perhaps that project will develop into some form of labelling scheme, or at least provide ways for typical consumers of the services to determine their own risks as simply as possible.

I don't know the status of the SwAC project but will now make the effort to find out.

Yesterday I arrived in Barcelona in advance of Secure Cloud 2010 organised jointly by Cloud Security Alliance (CSA), European Network and Information Security Agency (ENISA), ISACA and IEEE.

In advance of the conference I attended the initial meeting of a new ENISA project to develop a security metric tool for cloud and other computing services, based around the information assurance framework outlined in last year's excellent report on cloud computing risks. I am participating on behalf of the Open Web Application Security Project (OWASP) and its Global Industry Committee so we can share our knowledge and experience from application development and operation. The initiative seems to have the support of the major vendors (Microsoft, eBay, Google, Amazon Web Services, etc) and other security groups (CSA, ISACA, ISF, ISSA, Jericho Forum, etc), and plans to build on other existing efforts (e.g. Shared Assessments, CloudAudit, FTC, NIST, etc). There are high expectations that something relevant, open, transparent and practical—for all sizes of organisation—can be delivered in the next year.

Now, off to the conference.