Happy new year. Sophos has released its review of security attacks in 2012 with a look forward to what can be expected in 2013.

The Security Threat Report 2013 describes the increase in attacks against social media platforms and the cloud services. The report includes a feature on the Blackhole malware exploit kit, and has sections on the increase in attacks against Java and Android operating system, ransomware and attacks against OS X.

And for 2013? More of the same.

It took me a while to hear about a recent research report from the Ponemon Institute regarding application business logic attacks.

2012 Web Session Intelligence & Security Report: Business Logic Abuse Edition, published in early October, describes the results of a survey of 425 United Kingdom IT and IT security practitioners with some responsibility for the security of their transactional website and who were familiar with logic abuse. A parallel report details the survey of 643 similar professionals in the United States of America. In these studies, business logic abuse is the mis-use of intentional web site functionality to "perpetrate cyber attacks, hacks or fraud".

The most interesting figure is that 90% of companies lost revenues due to the financial or brand impact of fraud (alone?), and 20-25% lost more than 5% of their total revenues. The business logic abuse scenarios presented are web scraping, account hijacking, click fraud, botnets causing denial of service, electronic wallet exploitation, coupon abuse, testing stolen credit cards, mobile device malware to take over customer accounts, app store/marketplace fraud, and mass registration.

However, I was most interested to see what these IT and IT Security practitioners considered ought to be the steps that are taken to detect or prevent business logic abuse. The answers appeared to be selected from a pre-defined list provided in the survey, with "Manual inspection and assessment of web pages" during development and in production seemingly being the two most "important or very important" methods (each by about 50% of those responding). This is not "business logic security testing" since "thorough testing of the website's functionality prior to production" was a different item and considered important or very important by 20-30% of those responding.

But there was no mention of defining security requirement in advance, secure design, threat assessment, manual and automated code analysis, etc, or of building attack detection and prevention into the web sites themselves. Yes, web application firewalls (WAFs) and "content aware firewalls" were mentioned, and it seems the surveys' authors and respondents are very biaised towards operational practices.

The reports' conclusions appear to have missed that the activities are generally too late (not just too little), and that a range of security practices are needed throughout the software development life cycle (SDLC). However, the reports' recommendation to assign responsibility for web site security is correctly the most important first step.

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.

In October Securosis published a free paper concerning the security of "big data" systems.

Securing Big Data: Security Recommendations for Hadoop and NoSQL Environments focuses on the security aspects relating to the specifics of "big data" that are different architecturally and operationally to other environments rather than the, also important, security of the applications themselves. Thus, consideration of how nodes and client applications are vetted before joining the cluster, how data at rest is protected from unwanted inspection, the privacy of network communications, and how nodes are managed are covered.

The paper discusses what "big data" means, and the particular architectural and operational security issues that arise. It then presents six recommendations.

Testing for vulnerabilities is just one part of a wider secure software development life cycle. While manual testing has great value, the use of automated tools is necessary to assist with anything but the smallest of applications. But which tools should you use?

The results of a comparison of dynamic web application vulnerability scanners has just been published by Shay Chen. 2012 Web Application Scanner Benchmark updates a similar study undertaken in 2011 and compares ten different aspects of the tools.

The analysis examined 11 commercial tools and a slightly larger number of maintained free/open source tools and provides a superb reference for anyone undertaking a selection process. The results are presented in a dozen web pages at http://sectoolmarket.com/.

Of course what matters is the coverage, false negative rate, false positive rate and the features you need for your own style of applications.

See also the comparative studies in the other papers referenced, but especially Analyzing the Accuracy and Time Costs of Web Application Security Scanners, Larry Suto, February 2010 (and discussion/responses) and the SAMATE bibliography.

WhiteHat Security in the United States has published the 12th edition of its Security Statistics Report for summer 2012).

As with the previous edition, the new Volume 12 provides a detailed breakdown of the number of higher-risk vulnerabilities found, types, remediation rates and time to fix by industry sector from work with its own clients. These were over 500 organisations with web sites ranging from highly complex and interactive, to static brochureware sites.

This time there is also an analysis of re-open rates — application vulnerabilities that had been identified, and later has been remediated or mitigated, but then re-appears at a later date. WhiteHat found that 20% of identified vulnerabilities were re-opened at some time, and in some cases many times. The report examines why this rate is relatively high and examines the re-open rate by vulnerability type.

WhiteHat define the included vulnerabilities as those with a High, Critical or Urgent severity as defined by PCI DSS naming conventions, exploitation of which "could lead to server breach, user account take-over, data loss or compliance failure".

Those names were defined in PCI DSS Security Scanning Procedures, Version 1.1, September 2006, also known as "high-level vulnerabilities", but which are not explicitly named in the document that supersedes it: Approved Scanning Vendors - Program Guide Reference 1.0 PCI DSS, Version 1.2, March 2010. The terms Urgent, Critical, and High are however still mentioned in PCI DSS v2.0 requirement 11.2 on vulnerability scanning. The naming does not matter; at least WhiteHat has defined their categorisation and has been consistent with its use. But remember your own organisation's definition of severity, and how it prioritises application vulnerabilities, could be quite different.

The week after next OWASP AppSec EU begins in Athens where I am speaking. During my presentation I will discuss the newly mandatory requirement 6.2 in PCI DSS relating to ranking of vulnerabilities, with special emphasis on ranking the severity of vulnerabilities in software applications.

In Tricolour Alphanumerical Spaghetti I will also describe alternative ways of meeting PCI DSS v2.0 Requirement 6.2 and which is a mandatory requirement from 30th June tomorrow, previously just being considered a best practice. I will discuss risk ranking schemes and how to develop a method for evaluating vulnerabilities and assigning a risk rating relevant to your own specific environment and business needs.

PCI DSS requirement 6.2 influences other requirements where the prioritisation of vulnerabilities are referenced:

• 2.2 Develop configuration standards for all system components. Assure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards.
• 6.5.6 Develop applications based on secure coding guidelines. Prevent common coding vulnerabilities in software development processes, to include the following: ... All "High" vulnerabilities identified in the vulnerability identification process (as defined in PCI DSS Requirement 6.2).
• 10.4 Using time synchronization technology, synchronize all critical system clocks and times and ensure that the following is implemented for acquiring, distributing, and storing time.
• 11.2.1 Perform quarterly internal vulnerability scans.
• 11.2.3 Perform internal and external scans after any significant change.

So, I am hoping it will be of use to those with PCI DSS obligations, as well as to organisations who simply want to know what the severity rating of a vulnerability, flaw, fault or weakness means. The presentation is being given at 15:20 hrs on Thursday 12th in the "Builders" track.

Immediately prior to the conference there are training courses. There are still some places left on my course Application Attack Detection & Response — A Hands-on Planning Workshop being held on Tuesday 10th July. This will be a highly interactive day with generous learning opportunities. Last time we did the course, the participants really enjoyed it and gave great feedback.

If you are going for the conference, why not take the opportunity to receive some training. On the next day, Wednesday, you could also register for the training course Elite Web Defense — How to Build Robust and Secure Web Applications being run by the excellent Jim Manico and Eoin Keary. Register for the training and conference here.

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.

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.

Next week there are two London-based Open Web Application Security Project (OWASP) events.

On Thursday 10th May, there is an Application Security One-Day Conference organised jointly with ISSA UK. It is being held at Bletchley Park from 09:45 hrs and is free to members of OWASP London, ISSA-UK and the Charities Security Forum (CSF). Prior registration is required. The presentations include:

• ISO/IEC 27034-1 and OpenSAMM software assurance frameworks
• Third party application analysis
• OWASP Mobile Top Ten
• HTML5 web security
• Cost & business justification models for AppSec

There is also an opportunity for a guided tour of Bletchley Park to see the site of the secret British code-breaking activities during WWII and birthplace of the modern computer.

In the evening there is another OWASP event organised by OWASP Royal Holloway University of London (RHUL) at RHUL's main campus in Egham. The presentations start at 18:30 hrs and will be about:

• Websecurify web security testing technology
• Online habits and digital trails
• Making security invisible for developers

There is just about time to attend both meetings for a very full and informative day.