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?

After an exciting trip to the United States, the very encouraging interest in OWASP AppSensor, and the productive AppSensor Summit, I'm back in the UK and catching up on a few things.

While I was away, a podcast interview has been published in advance of RSA Conference Europe 2011 where I am speaking about application-specific defences. In the podcast I explained the concepts but during my presentation will discuss specifications, requirements for procurement as well as building application-specific defences into your own development practices.

If you want to find out more, please come along to the Windsor Suite at RSA Conference Europe on 13th October at 13:00 hrs.

The UK's Centre for the Protection of National Infrastructure (CPNI) has updated its guidance on protecting business applications with the publication this month of a new document on developing and implementing secure web applications.

Development and Implementation of Secure Web Applications is a well-written and digestible 81-page A4 document arranged in seven main sections:

• Introduction to web application security
• General aspects of web application security
• Access handling (authentication, session management and access control)
• Injection flaws
• Application users and security
• Thick client security
• Preparing the infrastructure

It appears to replace the good, but somewhat dated document "Briefing 10/2006 - Secure web Applications - Development, Installation and Security Testing" created by their predecessor National Infrastructure Security Co-ordination Centre (NISCC), and issued in April 2006. The new document is more compact and focused, and I think I prefer it. Yes of course it is more up-to-date, and while it would be possible to argue why some things are included and not others, these others things tend to be explained further in the references. It's clear there is considerable overlap with information from OWASP and the Microsoft SDL, but I'm sure the reverse is true to an extent too.

It is very encouraging CPNI have taken the time to produce an updated document, but that probably reflects the types of risks facing their audience. I am especially pleased to see the section on infrastructure, since application security cannot be an island on its own. I would say the guidance is probably on the medium-to-heavy weight side of advice, but that is probably appropriate for critical national infrastructure, and the document does discuss threat modelling initially. It might seem overwhelming to some organisations new to the subject, and that might need some help on what to do first.

I think the document could perhaps do with more cross-referencing to additional information resources elsewhere. Yes, documents can always be improved, and I am sure we will find niggles and faults with use, but threats evolve and so does our knowledge.

Common Event Expression (CEE) Architecture Specification version 0.6 has been published for comment.

As noted noted in June, CEE defines the structure and components comprising the community-developed event log standard that intends to be industry accepted and practical. The following v0.6 documents were released on 26th August 2011:

• CEE Architecture Specification v0.6
• CEE Profiles Specification
• CEE Common Log Syntax (CLS)
  • CLS Encoding: JSON
  • CLS Encoding: XML

I will be having a read through these to see how they can be applied to application logging in some upcoming projects.

Feedback is sought on these documents using the CEE Email Discussion List or by email to cee@mitre.org.

Whilst on the theme of the privacy protection, this afternoon I attended the launch of the Information Commissioner's Office (ICO) Data Sharing Code of Practice, at the House of Commons.

If you remember there was a public consultation at the end of 2010, and the final document is now complete. I contributed to my company's written response, as well as to a response by OWASP on the security aspects of data sharing.

The event was sponsored by John Leech MP, Alun Michael MP and Dominic Raab MP, and the new code of practice was introduced eloquently by the Information Commissioner, Christopher Graham. He made the important point that the ICO is about enabling safe use of personal data, and that blocking the use of personal data is not its role. In fact, consumers and citizens can benefit from transfers and sharing of their data — it just has to be done legally. He described the guidance as "making sense on paper, and in the real world".

Note this is statutory guidance which has therefore been approved by the Secretary of State and laid before Parliament. It does not impose new legal obligations nor is an authoritative statement of the law. But both courts and the Information Commissioner must take into account the contents of the code when determining any question arising from proceedings, or functions being performed by the ICO under the Data Protection Act (DPA).

It applies to all sectors — public and private — although there is some sector-specific guidance included. Importantly it applies to both routine systematic data sharing as well as one-off data sharing tasks. The guidance notes data protection principles also apply to the sharing of information within an organisation, such as between divisions, departments and teams. Examples and case studies used in the document include "a retailer providing customer details to a payment processing company", "a mobile phone company intends to share details of customer accounts with a credit reference agency" and "a marketing company wants to share data with a fulfilment company so it can send out free samples". Practical, yes.

I was interested to read the new document to see what changes had been made in the period since the consultation. The draft document was quite good, but the final guidance is an order of magnitude better. It looks as though considerable re-writing, greater explanation, and addition of a glossary and quick-reference checklist have improved its content and usability. Additionally, I am pleased to see many more practical private-sector examples have been included throughout the main body, and in the case studies in Annex 3.

In terms of information security, the primary aspects are detailed in Section 7, which lists good practice to take in respect of information shared with other organisations, highlights the need for building a security-aware culture, identifies the need to take reasonable steps to ensure the receiving organisation understands the nature and sensitivity of the information, the need to consider all modes of transmission, and provides two short lists of physical and technical security measures to be considered. One which stands out in particular is:

Well, that's quite specific! And, good advice.

So, data controllers take note. If you are involved with specifying or designing online (or other) business systems, read the whole document — it really will help. The code of practice does not itself have the force of law (the DPA does), but it describes good practice, and the ICO can only take enforcement over breaches of the DPA. But as the guidance says doing nothing, risks breaking the law.

The whole structure of the document is:

1. Information Commissioner's Foreward
2. About this code
3. What do we mean by "data sharing"?
4. Data sharing and the law
5. Deciding to share personal data
6. Fairness and transparency
7. Security
8. Governance
9. Individual's rights
10. Things to avoid
11. The ICO's powers and penalties
12. Notification
13. Freedom of Information
14. Data sharing agreements
15. Data sharing checklists

The annexes are:

1. The Data Protection principles
2. Glossary
3. Case studies

Coincidentally today a potential £200,000 penalty was imposed by the ICO for a recent web site personal data loss, and the full amount was only avoided because the sole trader had already ceased trading.

The code of practice has not yet been published on the ICO web site. I will check again tomorrow morning.

Update 11th May 2011: The ICO has now announced and published the Data Sharing Code of Practice and checklists on their web site.

I seem to have arranged quite a few upcoming presentations and training sessions relating to the concepts in OWASP AppSensor during May and June, across Europe (and further afield).

Following my previous speaking enagements at events in Newcastle-upon-Tyne and London, and the release of an implementation guide at AppSec DC last year, I was approached to talk about this subject in one of the training slots at the OWASP Ireland Training Day in Dublin in March.

But coming up, I seem to have ended up doing a mini European tour. Here are the dates and what's being presented about AppSensor:

• 12th May, ISSA UK application security training day at National Codes and Cipher Centre, Bletchley Park, UK — a high-level overview of application defence with a focus on how this can contribute to a reduction in operational risk (free to ISSA members, registration required).
• 19th May, 2nd International Secure Systems Development Conference, London, UK — an introduction to OWASP AppSensor (chargeable).
• 25th May, OWASP Greece chapter Training Day, Athens, Greece — introduction and walk-through on how to identify and select attacker detection points (free to OWASP members, registration required). I will also be presenting Software Assurance Maturity Model at this event.
• 9th June, AppSec EU 2011, Dublin, Ireland — an update on the OWASP AppSensor project including how to build the concepts into your own software projects (chargeable, discount to OWASP members, registration required).
• 16th June, OWASP Belgium chapter meeting, Brussels, Belgium — a repeat of the AppSec EU presentation (free, registration required).

I am also providing a full day course "Application Attack Detection & Response — A Hands-on Planning Workshop", based on the concepts in the OWASP AppSensor Project, at AppSec USA in Minneapolis on 20th September 2011.

The training course is a practical hands-on day-long workshop where participants will learn how to define, select and specify application-layer intrusion detection and protection (IDP). The training course uses a problem-centered approach where participants are encouraged to use their own knowledge and experience to apply the techniques learned in example lab projects. Most of the day will be spent working in small teams creating strategies and implementation plans, which could subsequently be used in development. The course does not involve any coding and is language/ framework agnostic. Full printed handouts are provided together with materials for all the exercises, so participants can take these away and apply the ideas within their own organizations.

The course will be of direct use by anyone interested in building attack-aware applications or in constructing defensive measures directly into applications. The development lifecycle for application-specific intrusion detection and protection (IDP) spans analysis, planning, implementation and operation. This training course covers the first two of these — analysis and planning.

The processes and templates provided during the course may be of most use in larger development teams, but more advanced individual designers, architects & developers will gain knowledge which they can apply themselves directly in their own projects. The course is also a useful introduction to the attack-aware application concepts, and therefore may be of interest to those involved with specification, verification practices such as testing & audit, and operational processes such as deployment and incident handling. The examples used will be repeatedly linked back to business objectives throughout the day. The course outline is:

1. Course Introduction
2. Preliminary Requirements
3. Application Logging Practices
4. Standard Detection Points
5. Custom Detection Points
6. Model Creation
7. Model Optimization
8. Attack Analysis
9. Response Actions
10. Response Threshold Specification
11. Implementation Plan
12. Optional Course Assessment Test

Exercises will be undertaken in small teams of between 4 and 6 people, depending upon the number of participants on the course. Each exercise during the day will be the continuation of the previous one, so the teams build up a complete IDP plan for their example project.

Registration is now open. Please book early to ensure a place. Discounts are available for group bookings.

What will be your new year's resolution? I would like to suggest a work-related one should be "implementing proper application logging" for web products.

Construction sites and manufacturing facilities routinely publish safety statistics such as "hours since last lost time incident", "number of man hours worked without a reportable accident" and other performance metrics. How about "days since last vulnerability exploited" or "days since last vulnerability reported"?

Without good application logging, you do not know the real performance of your system, whether there have been attacks, what suspicious activity has been occurring. You also will not have much information to examine to determine the cause of previous problems, generate meaningful security metrics, or build feedback mechanisms to improve security.

Put it near the top of the "to do" list for 2011. And have a good, safe & secure night!

After arriving in Dublin last night, I walked to Trinity College this morning and had a little time for a coffee and to greet people I knew before we moved into the lecture theatre.

Following the welcome to OWASP Ireland 2010 by Eoin Keary, Fabio Cerullo & Rahim Jina of the OWASP Ireland Board, John Viega delivered a thought-provoking keynote speech on "Application Security in the Real World". John described real-world problems and approaches to application security need to prove their value. He described seven practices: awareness & training, assessments & audits, development & Q&A, vulnerability response, operational security, compliance and security metrics which, when applied appropriately can demonstrate a return on investment.

OWASP Board members Eoin Keary & Dinis Cruz provided an overview of OWASP's current status, its activities including many of its projects and of the global committees. They described how OWASP's mission "is to make application security VISIBLE for buyers and INVISIBLE for developers". Samy Kamkar was given a brief slot to describe how cross site scripting (XSS) can be used against user's routers to eventually gain the MAC address and ultimately a user's geolocation using Google data.

After a short break and opportunity to look at the sponsor booths, the conference split into two streams for the rest of the morning. Fred Donovan spoke on the topic of "Counter Intelligence as a Defense", describing how gathering information and taking approved action can help identify, assess and potentially neutralise threats to an organisation's ability to conduct business, and to enhance the protection of corporate assets and customer data. He also described sources of information including web application firewalls (WAFs), server logs, application logs, the media, list servers, MITRE, honeypots and from the source of the threat itself. some of the impediments and do's and dont's in this pro-active approach.

Ryan Berg gave a lively and fast-paced description on the "Path to a Secure Application". He described what isn't working, and the need to mitigate the damage that attackers can do, rather than assuming you can keep them outside your network, He provided numerous examples of how security can be built into to all stages of the software development process, but made the point that organisations should make efforts to improve their existing application development processes, rather than creating new ones.

Dan Cornell described how Android and iPhone smartphone applications are coded, deployed and, how and when the source code can be reverse engineered. He presented an example Android application and some tools to demonstrate how embedded URLs, file paths and host names can be extracted to help determine its workings. He recommended that, like other applications, smartphone applications should undergo threat modelling, care should be taken on what information is stored and where, and to be careful when consuming any third-party services, and ensure that enterprise web services are approved and deployed securely.

After lunch which was held in the beautiful Dining Hall of Trinity College Dublin, Professor Fred Piper (Royal Holloway College) presented the second keynote on "The changing face of cryptography". Prof Piper described that people do not need to attack algorithms when they can attack the implementation or cryptographic system instead. He provided an engaging and personable talk about algorithms, implementation weaknesses, real-life cryptography and the related political and social issues, clearly demonstrating his wide and deep knowledge.

Tyler Shields' presentation "Application Security Scoreboard in the Sky" described the results from Veracode's State of Software Security, which I have discussed before but is worth remembering as a good source of information when building business cases for secure development processes. The first volume had examined the differences between open source, commercial and out-sourced software. The second volume is due to be released in the next fortnight.

Rory Alsop & Rory McCune (co-chairs of OWASP Scotland) "The 'Real' Application Security Pentest." described why penetration test companies and purchasers of their services need to understand the requirements clearly and to make best use of the budget. They described that penetration testing is increasingly being used but there are inconsistencies in how it is undertaken and customers don't always receive what they want. The speakers described common myths and what buyers should do.

Vinay Bansal and Martin Nystrom jointly presented Cisco's experiences of "How to Defend Fragile Web Applications". Cisco know they are constant attack on their perimeter, but they have to concentrate their resources on defending DMZ & internal systems and minimising the damage from compromises. Cisco use architectural assessments, developer training, secure coding techniques, verification practices and more recently using web application firewalls (WAFs) in a reverse proxy mode using Apache httpd, ModSecurity and ModProxy. They described the problems and benefits of using WAFs in front of Cisco's tens of thousands of applications, and how they are trialling using the WAFs for virtual patching, where the applications cannot be modified.

The final keynote "Hackers and Hollywood: The Implications of the Popular Media Representation of Computer Hacking" was presented by Damian Gordon (School of Computing, Dublin Institute of Technology). Damian gave a light-hearted look at "Hackers and Hollywood: The Implications of the Popular Media Representation of Computer Hacking". He has researched whether or not movies accurately portray hackers and the implications of that portrayal, based on filtering 200 potential movies down to 50 clearly relating to computer hackers and not just cyberpunk, sci-fi or where hacking is only a peripheral activity. The conclusion? Movies are doing quite well but are missing out on some hacking features such as denial of service, phishing, organisation identuty theft and e-harassment of employees. Maybe next year?

Congratulations for a very successful and informative day to all the organisers, helpers and speakers. A little late, but off to the social event...

I have been meaning to write again about web application security logging, but luckily read a paper last week which provides excellent guidance.

How to Do Application Logging Right is the best guidance I have come across to date. Co-written by Anton Chuvakin and Gunnar Peterson for the IEEE Security & Privacy Journal, the paper describes the problems with typical logging systems, what events need logging, and for those, what to include and exclude. They have also provided some broader guidance on log management and protection.

Previously, the most notable application security logging guidance existed buried rather deeply in the documentation for OWASP's ESAPI Java edition, the OWASP Logging Project, and more general guidance in NIST's SP 800-92 Guide to Computer Security Log Management.

If you read those in conjunction with the new paper, and perhaps Chuvakin's and Peterson's own comments, you'll be well up to speed.

The content of the "module", "object" and "action" fields will be dependent upon the degree of granularity required and how much additional event information is collected as additional details (e.g. stack trace, request headers, response body). I believe a transaction ID should always be included so that all events for a single request/response can be more easily correlated—this has a request scope rather than the session scope of a username/id. If I might suggest some other additional items for "what to include", I would also consider:

• host address (e.g. host name and domain, or server IPv4 or IPv6 address) which is useful if clustering is being used, or to confirm logs are from live rather than staging systems
• service (e.g. name, port and protocol)
• full actual entry point URL (protocol, full domain, port, path and further parameters)
• canonicalised entry point URL
• HTTP method (for web applications)
• responses seen by the user and/or taken by the application (e.g. status code, custom text messages, session termination, administrator alerts)
• analytical confidence in the event detection (low, medium, high or a numeric value).

Full request headers and possibly the response body may be worth collecting for some events. But ensure these are sanitised for sensitive input such as passwords, session cookies or credit card numbers.

I would also tend to use a severity scale (0=emergency, 1=alert, ..., 7=debug) rather than the suggested "priority" field, for consistency with syslog protocol. But the paper's authors note that whatever scale is used, it will be different for each organisation due to their own priorities and views on risk.

You may also want to consider how the integrity of the logged information can be determined.

Whatever you log, bear in mind you probably want it to be relatively human-readable, but also done in a way you can share the information with other systems. For the moment, consider Common Event Format (CEF). But Common Event Expression (CEE) is an ongoing collaborative effort to develop an event interoperability format summarised in a presentation, and in more detail in a white paper. The CEE web site includes a description of alternative approaches for sharing data from event producers.

See also my previous web application logging related posts How Much Logging, Monitoring and Alerting?, Security Logging Requirements, Testing the Audit Trail, Don't Stop the Attack (Too Soon), and Application Log Management and Analysis.

Happy application logging!

Security and audit logging should be defined, implemented and tested for every web application. But what about log management and analysis?

This week Raffael Marty posted an updated item to his blog about a Maturity Scale for Log Management and Analysis. It is an excellent review.

Whilst much of this management and analysis is intended to be external to an application, we need to remember each application needs to record adequate information to feed into these analysis and reporting tools. And why do that? Read the bullet points under return on investment (ROI) at the end of the article. What else? Well perhaps also:

• feedback into the development lifecycle (to improve subsequent patches, versions and other projects)
• greater trust by users
• brand protection
• protection of information assets (not just preventing leaks, but ensuring accuracy and integrity).

Therefore, build adequate logging in from the start. Web server logs are not enough!