The first report on the state of software security has been published by Veracode who provide a cloud-based application risk management service.

The data presented in State of Software Security Report - The Intractable Problem of Insecure Software are interesting, it relates to both web application (40%) and non-web application (60%) software but spans in-house developed, commercial, open source and outsourced, developed in .NET, C/C++ and Java. But don't get bogged down in the data. I'd recommend that everyone responsible for web development, or who commissions or operates a web site, read the executive summary. I was quite surprised that backdoors (a method of bypassing normal authentication) are still a significant issue: "Open Source projects have ... fewer potential backdoors than commercial or outsourced software". This is why "V13 Malicious Code Search Verification Requirements" appears in the Application Security Verification Standard.

There are seven recommendations, which are in summary:

• Implement a comprehensive, risk-based, application security programme.
• Implement security acceptance criteria for third-party suppliers.
• Test code from outsourced, commercial and open source suppliers as rigorously as internally developed code.
• Verification of C/C++ code must not be ignored and it is likely to be present in many applications.
• Implement specific developer training on security.
• Learn from organisations in higher-risk sectors such as finance and government.
• Ensure security requirements are built into outsourced software development.

Some good advice there. The report provides a fuller description and gives the background to these recommendations.

I guess there must be much more detailed data available to Veracode than is presented in this "Volume 1". Perhaps Volume 2 will look at trends over time, but I'd also like to see:

• Breakdown of root causes (e.g. unvalidated user input).
• Breakdown of how the vulnerabilities had been fixed when the software was re-tested (e.g. parameterized queries implemented).
• What proportion of faulty code was identical — found in more than one application (i.e. copied/duplicated from elsewhere).
• Details of any secure development lifecycle in use by suppliers and their level of maturity with these.

Hopefully this type of aggregated data can be shared under Veracode's terms of service and agreements with individual customers. The software suppliers included in Veracode's analysis are likely to exclude customer organisations who do not have the knowledge or resources to have their code analysed. It would be an interesting research project to test a selection of applications developed by other suppliers to see how they compare.

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.

Today the UK Information Commissioner's Office (ICO) announced the publication of its report on the business case for investing in proactive privacy protection, which it is launching at the Data Protection Officer Conference in Manchester.

The aim of the research and report defined in the tendering brief was to create a soundly argued business case for expending money on privacy friendly systems and business processes. John Leach of John Leach Information Security Ltd and myself working for Watson Hall Ltd submitted a proposal to undertake the project for the ICO. We were awarded the contract in August 2009.

We began the project by producing a public discussion document and initiated conversations with a number of experts. Our research was complemented by interviews with a cross-section of data processors and discussions held with an expert panel. We were particularly concerned about producing a report that would be relevant across all UK business sectors and size of organisation. Our draft report was reviewed by a small number of senior business leaders, and modified based on their experience and knowledge of justifying investments and practical experiences of implementing privacy protection measures.

The result? Well I'd like your opinions after reading the report. The Privacy Dividend is comprised of two volumes:

• Volume 1 - The Business Case (20 pages)
• Volume 2 - Supporting Materials (71 pages)

I hope you find "The Privacy Dividend" a useful resource. Additional updates and references are included on the Business Case for Investing in Proactive Privacy Protection project microsite.

Last week I visited the London Design Museum on South Bank. One of the current exhibitions is about Dieter Rams—not someone I was aware of previously—who is head of design at Braun, the German consumer electronics manufacturer. The exhibition included scores of examples of products he has designed over 40 years; with many on loan from Braun's own archives.

Ten Principles of Good Design

But Rams' ten most important principles of good design caught my eye since it seemed they might apply more widely. I wondered how they might be applied to good security. Of course the ten most important security principles would actually be something else, but let's just look at Rams' ones.

Good design security is innovative

Technological developments offer new opportunities for innovative security. Security practitioners must innovate to meet new threats.

Good design security makes a product useful

Interesting in the security context. I believe that good usability includes good security and vice versa. Good security won't always make a web application useful, but equally good design can never truly make up for fundamental shortcomings of a product. Good security should enhance the application, not detract from it.

Good design security is aesthetic

I don't expect aesthetic quality to be mentioned any time soon in the ISO 27000 series of standards, but if we can achieve beauty, that should be preferred. For example, ugliness in user interfaces inevitably introduces errors in data selection and entry, and these may have a security impact.

Good design security makes a product understandable

Self-explanatory security? Yes, the inclusion of security measures should aid the user's understanding. Security measures should complement the software and make sense.

Good design security is unobtrusive

Security should not get in the way of the other functionality and where it is visible, its reason and method of use should be obvious.

Good design security is honest

Cut out the fear, uncertainty and doubt (FUD). For example, don't include claims about security (and privacy) that are not true or cannot be substantiated.

Good design security is long-lasting

Repeated changes to software are prone to introducing faults and should require a carefully controlled change management processes. By getting it right first, and not having to change security measures later, this makes better security.

Good design security is thorough down to the last detail

Building security in at an early stage by assessing the risks and requirements reduces the chance of having to make arbitrary decisions later or security implementation being left to chance.

Good design security is environmentally friendly

This one is harder, but perhaps good security uses resources more efficiently? It is certainly more expensive to fix faults later, so there could be an environmental benefit.

Good design security is as little design as possible

Purity? Simplicity? Architectural and programming code complexity leads to faults that may be security vulnerabilities. It is also difficult to maintain. Yes, keep it as simple as possible to achieve the security requirements.

Maybe in time we'll have security celebrities who adorn software packaging and interfaces with their signatures, like sportsman on clothing or chefs on saucepans. I don't think Dieter Rams would ever want his signature on one of his designs—they are enough of an inspiration without adding un-necessary branding.

Top Ten Most Critical Web Application Security Risks

There's a different "ten" being presented and discussed at OWASP London this Thursday: the OWASP Top Ten 2010 RC1. Web application developers should find the new document and associated cheat sheets a great help but it's very important for organisation subject to Payment Card Industry Data Security Standard (PCIDSS). As usual all meetings are free and open to anyone, but prior registration is required. The meetings are very popular, so register now if you haven't already.

It seems we are spending about ten times as much on infrastructure security as application security.

This is the conclusion of Jeremiah Grossman in his post on Infrastructure vs. Application Security Spending using some broad calculations and estimates from the available information. Have a look at the referenced sources and comments, and keep an eye open for the next web application security spending benchmark report.

What is your organisation spending on these two aspects?

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.

This weekend I'm going to a fancy dress party with a theme of film actors and characters, and was looking for Toy Story Buzz Lightyear gear.

One price comparison website listed a Buzz Lightyear toy at £999999.00 which seems rather high. It was either made from something very valuable, or an error.

How do you validate pricing information being added and also when displayed? Who/what can alter pricing, discounts, additional charges, tax rates, etc on your e-commerce web site? What approval processes are in place? Who is accountable? All data should be checked for reasonableness, type, format, characters, length, encoding, etc. Reporting/alerting on changes might also help detect this type of issue.

And, make sure your terms state what happens if a price is "incorrect" and exactly when a contract is formed.

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.

A couple of weeks ago I mentioned listings of user agent (browser identifications). But can this data be helpful in validating logged in user sessions?

Session data (relating to the user) should be stored on the server rather than in cookies or locally on the client (browser) and this is often referenced by a unique, difficult to predict, session identifier, usually set as a secure, httpd-only, temporary cookie. It is sometimes better to validate the session identifier is still being used by the same user it was issued to. Apart from checking the session is still valid (exists and has not expired), you can also check that it corresponds to the same IP address, or at least an IP address range. It's also possible to build into this, checks that the following Hypertext Transfer Protocol (HTTP) request headers haven't changed:

• User agent
• Acceptable languages for response
• Acceptable encodings for response

by storing these properties, or a hash of them, along with the session identifier in the web application's database. They should not change. These additional checks make it harder for someone else to impersonate the (authenticated) user.

You might wonder how unique user agent data can be. In an attempt to determine the uniqueness of browser information and whether this constitutes personal data for privacy protection because it identifies them, the Electronic Frontier Foundation (EFF) has released a new online tool called Panopticlick to let you calculate how unique your own web browser fingerprint is. The test identifies the user agent string, HTTP accept headers, browser plug-ins, time zone, screen size, screen colour depth, system fonts, whether cookies are enabled and storage settings. There is a good write-up about the personal data issues on the Tech and Law blog. But can we use this data for session tracking?/p>

I tried three browsers with Panopticlick:

• Firefox 3.6 running several add-ons (FF3.6)
• Opera 10.10 with JavaScript enabled (O10)
• Internet Explorer 8.0.6 (IE8)

which indicated that all three browser's fingerprints were "unique among the 71,823 tested so far" with at least 16.13 bits of identifying information.

The differences appear to be related to how much information could be gleaned from the browser and system, with plug-ins, screen dimensions and system fonts being very unique—the computer has two graphics packages installed and several custom fonts. Making the browser full screen reduced this aspect's uniqueness, but had no overall change in the browser's identifiability.

This means that some of these data could be used to check for impersonation or even to help identify returning site visitors without setting cookies or requiring people to log in, but you would have to be careful because some browsers won't send all of this data e.g. if JavaScript is disabled. For example, with NoScript enabled, FF3.6 reported as only one in 2,433 browsers with the same fingerprint and that it conveyed 11.25 bits of identifying information instead of over 16 bits.

Further reading about the scary things here and here that JavaScript might be able to detect about your computer and network.