In my previous post, I mentioned the lack of data on return of investment (ROI) concerning building security into the software development life cycle (SDLC). Well after commenting on the Aberdeen Group report earlier this week, another study has been published by Forrester Consulting.

The report State of Application Security - Immature Practices Fuel Inefficiencies, But Positive ROI Is Attainable was commissioned by Microsoft to survey influencial people in software development in the United States and Canada. Appendix B of the report defines the demographics of the 150 people — there is a heavy bias towards people working in the "high tech" industry sector (rather than say financial, utilities or manufacturing) with more than half their organisations having annual revenue in excess of $5 billion including the development of software products and services.

The study examined the secure development drivers, practices, effectiveness and maturity. Table 1 in the report identifies that almost half of the organisations use their own software security methodology, with others using CMM/CMMI, Microsoft SDL, OpenSAMM and DISA STIG.

The conclusions? Most of the organisations surveyed have implemented some form of application security measures, but these are not yet mature and risk is still most commonly transferred from development to operations, where the remediation costs are highest. Tactical approaches with point technologies are less effective than prescriptive application security methodologies applied strategically throughout the SDLC. Those using a more coordinated, prescriptive approach reported a better ROI for application security. However, the ROI for these organisations is not has high as suggested in the Aberdeen Group study.

Perhaps you have some time at the moment to catch up with the backlog of reading? Here's a quick one to review. The Cloud Security Alliance has published an update to its Cloud Controls Matrix.

The Version 1.1 spreadsheet helpfully includes details of the revisions implemented, although it might have been clearer if the previous text were striked out to make it clearer which is the current version of the control. The changes are mainly clarifications or improved wording.

See also the related resources mentioned in my posts:

• Cloud Computing Risks, 27 November 2009
• Cloud Computing Security, 18 December 2009
• Secure Cloud 2010, 16 March 2010
• Web Application Security in the Cloud - Part 1, 17 April 2009
• Web Application Security in the Cloud - Part 2, 21 April 2009
• Seven Information Security Reports, 14 May 2010

... and perhaps the slightly related Trust .UK — happy reading!

Service and ownership location can be fundamental selection factors for online users. The importance of confidence in the UK's digital economy was highlighted in the Digital Britain Report (2009) and more recently in the Cabinet Office's Cyber Security Strategy of the United Kingdom/Fact Sheet on Cyber Security and EURIM's Can Society Afford to Rely on Security by Afterthought Not Design?. Building trust in the .UK brand is a necessary part of a healthy competitive economy.

Hand-in-hand with creating "the best place to do online business", the UK needs to increase visibility of the geographical properties of its online organisations. I wonder if in time, we will have more "country of origin" information, like the security labelling mentioned on Friday, to help users (employees, customers, clients, and citizens) make informed choices about who they will share information with and buy products & services from.

A ruling last week by the EU Court of Justice suggests that companies directing their activities at foreign consumers, will affect where they can take legal action, or have legal action taken against them. "Directing" may include using a domain name of another country, using a .com domain name, quoting international contact details, mentioning country names (e.g. delivery rates) or offering country/lanuague options.

We have already seen moves to ensure .uk domains are not used for criminal activities, but is the domain name enough? No. Without getting jingoistic, as the ruling indicates, there are all sorts of additional geographical properties that affect users' rights and the ability for governments to enforce legislation. An equivalent to the "Security Facts" label might be "Location Facts":

where "GB" is the ISO 3166-1-alpha-2 code for the United Kingdom. In the example on the left, the application is hosted in Germany and has some data transfers to the United States because of web analytics, SSL verification and inline advertisement code hosted there. Of course, the situation can be complex, and in a single label it can be difficult to describe all the important geographical properties, but let's at least try. Knowing the locations of each element of the supply chain is less relevant to the end user than the details above.

These two examples are just made up to emphasize the possibilities and are not meant to be xenophobic in any way. Consumers, and other web product users, should be able to find out who they may be interacting with and the scope for redress in the event of a problem, so they can make their own choice? This is no different to having the place of origin on food product labelling.

This quotation from the forward by James Paice, Minister of State for Agriculture and Food, to the British Retail Consortium's new guide on Principles on Country of Origin Information couldn't explain it better:

It would seem to be as appropriate for web products too. Of course, there are many other issues that affect user trust—jurisdiction being just one.

Can we trust self-labelling? Well for consumers, the Advertising Standards Authority's remit will include digital assets like web sites from 1st March 2011. Honesty plays a big part too, but consumer groups (e.g. the Confidence Code for energy comparison web sites) have some punch, and trade associations could develop standards for their members. Ultimately, the power of markets and groups of individuals would hopefully keep other organisations in check.

Following an extended period of development and consultation, BSI has announced the publication of BS 8878:2010 Web Accessibility - Code of Practice.

At the launch event this morning, Jonathan Hassell (Committee Chair BSI IST/45), introduced a series of presentations on the development, content and use of the new standard.

The standard replaces the somewhat outdated PAS 78:2006 Guide to Good Practice in Commissioning Accessible Websites, and provides a practical 21st century view of accessibility addressing a wider view of the web, varied delivery and consumption mechanisms, the rise of user-generated content, use by older people, and the increasing use of off-the-shelf services, frameworks and components. It is not a technical standard, but instead describes an approach to addressing web accessibility through the development lifecycle from commissioning through to operation—building accessibility in to the organisation as it were.

The fundamental driver for the standard in the UK are the Disability Discrimination Act 1995 (now Northern Ireland only) and the Equality Act 2010 (rest of the UK), which came into force in October and describes how organisations have a duty to make reasonable adjustments, but not anything that would fundamentally alter the nature of the "service". The standard uses the interesting term "web products" to include workplace applications, widgets, RIAs, SaaS and mobile apps, as well as web sites.

The standard describes 16 steps, from Step 1 - Define the Purpose of the Web Product, through to Step 16 - Plan to Assure Accessibility in All Post-Launch Updates to the Product. But the appendices, that account for more than half the document, provide some very useful supporting material. I suspect these partially came about from the large number of responses received to the consultations, and from the extensive experience of the committee members. The appendices include information on the legal requirements (UK), making a business case, example policy wordings, how to allocate responsibilities, metrics, procurement advice and information of a more technical nature for production & operational teams.

Do you need to read this? If your organisation is established in Great Britain, yes, and then even if you are not subject to the Equality Act but are looking for good web accessibility practices, yes too. Then act on it.

Last night I attended the ISACA London technical event on ISO Technical Standards, presented by David Fatscher of BSI. His excellent presentation described many standards and associated BSI products, including BS 10012:2009 Data protection - Specification for a Personal Information Management System (PIMS) (which I mentioned in June). When BS 10012 was launched, BSI also released a related tool Data Protection Online to help ensure a PIMS meets the requirements of the standard.

I realised this is exactly the same approach of another tool released a week ago by David Rook (Security Ninja). The Agnitio tool guides you through the process of application categorisation and undertaking & recording security source code reviews. It encourages a consistent approach to reviewing source code and the generated reports can even be validated for integrity.

Like the BSI tool which relates to BS 10012:2009, Agnitio relates to David Rook's Principles of Secure Development, which is rather like a standard for developers in many ways. Standards need supporting guidance, templates and tools—David Rook shows how this can be done. I'm sure he'll welcome feedback on the tool.

Agnitio is free to download and use.

The Center for Internet Security (CIS) has announced and published an update (v1.1.0) to the Consensus Security Metrics; I discussed the previous version (v1.0.0) last year. As with the previous version, the aim of the document is to allow organisations to collect, analyse and share data on security performance and outcomes.

This version has no new Application Security metrics, but additional collection data attributes have been defined for technologies, business applications including status, risk assessments, security testing and completely new attributes for the current mitigation status of weaknesses discovered. There is also a new diagram showing the relationship between the various data attributes.

As mentioned above, the actual metrics are essentially unchanged, although the table for "Number of Applications" appears to be missing in the new document, and "Security Testing Coverage" is included but omitted from the contents list.

The Consensus Security Metrics includes more than suggested metrics for Application Security—there are a range of management, operational and technical metrics for Incident Management, Vulnerability Management, Patch Management, Configuration Management, Change Management and Financial Metrics. A new Quick Start Guide has also been produced by CIS to help organisations understand and implement the metrics. The document is a good if you are considering the introduction of security metrics, but be aware that metrics have a tendency to distort normal behaviour, especially if they have an affect on people's performance measurement too. Do remember to read "Security Metrics - Replacing Fear, Uncertainty, and Doubt" (ISBN: 0321349989) by Andrew Jaquith—he has a refreshing viewpoint on security metrics. Also see the information and resources at http://www.securitymetrics.org and https://www.metricscenter.net/.

As a related note, at last week's AppSec Washington DC 2010, Rafal Los presented a passionate suggestion for Five KPIs for Web Application Security Programs, which he had previously announced in a webcast in October. There was plenty of discussion at AppSec DC about these and it will be interesting to see how they firm up, and whether they can be incorporated into the CIS Consensus Security Metrics.

The Payment Card Industry Security Standards Council has announced version 2.0 of the Data Security Standard.

Version 2.0 is available to download and the PCI SSC have also published a summary of changes. The changes are mainly clarifications rather than new major requirements; the following blogs discuss the main issues well:

• PCI DSS 2.0 Release And Review
• PCI DSS 2.0 is out!

There are no requirements for merchants to publish confirmation of compliance or assessment results which I was hoping for. But I am curious to see how merchants undertake a risk-based approach to assessing and prioritising vulnerabilities, without simply choosing to accept weaknesses.

PCI DSS v2.0 must be adopted by all organisations with payment card data by 1st January 2011, and from 1st January 2012 all assessments must be under version 2.0 of the standard.

As mentioned previously, the Advertising Standards Authority is to extend its digit remit for consumer protection.

The announcement on Wednesday describes how the Committee of Advertising Practice (CAP) made the decision and published a guide to the new remit, exclusions and sanctions. The regulation covers advertisers' own marketing communications on their own websites and in other non-paid-for space online under their control (e.g. social networking sites).

Note that some user-generated content could fall under regulation—see section 3.9 for a description. Communications that do not constitute an advertisement or other marketing communication are excluded from the remit, as are marketing communications that promote causes or ideas, and anything already in list of content already excluded by the CAP Code (e.g. press releases, editorial content, corporate reports, natural listings on a search engine or a price comparison site).

CAP recommend all web site owners and agencies sign up to their free CAP Services to learn more about the code, its implications,ensure their web sites comply with the CAP code, and most importantly access to the free Copy Advice service. The remit will come into force on 1 March 2011.

New UK Advertising Codes were also published on Wednesday, and came into effect the same day.

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.