Following a successful training course yesterday with great group of delegates, today I attended the OWASP AppSensor Project working group at AppSec USA 2011.

The AppSensor Summit was held to review the project's recent developments and activities, and to gather ideas from existing and new contributors to create a future roadmap. It was good to meet at long last John Melton, AppSensor's lead programmer, and catch up with Michael Coates and Ryan Barnett.

The summit also attracted a diverse range of developers, architects, users and security vendors. There were probably about 10-12 people attending all day, with a few more popping in and out as their timetables and other commitments allowed. The discussions defined the contents for a new book, an AppSensor development life cycle, an integration plan and a new concept to modularise the analysis engine to simplify integration with application software. The idea of creating a set of example usage profiles was also suggested. I think my name is down to help mainly with a new version of the AppSensor book, but I hope I can contribute with some of the interface definitions for interactions with the analysis engine, and possible signalling/exporting functionality.

The meeting notes are available, so if you have any comments or suggestions, please add them there, or discuss them via the project's mailing list.

The talks at the conference begin tomorrow.

This week I attended and spoke at the Software Assurance Forum Fall 2011 in Arlington, Virginia.

With three tracks running, my own talk was in the "SwA at the Code Level". It seemed to be received well and the audience asked some great questions including some relating to practicality and scaleability. There were also some good suggestions for me to investigate concerning integration with, and cross-referencing with, other standards and protocols.

On the remainder of the day I listed to Jack Mannino talking about the OWASP Top 10 Mobile Risks, Jeff Williams on OWASP Acquisition Language for Software Assurance, and Jim Manico on Scalable Application Security Practices.

On Thursday, I attended the discussions on education and training, the educational supply chain and standards for software transparency. On Friday the presentations focused on software lifecyle development afforts including the effects of standards, people and culture.

I really enjoyed the event and heard about things I wouldn't normally have had time to investigate. And yes, I have some homework to do now.

Update 18th October 2011: The presentations at the Software Assurance Fall 2011 Forum have been published.

The new edition of CrossTalk Magazine, the Journal of Defense Software Engineering, includes an article about OWASP AppSensor Project.

In this September/October 2011 edition, CrossTalk focuses on the theme of Protecting Against Predatory Practices. Articles examine the most recent dangers the software community faces and methodologies used to protect information against cyber espionage. They explore the latest threats, security measures, software security automation, and social networking dangers.

I had the pleasure of working with AppSensor project leader Michael Coates, and project contributors John Melton and Dennis Groves to write the article Creating Attack-Aware Software Applications with Real-Time Defenses describing why conventional defences fail to protect applications and the benefits of building-in application-specific defenses. We describe the accumulation of information, ideas and code within the AppSensor Project, how these can be applied to an organisation's own software applications, and plans for the continued development of the project.

If you would like to find out more, I will be speaking at Software Assurance (SwA) Forum - Fall 2011 tomorrow, running a one-day training course at AppSec USA 2011 on 20th September, and participating in the recently announced AppSensor Summit on 21st September 2011.

The UK's Centre for the Protection of National Infrastructure (CPNI) has updated its guidance on protecting business applications with the publication this month of a new document on developing and implementing secure web applications.

Development and Implementation of Secure Web Applications is a well-written and digestible 81-page A4 document arranged in seven main sections:

• Introduction to web application security
• General aspects of web application security
• Access handling (authentication, session management and access control)
• Injection flaws
• Application users and security
• Thick client security
• Preparing the infrastructure

It appears to replace the good, but somewhat dated document "Briefing 10/2006 - Secure web Applications - Development, Installation and Security Testing" created by their predecessor National Infrastructure Security Co-ordination Centre (NISCC), and issued in April 2006. The new document is more compact and focused, and I think I prefer it. Yes of course it is more up-to-date, and while it would be possible to argue why some things are included and not others, these others things tend to be explained further in the references. It's clear there is considerable overlap with information from OWASP and the Microsoft SDL, but I'm sure the reverse is true to an extent too.

It is very encouraging CPNI have taken the time to produce an updated document, but that probably reflects the types of risks facing their audience. I am especially pleased to see the section on infrastructure, since application security cannot be an island on its own. I would say the guidance is probably on the medium-to-heavy weight side of advice, but that is probably appropriate for critical national infrastructure, and the document does discuss threat modelling initially. It might seem overwhelming to some organisations new to the subject, and that might need some help on what to do first.

I think the document could perhaps do with more cross-referencing to additional information resources elsewhere. Yes, documents can always be improved, and I am sure we will find niggles and faults with use, but threats evolve and so does our knowledge.

Today I came across a useful marketing-related discussion of common e-commerce trustmarks.

Which E-commerce Trustmarks Are Most Effective? describes a study of twenty different security-related trustmarks that cover SSL certificates, payment card merchant identity, business accreditation and that all-embracing term "security".

The 150 US respondents identified which logos they recognised, and then ranked them according to level of "reassurance". Very few trustmarks were actually recognisable, but those that were appeared to provide some level of increased trust. Of course, the top three (PayPal, Verisign and McAfee) are different types of thing — a payment service provider, an SSL certification authority and a site information security scanning service. Maybe it doesn't matter what service you provide as long as it is recognisable?

The blog post also lists other ways to increase user trust, and suggests that good checkout design can trump trustmark logos.

No mention of browser SSL indicators, security labelling, national reputation or HTTP security headers! And neither are having lots of credit card logos displayed nor "PCI DSS compliant" beside a PCI SSC logo which of course aren't trustmarks, but are used as such by some organisations.

Maybe UK customers would respond differently?

Application Attack Detection & Response is the title of the one-day hands-on training course I am providing at North America's most important application security conference AppSec USA 2011 in Minneapolis, MN.

I mentioned the course in May and since then have been preparing the course presentations, exercises, team handouts and other supporting materials. This week they are now ready and I have been through a dry-run of the whole day. The course is going to be very participatory. I will be presenting information largely based on the OWASP AppSensor Project, but half of the time will be spent on practical exercises which show how to plan a defensive strategy using application-specific intrusion detection and response.

Through the day the attendees will work in small teams building the specification for application-specific defenses of an example web application, in a tutorial-based approach. The course is technology and programming language-agnostic. In fact there is no code at all, but attendees need to be familiar with web application risks, vulnerabilities and the types of techniques attackers use to identify and exploit weaknesses. The exercises will be paper based but electronic templates will also be provided. The day will culminate in a defense simulation exercise, where the teams will score each other's defensive models against a range of attacks. 12 attacks will be selected at random from a set of pre-built scenarios with the code names:

• Slow Discoverer
• Yadda Yadda Yadda
• Hit & Run
• An Offshore Enquiry
• Scratch 'n' Sniff
• A Visit From A Foreign Gentleman
• Nosey Parker
• Coupon Chaser
• Build Your Own Data Warehouse
• Fraudulent Fingers
• Teen Leaver's Delight
• Blast From The Past
• The Forbidden Scriptures
• Slab Fondler's Folly
• Yet Another Hopeless User
• The Thirteen Problems
• Protect and Survive

You will have to be there to discover what these are all about, but perhaps you can guess some of them?

The AppSec USA 2011 organisers have been fantastic, especially Adam Baso and Lorna Alamri of the OWASP Minneapolis-St. Paul (OWASP MSP) chapter. I am really looking forward to the week there.

I believe there are still some places left on the course, so if you want to learn about this topic and leave well-briefed to apply the techniques in your own projects or software specifications, please register as soon as possible. The course begins at 8:30 am. This is the only time this one-day course is being offered in the Americas.

On the following day (21st September), apart from one-day training courses with Robert Zakon and Sumit Siddharth, there will be an AppSensor working session, and ESAPI summit. The conference then runs on the 22nd-23rd September.

Do you remember Lush Cosmetics' rather public payment card data and personal data loss announced in January 2011? After 4 months of being compromised, the problem was recognised, customers were notified and the web site was shutdown.

Lush had allowed people's data to be stolen via its own web site. We still await to hear what the fines and other penalties will be levied under the Payment Card Industry Security Standards Council (PCI SSC) Data Security Standard (DSS) if they are found to have been non-compliant at the time. However the UK's Information Commissioner's Office (ICO) became involved due to the related loss of 5,000 individual's personal data and confirmed in a press release on Wednesday this week that Lush Cosmetics had also breached the Data Protection Act 1998. Formed in 1994-1995, Lush Cosmetics has been a registered data controller (No. Z8189523) since late 2003.

As expected, no enforcement notice or monetary penalty has been issued, but Lush Cosmetics Limited's Managing Director, Mark Constantine, has signed an undertaking to ensure that personal data are processed in accordance with the seventh data protection principle concerning security, and in particular take the following measures to improve the protection of personal, and cardholder data:

1. Appropriate technical and organisational measures are employed, and maintained, to prevent the unlawful processing of customer data, particularly within web based systems;
2. Only the minimum amount of customer personal data is stored and that this is retained only for as long as a relevant business need exists;
3. Computer systems storing customer personal data must be subject of regular penetration testing , with activity logs retained for an appropriate period of time and frequently interrogated for evidence of malicious attack;
4. The processing of customer credit card data is conducted by a PCI compliant external service provider;
5. The data controller shall implement such other security measures as it deems appropriate to ensure that personal data is protected against unauthorised and unlawful processing, accidental loss, destruction, and/or damage.

...as long as the Data Protection Act, or succeeding legislation are in force. So correctly a focus on Lush's web systems, including penetration testing of systems holding personal data. But also other appropriate security measures as necessary. Let's hope Lush aren't left thinking penetration testing is the answer — security needs to be considered at all stages of acquisition, development, deployment and operation.

And yes, that's right, the ICO is insisting on compliance with PCI DSS. The ICO made it clear in the press release of its expectations for PCI DSS compliance by other online retailers, that will otherwise risk enforcement action by the ICO.

This seems to be a valid approach, since fines, investigation costs, etc may still be levied for lack of PCI DSS compliance too. But I have some concerns with how Lush are portraying their squeaky-clean new status in the web site's terms and conditions:

I'm not entirely sure that moving all cardholder data off-site to a PCI DSS compliant third party processor necessarily means much about the security of other data on the Lush web site and elsewhere at Lush, or much about systems outside the cardholder data environment. Is this just meaningless bubbly rhetoric to provide false assurance, or maybe Lush still does not understand what they are doing? Complying with regulatory and contractual mandates isn't the same as believing in "filling the world with perfume and in the right to make mistakes, lose everything and start again". Some of that "honest meaning" mentioned by Lush would be welcome here too.

Personally I think the PCI SSC should be a bit more strict about how their name can be used to endorse systems. Hey, clerkendweller.com meets PCI DSS compliance criteria too! There's no cardholder data to begin with...

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.

On Sunday morning, I was intrigued to read on Web Application Security - From the Start about a security vulnerability supposedly found on the Child Exploitation and Online Protection Centre (CEOP) web site.

But it is apparently true, the short story on the BBC web site seemed to be confirmed in their interview with CEOP which was mentioned by @StewartRoom, @xklamation, @siliconglen, and received further coverage yesterday in IT Pro and IT Week. I wondered where this report came from and how the Information Commissioner's Office (ICO) became involved so quickly. IT Week suggests a member of the public tested the CEOP site and then told them of the problem; presumably CEOP then reported it to the ICO.

Don't get me wrong, I think the ICO should investigate whether there has been a breach of the Data Protection Act 1998, but some of the information released so far doesn't seem correct. The BBC story includes several statements supposedly attributed to CEOP's Chief Executive Peter Davies. But I cannot quite believe CEOP would say some of these things about a web form to report alleged offenders, so perhaps sadly there is some over-zealous PR going on, or misinterpretation by the BBC's journalist.

A later item on The Register Child protection Website Insecurity Fixed paints a slightly different picture, suggesting the form is, and always has been, using SSL only, but that there was a link to a non-SSL address which then redirected. I must say, I'm inclined to believe The Register's version more than the BBC. I think we have to leave it up to whoever is investigating to get to the true facts, but it does seem to be creating a link between personal data protection and the use of SSL.

It is perhaps not always clear to government agencies what administrative, physical and technical security practices should be implemented to protect a web site, and who makes the decisions. The government's Central Office of Information (COI) have never published any web standards and guidlines on security or privacy protection, perhaps feeling it is some other agency's responsibility (maybe CESG, CPNI or even the ICO?).

The security measures implemented for a web form like this ought to be similar to those defined in open standards, and common sense alone would tell you this is an obvious place for using appropriately designed HTTPS. Anyone auditing or verifying the security aspects would have made this clear in large red letters, but waiting until after being made live is incomprehensible too. Security and privacy need to be considered from early stages in every project, and built in to the final system. There are existing standards for that too.

But I am concerned about some statements which have been reported. If they are true, I am worried.

"All secure website carried the prefix https, compare[d] to http for insecure ones"

False. Using HTTP over SSL does contribute to the protection of a user's, or organisation's, data in transit and also gives some degree of identity assurance. There is even a campaign to increase adoption. But SSL is not the same thing as a web site being secure. A web site using SSL can still be vulnerable to attacks (e.g. SQL injection, cross-site scripting, cross site request forgery) leading to contamination with malware or data damage, loss and destruction.

SSL does not stop breaches of the Data Protection Act.

"It's been fixed now"

Really, that quickly? There's more to implementing SSL than just turning it on. Last year I mentioned some other concerns about CEOP and trust, but you cannot check or test a web site without authorisation. On Sunday, @siliconglen also asked why they CEOP were not using an extended verification (EV) SSL certificate. For many purposes I'm on record as saying EV certificates are not needed, but here I agree, I think an EV certificate should be used. And really, why not have the whole site SSL.

Of course, all organisations would do well to ensure that their SSL certificates are valid, applied appropriately to the applications and that SSL is configured securely, such as ensuring weak protocols and ciphers are not available. They should also think about whether any data can be cached locally on the web browser, whether other domains have access to the web page contents, and what exactly is done with the sensitive data once it is saved on the web site. How secure are the information systems and subsequent processes?

Fix and verify.

Conclusion

Other public and private sector organisations take note. It will be interesting to see the outcome of the ICO investigation and whether this incident leads to a change in attitude, or even sets a precedent for online data protection requirements.

SSL has its problems, see here, here and here, but it would be wrong not to implement it. After all we've been using it for over ten years to help protect credit card data in online shopping; information from children about possible offenders is an order of magnitude more important than payment card data.

I just hope some of the statements that appeared in the BBC article about SSL were misinterpreted, and don't become the accepted understanding. CEOP please set the record straight.

SAFECode, a non-profit organisation of some of the major software vendors, has published the second edition of their Fundamental Practices for Secure Software Development: A Guide to the Most Effective Secure Development Practices in Use Today.

The updated and extended 2nd edition is a significant improvement on the previous version, but focuses only on secure design, secure coding and testing stages of development, as well as some separate recommendations concerning technologies. The previous information on training and secure code handling no longer form part of this paper, as they are addressed in other SAFECode publications. Thus the paper concentrates on what SAMM would consider to be constuction and verification functions, and not the governance or deployment functions. But the SAFECode document provides more prescriptive, detailed advice than SAMM. Perhaps only the three secure design principles (threat modelling, use of least privilege and implement sandboxing) are most similar in concept to SAMM's level of granularity; the remaining items would fit well within secure coding guidelines for developers.

Helpfully, the principles, practices and & have been cross-referenced with the Common Weakness Enumeration (CWE) list of software weaknesses, and links to verification resources such as references, tools and tutorials have been provided. It is also probably worth reading the SAFECode paper in conjunction with other guidance on application security programmes e.g. those mentioned previously here and here.

SAFECode has asked for comments and contributions.