It's encouraging to see commercial information security organisations sharing their experience, knowledge and data, such as in the OWASP Security Spending Benchmarks Project. Last week Verizon also published details of its Incident Sharing Framework.

The framework (beta, 1st March 2010) is used in Verizon's internal security metrics gathering processes and to produce its public data breach investigation reports. The framework provides details of how various security incidents should be classified and recorded, including what is done to remedy the situation and further actions taken, such as education. By publishing the framework, Verizon hope that other organisations might collect similar data and ultimately share it to improve common knowledge.

Some other related frameworks and initiatives are listed at:

• Security Content Automation Protocol (SCAP), NIST, specifications and emerging specifications
• Consensus Information Security Metrics, CIS (see previous post on Web Application Security Metrics

These frameworks may be too complex to consider for some organisations, but even so, they provide a good guide to the kind of things you should be considering in security and privacy incident management policies and procedures. They are also useful standalone references for classifying various types of attacks and accidents.

Last month I described the ability to track users sessions with browser data. A recent posting on IT Law in Ireland highlighted a series of blog posts elsewhere that give further insight into what is possible.

Well, I just got round to reading them properly. The posts on Freedom to Tinker by David Robinson and Harlan Yu are:

• Identifying John Doe: It might be easier than you think
• What Third Parties Know About John Doe
• The Traceability of an Anonymous Online Comment

The conclusion? It is possible to trace and identify individuals easier than you may think. We are dropping evidence like dead skin cells as we traverse the internet. Fact or fiction? Well the US Defense Advanced Research Projects Agency (DARPA) are taking it seriously with a recent call for research into cyber genetics, cyber anthropology and cyber physiology in its Cyber Genome Program. DARPA hopes to develop advanced methods to fingerprint or identify the origins of a cyber attacks by examining digital artifacts, and presumably other criminal activities utilising computer technology.

Getting a bit more down to earth, web site owners need to consider what information is being gathered and why, ensure this is legal, check that consent is implied or has been explicitly given for the purposes and what monitoring and analysis is performed on the data. It could be easy for system developers to carried away with tracking and tagging. Contracts with third parties should state clearly what the expectations are about the security and privacy of information, to protect web site users (employees, customers, clients, citizens) and the business.

Testing a web site is important, and smoke/regression testing would normally be undertaken each time the web site's code is updated or extended. But what about third party code and data on your web site? I was using a shop's store locator and it wrongly identified the two closest store locations to Farringdon Station in Clerkenwell, EC1M. Both Euston Station NW1 and Canary Wharf E14 are further away than the third result, Cheapside.

Intrigued, I zoomed in on the map and the ordering of the first two results swapped. And the data point for Canary Wharf seems to be located in the centre of the City of London, instead of its actual location downriver on the Isle of Dogs. The data point for the first result wasn't even displayed.

So is this a third party problem, or something else? Well, without investigating further you can't really tell, but it's the concept that matters.

This inaccuracy is worrying for a number of reasons:

• Customers may have difficulty locating shops.
• It undermines customer confidence and therefore trust in the brand.
• It indicates a lack of care in the web site's development and may put off online shoppers.
• It could indicate the presence of a security vulnerability which could be exploited to damage the site, its data or its users.
• The same geo-location code may be used for other internal calculations such as marketing data processing that affect business decisions.

If you are including functionality or data from third parties, you need to know when that system or service is updated. This notification requirement should be built into contracts. In this case, the data being returned may be inaccurate, formatted in an unxpected manner or be exposing a fault in your own processing of the data. Undertaking input validation on the data provided by the third party and output validation on what you are about to send back to the web site user need to test for reasonableness as well as more technical checks. Why not cross-check that the first result's postcode is closer than the second and the third?

It may just be a problem with the company's own data, but that's even more worrying.

The review of safety at BP's Texas Refinery following investigation and report on the explosion in 2005 which killed 15 people, injured 180 and caused substantial property damage, included a recommendation to use pre-startup safety reviews (PSSRs).

We can all learn lessons from unfortunate incidents like this in other disciplines (e.g. also the sinking of the MV Herald of Free Enterprise in 1987). Do web site developers and designers have an equivalent pre-launch security review (PLSR)?

I remember once reading an email press release about a new web site, only to visit it and find out that within a few link clicks you ended up in some sort of CMS admin area; we stopped browsing immediately and contacted the site's owner. In the past I have also been asked to make a web site live on Friday afternoon at 4pm; the answer has to be "no".

What should a PLSR include for a new or revised web site? If you don't already have a security policy, standards and procedures, here is a checklist of suggestions:

Not all these checks will be needed for your project but the order in which they are done is important. For a small web site with little functionality, this doesn't have to be complicated. For example, the build documentation and disaster recovery plan could mean having a full set of source files (pages, scripts, images, etc), each night's full backup of any changing data (e.g. database and generated files), login credentials, some notes on the server's configuration and contact details for the domain name registrar, design agency and hosting company.

For any project, try to discuss launch as early as possible in its lifecycle—preferably at the bidding/tender stage, but if not, immediately on project initiation. Define the launch/release criteria well in advance. Find out what the client and project owner's expectations are and who will be responsible for what. A good launch takes time, so make sure the team have enough time to complete the launch and subsequent checks without it running into abnormal hours of the day. Your web site project's failings might not lead to people's deaths, but that doesn't mean sloppy configuration, launch and operation are acceptable. What standards do you have?

Please let me know if you think anything should be added to or altered in this launch checklist.

PS if you are looking for a launch checklist that addresses wider website issues, I'd recommend the The Ultimate Website Launch Checklist.

Today I thought I'd share some of my favourite blog posts about building software securely by implementing web application security programmes.

The excellent blog posts about building a software security assurance programme are:

• Rafal Los on Enterprise Web Application Security and Building a Web Application Security Program Without a Budget
• Justin Clarke on The Fallacy of Secure Software
• Adrian Lane on Agile Development and Security

Can you recommend any others?

As a reminder, the main software security maturity models and process models are:

• Building Security In Maturity Model (BSIMM)
• Microsoft Security Development Lifecycle (SDL)
• National Institute of Standards and Technology (NIST) SP 800-64 Rev2 Security Considerations in the Information System Development Life Cycle
• Software Assurance Maturity Model (SAMM)

Last week Microsoft also released a short document describing how to implement a simplified version of their SDL.

Which should you choose? It's what works in your own organisation that matters. Ask your software suppliers (e.g. web developers) what they use before you buy.

Taking payments online? Were you strongly encouraged to implement a 3D Secure system like Verified by VISA or MasterCard SecureCode?

A new paper from University of Cambridge Computing Laboratory describes how how online card security fails. It identifies a number of security weaknesses in 3D Secure and proposes that the economics of security have driven insecure implementations (like this), that are difficult to use, in order to move the risk to cardholders.

Ross Anderson's blog post links to comments about the paper elsewhere.

"Voucher Codes: assets or liabilities?" was a question asked on Creative Match recently.

Codes providing discounts during the checkout process on e-commerce sites can be an incentive to attract shoppers and increase their spending but also can affect revenues if they are used by people who would have bought anyway.

Misuse by real shoppers is certainly a concern, but voucher codes can sometimes easily be abused if their implementation, operation and lifecycle are not considered carefully. Unlike in the real world where paper coupons may be difficult to forge and can be cancelled by collecting or marking, online voucher codes can be harder to control and expire.

Plan ahead, don't create vouchers code schemes in a rush.

On Thursday the UK Government's Central Office of Information (COI) is hosting an event about auditing government websites aimed at government agencies (EAs) and non-departmental public bodies (NDPBs) that have a deadline looming in April 2010.

Web site quality and value concerns were raised in a National Audit Office report on Government on the Internet: Progress in Delivering Information and Services Online in published in July 2007 and recommendation made in the Public Accounts Committee (PAC) Sixteenth Report. Along with their other web standards and guidelines, the COI has issued standards relating to costs, usage and quality. Version 1.1 of TG126, November 2009, on measuring website quality describes three requirements for measuring and auditing website usage:

The benefits of web site auditing were described last year by Adam Bailin on the Digigov blog.

It is very encouraging that the COI are developing standards to improve quality and value. Apart from usage measurement and audit, the quality requirements cover the topics of domain names, usability, accessibility, archival, browser testing, web site map, cost monitoring and web site closure (disposal).

But there are some areas that are not represented in these standards. A glance at something like ISO 9126 indicates other important software quality. A starting point would be to monitor some privacy and security metrics.

And of course, I'd like to see some government requiring some standards for security, which unlike privacy, has a much less firm legal guidance and regulation (for privacy these are the Data Protection Act 1998 and the Information Commissioner's Office). The most well-developed standard for web site security verification is the Application Security Verification Standard (ASVS) from the Open Web Application Security Project. It's free to download and use, and perhaps this can be incorporated or referenced by future government standards and other software security assurance programmes.

The next Open Web Application Security Project (OWASP) London meeting is this week.

The London chapter meeting is on Thursday 14 January 2010 in EC1. Everyone is welcome, but you need to register first (free).

There will be talks on Top Ten Deployment Mistakes That Render SSL Useless by Ivan Ristić and Using Selenium to Hold State for Web Application Penetration Testing by Yiannis Pavlosoglou, who recently joined the OWASP Global Industry Committee.

Unfortunately I am unable to attend the meeting but hope to read the presentations afterwards.

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.