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 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.

Following on from Tuesday's topic of terms and conditions for interactive advertising, the US Network Advertising Initiative (NAI) has just released their 2009 compliance report.

The NAI is an association of 35 US advertising networks, data exchanges, and marketing analytics services providers including Advertising.com, Google and Yahoo.

The NAI Compliance Report 2009 discusses compliance by its members with its self-regulatory code of conduct governing the collection, use, and disclosure of data for online advertising services by its member companies (the NAI Code). The NAI Code has its own definition of personally identifiable information (PII) and sensitive information and its own protection principles. The NAI found its members to be broadly in compliance with the code, apart from ten members that did not disclose specific retention periods for data collected.

Whatever your views of behavioural advertising, industry initiatives like this to improve, and report on, standards are a welcome contribution. No doubt the code will evolve over time, but it is a good starting point. The code perhaps lacks requirements for measuring the accuracy of data or requiring ways for consumers to correct information about themselves, and it would be useful to know what checks are being undertaken as part of the audit. For example "Reasonable security is determined in light of several factors including, but not limited to, the sensitivity of the data, the nature of a company's business operations, the types of risks a company faces, and the reasonable protections available to a company" could be interpreted in a number of ways and some guidance on what is "reasonable" both from the organisation and individual's points of view would be welcome.

P.S. Happy new year.

The Interactive Advertising Bureau (IAB) and Association of American Advertising Agencies (4A's) have published a draft revised Standard Terms and Conditions for Interactive Advertising. Whilst this is principally aimed at the USA market, due to the international nature of the Internet, I thought it worth a mention here.

Use of the template (full title "Standard Terms and Conditions for Interactive Advertising for Media Buys One Year or Less") is voluntary and open to negotiation between media companies and advertisers. However it does discuss data usage and privacy. This is important if you have advertising on your own web site and need to write a privacy notice. Without knowing the agreement between the advertiser and media company, how can you inform your web site users what will happen to their personal information? Although this is only an example template, it probably contains most of the likely issues you will come across in other ones. The definitions of "user volunteered data", "performance data", "site data" and "use of collected data" probably need careful reading and advice from a lawyer! The education version provides some further explanation of terminology and the changes since the previous version.

The template also describes the "special situation of User-Generated Content (UGC) pages" on advert placement and positioning—there could be an interesting discussion if the actual content was neither that intended by the site owner, nor that added by the user, but instead was the result of some malicious injection.

There doesn't seem to be any reference to malware on the site or malware delivered by the advert.

Of course, including third party content is a risk that should be considered in itself.

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.

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.

Two recent reports discuss the growth in web application vulnerabilities.

The latest Microsoft Security Intelligence Report on threats, vulnerability disclosures, exploits and malicious software in the the first half of 2009 highlights, amongst many other things the growth of automated SQL injection attacks. It is both broad and deep, but with coverage on all types of software — operating systems, applications and web applications.

There is more detailed information about web application vulnerabilities in the previously discussed WASC Web Application Security Statistics and to a certain extent in the IBM X-Force Trend and Risk Report which suggested the growth of vulnerabilities in standard (off-the-shelf) software web application is beginning to plateau.

The IBM report suggests that web application vulnerabilities account for around half of all vulnerability disclosures. These are mainly cross site scripting (XSS), SQL injection, and file include vulnerabilities.

This weekend the clocks change as we revert from British Summer Time (BST) to Greenwich Mean Time (GMT) at 02:00 BST on Sunday 25 October 2009 and the clocks go back, giving an extra hour.

What does this mean for web site security? Does running 01:00 to 02:00 twice matter? Well some brave web application owners will be disabling their systems like this online bank:

And, I don't think it's just being done as a finale to the current Energy Saving Week. Most people, quite rightly, won't be taking this rather severe step. Another millennium bug anyone? The date/time should be considered rather like other untrusted user input. Most problems will probably fall into the "business logic" category such as:

• Failure of time-based logic where dates are being compared.
• Assumptions of uniqueness in time-stamped output (e.g. by a single-threaded process).
• Running tasks again leading to possible:
  • loss of data due to overwriting
  • duplication of exports or emails
  • creation of inaccuracies in management information.
• Chronological ordering anomalies leading to other faults.

It's not just banks and other financial organisations that may have difficulties.

The time change may expose some other vulnerabilities that only exist at changeover time and/or during the next overlap hour.

• Circumvention of brute force attacks on user authentication mechanisms.
• Increased risk due to extension of a session's validity where local time is recorded.
• Failure in data validation routines for time-related comparisons.
• Incubated vulnerabilities where a time-related aspect causes the attack to be possible.
• Denial of service due to extension of account lock-out.
• Using time as a loop counter.
• Additional errors caused by any of the above leading to information leakage.

Recording the offset of local time to GMT/UTC and synchronisation should certainly be done, but may not resolve the time overlap issues. The effects on long-running "saga" requests might be especially difficult to determine. Time dependencies need to be specified and considered through the development lifecycle. Perhaps the bank is right after all?

It's common for access to some web sites to be restricted to users from particular Internet Protocol (IP) addresses. This is usually in addition to some other identification and authentication method. But other IP addresses are often added to this "allow list" and these should not necessarily be trusted in the same way.

In a typical scenario, a web site hosted on the internet that is used to administer another web application might be restricted to the company's own IP addresses. Then the developers say they need to check something on the live site, or another server needs to index the content, or someone wants to work from home for a while, or the site needs to be demonstrated at a client's location. All these additional IP addresses are added to the "allow list". These restrictions may be being applied at a network firewall, traffic management system, at the web server, in the application itself, in intrusion detection systems or in log analytical software, or in many of these. These are difficult to manage and in time there will be many IP addresses that no-one knows why they are allowed unless they are carefully documented, and subject to a fixed time limit when they are confirmed again by an appropriate person or removed. These extra addresses are quite often hard for someone else to guess.

However, there is another area where IP addresses are added to "allow lists", and this is for remote monitoring and testing services. These might be checking uptime, response times, content changes, HTML validation or security testing. The service providers publish the IP addresses of the source systems so that companies can specifically allow access to their web sites. Since the number of these services is relatively small, it's not too difficult to find which one might give access to areas of a web site or web application that the public (and malicious people) should not be able to get to. The particular danger here is that the IP addresses might be excluded from monitoring and logging, and therefore even a diligent web site manager might not realise for example the uptime monitoring service is making unusual, or excessive, requests.

Although it is not likely a malicious person is using this "trusted" address unless routing has been compromised as well, problems can go undetected, from what might seem to be a legitimate source. The IP address may have been typed incorrectly, or worse, the restrictions/exceptions may not have been implemented correctly allowing more addresses to have the privileged access than intended. Not logging a user's session is privileged access.

Allow traffic through, but be very specific what is allowed and monitor what's going on. Review all the exceptions periodically. Be especially careful about anything that bypasses authentication (such as allowing a search engine to crawl restricted-access content) on an otherwise public site.

One of the most common issues that arise when discussing accessibility and security, is the use of CAPTCHA images on web pages. These are used to differentiate between real human users and automated systems that might want to submit forms to register fake users, create spam or add links to malicious web sites in forum postings, blog comments and the like. CAPTCHAs are also in the news again after Google acquired reCAPTCHA, one of the larger free CAPTCHA providers.

CAPTCHAs also sparked a new topic in the Web Security Mailing List yesterday, Complex CAPTCHA Solutions raised the subject of the benefits and usability issues relating to CAPTCHA and alternative complex methods.

An article in this quarter's issue (Issue 74 Summer 2009) of Ability Magazine discusses the problem and alternative approaches such as audio versions, logic puzzles and image recognition or even having a human operator available to help.

Using CAPTCHAs on web sites where there are particularly sensitive data or as part of authentication mechanisms before providing access to sensitive or high-value information, is almost never justified. The identification and authentication mechanisms should be sufficient in themselves.

The most appropriate use for CAPTCHAs is on high usage web sites where the criticality of information is low, and the benefits to successful abuse greater. But then the owners of these sites have the resources to develop effective CAPTCHA systems and spend time maintaining the robustness of the method against automated systems and other attacks. The larger the user base, the greater the incentive there is to break the method. See also suggestions on an effectiveness test and my discussion on the security implications of Web Content Accessibility Guidelines 2.0 compliance.

So, normally there are simpler ways to prevent spam on most sites that might consider using CAPTCHAs. There is a good summary on the WebAIM blog and discussion list, based on ideas like the Honeypot Captcha. These measures should be used in the first instance for response forms, forum registration and the like. Proceed from there only if a problem occurs, and spend time thinking about other security matters.

Ability Magazine can be obtained by subscription but it is also a free benefit to members of the British Computer Society (BCS) Assistive Technology Group, formerly the BCS Disability Group.

Update 28th September 2009: I just read Using Web Analytics to Assess CAPTCHA Usability on Smiley Cat Web Design which describes an assessment of how many visitors to a web page had difficulty with the CAPTCHA by looking at how often they reloaded it.