OFCOM, the UK communications sector's regulator and competition authority, has announced a report on adults' use of media and attitudes.

The Adults' Media Use and Attitudes Report 2013 (complete 181 page print version) discusses media literacy, take-up, preference and media use, understanding, attitudes and concerns, use of the internet and mobile phones, and users in three class — new, "narrow" and non-users.

There is a wealth of valuable data for strategic planning and marketing purposes, but also useful information on security and safety habits and attitudes to regulation of the internet. If you need information to help support decisions around security and usability, this report will have something of use to you.

It is this weekend's best read.

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.

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.

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.

In previous posts, I have mentioned labelling in A Software Security Kitemark?, Trust and E-commerce Trustmarks, Privacy Labelling, Trust .UK, Security Labelling, and Software Assurance Labelling. There are some impressive developments in ideas for privacy and terms of use labelling.

In Coming to Terms on the Project VRM blog describes the work at StandardLabel.org, CommonTerms and BiggestLie.

There are some great insights into rights, user behaviour and clarity of expression, which could contribute to formulating better, more understandable, descriptions of software security quality for users. Could security be meaningfully summed up in a single statement, or even just a small number of icons?

It's a challenging problem to produce something of value to a consumer, that takes a minimal amount of effort to digest. I like the approach of the OWASP Application Security Verification Standard, but even this has a degree of complexity of manual vs. automated testing, and I am not sure software security (from the end user's viewpoint) can be entirely divorced from the security of the underlying infrastructure.

Any thoughts?

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.

The European Network and Information Security Agency (ENISA) has published a new guide on monitoring the security of cloud services throughout the project life-cycle.

Procure Secure: A Guide to Monitoring of Security Service Levels in Cloud Contracts defines an ongoing security monitoring framework comprised of:

• Service availability
• Incident response
• Service elasticity and load tolerance
• Data life-cycle management
• Technical compliance and vulnerability management
• Change management
• Data isolation
• Log management and forensics

The concept is to provide continuous cloud-specific service level metrics in-between one-off or periodic assessments (e.g. using information technology audit standards such as ISO 2700x, SSAE 16 or ISAE 3402). For each suggested monitoring parameter examples are provided to help guide what to measure, how to measure it, how to obtain independent measurements, alerting & reporting thresholds and customer responsibilities.

Although there is a focus on public procurement, the issues are equally relevant in the private sector. There is also a 9-page checklist guide to the document "if you have little time available".

The UK's data protection agency Information Commissioner's Office (ICO) has updated the previous guidance on the use of cookies and similar tracking technologies, under the revised Privacy and Electronic Communications Regulations which came into force on 26th May this year.

In a press release today, organisations were warned they are not doing enough during the lead-in period to formal enforcement.

The updated Guidance on the Rules on use of Cookies and Similar Technologies provides concrete advice and practical guidance on the legal requirements, their interpretation and what are considered acceptable practices. The guidance was issued as a result of a review of progress to date which shows a lack of knowledge and action from web site owners. Of most concern are likely to be persistent cookies, cookies issued by third parties, cookies issued immediately a user visits a web site, are used for any sort of profiling or which span multiple website hostnames or multiple domains.

If you have any analytics, advertising, tracking or content provision by third party web sites, beware — you may just find the terms and conditions of service state you are responsible for obtaining and managing consent.

If you are a web site owner, take note and act now, if you have not already done so. From May 2012, the ICO will be accepting complaints from users, and will then contact web site owners to ask them to respond to the complaint and explain what steps they have taken to comply with the regulations. Therefore, document what you are doing and the decisions taken.

I seem to have arranged quite a few upcoming presentations and training sessions relating to the concepts in OWASP AppSensor during May and June, across Europe (and further afield).

Following my previous speaking enagements at events in Newcastle-upon-Tyne and London, and the release of an implementation guide at AppSec DC last year, I was approached to talk about this subject in one of the training slots at the OWASP Ireland Training Day in Dublin in March.

But coming up, I seem to have ended up doing a mini European tour. Here are the dates and what's being presented about AppSensor:

• 12th May, ISSA UK application security training day at National Codes and Cipher Centre, Bletchley Park, UK — a high-level overview of application defence with a focus on how this can contribute to a reduction in operational risk (free to ISSA members, registration required).
• 19th May, 2nd International Secure Systems Development Conference, London, UK — an introduction to OWASP AppSensor (chargeable).
• 25th May, OWASP Greece chapter Training Day, Athens, Greece — introduction and walk-through on how to identify and select attacker detection points (free to OWASP members, registration required). I will also be presenting Software Assurance Maturity Model at this event.
• 9th June, AppSec EU 2011, Dublin, Ireland — an update on the OWASP AppSensor project including how to build the concepts into your own software projects (chargeable, discount to OWASP members, registration required).
• 16th June, OWASP Belgium chapter meeting, Brussels, Belgium — a repeat of the AppSec EU presentation (free, registration required).

I am also providing a full day course "Application Attack Detection & Response — A Hands-on Planning Workshop", based on the concepts in the OWASP AppSensor Project, at AppSec USA in Minneapolis on 20th September 2011.

The training course is a practical hands-on day-long workshop where participants will learn how to define, select and specify application-layer intrusion detection and protection (IDP). The training course uses a problem-centered approach where participants are encouraged to use their own knowledge and experience to apply the techniques learned in example lab projects. Most of the day will be spent working in small teams creating strategies and implementation plans, which could subsequently be used in development. The course does not involve any coding and is language/ framework agnostic. Full printed handouts are provided together with materials for all the exercises, so participants can take these away and apply the ideas within their own organizations.

The course will be of direct use by anyone interested in building attack-aware applications or in constructing defensive measures directly into applications. The development lifecycle for application-specific intrusion detection and protection (IDP) spans analysis, planning, implementation and operation. This training course covers the first two of these — analysis and planning.

The processes and templates provided during the course may be of most use in larger development teams, but more advanced individual designers, architects & developers will gain knowledge which they can apply themselves directly in their own projects. The course is also a useful introduction to the attack-aware application concepts, and therefore may be of interest to those involved with specification, verification practices such as testing & audit, and operational processes such as deployment and incident handling. The examples used will be repeatedly linked back to business objectives throughout the day. The course outline is:

1. Course Introduction
2. Preliminary Requirements
3. Application Logging Practices
4. Standard Detection Points
5. Custom Detection Points
6. Model Creation
7. Model Optimization
8. Attack Analysis
9. Response Actions
10. Response Threshold Specification
11. Implementation Plan
12. Optional Course Assessment Test

Exercises will be undertaken in small teams of between 4 and 6 people, depending upon the number of participants on the course. Each exercise during the day will be the continuation of the previous one, so the teams build up a complete IDP plan for their example project.

Registration is now open. Please book early to ensure a place. Discounts are available for group bookings.