The Ponemon Institute has realeased its latest survey of UK data losses.

The findings of the 2009 Annual Study: Cost of a UK Data Breach indicate that personal data losses ("breaches") are still increasing in cost (per record). The report discusses the growth of data breaches due to malicious attacks and botnets, how prevalent these are compared with other losses and the relative costs. The report also presents comparitive data for losses involving third parties, and for organisations who have experienced their first data loss.

Although we hear a lot about lost or stolen devices (laptops, USB sticks, mobile phones, etc) and malicious/criminal attacks, the most common primary cause for the losses was negligence.

The recent news that the German government is considering buying stolen personal data of its citizens who it suspects of tax evasion is worrying. This sort of activity may fuel personal data theft by leavers and disgruntled employees.

The report is available in PDF format.

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.

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.

After yesterday's long day (Thursday) at Open Web Application Security Project (OWASP) AppSec DC 2009, the second day (Friday) began promptly again at the Washington Conference Centre.

The second day had four different streams:

• Process
• Attack and defend
• Metrics
• Compliance

My own programme comprised:

• The Big Picture: Web Risks and Assessments Beyond Scanning, Matt Fisher
  A description of why automated security scanner are not sufficient to cover an entire application or detect most vulnerabilities.
• SCAP: Automating Our Way Out Of the Vulnerability Wheel of Pain, Ed Bellis
  A description of how SCAP standards can be used to combine various vulnerability feed data into a single organisation-wide repository that can be used to normalise and correlate data.
• OWASP Top 10 2010, Dave Whichers
  First look at RC1 of the new OWASP Top 10, planned for release in early 2010.
• The 10 Leasr-Likely and Most Dangerous People on the Internet, Robert Hansen
  Key people/roles in named organisations who, if compromised, could have significant adverse effect on the secure operation of the internet.
• Deploying Secure Web Applications with OWASP Resources, Sebastien Deleersnyder and Fabio Cerullo
  Case studies in the education, financial and telecommunication sectors.
• Injectable Exploits: Two New Tools for Pwning Web Apps, Frank DiMaggio
  Two new utilities to assist with injection and fingerprinting and a brief introduction to the Samurai web testing framework.
• Techniques in Attacking and Defending XML/Web Services, Jason Macy and Mamoon Yunus
  A description of three types of attack and methods to defend against them.

The presentations will be available on the conference web site.

At the end of the day, prizes for the capture the flag event were given out, vendor draws undertaken and a selection of prizes given to OWASP members who were present, selected at random.

It was a well organised event and the conference team and helpers deserved the praise and thanks.

Following an encouraging discussion of the Building Security In initiative of the US Department of Homeland Security by Joe Jarzombek, Director for Software Assurance in the National Cyber Security Division, and a short presentation from the Open Web Application Security Project (OWASP) board, OWASP AppSec DC 2009 got underway.

The conference had four streams on the first day:

• OWASP
• Tools
• Web 2.0
• SDLC

This made choosing which presentations to attend difficult, but I settled on:

• Understanding the Implications of Cloud Computing on Application Security, Dennis Hurst.
  Briefing on the upcoming second version of the guidance document from the Cloud Security Alliance.
• Transparent Proxy Abuse, Robert Auger
  The lifecycle, explanation and demonstration of an unexpected weakness in transparent proxies.
• OWASP ModSecurity Core Rule Set Project, Ryan Barnett
  Briefing on ModSecurity web application firewall (WAF) and the changes in the recently issued v2 rule set which is now an OWASP Project.
• Defend Yourself: Integrating Real Time Defenses into Online Applications, Michael Coates
  An update on the OWASP AppSensor Project and two example implementations demonstrating how the AppSensor responds to an automated scanner, and how it could suppress application worm propagation.
• The ESAPI Web Application Firewall, Arshan Dabirsiaghi
  Demonstration of code built upon the OWASP ESAPI Project to apply virtual patches to an application built in Java.
• Attacking WCF Web Services, Brian Holyfield
  Description of .NET core communications framework and how messages can be intercepted, decoded and modified.
• When Web 2.0 Attacks – Understanding Security Implications of Highly Interactive Technologies, Rafal Los
  Issues and examples of how Web 2.0 is reinventing old faults.

The presentations will be available on the conference web site.

The day ended with a generously sponsored reception for delegates to network further and practice penetration testing.

Update 14th November 2009: Part 2 added.

Earlier this year, the Center for Internet Security (CIS) published Consensus Security Metrics to allow organisations to collect, analyse and share data on security performance and outcomes. These are based on the consensus viewpoint of 100 experts.

I've just had a chance to read the whole document and I'm impressed. The document includes twenty consensus metrics definitions for six business functions:

• Incident management
• Vulnerability management
• Patch management
• Application security
• Configuration management
• Financial metrics

Additional metrics for these and other business functions are in development.

The metrics are an excellent reference document and are carefully explained, referenced and excellently presented. These should be of interest to people owning, operating or developing web applications and looking for measures to examine performance, regardless of their role or experience. If you are looking for some metrics, don't re-invent the wheel, read this document first.

In this month's PC Pro magazine, Davey Winder commented on the Information Security Awareness Forum (ISAF) concerning their recommendation to have "report abuse" links on web sites.

In his column titled "Stupid Security" in the Online Security section of Real World Computing, he says there are too many "click this" links on most sites and that a report abuse link on a fake site is likely to give you a fake answer. Very true.

But that doesn't get away from the problem that people still need to have somewhere to go to ask for help, to query account entries, to answer concerns or to report suspicious emails and web pages. That's why we have phone numbers printed on credit cards, bank statements and even on web sites.

The ISAF and its member organisations are doing more than many others, including their excellent Directors' Guides, and they didn't deserve this. Perhaps PC Pro will become a member and contribute to the effort to promote and improve information security awareness.

Bruce Schneier's blog posting this week about Security vs. Usability highlighted an essay by Prof Don Norman (of the Nielsen Norman Group) concerning When Security Gets in the Way.

It struck a chord with me since I had just been reading an article on Econsultancy.com speculating that customer's problems with 3D Secure had led to Google Checkout Dropping Payment by Maestro. You might know 3D Secure better by the scheme-specific names Verified by Visa and MasterCard SecureCode. The implementation of these schemes by banks and e-commerce merchants has been a terrible mishmash of in-line frames, pop-up windows, unbranded pages, redirects and mandatory JavaScript. Most instances have terrible usability, many raise users' security concerns and some applied the password setup and change mechanisms poorly. The article suggests merchants have found 3D Secure decreases the conversion rate. How were usability and privacy concerns addressed during each system's design? After all, the users are the banks' customers, and the credit card companies' customers and the e-tailers' customers.

Prof Norman finishes with:

Perfect.

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.