A draft of the next edition of the OWASP Top 10 is available for review and comment.

OWASP Top 10 - 2013 Release Candidate includes some changes to the current 2010 edition:

• A1 Injection
• A2 Broken Authentication and Session Management (was formerly A3)
• A3 Cross-Site Scripting (XSS) (was formerly A2)
• A4 Insecure Direct Object References
• A5 Security Misconfiguration (was formerly A6)
• A6 Sensitive Data Exposure (merged from former A7 Insecure Cryptographic Storage and former A9 Insufficient Transport Layer Protection)
• A7 Missing Function Level Access Control (renamed/broadened from former A8 Failure to Restrict URL Access)
• A8 Cross-Site Request Forgery (CSRF) (was formerly A5)
• A9 Using Known Vulnerable Components (new but was part of former A6 – Security Misconfiguration)
• A10 Unvalidated Redirects and Forwards

OWASP plans to issue the final public release of the OWASP Top 10 - 2013 in April or May after a public comment period ending 30th March 2013. The alternative methods for submitting comments are described on the first page of the draft document. There are discussions already on the OWASP Top Ten Project's mailing list.

Twice this week I have referred people to a unique centralised resource of information topics about programming in Java.

John Melton spent a year of his life (no, actually more like a few hours a week for 52 weeks), writing blog posts in his series Year of Security for Java (introduction, conclusion and listing). I have worked with John on aspects of the OWASP AppSensor project, and had the pleasure to meet him in person during AppSec USA 2011 in Minneapolis.

If your company develops in Java, you should reference these in your intranet or development portal — John has created a PDF comprising all the Java security posts.

Applications that accept payments and are installed on consumer mobile devices, not used exclusively used for a single payment application, such as smart phones, tablets and PDAs have been excluded from the PCI SSC's validation programme Payment Application Data Security Standard (PA-DSS). These types of mobile payment acceptance applications are known as Category 3 - payment applications operating on any consumer electronic handheld device that is not solely dedicated to payment acceptance for transaction processing.

Mobile payment Acceptance FAQs, published in June 2011, recommended that Category 3 applications intended for use in the cardholder data environment are developed using PA-DSS as a baseline for protection of payment card data and in support of PCI DSS compliance, until the development of appropriate advice, guidance, and/or standards to ensure that such applications are capable of supporting a merchant's PCI DSS compliance. On Friday the PCI SSC published new guidance for developers.

PCI Mobile Payment Acceptance Security Guidelines v1.0 September 2012, describes firstly 3 objectives and guidance for application payment transactions:

1. Prevent account data from being intercepted when entered into a mobile device
2. Prevent account data from compromise while processed or stored within the mobile device
3. Prevent account data from interception upon transmission out of the mobile device

Secondly, guidance on 15 risks and controls in the supporting environment (mobile platform and associated applications):

1. Prevent unauthorized logical-device access
2. Create server-side controls and report unauthorized access
3. Prevent escalation of privileges
4. Create the ability to remotely disable payment application
5. Detect theft or loss
6. Harden supporting systems
7. Prefer online transactions
8. Conform to secure coding, engineering, and testing
9. Protect against known vulnerabilities
10. Protect the mobile device from unauthorised applications
11. Protect the mobile device from malware
12. Protect the mobile device from unauthorized attachments
13. Create instructional materials for implementation and use
14. Support secure merchant receipts
15. Provide an indication of a secure state

Recognising that no one party has sole responsibility for security of Category 3 applications, a table in Appendix B of the guidance suggests responsibilities for the 18 practices. The responsibilities are assigned to device manufacturers (e.g. Apple, Huawei, Motorola, Nokia, Samsung), operating system developers (e.g. Apple, Google, Microsoft), application developers (e.g. you?), and merchants as end-users or payment acceptance service providers.

The guidance also provides a list of ten additional sources of information to support the guidance. Further advice and standards on mobile payments are expected from the PCISSC in 2013.

In the next post, I will discuss some related updated guidance from Visa.

Application logging, and in particular, application security logging may not sound the most exciting of subjects, but it really can be a very useful tool that helps during development and operation.

If you remember, I have written about application security logging a number of times before. I have now consolidated all that information, and more, into a new document for the OWASP cheat sheet series about application logging that explains the benefits and details:

• Design, implementation and testing
  • Event data sources
  • Where to record event data
  • Which events to log
  • Event attributes
  • Data to exclude
  • Customisable logging
  • Event collection
  • Testing
• Deployment and operation
  • Release
  • Operation
  • Protection
  • Monitoring of events
  • Disposal of logs

The cheat sheet guide is a wiki page, so if you have any contributions, please add them. If you know any other good reference articles, I would like to hear about them.

This week I will be at Security B-Sides London, which my company is co-sponsoring. If you are there too on Wednesday, say hello.

A new report from Ponemon Institute describes the results from a survey of developers and information security employees in the United States.

2012 Application Security Gap Study: A Survey of IT Security & Developers provides useful data on the viewpoints from these important groups, and of course isn't necessarily encouraging reading. A very small proportion of the IT security budget is spent on application security, most do not have a standardised way of building security into new applications and security is most often addressed in later stages of the software development life cycle (SDLC). See the overview on the ISACA website.

The information could be used to help compare secure software development life cycle (S-SDLC) maturity, but the input of other groups such as product owners, architects, testers, QA, audit and operations would also provide useful data, and hopefully senior management might be able to provide an oversight of the all the processes and the organisation's needs and risk profile.

The regulator for premium rate services (PRS) in the UK, PhonepayPlus (PpP), has issued new consolidated guidance for when premium rate is used as the mechanism for application-based payments.

Application-Based Payments provides guidance relating to the obligations in the PhonepayPlus Code of Practice (as a PDF). The guidance is not binding and does not form part of the Code of Practice, but instead provides information on how compliance with the Code can be achieved.

The guidance is concerned with outcomes from the Code:

• Transparency and Pricing - [2.2] "That consumers of premium rate services are fully and clearly informed of all information likely to influence the decision to purchase, including the cost, before any purchase is made."
• Password Protection and Security - [2.3] "That consumers of premium rate services are treated fairly and equitably." and [2.4] "That premium rate services do not cause the unreasonable invasion of consumers' privacy."
• Complaint Handling - [2.6] "That consumers are able to have complaints resolved quickly and easily by the Level 2 provider responsible for the service and that any redress is provided quickly and easily."
• Method of Exit - [2.3] That consumers of premium rate services are treated fairly and equitably.

The guidance suggests how pricing and other key information should be presented before downloading an application & for purchases within an application, information where a service can be accessed on more than one device or channel, fermium services, how to provide a method of exit, consumer consent to charging, password protection and practices for handling complaints. It also discusses misleading promotions and virtual currencies, and most importantly that mobile-based payment service providers should ensure their services are compatible with every technical platform and/or device on which they are promoted.

One issue in particular is worth highlighting. Paragraph 7.2 of the guidance says that if malicious software (malware) is found, then a tribunal under the Code may not be likely to consider any proof of consent for charging to be robust enough.

If you are developing applications that rely on premium rate charging mechanisms, read the guidance with care. PpP has sharp teeth. In a recent case unrelated to this guidance, two companies were each fined £100,000 for placing adverts for premium rate services on typo-squatting hostname websites which looked like other popular websites.

Even if your applications do not fall within the controlled PRS covered by PpP, there is still a lot of useful good practice information for other consumer services in the Code and related guidance documents.

Transport layer security (TLS), also referred to by its predecessor's name secure sockets layer (SSL), cannot be implemented easily "out the box" in a robust manner. A new guide was published last week.

SSL/TLS Deployment Best Practices, from Qualys SSL Labs, provides clear concise instructions to obtain a correctly configured site or web application that uses transport layer security. This may "sacrifice completeness", but in seven largish-print pages describes all the important issues to get right. It is not a guide for beginners though — it is aimed at systems administrators and programmers who already understand the basic concepts and terminology.

References are provided for those who want to learn more, or want to look at more advanced topics. It will be a very useful document to refer to in requirements documents and configuration standards.

Weaknesses in software security? Long-term security advocate and practitioner Eoin Keary has written an article about the weaknesses in our approach to application security.

Eoin describes the problems with past and current approaches, and has come to believe organisations should use a structured and repeatable method for addressing security in the software development lifecycle (SDLC) encompassing:

• Secure design
• Developer training
• Common module/framework design and implementation
• Code review
• Integrated functional/security/anti-functional testing.

He also proposes that manual efforts are used in the SDLC, and in verification activities for runtime scanning, rather than in undertaking manual penetration testing. Eoin also highlights the need for ongoing, continuous monitoring, feedback and analysis in what he terms Enterprise Security Intelligence (ESI) — maybe that is Eoin's Secret Ingredient?

Read, learn, respond and implement what will work with your own organisation's risks and culture.

BITS, the technology policy division of the Financial Services Roundtable, an industry body representing the US financial services industry, has published a Software Assurance Framework.

The 50-page guidance document describes an outline of recommended components of what they describe as a "mature, strategic program for secure software development" for software used within the US financial services industry. The framework was a collaborative effort that involved several financial services companies in conjunction with Microsoft, and it references the Microsoft-sponsored Forrester Consulting research which indicated that the use of a prescriptive secure software development lifecycle achieves the greatest return on investment (see also the similar Aberdeen Group research).

This is not a hands-on "how to" for software architects, developers, testers or operational staff, but instead describes a framework of activities that contribute to the specification, production, deployment and operation of secure software throughout the development lifecycle. In that respect, the comparable documents to refer to are BSIMM, MS SDL and Open SAMM, and indeed these are referenced in the BITS framework. Some organisations also build their software assurance efforts around the Capability Maturity Model Integration (CMMI).

So what does BITS consider to be the key components of a software assurance framework? Eight are defined and explained:

• Education & Training
• Security Software Assurance Development Standard
• Threat Modeling
• Coding Practices
• Security Testing
• Pre-Implementation Practices
• Software Assurance Documentation Archive Best Practices
• Post-Implementation Phase Controls

There is of course considerable overlap with the references mentioned above which describe actual practices in place, how Microsoft undertakes secure SDLC and a maturity model for software assurance respectively. I have tried to indicate below how the BITS key components broadly map to Open SAMM:

So quite a lot of overlap. There is an existing mapping of Open SAMM to BSIMM activities which could be used to extend the above mapping onto BSIMM. As the BITS framework has been developed in conjunction with Microsoft, I expected to see a much closer relationship with MS SDL, and yes this is the case.

There isn't a direct one-to-one mapping here, but I hope the above help navigate the document if you use Open SAMM or MS SDL and want to delve into another source of ideas for secure software development lifecycles. Although the BITS framework might be somewhat heavyweight for some non-financial services organisations, especially on the documentation front, it is perhaps an easier starting point than the closely related MS SDL, to begin working on building security into development (and acquisition) processes. Take what suits, makes sense and fits your own organisation's type of applications and tolerance of risk.

Most of the content will be relevant, and since it is spelt out in reasonable detail, this could be very helpful. Some notable nuggets deeper in the document are:

• pp2-3 "teaching techniques of good design and their subsequent use can result in software secure not just against known attacks, but also against unknown attacks and attacks yet to come"
• p20 "Security defects are "defects", not just "security defects"
• p35 Security vulnerabilities identified in applications in production .... should not be treated as software defects, but as one part of the company's incident response process".

And on page 36 in the section relating to emerging threats in the post-implementation phase controls, there is a comment relating to the OWASP Top Ten and CWE/SANS Top 25 which seems out of kilter with the rest of the framework's text. The document states these as being valuable sources of information but "both represent an earlier generation of software security intelligence". I am not sure each of those sources set out to define the only threats to consider, and are instead a way of introducing the concepts to less-knowledgeable groups and encourage reading of the much deeper related materials. But perhaps this is more of a comment about PCIDDSS which specifically mentions these two sources. I wonder.

As you can see, worth the read.

Further to my previous notes about HTML 5 security, a superb reference document was published earlier this month.

Michael Schmidt (Compass Security) wrote his master's thesis about HTML5 security in May 2011 and has published an extract for everyone to access.

HTML5 Web Security describes issues, vulnerabilities, threat & attack scenarios and countermeasures across 80 pages including numerous well thought-out diagrams, and is backed up with detailed references and an appendix full of attack details.

The main sections are:

• 2.2 Cross-origin resource sharing
• 2.3 Web storage
• 2.4 Offline web application
• 2.5 Web messaging
• 2.6 Custom scheme and content handlers
• 2.7 Web sockets API
• 2.8 Geolocation API
• 2.9 Implicit relevant features of HTML5
  Web workers, new elements, attributes and CSS, Iframe sandboxing and server-sent events

If you are already developing HTML, or planning to, read this document as soon as possible and update your requirements documents, specifications, design documents, coding standards, and test plans to incorporate the knowledge.

The document would be worth buying if it were a book, but it has generously been made available publicly. Yes, I am still reading the document, and so far have only one very minor complaint — it would be good to have a content list. Maybe in version 1.1?