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.

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.

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.

MEP Jan Philipp Albrecht, Rapporteur to the European Parliament's Committee on Civil Liberties, Justice and Home Affairs has published a report with suggested amendments to the EU Data Protection Framework proposals.

These might well add to the concerns of the UK's Justice Committee, and certainly from the advertising industry around the issue of explicit consent and a widening of the definition of personal data, including in some circumstances "Internet Protocol addresses, cookie identifiers and other unique identifiers".

The report outlines the current text proposed by the Commission, the proposed amendment and justification for the proposed change. Apologies for the length of this post, but some of the more important suggested amendments for web site and web service operators are outlined below to give a flavour of what might be expected.

• 14 "... The principles of data protection should not apply to data rendered anonymous in such a way that the data subject is no longer identifiable"
  changed to
  "... This Regulation should not apply to anonymous data, meaning any data that can not be related, directly or indirectly, alone or in combination with associated data, to a natural person or where establishing such a relation would require a disproportionate amount of time, expense, and effort, taking into account the state of the art in technology at the time of the processing and the possibilities for development during the period for which the data will be processed."
• 15 "When using online services, individuals may be associated with online identifiers provided by their devices, applications, tools and protocols, such as Internet Protocol addresses or cookie identifiers. This may leave traces which, combined with unique identifiers and other information received by the servers, may be used to create profiles of the individuals and identify them. It follows that identification numbers, location data, online identifiers or other specific factors as such need not necessarily be considered as personal data in all circumstances."
  changed to
  "When using online services, individuals may be associated with one or more online identifiers provided by their devices, applications, tools and protocols, such as Internet Protocol addresses, cookie identifiers and other unique identifiers. Since such identifiers leave traces and can be used to single out natural persons, this Regulation should be applicable to processing involving such data, unless those identifiers demonstrably do no relate to natural persons, such as for example the IP addresses used by companies, which cannot be considered as 'personal data' as defined in this Regulation."
• 31 "In order for processing to be lawful, personal data should be processed on the basis of the consent of the person concerned or some other legitimate basis, laid down by law, either in this Regulation or in other Union or Member State law as referred to in this Regulation."
  changed to
  "In order for processing to be lawful, personal data should be processed on the basis of the specific, informed and explicit consent of the person concerned or some other legitimate basis, laid down by law, either in this Regulation or in other Union or Member State law as referred to in this Regulation."
• 19 "In order to ensure free consent, it should be clarified that consent does not provide a valid legal ground where the individual has no genuine and free choice and is subsequently not able to refuse or withdraw consent without detriment."
  changed to
  "In order to ensure free consent, it should be clarified that consent does not provide a valid legal ground where the individual has no genuine and free choice and is subsequently not able to refuse or withdraw consent without detriment. The use of default options which the data subject is required to modify to object to the processing, such as pre-ticked boxes, does not express free consent."
• 25 New "The interests and fundamental rights of the data subject override the interest of the data controller where personal data are processed in circumstances where data subjects do not expect further processing, for instance when a data subject enters a search query, composes and sends an electronic mail or uses another electronic private messaging service. Any processing of such data, other than for the purposes of performing the service requested by the data subject, should not be considered in the legitimate interest of the controller."
• 45 New "The right to the protection of personal data is based on the right of the data subject to exert the control over the personal data that are being processed. To this end the data subject should be granted clear and unambiguous rights to the provision of transparent, clear and easily understandable information regarding the processing of his or her personal data, the right of access, rectification and erasure of their personal data, the right to data portability and the right to object to profiling. Moreover the data subject should have also the right to lodge a complaint with regard to the processing of personal data by a controller or processor with the competent data protection authority and to bring legal proceedings in order to enforce his or her rights as well as the right to compensation and damages resulting of an unlawful processing operation or from an action incompatible with this Regulation. The provisions of this Regulation should strengthen, clarify, guarantee and where appropriate, codify those rights."
• 54 "To strengthen the 'right to be forgotten' in the online environment, the right to erasure should also be extended in such a way that a controller who has made the personal data public should be obliged to inform third parties which are processing such data that a data subject requests them to erase any links to, or copies or replications of that personal data. To ensure this information, the controller should take all reasonable steps, including technical measures, in relation to data for the publication of which the controller is responsible. In relation to a third party publication of personal data, the controller should be considered responsible for the publication, where the controller has authorised the publication by the third party."
  changed to
  "To strengthen the 'right to erasure and to be forgotten' in the online environment, the right to erasure should also be extended in such a way that a controller who has made the personal data public without legal justification should be obliged to take all necessary steps to have the data erased, but without prejudice to the right of the data subject to claim compensation."
• 61 "The protection of the rights and freedoms of data subjects with regard to the processing of personal data require that appropriate technical and organisational measures are taken, both at the time of the design of the processing and at the time of the processing itself, to ensure that the requirements of this Regulation are met. In order to ensure and demonstrate compliance with this Regulation, the controller should adopt internal policies and implement appropriate measures, which meet in particular the principles of data protection by design and data protection by default."
  changed to
  "The protection of the rights and freedoms of data subjects with regard to the processing of personal data require that appropriate technical and organizational measures are taken, both at the time of the design of the processing and at the time of the processing itself, to ensure that the requirements of this Regulation are met. In order to ensure and demonstrate compliance with this Regulation, the controller should adopt internal policies and implement appropriate measures, which meet in particular the principles of data protection by design and data protection by default. The principle of data protection by design require data protection to be embedded within the entire life cycle of the technology, from the very early design stage, right through to its ultimate deployment, use and final disposal. The principle of data protection by default requires privacy settings on services and products which should by default comply with the general principles of data protection, such as data minimisation and purpose limitation."
• 84 "'data subject' means an identified natural person or a natural person who can be identified, directly or indirectly, by means reasonably likely to be used by the controller or by any other natural or legal person, in particular by reference to an identification number, location data, online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that person;"
  changed to
  "'data subject' means an identified natural person or a natural person who can be identified or singled out, directly or indirectly, alone or in combination with associated data, by means reasonably likely to be used by the controller or by any other natural or legal person, in particular by reference to a unique identifier, location data, online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural, social or gender identity or sexual orientation of that person;"
• 106 New "4a. Consent looses its effectiveness as soon as the processing of personal data is no longer necessary for carrying out the purpose for which they were collected. "

The topic of information security is also addressed:

• 39 "The processing of data to the extent strictly necessary for the purposes of ensuring network and information security, i.e. the ability of a network or an information system to resist, at a given level of confidence, accidental events or unlawful or malicious actions that compromise the availability, authenticity, integrity and confidentiality of stored or transmitted data, and the security of the related services offered by, or accessible via, these networks and systems, by public authorities, Computer Emergency Response Teams - CERTs, Computer Security Incident Response Teams - CSIRTs, providers of electronic communications networks and services and by providers of security technologies and services, constitutes a legitimate interest of the concerned data controller. This could, for example, include preventing unauthorised access to electronic communications networks and malicious code distribution and stopping 'denial of service' attacks and damage to computer and electronic communication systems."
  changed to
  "The processing of data to the extent strictly necessary for the purposes of ensuring network and information security, i.e. the ability of a network or an information system to resist accidental events or malicious actions that compromise the availability, authenticity, integrity and confidentiality of stored or transmitted data, and the security of the related services offered by these networks and systems, by public authorities, Computer Emergency Response Teams - CERTs, Computer Security Incident Response Teams - CSIRTs, providers of electronic communications networks and services and by providers of security technologies and services, in specific incidents, constitutes a legitimate interest of the concerned data controller. This could, for example, include preventing unauthorised access to electronic communications networks and malicious code distribution and stopping 'denial of service' attacks and damage to computer and electronic communication systems. The processing of personal data to restrict abusive access to and use of publicly available network or information systems, such as the blacklisting of Media Access Control (MAC) addresses or electronic mail addresses by the operator of the system, also constitutes a legitimate interest."

While not all these amendments (or the rest of the draft framework itself) will come into law, it would be a brave organisation not to start taking these types of considerations into planning and upcoming projects.

Just in case you have got the development process running slickly, and operation is going smoothly, have you thought about asset disposal, and related data destruction, at the end of life?

Well, the UK's Information Commissioner has produced a short guide IT Asset Disposal for Organisations.

As it states in the guide "if personal data is compromised during the asset disposal process, even after it has left your organisation, you may still be responsible for breaching the DPA so it is important to manage the process correctly". This is of course relevant for other types of data too. And not just your own equipment, but that of organisations processing data on your behalf (and in the cloud).

Who is your "asset disposal champion"?

Nominet, the .uk internet registry, is consulting on a proposal to create unlimited second level domains (SLDs) using .uk (e.g. clerkendweller.uk instead of clerkendweller.co.uk).

The consultation document steps through the proposals and asks for responses to a number of aspects:

• Security
• Verification of registrant contact data
• Third level sub-domains
• Reserved and protected names
• Phased release and rights management
• Channel to market
• Existing second level domains
• General views

The security section proposes malware monitoring and notification, a mandatory digital signature to prevent the hijacking of a domain name (DNSSEC), and discusses how the new SLDs could be used as a trust mark. This would appear to reflect ideas published by the House of Commons Science and Technology Committee for a software security kitemark (at least for web sites).

I welcome the idea of building trust, but the bar is far too low.

I do not believe use of DNSSEC, initial and subsequent periodic verification of contact details, combined with some sort of commercial malware monitoring and notification are sufficient indicators of the safety of a web site for users and their data. The spread of malware is not the only risk to web site users. Trust needs to consider availability, prevention of misuse, protection of the data from breaches in confidentiality, maintenance of accuracy, and compliance with various mandates (e.g. legislative, regulatory and contractual such as PCI DSS). The processes for web site development, configuration and operation can all affect users and their data. These issues require a balanced combination of administrative, technical and physical controls, and thus are are not simple and cannot be determined by an automated scan.

Whatever measures are finally agreed, they should apply to new registrations and renewals of third level domains (e.g. co.uk and org.uk), not just for the proposed SLDs. Otherwise lack of trust in the current domains will undermine trust in the others.

The consultation closes on 7th January 2013. Responses can be sent by post, email or using an online form.

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.

If you missed AppSec EU, attend one of the next three OWASP global conferences.

The next conferences are:

• AppSec North America, 23-26 October 2012, Austin, USA
• AppSec Latin America, 18-21 November 2012, Montevideo, Uruguay
• AppSec Asia Pacific, 21-22 February 2013, Jeju, South Korea

There are also national events coming up in India (24 August), New Zealand (30 August), Ireland (4 September), Costa Rica (23 October) and Germany (7 November).

Find your local OWASP chapter, for smaller more local events.

I have posted a new message to the Software Assurance Maturity Model (SAMM) blog regarding scorecard charts.

Like the previously created roadmaps, the scorecard charts use a transformation from an XML file to create an SVG image. They illustrate a team, project or organisation's maturity level, scored against SAMM, at a single point in time (the scorecard charts in the SAMM document compare scores at two points in time).

The XML template, schema and transformation files are available to download without charge or registration.