As part of the OWASP EU Tour 2013, there will be a special event in London next month, along the lines of the recent ones in Cambridge and Leicester.

The one day conference is being held in central London on Monday 3rd of June 2013 at the Lion Court Conference Centre, 25 Procter Street, Holborn, London, WC1V 6NY. The nearest tube station is Holborn. It is free to attend and is open to all, but registration is required as numbers are limited to 100.

The agenda is still being finalised, but OWASP Ireland chapter leader Fabio Cerullo is presenting PCIDSS for developers, OWASP Cambridge chapter leader Steven van der Baan will be talking about simple steps for secure coding, and OWASP London chapter leader Justin Clarke will be speaking about securing development with PMD, the popular Java code scanning tool. I will be introducing and demonstrating OWASP Cornucopia. A very developer-orientated agenda so far.

The EU Tour continues to OWASP chapters in Barcelona, Bucharest, Belgium, Denmark, Dublin, Lisbon, Netherlands and Rome. Other locations will be added in due course.

Cornucopia Ecommerce Website Edition v1.00 was uploaded to the OWASP website in February and has now been upgraded to a full OWASP project.

Today, I have completed the new OWASP Cornucopia Project pages which include:

• Description and objectives
• Presentation given at OWASP Netherlands in March
• Links to all the references files, including a new security coding practice requirement identities, created last week
• Instructions on how to play
• Frequently asked questions
• Acknowledgements
• Road map and how to get involved
• Link to the PCISSC information supplement for PCIDSS referencing Cornucopia

Please let me know if you think I can add anything of use to the project pages.

I am also working on some minor updates to the ecommerce website edition's documentation and deck. I will be presenting the project at an event in London shortly.

Following the success of similar events in Latin America, a rolling tour of events with OWASP speakers will be occurring in European Countries, beginning with Cambridge this month.

This first event of the tour has been organised in conjunction with Anglia Ruskin University's Department of Computing and Technology for Monday 13 May 2013.

The agenda lists all the speakers:

• Adrian Winckles, OWASP Cambridge Chapter Leader & Senior Lecturer
• Ross Anderson, Cambridge University Computer Laboratory
• DI Stewart Garrick, Metropolitan Police ECrime Unit
• Justin Clarke, OWASP London Chapter Leader
• Eoin Keary, OWASP Board Member
• Steven van der Baan, OWASP Cambridge Chapter Leader
• ... and myself.

I will be speaking about application security vulnerability severity ranking and prioritisation. This will be of use if you have to create or consume vulnerability assessments and penetration test reports, or are involved in patch management or PCIDSS compliance.

Thank you to Fabio Cerullo and the OWASP team who made this tour happen.

The event runs from 11:00 to 17:15 hrs and is located in LAB 002, Lord Ashcroft Building, Anglia Ruskin University, Cambridge. It is free to attend, but advance registration is required.

I have just had time to catch up on my attendance and participation at Security B-Sides London 2013.

This community-led event was held at the town hall of the Royal Borough of Kensington and Chelsea on Wednesday 24th April, and was supported by a large number of speakers, educators, volunteers and sponsors. It was an extremely well organised, and useful, day.

Following the very well attended welcome and introduction from the B-Sides London crew, I went to an immensely valuable and engaging presentation by David Rook (aka Security Ninja) on how he introduced and developed an application security programme at his employer Realex Payments. He has got to the point where customers are approaching his company to act as a payment services provider due only to their knowledge of Security Ninja, and so the marketing department kindly designed cartoon-style presentation slides (like the one illustrated above). They also had these printed as booklets to hand-out to those attending the talk at B-Sides London. David described what was done, how it was achieved, and things he would approach differently in hindsight. I won't spoil the plot for you as you will be able to read the booklet yourselves (keep an eye open for a blog post (now available).

After this, I went down to the new Rookie Track where new presenters had been given support through mentoring to give 15-minute presentations. Firstly I listened to Artjom Vassiljev describe how he has built software security testing checks into a continuous integration process with Jenkins.

Following a quick coffee break and catch up with some friends & acquaintances, I returned to the Rookie Track and listened to Diarmaid McManus describe a new Eclipse plugin called ESP he has been working on to help integrate code review checks into developer's coding tools.

Ksenia Dmitrieva provided an introduction to HTML5 risks and gave explanations and examples of common attacks. She also explained the preventative measures which should be used to protect against these issues.

Post lunch, I tracked down Dinis Cruz and we set up our workshop on using OWASP O2 to visualise OWASP AppSensor behaviour. I introduced the concept of application-specific attack detection and response, and described how the ideas might be retrofitted relatively simply to an existing web application such as the bulletin board software phpBB. A review of phpBB's inherent capabilities and logging provide a useful hook for detection points, and responses can include adding users to phpBB's list of "banned IPs" and blocking IPs at the operating system level. Dinis continued with a live demo of the AppSensor demo application, created by Michael Coates, and then he went on to show how AppSensor's new web services Java code can be called directly from within a .Net application TeamMentor.It was good to bounce ideas off the workshop participants and get their thoughts and suggestions on the practicalities of implementing AppSensor-like capabilities.

Finally I saw Gavin Holt talking about "NoSQL & Big Data - A Way to Lose Even More Stuff" in which he described the common weaknesses in using NoSQL and attacks that attempt to access such systems and their data. I really liked the 15minute format on the Rookie Track and all three speakers I heard were really good.

Overall, an excellent day. Many thanks to the very professional B-Sides London team in particular for making sure it all happened.

Update 30th April 2013: Link to Security Ninja's slides added. Ksenia Dmitrieva's talk added.

Three regional OWASP application security conferences are planned for later this year.

OWASP runs the most comprehensive application security conferences with a very high standard of training courses, speakers and delegates to network with. The next three conferences are:

• August 20-23: AppSec EU Research 2013, Hamburg, Germany
• October 1-4: AppSec Latam 2013, Lima, Peru
• November 18-21: AppSec USA 2013, New York, USA

The calls for training and papers are open for AppSec EU and AppSec USA. I hope to attend both of these. AppSec Asia will occur again in spring 2014.

Do you remember Nominet's consultation regarding a new .uk domain name?

Nominet has produced an comprehensive summary of the consultation, a response analysis and an update which identifies the next steps being taken. There is much useful commentary on the proposed security aspects (Part II of the summary document, pp18-38) including:

• Concern that enhanced security requirements for direct.uk would devalue existing .co.uk and .org.uk domain names
• General consensus that making DNSSEC mandatory for new domains
• Security features not comprehensive enough or rigorous enough
• Malware monitoring is the responsibility of the registrant, not the registry
• Malware monitoring may not be effective
• The proposed trustmark could be misleading and be a large burden on registrars and registrants
• Consider applying the proposed security features to existing third level domain names

The current proposal will not proceed and Nominet are reviewing alternatives. It notes there was widespread support for DNSSEC, but concern about the use of a trustmark, and a need to address security more widely than just a subset of new domain names.

On Wednesday this week, Trustwave has published the full version of its latest global information security report. It is comprehensive, information-rich, and well designed.

2013 Trustwave Global Security Report (registration required) provides information from their incident investigations, updates from law enforcement agencies around the world (including SOCA), threat intelligence (attack sources, motivations, emerging techniques, attacks and defences), and some international perspective viewpoints. The sources used to aggregate data and draw conclusions from include their vulnerability scanning, penetration testing and incident response investigation services, publicly disclosed data breaches, email sources, published vulnerabilities, and analysis of malicious web sites. Even this cannot be said to be completely representative, but it is amongst the better data available.

Based on the incident investigation information, payment cardholder data was the primary target because it is highly saleable for subsequent use in fraudulent transactions. Secondly personal data is noted as having some monetary data. The primary targets were retail, food & beverage and the hospitality sector via their e-commerce and retail channels (web sites and point of sale/payment processing). These of course reflect organisations that are required to, or felt the need to, engage a company like Trustwave to perform incident investigation. Thus there will be a bias towards medium and larger organisations with personal, credit and debit card data.

Where large quantities of data were compromised, the incident investigations identified weak administrative credentials, SQL injection and remote file inclusion as the primary vulnerabilities, with data being exfiltrated using HTTP and HTTP over TLS, RDP, SMTP and SMB protocols due to missing egress firewall controls. The report recommends building a defence in depth strategy with multiple layers of security. In terms of important applications, a holistic approach that builds security in throughout the development and operation is required. In the section on international perspectives for EMEA, the report notes there is an increasing trend of medium-sized and non-banking organisations developing strategic application security programmes, where assurance activities are based on the business risk each application presents.

Information points from the WASC Web Hacking Incident Database are also presented. These relate to publicly reported incidents of web applications during 2012 that have an identified outcome. This does not pretend to be fully representative of all web application attacks, but it does represent many significant events. The most common attack methods were denial of service followed by SQL injection.

The top 10 application vulnerabilities (I believe the label on the table on page 50 possibly mistakenly includes the word "mobile") highlights how common cross-site scripting (XSS) and cross-site request forgery (CSRF) are, based on a sample of application penetration tests. Separate information is also presented for mobile application penetration tests, comparing the findings to the OWASP Mobile Top 10.

The other part of the report of interest to application software designers and architects is the statistical analysis of nearly 3.1 million encrypted passwords from Active Directory servers. In order of number of occurrences "Welcome1" is the most common password, followed by "STORE123", "Password1", "password", "Hello123", and "12345678". "training" and "Welcome2". "STORE123" sounds very like point of sale (POS) systems. These results and analysis of password composition and markup will be useful where there is a desire to limit the use of common passwords and formats.

Definitely worthwhile reading.

The SANS Analyst Program has published a white paper by Jim Bird and Frank Kim.

SANS Survey on Application Security Programs and Practices describes the results of a sponsored survey of 700 employees with responsibilities for security, management and software development. The aims of the survey were to identify the drivers for application security programs, the greatest risks, how resources are prioritised, what practices are being undertaken, which tools and services are used, programme challenges, and the maturity and effectiveness of the programmes.

Similar to the 2011 report from Forrester Research, the most import driver for application security programmes (secure software development life cycles) are regulatory/compliance requirements with Payment Card Industry (PCI), US Sarbanes–Oxley Act (SOX) and the US Health Insurance Portability and Accountability Act (HIPPAA) being the most common.

The comprehensiveness of application security programmes is reviewed for internally-developed, outsourced application development, and commercial off the shelf (COTS) applications. Apart from policies and vulnerability awareness, and risk assessments/due diligence of third parties, the survey primarily reports on technological controls and practices. These are static analysis code review, dynamic analysis (e.g. vulnerability scanning), manual penetration testing, and use of web application firewalls (WAFs) and using WAFs for virtual patching.

There is no mention of other practices that can contribute such as defining security requirements, producing guidance materials, training, design and architecture reviews, secure deployment (see more in the Software Assurance Maturity Model, BITS Software Assurance Framework, BSIMM, etc).

See also the related Application Security Gap Study and Protection Against Business Logic Attacks.

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.

Th excellent Building Security In Maturity Model (BSIMM) survey of secure software development practices has been updated again.

BSIMM v4 was released in September and now includes data from 51 companies across a dozen sectors, including 19 each from financial services and independent software vendors.

The data is richer since 13 of the companies have now been assessed twice, and one thrice. The summary data on pages 57 and 58 identify 12 objectives/activities that were found to pe present across the secure software development life cycle (S-SDLC) process of all companies, and the prevalence of each activity in the total set.