It's encouraging to see commercial information security organisations sharing their experience, knowledge and data, such as in the OWASP Security Spending Benchmarks Project. Last week Verizon also published details of its Incident Sharing Framework.

The framework (beta, 1st March 2010) is used in Verizon's internal security metrics gathering processes and to produce its public data breach investigation reports. The framework provides details of how various security incidents should be classified and recorded, including what is done to remedy the situation and further actions taken, such as education. By publishing the framework, Verizon hope that other organisations might collect similar data and ultimately share it to improve common knowledge.

Some other related frameworks and initiatives are listed at:

• Security Content Automation Protocol (SCAP), NIST, specifications and emerging specifications
• Consensus Information Security Metrics, CIS (see previous post on Web Application Security Metrics

These frameworks may be too complex to consider for some organisations, but even so, they provide a good guide to the kind of things you should be considering in security and privacy incident management policies and procedures. They are also useful standalone references for classifying various types of attacks and accidents.

On Thursday the UK Government's Central Office of Information (COI) is hosting an event about auditing government websites aimed at government agencies (EAs) and non-departmental public bodies (NDPBs) that have a deadline looming in April 2010.

Web site quality and value concerns were raised in a National Audit Office report on Government on the Internet: Progress in Delivering Information and Services Online in published in July 2007 and recommendation made in the Public Accounts Committee (PAC) Sixteenth Report. Along with their other web standards and guidelines, the COI has issued standards relating to costs, usage and quality. Version 1.1 of TG126, November 2009, on measuring website quality describes three requirements for measuring and auditing website usage:

The benefits of web site auditing were described last year by Adam Bailin on the Digigov blog.

It is very encouraging that the COI are developing standards to improve quality and value. Apart from usage measurement and audit, the quality requirements cover the topics of domain names, usability, accessibility, archival, browser testing, web site map, cost monitoring and web site closure (disposal).

But there are some areas that are not represented in these standards. A glance at something like ISO 9126 indicates other important software quality. A starting point would be to monitor some privacy and security metrics.

And of course, I'd like to see some government requiring some standards for security, which unlike privacy, has a much less firm legal guidance and regulation (for privacy these are the Data Protection Act 1998 and the Information Commissioner's Office). The most well-developed standard for web site security verification is the Application Security Verification Standard (ASVS) from the Open Web Application Security Project. It's free to download and use, and perhaps this can be incorporated or referenced by future government standards and other software security assurance programmes.

This week the Ministry of Justice published the summary of responses to their consultation on revised fines for serious breaches of the Data Protection Act.

In Civil Monetary Penalties: Setting the Maximum Penalty proposals were made for a maximum £500,000 fine following granting of powers to impose civil monetary penalties being added to the Data Protection Act (DPA) 1998 (Sections 55A to 55E) by the Information Commissioner's Office (ICO) through section 144 of the Criminal Justice and Immigration Act 2008.

The 52 submissions described in the summary of responses showed broad agreement for fines up up to £500,000 for data controllers who seriously contravene data protection principles. The ICO issued a press release Data Breaches to Incur Up To £500,000 Penalty on the same day with details of how they will consider:

• the circumstances including the seriousness of the data breach
• the likelihood of substantial damage and distress to individuals
• whether the breach was deliberate or negligent
• what reasonable steps the organisation has taken to prevent breaches.

The ICO has produced statutory guidance about how it proposes to use this new power, which has been approved by the Secretary of State for Justice, and has been laid before Parliament.

The statutory guidance is worth reading since it outlines things such as "reasonable steps the Commissioner expects the data controller to take" that include (in a non-exhaustive list that includes mention of risk assessment, governance, audit, policies, procedures and practices):

So, the standards are being raised.

Subject to Parliamentary approval, the civil monetary penalties are expected to come into force later this year on 6 April:

• Draft Order "The Data Protection (Monetary Penalties) Order 2010"
• Statutory Instrument 2010/31, The Data Protection (Monetary Penalties) (Maximum Penalty and Notices) Regulations 2010

P.S. If you are interested in privacy matters, The EU's Article 29 Working Party and Working Party on Police and Justice have jointly published a paper on The Future of Privacy (WP 168) and there is an excellent summary and overview on the Tech and Law blog. The conclusion: a new comprehensive legal framework for data protection is needed in the EU.

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.

As I prepare to go to OWASP BeNeLux Day 2009 tomorrow to speak about compliance driven vulnerabilities in web applications, the aspect of auditability came to mind.

Audit logs record user-initiated activity (human or otherwise) in a system or application. They are a trail to establish accountability and responsibility for processed transactions i.e. what, when, where and who. Some form of audit trail is often specified in a web site's requirements, but this is often incorrectly seen as independent to other requirements. All software test cases should also identify the expected audit trail outputs and check they are being generated correctly:

• It is not sufficient for the user functionality to match the requirements alone.
• The generated audit trail must match the tests undertaken.
• It must be possible to determine the original actions from the audit trail.
• Mis-use cases should generate appropriate trails as well.

In-built audit hooks (embedding code in applications for the examination of selected transactions) and continuous auditing (near real-time auditing logic) must not introduce their own vulnerabilities:

• The extra complexity of audit code in an application requires additional security verification.
• Identify the trust boundaries around these parts of the application.
• Ensure the audit code cannot be used by malicious users to circumvent other controls such as authentication and authorisation.

Test cases will also need to be prepared to verify the protection and management of the audit trail. Ensure the integrity of the audit trail:

• The trail must be protected from subsequent modification (alteration and deletion).
• Even if the amount of logging is configurable, the default should provide sufficient detail for the business's needs.
• It should not be possible to completely inactivate all audit trail generation.

NIST have a useful document SP 800-92 on management of security logs—many of the considerations are similar for the protection of audit trails.

The extraction and examination of audit trail data must be controlled:

• Audit trails may contain personal and other sensitive information.
• The data may give away information regarding the application's code and logic.
• Consider whether parts of the data may need to be excluded, masked or encrypted.
• The privileges to read audit trails should be restricted and reviewed periodically.
• All access to the audit trail must be recorded and monitored by a separate manager.
• Audit trail data must not be destroyed before the duration of its required data retention period, and not kept beyond this time.

Remember that in some jurisdictions, capture of any personal data or monitoring of employees may need particular approval and safeguards, and some data may not be allowed to be stored at all. Happy verification!

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.

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.

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.

There's quite a lot of "noise" about Web 2.0 application security, with countless news stories and whitepapers.

But I'd like to share three resources I keep coming back to and find useful:

• Web 2.0 Security and Privacy, position paper, ENISA
• Rich Data: The Dark Side to Web 2.0 Applications, The Register
• Guide to Building Secure Web Applications and Web Services, OWASP

And if you are looking for more of the nitty-gritty:

• Security Risks of Web 2.0, presentation, David Rook

Keep them to hand.

Last night, I spoke at OWASP Ireland's meeting in Dublin about the previously discussed Software (Security) Assurance Maturity Model (SAMM).

My presentation defined what software assurance, and in particular software security assurance, are, and why they are needed for complex software quality aspects. I also discussed what a maturity model is and how SAMM fits in with other business, project management, IT and software development maturity models. Moving onto SAMM, we reviewed the structure and how it may be used in software development teams and businesses to measure the current capability, act as a benchmark and help in building out a software security assurance programme.

There's been some discussion about applying SAMM on the SAMM mailing list, but it was good to chat with other people about their experiences and ideas to help organisations build better (more secure) software. The evening continued with an interesting talk on Niall Jordan on "Evading SQL Injection Detection Through Encoding", and then off to the nearest (almost adjacent) pub for further lively discussion and debate.

Oh, and a reminder... the Ireland chapter have organised OWASP Ireland AppSec 2009 Conference on 10 September 2009. With two tracks of application security related presentations from excellent speakers, I think it's going to be well worth attending.