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?

Web sites are being published "in the cloud", but what are the cloud computing security risks?

I have mentioned previously the excellent Cloud Computing Benefits, Risks and Recommendations from ENISA. Yesterday the Cloud Security Alliance (CSA) published their updated document Security Guidance for Critical Areas of Focus in Cloud Computing V2.1 (December 2009), which was previewed at last month's OWASP AppSec DC 2009.

The operational domain (the term used for a category in this guidance document) of Application Security will be of most interest to web folk, but the remaining architectural, operational and governance domains provide full coverage of the cloud computing risks. After all, there's no point securing your web application if the server's wide open to abuse, or you don't have the clear responsibilities defined, or you don't have access to the data in the event of a disaster.

The recent Amazon EC2 Botnet is a timely reminder of the issues that can occur.

In April I described some issues with Web Application Security in the Cloud - Part 1 and in Part 2. The CSA's Domain 10 (Application Security) describes five aspects to consider:

• application security architecture
• software development life cycle (SDLC)
• compliance
• tools and services
• vulnerabilities

and provides a number of key security recommendations. The same pattern is used for the other domains.

Alternatively, if you are looking for a broader introduction to the subject, I'd recommend the book Cloud Application Architectures by George Reese and published by O'Reilly (ISBN 978-0-596-15636-7). This also has a chapter about security, but the ENISA and CSA documents provide much wider coverage and greater detail.

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.

Information leakage is a term we are hearing more about these days. But what is it, and what does it look like?

There's a useful briefing document Information Leakage available from the Information Security Forum (ISF), that describes the what information leakage is, why it's important and ways to reduce the likelihood of information leakage occurring. It describes information leakage as "an incident where the confidentiality of information has been compromised" but I'd also include privacy breaches within that description. An alternative application development view of information leakage is published by the Web Application Security Consortium (WASC).

We've all heard about lost laptops and misplaced USB memory sticks, but in what other more subtle ways can information leakage occur? Well, certainly by malicious hacking, but also by more ordinary actions too. This week, I was looking for a location to host a meeting, and some of the possible venues had web site enquiry forms to collect my requirements. One of these form submissions appeared to work okay, but shortly afterwards I received a message from their mail server informing me that it had been unable to deliver an email from me to two of the company's email addresses:

I've mentioned previously about using email in business processes in Keep The Emails Coming and Application Data Flows by Email. But what else did this fault lead to? Well it gave away (leaked) two email addresses and an internal document that was attached. In fact, I don't think there was any information that I hadn't added myself in the attachment, but it may be that the two email addresses were not intended to be known publicly.

This seemingly small, and hopefully transient fault, has leaked some information. Whilst it is not major in any way—more like a couple of drips than a flood—you can see how information can be divulged in unexpected ways.

In this example, using an external email address as the "from" or "reply-to" fields within internal business processes may be convenient, but in error situations the sender may be notified, so do this with care. A similar situation might also occur if your own mail server rejects the message as spam, or has an out-of-office auto-responder set up for the recipient email account.

Last week I discussed the business case for web security and how this is necessarily organisation-specific.

If you use common IT investment models, you may want to look at the paper Business Models for Assurance on the US Build Security In (BSI) web site. But what are real organisations spending?

Sources of data to compare yourself with are very rare and it's good to see the second quarterly report on Web Application Security Spending Benchmarks. This quarter, the report has a special emphasis on three aspects of cloud computing:

• Infrastructure-as-a-Service (IaaS)
• Platform-as-a-Service (PaaS)
• Software-as-a-Service (SaaS)

This type of benchmarking is really useful. Years ago, I helped with some work on benchmarking water usage across UK industry sectors—without this type of initiative it is difficult to determine whether what you are doing is reasonable.

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.

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.

I will be speaking later this morning at the IT Governance Watch event in London.

IT Governance Watch is a joint initiative of the Cyber Security Knowledge Transfer Network and The National Computing Centre. The day's programme is intended to be a combination of seminars and workshops; IT Governance Watch is proposed as a new observatory of standards and good practice in governance, security, risk, and information assurance of information systems.

Update 26th March 2009: David Lacey, an attendee at IT Governance Watch on Tuesday, has posted his views on the event in Better Standards for Standards Please.

The next Open Web Application Security Project (OWASP) Application Security (AppSec) European Conference is in Kraków, Poland from 11-14 May 2009.

The OWASP AppSec Europe 2009 will include two days of training and a two-day conference with a pair of tracks. Whilst this is a reminder for web application managers, architects, designers, developers, testers and auditors to keep the date free, the calls for presentations, trainers and refereed research papers are currently open:

• Call for presentations, deadline 1 February 2009
• Call for training providers, deadline 1 February 2009
• Call for refereed research papers, deadline 2 March 2009

So if you are working in web application security, please consider participating.

The next OWASP local chapter meeting in London is on Thursday 12 March 2009 at which I hope to be speaking about the OWASP Global Industry Committee. Everyone is welcome, but you need to register (free) first.

Update 19th May 2009: See also What's the Scope for Accessibility Testing? and Can An Accessible Web Application Be Secure? concerning my own presentation at OWASP AppSec EU09.

I'm thinking about whether to write some posts on my recommendations for logging, monitoring and alerting.

Much as I hate to suggest you need more monitoring, web sites and web applications shouldn't be left alone. So I'll write more about this in the new year.

In the meantime, here's my seasonal card—even Christmas trees have CCTV cameras in them now:

Seen in a London shopping centre, early December 2008.