Next week Dinis Cruz and I will be running an AppSensor workshop at Security B-Sides London 2013.

We will be demonstrating and helping attendees of the workshop specify, define and implement application-specific attack detection and real-time response. Our agenda is:

• OWASP AppSensor concept
• Attack detection exercise
• Real world implementation
• Alternative deployment models

We'll be using paper-based materials and real code demonstrations (in .Net, Java and PHP), so just bring your brains along. The workshop is being run from 14:00 to 15:30 hrs on Wednesday April 24th 2013 and can be booked on arrival at the event. It is available on a first come, first served basis. Security B-Sides London is a community-driven free event but requires registration, but due to overwhelming demand there is a waiting list.

We hope to see you there.

There was a high attendance at OWASP NL's chapter meeting at Radboud Universiteit Nijmegen.

Jim Manico was unable to present due to illness but Georgia Weidman, who was speaking at Blackhat Europe 2013, stepped in to present the Smartphone Pentesting Framework (SPF). SPF is the result of a DARPA Cyber Fast Track project, and provides tools and a methodology for penetration testers and security teams to gather information, assess and exploit smart phone devices in the workplace.

We were well looked after at the event. The attendees asked very relevant questions, and I hope my animated presentation showing how to play the Cornucopia card game explained the rules adequately. Thanks to Martin for driving us from Amsterdam to Nijmegen and back.

The presentations are available on the OWASP website.

I will be travelling to Nijmegen on Wednesday 13th March having been invited to speak at the OWASP Netherlands local chapter.

At the meeting in the Radboud Universiteit Nijmegen, I will present two brand new talks.

• "Record It!" — Do you know security event information should be recorded by an application? The presentation will outline which event properties are useful, what should be avoided and how logging can be implemented. In this short presentation, the benefits of good application logging will also be described. The content is drawn from the OWASP (Application Security) Logging Cheat Sheet
• "OWASP Cornucopia" — Microsoft's Escalation of Privilege (EoP) threat modelling card game has been refreshed into a new version more suitable for common web applications, and aligned with OWASP advice and guides. The PCI DSS referenced OWASP Cornucopia - Ecommerce Web Application Edition will be presented and used to demonstrate how it can help developers identify security requirements from the OWASP Secure Coding Practices - Quick Reference Guide.

OWASP board member Jim Manico is also presenting on the subject of "Access Control Design Best Practices". Jim is a great speaker and I am looking forward to this.

The venue is the Beta-faculty, Huygensgebouw, at Heyendaalseweg 135, Nijmegen, Parkeergarage P11. Registration and pizza will occur from 18:30 hrs until 19:15 hrs when my first talk commences. The presentations will end at 21:00 hrs followed by a period for further networking. Registration is free but necessary.

In Scotland and northern England, a "waff" is a gust or puff of air, or a passing glimpse. It is also a verb meaning to flutter or cause to flutter. In this post I want to avoid hot air, waffle and waggish comments to highlight guidance on the deployment and use of web application firewalls (WAFs).

WAFs can be controversial in that they can be a blunt instrument to add some protection to web applications, may not be well understood, are often not configured well, can be expensive to acquire, require an ongoing resource commitment, may cause problems with valid business functionality, could lead to the delegation of responsibility for application security primarily to operations, and if not integrated with other software assurance activities, can lead to the mistaken assumption that applications are secure. These issues need to be considered, but WAFs are a valid tool to have in your arsenal of defences.

Some more recent, and older long-standing, viewpoints and uses are described in the sources listed in alphabetical order below:

• Defending Against Denial of Service Attacks
  Securosis, November 2012
  The applicability of WAFs as a measure to contribute to the defence of applications against denial of service attacks
• Effectiveness of Web Application Firewalls
  Larry Suto, November 2011
  An evaluation of some commercial and open source web application firewalls
• ModSecurity Blog
  Trustwave
  Interesting articles on techniques that can be implemented using a WAF such as this, this and this
• Pragmatic WAF Management: Giving Web Apps a Fighting Chance
  Securosis, September 2012
  Issues, WAF management process, policy management, application lifecycle integration and protecting WAFs
• Protocol-Level Evasion of Web Application Firewalls
  Ivan Ristic, July 2012
  Discussion of the challenges of implementing WAFs and the types of evasion issues seen in production WAFs
• Use of Web Application Firewalls
  OWASP Germany local chapter, September 2008
  Characteristics, benefits, risks, selection criteria and best practices
• Web Application Firewall Evaluation Criteria
  WASC, January 2006
  A solid resource due to be updated in conjunction with OWASP

If you have, or are thinking of using WAFs, do read all of the above and subsequent discussions about some of those papers, as well as listening to suppliers/vendors. Then make up your own mind.

Last month I discussed application logging from an implementation viewpoint. Rafal Los (Wh1t3Rabbit) has published a helpful series of posts on his Following the White Rabbit blog regarding the drivers, motivation and strategic considerations when undertaking application logging.

The four posts are:

• Logging: Opening Pandora's Box - Part 1 (Anxiety)
• Logging: Opening Pandora's Box - Part 2 (Elation)
• Logging: Opening Pandora's Box - Part 3 (Paralysis)
• Logging: Opening Pandora's Box - Part 4 (Awareness)

My own implementation notes are written up in the OWASP Application [Security] Logging Cheat Sheet.

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.

On Wednesday evening I attended another meeting of the London Web Performance Group at the Lamb Tavern in Leadenhall Market.

The subject was Application Performance Management (APM) across the Software Development Life Cycle (SDLC). Martin Pinner described a history of application performance & service availability measurement and management, and how it includes end user experience monitoring, transaction profiling, application discovery & instrumenting, deep-level component monitoring and analytics. He explained that APM needs to be addressed through the SDLC — during development, in test and under operation — across all architectural tiers, and across development, staging/UAT and production environments.

At one point he surveyed the audience of about what technologies they were working with for web, application and database servers:

• Apache HTTPD was most in use, far ahead of IIS and anything else
• PHP and Java were roughly equally used, trailed by .Net and then others like Node.js and C++
• MySQL was most in use, followed by MS SQL Server, with a small number of people using everything else (Oracle, DB2, CouchDB, MongoDB, Hadoop systems, etc)

The presentation included pointers to many useful free and commercial products for different APM requirements, and rather than trying to repeat that, you will be able to download the slides once have been published (I will update this post).

A friendly group, and much for me to learn about in this area.

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.