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.

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.

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.

Sometimes finding all the web applications in an organisation can be the difficult part in trying to assess what risks exist.

Transport for London don't just have web sites and, I suspect, an intranet. They have been gradually moving from whiteboards for live underground travel news at tube stations:

And now have electronic versions:

I don't know what technology is being used here, but other information boards have been seen to display web browser error messages leaking network information:

But, what about elsewhere? I saw this on the live electronic advertisement boards at Bond Street station this weekend:

Sorry it's a bit blurred, but I was going up the escalator at the time. Several, but not all the displays had their system names shown rather than an advertisement. It certainly looks like an IP address, but is there a web application inside? I've previously highlighted other information systems and displays that seem to be IP-enabled.

An investigation of your network, examining what is listening on which ports, and correlating this with the actual network traffic, might reveal more web applications than you thought.

It seems a missing full stop brought down every web site hosted on a domain ending with .se (the top-level domain for Sweden) on Monday evening.

The .SE registry had apparently performed an incorrect software update but actually a script (program written by a human) had failed to add a terminating full stop (.) to the DNS records in the .se zone. Tested? I guess not.

It reminded me of Google's mishap in May when it flagged every site as potentially harmful by simply adding an extra forward slash (/) character to a file.

And, simple punctuation mistakes can invalidate the HTML of your web page, or stop your application's scripts from running. In July Microsoft created a security flaw in Windows by the addition of an extra ampersand (&) character.

Tim Berners-Lee is still wishing he hadn't put two forward slashes in every URL.

The mighty power of a punctuation mark.

The design and architecture of web sites and the supporting application software and systems is an important step in a well-managed development programme.

Design reviews can be used to identify security-related problems with the fundamental structure (architecture) which no amount of secure coding will solve. And, it's not just about adding network and application firewalls and intrusion protection systems (IDS)—in many cases a better (less complex, more robust) design can be achieved by considering security issues such as authentication, authorisation and integrity, and the privacy issues of data subjects themselves.

Even if you, or your development agency, don't have a formal process, you should try to build reviews into the project's requirements and ensure that software designs, architecture and data flow diagrams are itemised deliverables that require sign-off. Then any changes to these should be re-assessed, agreed and approved.

In Web Application Security in the Cloud Part 1, I mentioned some risks associated with "cloud computing", and other services provided online by third parties.

At my work, we sometimes use Infrastructure as a Service (IaaS) virtual hosting to undertake testing. These are not a business critical use and there is never any client, or business, data on the servers. One of these is GoGrid. A few weeks ago it seems their services were offline for an extended period (significant if the service is a vital process), due to a combination of denial of service (DoS) attack and scheduled maintenance, culminating in this Update from GoGrid Founders:

I applaud the efforts undertaken by service providers such as these, rather than being unable to recover like Ma.gnolia after a, much less complex, database and backup loss:

The video on the Ma.gnolia home page is worth watching before signing contracts with third party providers.

For further discussion of the issues, some further blog posts which I recommend, are:

• The Cloud: policy consequences for privacy when data no longer has a clear location
• Cloud Catastrophes (Cloudtastophes?) Caused by Clueless Caretakers?
• The Vagaries Of Cloudcabulary: Why Public, Private, Internal & External Definitions Don't Work...
• The new cloud infrastructure: Do you care?
• Does Cloud Infrastructure Matter? You Bet Your Ass(ets) It Does!

Look before you leap!

Update 27th November 2009: See also Cloud Computing Risks.

There have been some good discussions recently on the security of cloud computing services. Are you using or considering using external cloud computing for data storage or to undertake business functions?

A recent post A follow-up on SaaS & Cloud Risk reminded me to raise the topic here. The posting highlighted comments on The Register regarding Multi-site Bug Exposes Cloud Computing's Dark Lining included one by Raife Edwards:

Does this affect you? Not sure? Does your business use any of the following (the categories and terminology overlap)?

• software as a service (SaaS)
• platform as a service (PaaS)
• infrastructure as a service (IaaS)
• hosted application
• application service provider (ASP)
• cloud computing
• online office application (e.g. Microsoft Business Productivity Online Standard Suite, Google Docs)
• external web mail (e.g. Hotmail, Gmail, Live Mail)
• peer-to-peer services (e.g. Skype)
• online backup and synchronisation (e.g. Iron Mountain, iDisk, Live Mesh)
• other people's content included directly into your software applications (e.g. news feeds, maps)
• third party online service (e.g. address lookups, payment gateways).

If so, perhaps answer these three questions. Does it matter...

• if someone else deletes, or an unauthorised person views, your data?
• in which geographic location your data are stored?
• if your data or service are unavailable for more than 10 minutes?

If you answered "yes" to any of the above, take time to consider what the effects would be if any of your data was stolen or the service was unavailable for an hour, a day or a week. The considerations are very similar to any other business decision, but it's easy to forget the trust we are placing in another party.

The key security issues to review are software liability, right to audit, service level agreement (SLA), security testing plans, authentication policies, intellectual property, storage locations, system isolation, data encryption in transit and at rest, backup and recovery, archival, support, complaints procedure, contract jurisdiction and legal compliance. If you have cyber liability insurance, you will also need to check whether these cloud services are covered.

In Part 2 (of 2) on Tuesday, I'll highlight some more recent cloud computing issues and provide links to additional discussions.

Update 27th November 2009: See also Cloud Computing Risks.

Email is sometimes discounted or just excluded from the scope of web application code reviews and penetration testing. This isn't always the correct decision.

A web application's boundary can sometimes be difficult to define, and thus it's possible to set the wrong scope of a review, audit or security test. Web applications may be comprised of multiple independent separate systems across many organisations and geographic locations (e.g. a page containing a news feed from a third-party, someone else's widget and web analytics code).

But even the simplest web application usually have some sort of email functionality—this might be simply to raise alerts about unusual conditions such as errors, but often email is used in user authentication mechanisms such as registration forms and password change functions. But marketing emails may also be sent by third-parties and these might include web content drawn from the site or include URLs or redirects to particular resources on the web site.

I was reminded of this by an econsultancy.com blog posting this week UK retailers need to improve their email marketing efforts. Lots of good advice there. I have saved some recent poor quality marketing emails:

It just seems too easy to send these things off. Another one even had some FTP account details embedded in an image address! I spoke to the company's IT helpdesk on that one.

But yes, where the emails include links to the web site, describe functionality, submit data to the web site or include web content, they should normally be considered within scope of a security test. They may also contain useful details for the information gathering phase.

What a pity. Six weeks on and Sage Live, a new on demand Software as a Service (SaaS) web product from business management software providers Sage Group plc, is still offline. It was withdrawn at the end of January after less than a month of operation due to serious security flaws.

An article on ZDnet Sage Shows Why Bigcos Can't be Trusted with SaaS, describes the events leading up to the event which followed the blog posting on Sage Live - Serious SaaS Security Issues by a competitor KashFlow who Sage had previously complained about to Trading Standards. Despite 18 months in development, it took users of the public beta version to identify basic security flaws in Sage Live that have since been confirmed by more expert reviewers.

Developing web applications is not the same as developing conventional software, and Sage got it badly wrong. At least they have taken it offline—but it will take a lot of effort to rebuild the required trust in the service if it re-launches.