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.

This week the Ministry of Justice published the summary of responses to their consultation on revised fines for serious breaches of the Data Protection Act.

In Civil Monetary Penalties: Setting the Maximum Penalty proposals were made for a maximum £500,000 fine following granting of powers to impose civil monetary penalties being added to the Data Protection Act (DPA) 1998 (Sections 55A to 55E) by the Information Commissioner's Office (ICO) through section 144 of the Criminal Justice and Immigration Act 2008.

The 52 submissions described in the summary of responses showed broad agreement for fines up up to £500,000 for data controllers who seriously contravene data protection principles. The ICO issued a press release Data Breaches to Incur Up To £500,000 Penalty on the same day with details of how they will consider:

• the circumstances including the seriousness of the data breach
• the likelihood of substantial damage and distress to individuals
• whether the breach was deliberate or negligent
• what reasonable steps the organisation has taken to prevent breaches.

The ICO has produced statutory guidance about how it proposes to use this new power, which has been approved by the Secretary of State for Justice, and has been laid before Parliament.

The statutory guidance is worth reading since it outlines things such as "reasonable steps the Commissioner expects the data controller to take" that include (in a non-exhaustive list that includes mention of risk assessment, governance, audit, policies, procedures and practices):

So, the standards are being raised.

Subject to Parliamentary approval, the civil monetary penalties are expected to come into force later this year on 6 April:

• Draft Order "The Data Protection (Monetary Penalties) Order 2010"
• Statutory Instrument 2010/31, The Data Protection (Monetary Penalties) (Maximum Penalty and Notices) Regulations 2010

P.S. If you are interested in privacy matters, The EU's Article 29 Working Party and Working Party on Police and Justice have jointly published a paper on The Future of Privacy (WP 168) and there is an excellent summary and overview on the Tech and Law blog. The conclusion: a new comprehensive legal framework for data protection is needed in the EU.

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.

It's common for access to some web sites to be restricted to users from particular Internet Protocol (IP) addresses. This is usually in addition to some other identification and authentication method. But other IP addresses are often added to this "allow list" and these should not necessarily be trusted in the same way.

In a typical scenario, a web site hosted on the internet that is used to administer another web application might be restricted to the company's own IP addresses. Then the developers say they need to check something on the live site, or another server needs to index the content, or someone wants to work from home for a while, or the site needs to be demonstrated at a client's location. All these additional IP addresses are added to the "allow list". These restrictions may be being applied at a network firewall, traffic management system, at the web server, in the application itself, in intrusion detection systems or in log analytical software, or in many of these. These are difficult to manage and in time there will be many IP addresses that no-one knows why they are allowed unless they are carefully documented, and subject to a fixed time limit when they are confirmed again by an appropriate person or removed. These extra addresses are quite often hard for someone else to guess.

However, there is another area where IP addresses are added to "allow lists", and this is for remote monitoring and testing services. These might be checking uptime, response times, content changes, HTML validation or security testing. The service providers publish the IP addresses of the source systems so that companies can specifically allow access to their web sites. Since the number of these services is relatively small, it's not too difficult to find which one might give access to areas of a web site or web application that the public (and malicious people) should not be able to get to. The particular danger here is that the IP addresses might be excluded from monitoring and logging, and therefore even a diligent web site manager might not realise for example the uptime monitoring service is making unusual, or excessive, requests.

Although it is not likely a malicious person is using this "trusted" address unless routing has been compromised as well, problems can go undetected, from what might seem to be a legitimate source. The IP address may have been typed incorrectly, or worse, the restrictions/exceptions may not have been implemented correctly allowing more addresses to have the privileged access than intended. Not logging a user's session is privileged access.

Allow traffic through, but be very specific what is allowed and monitor what's going on. Review all the exceptions periodically. Be especially careful about anything that bypasses authentication (such as allowing a search engine to crawl restricted-access content) on an otherwise public site.

At this time of the year, gardeners have usually seen the best of their summer displays, and thoughts turn to tidying up the garden before the winter.

The publication of a new report from the Ponemon Institute on Data Security in Development & Testing is a timely reminder that like gardens, our web site and web application development and test systems need periodic attention, otherwise they can go wild too. The report describes the findings from a survey of IT practitioners in the United Kingdom and United States on the adequacy of their policies and technologies in place to protect real data used in development and testing. The survey is included in the report, so you can compare your own organisation.

Take some time to identify how real data are being used in your development and test systems, and determine what sensitive data is being used, stored, transmitted and how it is deleted. Are you allowed to sue the data for development and testing? Check who has access to the data, from where, and what the risks are.

If you undertake some form of masking or other anonymisation technique, do read and take into account a new summary of research and discussion by Paul Ohm in his paper Broken Promises of Privacy: Responding to the Surprising Failure of Anonymization.

Put plans in place now, that will make next year easier. No manure required.

Last night, I spoke at OWASP Ireland's meeting in Dublin about the previously discussed Software (Security) Assurance Maturity Model (SAMM).

My presentation defined what software assurance, and in particular software security assurance, are, and why they are needed for complex software quality aspects. I also discussed what a maturity model is and how SAMM fits in with other business, project management, IT and software development maturity models. Moving onto SAMM, we reviewed the structure and how it may be used in software development teams and businesses to measure the current capability, act as a benchmark and help in building out a software security assurance programme.

There's been some discussion about applying SAMM on the SAMM mailing list, but it was good to chat with other people about their experiences and ideas to help organisations build better (more secure) software. The evening continued with an interesting talk on Niall Jordan on "Evading SQL Injection Detection Through Encoding", and then off to the nearest (almost adjacent) pub for further lively discussion and debate.

Oh, and a reminder... the Ireland chapter have organised OWASP Ireland AppSec 2009 Conference on 10 September 2009. With two tracks of application security related presentations from excellent speakers, I think it's going to be well worth attending.

It can be hard to justify business spending when web sites are often viewed as low-value assets. The fact that so much Internet content and services are free, and you can buy a web site for less than the cost of a colour TV licence in the UK reinforces this idea in many small and medium enterprises (SMEs).

Much of my work is related to dealing with security incidents, such as web sites which have been hacked, or where an organisation is having security requirements imposed by their own customers and clients. Often these activities are undertaken late in the project and are therefore less effective, and more costly, than they might need to be.

I adhere to the principle "prevention is better than cure", and encourage the early consideration of security and privacy matters—just like any other business process requirement. It was encouraging to read the useful guidance and pointers on Business Cases For Software Security Initiatives but for many organisations, the issues are too complex and they don't have any supporting data. For those I recommend, as a starting point, concentrating on four types of issue:

1. mandatory compliance issues (e.g. legislative and contractual)
2. problems which can assist theft or fraud
3. security events which would be severely disruptive and possibly put the organisation out of business
4. issues for customer trust and ongoing reputation

It's always organisation specific though. As organisations mature, they can be encouraged to look at wider security issues—but, let's get the basics right first.

Old, backup, "secret" and test pages, scripts and other files shouldn't be left on live web sites. The Visit Britain web site should be a showcase for Britain, but I was trying to find a particular page and looked at their 97-page long full sitemap.

Oops, the 4th, 6th, 7th and 8th links were all test or old pages. I couldn't believe this prominent web site didn't have procedures in place to manage draft and test content, or even that they were making such pages live on their web site. The result test-script worried me most but fortunately all four of these returned were not found when clicked.

I wonder what the page "Delete" does though?

People use search engines such as Google to find hidden information on website (aka Google Hacking), but it's uncommon for web sites to clearly list it on their own site map. Rather than ploughing my way through the impenetrable site map, I switched to Google to see what it had found using the search query "site:www.visitbritain.co.uk test". Skipping the results about cricket test matches and testing your handicap, revealed more links to more test pages:

My favourite must be the page with the parent page labelled "Food & Drink - to be deleted EVENTUALLY" in the breadcrumb trail:

These types of practices don't instill any confidence in the management of the web site. Old, backup and test files may contain sensitive data, allow access to the application or functions otherwise restricted, or contain faults that have been fixed in the current version. And, if you actually list them, it looks terrible! Web sites and web applications, don't just look after themselves—you need clear policies, a well-designed specification, a robust development contract, good management, skilled staff, verification processes and be willing to learn from good practices elsewhere.

Today's message: read Testing for Old, Backup and Unreferenced Files.

The new British Standard 10012:2009, Data Protection - Specification for a Personal Information Management System, has been published.

British Standard 10012:2009 was the subject of an earlier draft for public comment (DPC) and I worked with the OWASP Industry Committee on a response.

BS 10012 is not an alternative to the excellent guidance for organisations now produced by the UK's Information Commissioner's Office, but instead is a specification for a personal information management system (PIMS). A PIMS is a governance process for all types of personal information within a company but could also be used for other types of sensitive data. BSI's slant on this is that a PIMS, and therefore BS 10012, could help maintain and improve compliance with the Data Protection Act (DPA) 1998.

A good start and one to watch.

In my post Safety Hazards and Security Threats I discussed how safety hazards and security threats have many similarities. A new safety presentation designed to raise awareness of safety issues, concerning the sinking of the MV Herald of Free Enterprise in 1987, provides a further analogy.

The MV Herald of Free Enterprise roll-on/roll-off (ro-ro) ferry was built in 1980 to operate on the short Dover (England) to Calais (France) route, but was moved to the much longer Dover to Zeebrugge (Belgium) Channel crossing. It capsized killing 193 passengers and crew following water entering the bow doors which had not been closed prior to departure.

The safety training material outlines lessons to be learned:

• lack of procedures
• lack of steady team structures and responsibility
• reduced staff resources
• inability to identify changed hazards
• poor change management practices
• reliance on a single layer of protection
• creeping changes moved beyond design specification
• insufficient monitoring
• poorly designed controls
• failure to implement controls
• insufficient time to react to incident.

These points could equally have been written about a catastrophic network breach. Clearly most web servers don't have a direct impact of human life, unlike in public transport where safety risk analysis considers human lives to be valued at millions of pounds each. However, an organisation may not survive a significant data breach and we can all learn lessons from other events such as this.

There can be a tendency to treat security as a "technical" issue, and specifically as an "IT issue". Most of the above lessons to be learned are not of the technical type. Focus on what will make a difference.

Further reading is available in "The MV Herald of Free Enterprise: Report of Court No. 8074", Department of Transport, Her Majesty's Stationery Office, ISBN 0 11 550828 7.