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?

Last week, the European Network and Information Security Agency (ENISA) announced the publication of two guidance documents relating to Article 13a of the new telecommunications legislation (Directive 2009/140/EC) regarding security incidents and security controls.

I don't often quote legislation here, but I thought it was relatively short and provides the intent behind ENISA's guidance. ENISA has published two documents.

Technical Guideline on Incident Reporting provides guidance on the annual summary of significant issues and the notification of cross-border incidents. While most (all?) readers of this blog won't necessarily work in the telecommunications sector, I think the document is useful more widely for two aspects. It demonstrates the type of reporting which could be required if breach notification becomes a requirement for other sector or types of data (e.g. personal data)in the future. Also, the Section 5 on impact parameters and thresholds provides some insight into the continental and national viewpoint on the effects of security incidents.

The second document Technical Guideline on Minimum Security Measures defines the security controls national regulators need to consider when evaluating public communications networks. These are relatively high-level and are grouped into governance/risk management, human resources security, security of systems and facilities, operations management, incident management, business continuity management, and monitoring, auditing and testing. So a clear mapping to ISO27001/2/5 for information security and risk management, and BS 25999 for business continuity.

OWASP has announced a new addition to the immensely helpful cheat sheet series.

This first version of the HTML Security Cheat Sheet includes guidance on:

• Cross Origin Resource Sharing
• Local Storage (a.k.a. Offline Storage, Web Storage)
• WebDatabase
• Web Workers
• WebSockets
• Geolocation
• Use the sandbox attribute of an iframe for untrusted content
• Web Messaging
• XHR and DOM abuses
• HTML5 Widgets
• Progressive Enhancements and Graceful Degradation Risks

If you have anything to add, or suggest, please contact the people involved — Mark Roxbury, Krzysztof Kotowicz, Will Stranathan and Shreeraj Shah are the authors and primary editors.

For something in more depth, go to html5security and the related html5sec for an encyclopaedic reference source.

There is another more general presentation about using HTML5 WebSockets at London Web on Thursday evening this week (20th October), but be quick to register as there are already 175 people attending, and currently only 4 spaces left.

Undertaking training for developers and documenting secure coding guidelines are two of the earliest activities that should be undertaken in software security initiatives.

It is good to see Mozilla has published its WebAppSec Secure Coding Guidelines.

These show that secure coding guidelines neither need to be long nor overly complex. And yes they have to be tailored to your own development practices and risks. Read, re-use and reinvent.

Following a successful training course yesterday with great group of delegates, today I attended the OWASP AppSensor Project working group at AppSec USA 2011.

The AppSensor Summit was held to review the project's recent developments and activities, and to gather ideas from existing and new contributors to create a future roadmap. It was good to meet at long last John Melton, AppSensor's lead programmer, and catch up with Michael Coates and Ryan Barnett.

The summit also attracted a diverse range of developers, architects, users and security vendors. There were probably about 10-12 people attending all day, with a few more popping in and out as their timetables and other commitments allowed. The discussions defined the contents for a new book, an AppSensor development life cycle, an integration plan and a new concept to modularise the analysis engine to simplify integration with application software. The idea of creating a set of example usage profiles was also suggested. I think my name is down to help mainly with a new version of the AppSensor book, but I hope I can contribute with some of the interface definitions for interactions with the analysis engine, and possible signalling/exporting functionality.

The meeting notes are available, so if you have any comments or suggestions, please add them there, or discuss them via the project's mailing list.

The talks at the conference begin tomorrow.

In 2005, the US Federal Financial Institutions Examination Council (FFIEC) published Authentication in an Internet Banking Environment building on their earlier work on electronic banking. A supplement to the 2005 guidance has now been published.

The 2005 guidance recommended periodic risk assessments so that control mechanisms can be adjusted to respond to changing internal and external threats. The guidance stated that authentication techniques should be appropriate to the risks associated with the product or service, but that single-factor authentication is inadequate. It also recommended building customer awareness, and minimum supervisory expectations for authentication controls relating to high-risk online transactions involving customer information and the movement of funds to other parties.

On 28th June 2011, the FFIEC announced its Supplemental Guidance on Internet Banking Authentication to reinforce the guidance's risk management framework and update the expectations for authentication, layered security and other controls in an increasingly hostile environment.

The supplementary guidance reiterates the need for risk assessments and authentication for higher-risk transactions. It also recommends a layered security approach "since virtually every authentication technique can be compromised". Its recommendations for layered security controls include fraud detection & monitoring, dual device authentication, out-of-band verification, positive pay & debit blocks, transactional limits, activity limits, geo-location IP address reputation monitoring, policies & processes for handling compromised devices and malicious users, monitoring of account maintenance activities and customer education.

So, useful information, and not just for internet banking. The guidance is a good reference source for anyone considering authentication controls for access to more sensitive information.

Thank you to Alexis Fitzgerald for bringing this document to my attention.

The Information Commissioner's Office (ICO) has now published its initial guidance on how cookies and similar technologies for storing information on user's equipment. This becomes a legal requirement from 26th May 2011, following an amendment to the EU Privacy and Electronic Communications Directive.

I had discussed the change last month, but now the guidance has been published. It does appear to be a reasonable, practical, approach but is still work-in-progress and will be subject to change. In general, it requires UK organisations to obtain informed consent from visitors to their UK web sites in order to store and retrieve information on users' computers (including mobile devices).

The ICO advises organisations to take three steps:

• Check what type of cookies and similar technologies are implemented and how they are used.
• Assess how intrusive the use of cookies is.
• Decide what solution to obtain consent will be best in the particular circumstances.

Generally both notice to the user and consent will be required. However, two important exclusions exist for technical storage of, or access to information:

• for the sole purpose of carrying out the transmission of a communication over an electronic communications network; or
• where such storage or access is strictly necessary for the provision of an information society service requested by the subscriber or user.

This is why temporary state management session identifiers (IDs) used only for the purpose of the provision of a service requested by the user (e.g. looking at an area of a web site they have chosen to access, to log in to a member-only area, to use a shopping basket), are probably excluded from the requirement for consent. But organisations need to check what information is being collected & stored using cookies, etc, when it is being collected, and how it is being used. If session data (as cookies, etc) is transient and only used for the purpose of navigating the site, I would argue it is strictly necessary.

The guidance reminds organisations "strictly necessary" means it must be limited to a small range of activities, and encourages organisations to test whether the activity was "explicitly requested" by the user in some way. Persistent cookies which last beyond the user's current session (e.g. remember me, site customisation) are very likely to require consent, and this is an area where further guidance would be welcome (e.g. session management without authentication).

The guidance includes information on how to obtain consent, and in particular discusses passing data to third parties and the use of third party cookies. If you must allow third party content, the onus is still on you to make sure your site, and all its content, complies with the new law. See also the previously mentioned IAB Europe Self Regulation Guidelines.

Remember, this is not just about cookies — all similar technologies for storing information on the user's device which can then be retrieved are covered by the new requirements. So that will include:

• HTTP cookies
• Local Shared Objects (LSO) i.e. Flash cookies
• userData in DHTML Behaviors
• data in a Google Gears database
• data in an Indexed Database API
• local data storage in mobile applications
• HTML5 storage

...and anything similar that exists now or in the future.

It's a busy week for the ICO; this afternoon, it will publish the new Data Sharing Code of Practice (see my discussion about the consultation last year).

The Advertising Standards Authority (ASA) published updated guidance on 1st March when their digital remit extension came into force.

I have discussed the changes previously, but the ASA has now updated the Committee of Advertising Practice (CAP) Code, which has been published together with an FAQ about the changes. The remit covers advertising and other marketing messages on organisations' own websites, regardless of sector, type of businesses or size of organisation, and communications in other non-paid-for space under the organisation's control, such as social networking sites like Facebook and Twitter. This affects all UK registered companies, other organisations and sole traders — not only those using .uk domains. The FAQ contains further information on issues like user generated content (UGC) and exclusions.

Therefore, there is a need for an understanding how marketing messages are generated, and which channels & destinations are used. Unlike other media, online messages can be difficult to retract, alter and retire once they have been released.

For those already familiar with the CAP Code, there is a marked up version showing the new alterations.

The series of pocket guides by the US Department of Homeland Security National Cyber Security Division's Software Assurance (SwA) community has been extended by the addition of three updated documents.

Secure Coding (v1.1) and Software Assurance in Education, Training and Certification (v2.1) and Architecture and Design Considerations for Secure Software (v1.3) have been added to the range which now includes:

• SwA in Acquisition and Outsourcing
  • Software Assurance in Acquisition and Contract Language
  • Software Supply Chain Risk Management and Due Diligence
• SwA in Development
  • Key Practices for Mitigating the Most Egregious Exploitable Software Weaknesses
  • Software Security Testing
  • Requirements and Analysis for Secure Software
  • Architecture and Design Considerations for Secure Software
  • Secure Coding
• SwA Life Cycle
  • Software Assurance in Education, Training & Certification

I must admit I had to check the precise meaning of "egregious" (outstandingly bad, flagrant; or distinguished, eminent). There are almost a dozen more guides in the pipeline. These are indespensable references, and free to download. If you have comments or suggestions, please provide feedback to the SwA forum.

Just a brief update to my post about PCI DSS v2.0 on Friday.

I should have mentioned the PCI SSC has also published a guide explaining the intent of each requirement.