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.

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.

The UK Code of Non-broadcast Advertising, Sales Promotion and Direct Marketing (CAP Code) will include new rules in a month's time (February 4th 2013) relating to greater transparency and choice for consumers around Online Behavioural Advertising (OBA).

The Committee of Advertising Practice (CAP) published the Online Behavioural Advertising Regulatory Statement in November 2012 describes how notices must be provided to web users, in or around online display advertisements, that they are undertaking OBA, together with a mechanism to opt out. These are based upon the pan-European industry-wide agreed self-regulatory standards — European Advertising Standards Alliance (EASA) Best Practice Recommendation and the IAB Europe Self-Regulation Framework.

The rules are defined in a new Appendix 3 of the CAP Code, and will be enforced by the Advertising Standards Authority. The rules will be reviewed again later in 2013.

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.

Another recent paper from Securosis addresses defending against denial of service (DoS) attacks.

Defending Against Denial of Service Attacks examines the types of attacks prevalent currently, and methods to maintain availability and minimise the adverse economic effect. The paper begins by identifying the threats‐protection racketeers, hacktivists, cyber war, exfiltrators, competitors, and business success itself.

The types of attack are described and defences for networks and applications are described. For applications, building security into the software development life cycle, web application firewalls (WAFs), anti-DoS devices and service providers, content delivery networks (CDN) are described. The need for a multi-faceted approach to application DoS protection is recommended in the paper.

I think some applications will just be more problematic than others and avoiding security vulnerabilities, minimising the attack surface and building in application-specific attack detection and response will help here too.

The paper includes links to further insightful sources of information, and recommends that to be effective, the process for defending against denial of service attacks needs to include activities before, during and after an attack.

I am looking forward to the upcoming OWASP AppSec Research 2012 in Athens from 10th-13th July. The organising team have put on a great programme.

My main participation in the four days of activities will be:

• Delivering a one-day training course Application Attack Detection & Response — A Hands-on Planning Workshop which will train you how to plan the implementation of application-layer intrusion detection through a series of team-based exercises
• Presenting a talk entitled Tricolour Alphanumerical Spaghetti which will describe how weaknesses in applications can be classified, common practices and what you should really do
• Hosting a networking event on behalf of the OWASP Global Industry Committee to discuss and share information concerning good application security amongst business managers in a vendor-free environment

I hope you are attending both the training programme and three-track conference, so please flag me down and say hello. Registration is open, and there are conference discounts for OWASP, ISACA and ISC2 members, and also for students.

Last month Veracode, who publish the State of Software Security Report posted an infographic on their blog highlighting cyber security risks in publicly listed US companies.

Cybersecurity Risks in Public Companies Infographic draws together data from the Verizon Data Breach Investigations Report 2012, the regularly updated Web Hacking Incidents Database and Veracode's own reports.

Quite a useful pictorial if you want to provide a snapshot of some of the key issues.

Earlier this week I heard that my talk about vulnerability severity ratings has been accepted for OWASP AppSec Research 2012 in Athens in July. The title of the presentation is "Tricolour Alphanumerical Spaghetti" which I need to explain.

Do you know your "A, B, Cs" from your "1, 2, 3s"? Is "red" much worse than "orange", and why is "yellow" used instead of "green"? Just what is a "critical" vulnerability? Is "critical" the same as "very high"? How do PCI DSS "level 4 and 5" security scanning vulnerabilities relate to application weaknesses? Does a "tick" mean you passed? Are you using CWE and CVSS? Is a "medium" network vulnerability as dangerous as a "medium" application vulnerability? Can CWSS help? What is FIPS PUB 199? Does risk ranking equate to prioritisation? What is "one" vulnerability?

Are you drowning in a mess of unrelated classifications, terminology and abbreviations? If you are a security verifier and want to know more about ranking your findings more meaningfully, or receive test reports and want to better understand the results, or are just new to ranking weaknesses/vulnerabilities and want an overview, come along to this presentation. It will also explain why the unranked information-only ("grey" or "blue"?) findings might contain some of the best value information.

In the presentation, I will outline techniques commonly used, or referenced, to rank application security weaknesses including:

• Common Vulnerability Scoring System (CVSS)
• Common Weakness Scoring System (CWSS)
• Guide for Conducting Risk Assessments (NIST SP 800-30 Rev. 1 DRAFT)
• Microsoft's STRIDE and DREAD
• OWASP Risk Rating Methodology
• OWASP Top Ten
• PCI DSS Security Scanning Procedure vulnerability classification
• Software Engineering Institute (SEI) OCTAVE
• Standard for Security Categorization of Federal Information Systems (FIPS PUB 199)
• Custom methods (and tester's experience)

The relevance to application security, advantages and disadvantages of each will be compared. The relatively new Common Weakness Scoring System (CWSS), co-sponsored by the Software Assurance Program in the National Cyber Security Division (NCSD) of the US Department of Homeland Security (DHS), will be described in some detail. This will include an explanation of the Common Weakness Risk Analysis Framework (CWRAF).

The presentation will also examine how impact is calculated and discuss why the direct business impact may not be the only thing you need to worry about. In this part, the counting of weaknesses will be discussed and why all of this is important from a compliance perspective. Five contrasting issues (system information leakage, personal data exposure, cross-site scripting, SQL injection and a non-security PCI DSS compliance issue) will be used to calculate example rankings using the OWASP Risk Rating Methodology, CVSS and CWSS. The methods and results will be compared and contrasted for different types of applications (website, web service and mobile app) in different business contexts. Finally the presentation will provide a list of issues to check before you commission assessments to make sure the results are meaningful.

Conference and training registration is now open. AppSec Research 2012 is being held at the Department of Informatics and Telecommunications at the University of Athens. The nearest metro station is Evangelismos.

At the end of March, Verizon published their 2012 Data Breach Investigations Report. Again it is packed full of useful, well-presented, data.

The report shows that many breaches are the results of more than one threat action (malware, hacking, social, misuse, physical, error and environmental). However, hacking accounted for 81% (58% for larger organisations with over 1,000 employees) of breaches and 99% of data records (same for larger organisations), and as the chart above (Figure 22) shows remote access/desktop services was the most common hacking vector, followed by backdoor or control channel, and thirdly web applications.

Figures 32 and 33 provide some great data on the scale of records lost for different varieties of data (authentication credentials, bank data, classified, copyright, medical information, organisation data, payment card data, personal data, systems information, trade secrets). From these we can get a feel for the average size of a breach for each data type. Unsurprisingly the number of records lost per "trade secret" event is about 1. For personal data it is around 2 million.

The data on timespan of events by percent of breaches (Figure 40) continues to show the short time from initial attack to initial compromise and initial compromise to data exfiltration (both in minutes), the long average time to discovery (several weeks), and from then until containment/restoration (weeks).

There is perhaps too much emphasis on counts of records lost, but of course this is a "data breach" report. The report states that it makes "no claim that the findings of this report are representative of all data breaches in all organizations at all times ". There is clearly a heavy bias to retailers (e.g. type of staff roles, recommendations referencing point of sale), and thus those organisations within scope of standards from the Payment Card Industry Security Standards Council (PCI SSC). However, data was gathered not only from Verizon but also from Australian Federal Police, the Dutch National High Tech Crime Unit, the Irish Reporting and Information Security Service, the UK's Police Central e-Crime Unit, and the United States Secret Service. So it is not just Verizon's paying clients.

Remember, you don't need to lose data to have an incident or a loss. I'd like to see reports titled:

• 2012 Attacks Without Data Loss Investigations Report
• 2012 Data Alteration and Destruction Report
• 2012 Breachless Fraud & Misuse Report
• 2012 Undetected Incidents Report
• 2012 Service Unavailability Investigations Report
• 2012 Reputation, Risk and Resolve

We have that data, yes? Oh, ...maybe not.

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.