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.

A posting about cloud computing's broadband requirements by EURIM Secretary-General Philip Virgo on his When IT Meets Politics Blog caught my eye yesterday.

In the posting Does Cloud Computing need Superfast Broadband?, Philip Virgo highlights two documents from 2009 that I hadn't come across previously:

• UK Broadband Speeds 2009 - Consumers' Experience of Fixed-line Broadband Performance, OFCOM, 28 July 2009
• Next Generation Connectivity - A Review of Broadband Internet Transitions and Policy from Around the World, Berkman Centre for Internet and Society, Harvard University for the US Federal Communications Commission (FCC), October 2009

Certainly plenty of data about the UK and comparisons with abroad, especially when combined with the Oxford Internet Institute report Internet in Britain 2009. Useful if you are planning a web project that depends upon high-speed internet access in the UK, or are developing a web application for mobile devices and are wondering just how fast connection speeds are.

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.

The web browser (user agent) normally sends a string of text to identify itself, but this can be blank or many other things, and can be altered by users.

The Bots vs Browsers (robots versus web browsers) web site monitors the user agent identification strings and helpfully provides access to their valuable data. They have identified over 400,000 different user agent strings to date. You can see 5,000 unidentified that are not obviously any particular search engine robot or browser and could be accidental, mischievous or malicious.

Always treat user agent strings as untrusted, and check their length and content before using the sanitised text to display, or in decision-making logic or when writing it to a file or database. The lists for particular types of devices (e.g. the iPhone) may be useful to remind you of the range of values sent. User agent strings certainly shouldn't be used for any form of user authentication.

On Wednesday I attended the Information Commissioner's Office (ICO) Personal Information Online Conference 2009 at which the ICO launched their consultation on the new Personal Information Online Code of Practice.

Manchester and Salford gave us a beautiful sunny day for the event which briefed delegates on the ICO's approach to data protection and an outline of the collaborative process used to develop the draft code of practice. Iain Bourne, Head of Data Protection projects, noted that fewer than hoped public sector organisations had been involved to date, and they would like more feedback from this sector in particular during the consultation phase that ends on 5 March 2009.

My first impressions are this will be a useful document for organisations without staff dedicated to data protection or compliance, especially once the examples and SME checklist are added. The structure and content are still a little raw, but probably about right for the start of a 12-week consultation process. Areas where I am already considering providing feedback are:

• local storage of personal information (not just cookies)
• verification of protection
• suppliers, sub-contractors and staff
• monitoring and anomaly detection
• transmission of personal information
• inclusion of third party content in web sites
• using cookies to enforce an opt out
• additional reference materials.

The full text and consultation document is available as a PDF.

Feedback on the Personal Information Online Code of Practice can be provided using the ICO's consultation portal with further background available in the related press release.

What are the business risks of using cloud services? Well, the European Network and Information Security Agency (ENISA) has published a thorough review of cloud computing benefits, risks and recommendations.

I have mentioned web application security in the cloud on two occasions previously, but what are the wider issues? Risk assessment explanations can sometimes be rather dry and lacking in practical examples. The majority of ENISA's document is a walkthrough of a risk assessment for a real SME use case. Wow, not a bank!

In this particular use case, and it would of course be different for each organisation, the greatest risks were found to be loss of governance, compliance challenges and risk from changes of jurisdiction.

Whilst the analysis does not represent a real company nor any particular cloud services, the approach can be used by anyone wanting to undertake an analysis of the cloud computing risks in its own context. The document examines the risks for:

• software (application) as a service (SaaS)
• platform as a service (PaaS)
• infrastructure as a service (IaaS)

and details:

• technical risks
• legal risks
• risks not specific to the cloud.

A non-exhaustive list of vulnerability categories and asset types is included together with recommendations for an information assurance framework, legal recommendations and a thorough checklist of information assurance requirements. Overall, extremely useful.

If you have already assessed the risks and want more detail about information security, the guidance document from the Cloud Security Alliance is worth reading. Dennis Hurst (HP) spoke about the forthcoming update to this document at OWASP AppSec Washington DC 2009.

Examples of content aggregation often refer to the use of web services and XML data such as RSS feeds. But today's world of web 2.0 in creating more and more data in a wide variety of formats including JSON (JavaScript Object Notation); and web applications are being used as a concentrator to combine these together.

With the growth of layered communications, multiple communication channels such as text, video and audio are merged into one event. If the content is recorded it can be republished via a web site. But what are the specific security risks of this?

Web services and XML data can include invalid or malicious data. The format/schema may be incorrect. But with the increase in layered communications, content from many different devices in many media may need to be aggregated into a single resource; and these often don't have any formal syntactical structure. The data might even include active content such as embedded rich applications.

If these need to be stored and replayed such content at a later date, how might they affect a web page? The content could contain, or link to, malicious content that steals user data such as session cookies, modifies the page's content or installs malware onto user's computers.

• Identify all the data streams.
• Determine their formats and encoding where appropriate.
• Ruthlessly limit what active (script) content is allowed and what ability it has to interact with the parent web site and its domain.
• Analyse the data streams to validate they contain what is intended and scan for malware.
• Sanitise content where applicable.
• Limit file size/length/number of nodes.
• Avoid merging trusted and untrusted content in data fields.
• Encode the output correctly for your own application.
• Monitor activity and look out for unusual events.

And beware embedding rich internet applications (RIAs) such as Adobe Flash or Microsoft Silverlight, which may be doing this aggregation themselves.

After all, you don't want your web site to be a concentrator multiplexing malware.

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.