The first report on the state of software security has been published by Veracode who provide a cloud-based application risk management service.

The data presented in State of Software Security Report - The Intractable Problem of Insecure Software are interesting, it relates to both web application (40%) and non-web application (60%) software but spans in-house developed, commercial, open source and outsourced, developed in .NET, C/C++ and Java. But don't get bogged down in the data. I'd recommend that everyone responsible for web development, or who commissions or operates a web site, read the executive summary. I was quite surprised that backdoors (a method of bypassing normal authentication) are still a significant issue: "Open Source projects have ... fewer potential backdoors than commercial or outsourced software". This is why "V13 Malicious Code Search Verification Requirements" appears in the Application Security Verification Standard.

There are seven recommendations, which are in summary:

• Implement a comprehensive, risk-based, application security programme.
• Implement security acceptance criteria for third-party suppliers.
• Test code from outsourced, commercial and open source suppliers as rigorously as internally developed code.
• Verification of C/C++ code must not be ignored and it is likely to be present in many applications.
• Implement specific developer training on security.
• Learn from organisations in higher-risk sectors such as finance and government.
• Ensure security requirements are built into outsourced software development.

Some good advice there. The report provides a fuller description and gives the background to these recommendations.

I guess there must be much more detailed data available to Veracode than is presented in this "Volume 1". Perhaps Volume 2 will look at trends over time, but I'd also like to see:

• Breakdown of root causes (e.g. unvalidated user input).
• Breakdown of how the vulnerabilities had been fixed when the software was re-tested (e.g. parameterized queries implemented).
• What proportion of faulty code was identical — found in more than one application (i.e. copied/duplicated from elsewhere).
• Details of any secure development lifecycle in use by suppliers and their level of maturity with these.

Hopefully this type of aggregated data can be shared under Veracode's terms of service and agreements with individual customers. The software suppliers included in Veracode's analysis are likely to exclude customer organisations who do not have the knowledge or resources to have their code analysed. It would be an interesting research project to test a selection of applications developed by other suppliers to see how they compare.

Last month I described the ability to track users sessions with browser data. A recent posting on IT Law in Ireland highlighted a series of blog posts elsewhere that give further insight into what is possible.

Well, I just got round to reading them properly. The posts on Freedom to Tinker by David Robinson and Harlan Yu are:

• Identifying John Doe: It might be easier than you think
• What Third Parties Know About John Doe
• The Traceability of an Anonymous Online Comment

The conclusion? It is possible to trace and identify individuals easier than you may think. We are dropping evidence like dead skin cells as we traverse the internet. Fact or fiction? Well the US Defense Advanced Research Projects Agency (DARPA) are taking it seriously with a recent call for research into cyber genetics, cyber anthropology and cyber physiology in its Cyber Genome Program. DARPA hopes to develop advanced methods to fingerprint or identify the origins of a cyber attacks by examining digital artifacts, and presumably other criminal activities utilising computer technology.

Getting a bit more down to earth, web site owners need to consider what information is being gathered and why, ensure this is legal, check that consent is implied or has been explicitly given for the purposes and what monitoring and analysis is performed on the data. It could be easy for system developers to carried away with tracking and tagging. Contracts with third parties should state clearly what the expectations are about the security and privacy of information, to protect web site users (employees, customers, clients, citizens) and the business.

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.

Today the Council of Registered Ethical Security Testers (CREST) and CESG, the UK national technical authority for information assurance, are running the first Ethical Security Testers Conference at Royal Holloway, University of London.

I am attending the conference on behalf of the Open Web Application Security Project (OWASP) Global Industry Committee. Apart from the web security related presentations, I am particularly looking forward to hearing about CREST's progress and the future of CREST/CESG certification schemes.

I will update this posting at the end of the day tomorrow.

Update 16th December 2009: There were many familiar faces at the well-attended first conference. CREST and CESG had put on an interesting programme of mainly technical speakers—the demonstration of the Context App Tool was particularly useful for the application testers present, and I'm looking forward to trying the beta 3 version. Infrastructure security testing presentations were given on USB drivers, Windows authentication, CISCO IOS, deployment solutions and full disk encryption products.

CREST and CESG outlined their vision for information assurance professionalism, and it sounds like the CREST scheme is growing in momentum both in the UK and overseas. It seems there may soon be CREST services available in South Africa abd Benelux, and mention was made of some potential partnership with the SANS Institute.

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.

Web applications that process, store or transmit payment card data fall under the Payment Card Industry Security Standards Council (PCI SCC) Data Security Standard (DSS) requirements where they are being enforced by the merchant's acquiring bank or card processing company.

PCI DSS

PCI DSS 6.5 (version 1.2) requires the use of secure coding practices that cover prevention of common coding vulnerabilities in software development processes including the vulnerabilities listed at 6.5.1 through 6.5.10 (taken from the OWASP Top Ten 2007).

PCI DSS 6.6 (version 1.2) requires addressing new threats and vulnerabilities on an ongoing basis and ensuring public-facing web applications are protected against known attacks by either review via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes or by installation of a web application firewall (WAF). This is to ensure web applications exposed to the public internet are protected against the most common types of malicious input. If a WAF is used, a recommendation is that it "react appropriately (defined by active policy or rules) to threats against relevant vulnerabilities as identified, at a minimum, in the OWASP Top Ten and/or PCI DSS Requirement 6.5.".

OWASP Top Ten

Therefore the OWASP Top Ten is inherently linked with PCI DSS Requirements 6.5 and 6.6, and updates to it affect PCI DSS compliance. At the OWASP AppSec DC2009 in Washington, the OWASP Top Ten project announced release candidate 1 (RC1) for the Top Ten 2010. The RC1 document is open for comment until 31 December 2009 and is expected to be finalised in January 2010. This will affect every merchant and payment gateway with a web-facing application in scope that is required to be PCI DSS compliant (e.g. merchants and service providers where Self-Assessment Questionnaire validation type 5 applies).

The Top Ten has been revised to focus on risk rather than vulnerabilities. For each web application security risk, the Top Ten document provides an explanation of the risk, how to determine if a web application is vulnerable, how to prevent the problem, example attack scenarios and references. Yes, that's right— you can actually prevent all of these risks, unlike many other risks that business fave which can only be reduced, accepted or ignored.

There has already been discussion concerning:

• the use of a risk-based ranking;
• the degree to which umbrella categories (e.g., A1 Injection) should be used to group multiple risks;
• whether proper error handling is included within A6 Security Misconfiguration; and
• the use of business-related language rather than attack/weaknesses language.

Actions

So what needs to be done? Well, nothing immediately unless you have some feedback on the new document. But prepare for a change in PCI DSS compliance requirements. If requirements 6.5 or 6.6 apply to your systems, this could include the following:

• If you have explicitly detailed the ten vulnerabilities listed in 6.5.1 through 6.5.10 in any internal compliance documents, standards or policies, these will need to be updated to the new risks.
• The vulnerabilities covered in the software development processes of your own web applications may need to be altered.
• Web application vulnerability assessments and/or web application firewalls, need to ensure they address the new listed risks.
• Discuss with your advisors or auditors when the changes apply to your own operations to achieve continuous compliance.

In practice, you may also want to start looking at the Application Security Verification Standard (ASVS) for web applications which gives a broader view of application security issues than those in the Top Ten.

But remember, the Top Ten was of course only meant to be the most important risks to web applications and as the new 2010 RC1 version states, the Top Ten is only the first ten. Your processes, reviews and controls should already be addressing the "new" risks. They are new in the Top Ten, not new problems.

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?