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.

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.

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.

Common Event Expression (CEE) Architecture Specification version 0.6 has been published for comment.

As noted noted in June, CEE defines the structure and components comprising the community-developed event log standard that intends to be industry accepted and practical. The following v0.6 documents were released on 26th August 2011:

• CEE Architecture Specification v0.6
• CEE Profiles Specification
• CEE Common Log Syntax (CLS)
  • CLS Encoding: JSON
  • CLS Encoding: XML

I will be having a read through these to see how they can be applied to application logging in some upcoming projects.

Feedback is sought on these documents using the CEE Email Discussion List or by email to cee@mitre.org.

Whilst on the theme of the privacy protection, this afternoon I attended the launch of the Information Commissioner's Office (ICO) Data Sharing Code of Practice, at the House of Commons.

If you remember there was a public consultation at the end of 2010, and the final document is now complete. I contributed to my company's written response, as well as to a response by OWASP on the security aspects of data sharing.

The event was sponsored by John Leech MP, Alun Michael MP and Dominic Raab MP, and the new code of practice was introduced eloquently by the Information Commissioner, Christopher Graham. He made the important point that the ICO is about enabling safe use of personal data, and that blocking the use of personal data is not its role. In fact, consumers and citizens can benefit from transfers and sharing of their data — it just has to be done legally. He described the guidance as "making sense on paper, and in the real world".

Note this is statutory guidance which has therefore been approved by the Secretary of State and laid before Parliament. It does not impose new legal obligations nor is an authoritative statement of the law. But both courts and the Information Commissioner must take into account the contents of the code when determining any question arising from proceedings, or functions being performed by the ICO under the Data Protection Act (DPA).

It applies to all sectors — public and private — although there is some sector-specific guidance included. Importantly it applies to both routine systematic data sharing as well as one-off data sharing tasks. The guidance notes data protection principles also apply to the sharing of information within an organisation, such as between divisions, departments and teams. Examples and case studies used in the document include "a retailer providing customer details to a payment processing company", "a mobile phone company intends to share details of customer accounts with a credit reference agency" and "a marketing company wants to share data with a fulfilment company so it can send out free samples". Practical, yes.

I was interested to read the new document to see what changes had been made in the period since the consultation. The draft document was quite good, but the final guidance is an order of magnitude better. It looks as though considerable re-writing, greater explanation, and addition of a glossary and quick-reference checklist have improved its content and usability. Additionally, I am pleased to see many more practical private-sector examples have been included throughout the main body, and in the case studies in Annex 3.

In terms of information security, the primary aspects are detailed in Section 7, which lists good practice to take in respect of information shared with other organisations, highlights the need for building a security-aware culture, identifies the need to take reasonable steps to ensure the receiving organisation understands the nature and sensitivity of the information, the need to consider all modes of transmission, and provides two short lists of physical and technical security measures to be considered. One which stands out in particular is:

Well, that's quite specific! And, good advice.

So, data controllers take note. If you are involved with specifying or designing online (or other) business systems, read the whole document — it really will help. The code of practice does not itself have the force of law (the DPA does), but it describes good practice, and the ICO can only take enforcement over breaches of the DPA. But as the guidance says doing nothing, risks breaking the law.

The whole structure of the document is:

1. Information Commissioner's Foreward
2. About this code
3. What do we mean by "data sharing"?
4. Data sharing and the law
5. Deciding to share personal data
6. Fairness and transparency
7. Security
8. Governance
9. Individual's rights
10. Things to avoid
11. The ICO's powers and penalties
12. Notification
13. Freedom of Information
14. Data sharing agreements
15. Data sharing checklists

The annexes are:

1. The Data Protection principles
2. Glossary
3. Case studies

Coincidentally today a potential £200,000 penalty was imposed by the ICO for a recent web site personal data loss, and the full amount was only avoided because the sole trader had already ceased trading.

The code of practice has not yet been published on the ICO web site. I will check again tomorrow morning.

Update 11th May 2011: The ICO has now announced and published the Data Sharing Code of Practice and checklists on their web site.

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.

What will be your new year's resolution? I would like to suggest a work-related one should be "implementing proper application logging" for web products.

Construction sites and manufacturing facilities routinely publish safety statistics such as "hours since last lost time incident", "number of man hours worked without a reportable accident" and other performance metrics. How about "days since last vulnerability exploited" or "days since last vulnerability reported"?

Without good application logging, you do not know the real performance of your system, whether there have been attacks, what suspicious activity has been occurring. You also will not have much information to examine to determine the cause of previous problems, generate meaningful security metrics, or build feedback mechanisms to improve security.

Put it near the top of the "to do" list for 2011. And have a good, safe & secure night!

Online behavioral advertising continues to be in the news (see also previous here, here and here). The US Federal Trade Commission (FTC) has now issued a preliminary staff report which has been widely discussed (including here, here, here and here.)

The FTC's work was prompted by the lack of success with "notice-and-choice" and "harm-based" models to provide adequate and meaningful consumer protection, despite various industry initiatives such as self-regulation. The FTC report proposes a new framework and suggests organisations should adopt a privacy-by-design approach in their information systems and business processes, provide greater clarity in explaining their use of personal data and, for practices that are not "commonly accepted", provide information so that people can make informed and meaningful choices. One example of this, and the aspect which seems to have the most attention, is the ability for consumers to make a universal choice whether they allow their data to be used in behavioural advertising i.e. have the ability not to be tracked. And the FTC suggests organisations need to make their actions more transparent, and also help in the effort to educate consumers.

Note, the FTC document refers to "consumers" due to their area of responsibility, but the concepts could/should also be relevant to other personal data (e.g. employees, citizens).

But what does "no tracking" mean? There are already some initiatives in this area (e.g. the Network Advertising Initiative (NAI) Opt-out Tool and the Interactive Advertising Bureau (IAB) Self-Regulatory Program for Online Behavioral Advertising). The FTC has testified that the mechanism should be browser based allowing consumers to opt out easily and permanently. There has been debate about how "Do Not Track" might be achieved online, and a suggestion is organisations honour a new HTTP header. The "X-Do-Not-Track" header would be sent if the user (consumer?) had set this as their preference (or not deselected it?). See http://donottrack.us/ for more discussion.

Tracking might involve cookies and recording data such as the type of device, configuration, user location & IP address, and using this to serve targetted "behavioural advertising".

Cleaning your own web server log files of tracking data is not going to be enough.

Any system that receives HTTP requests, including advertisers would have to honour the setting. But this does not just apply to advertisements. Look for anything hosted on another system such as:

• inline content (news, images, videos)
• JavaScript libraries
• trust seals (e.g. SSL certificate verification, privacy seals, trust schemes, tested for security, etc)
• web analytics
• widgets (e.g. buttons).

And these might be server from your own systems, not just third parties. Personal data may also be stored by the application on the user's own system locally. The question also arises what exactly constitutes "tracking", and whether audit and security event logs would be considered as tracking. Even traffic management and anti denial-of-service (DoS) systems track users to a degree, as of course does session management. Practices necessary to perform the designated service are likely to be acceptable, providing data are not kept indefinitely, and it is the usage for purposes which the user might not have expected, which is the real concern. Do users "expect" seceuity event logging? The examples on the http://donottrack.us/ discuss prevention of logging in web server log files, not other usages such as session management or incident monitoring. So guidance will be required.

The issue of tracking and personal data leakage may come as a surprise to some web site owners, and it was to the NHS, but is rather old news really. Like knowing all the components that make up your web site, and all the allowable entry points, knowing where you are sending data really is a baseline information requirement. The NHS example relates primarily to leakage of sensitive data to other parties, and the Obama example to security risks (see extended explanation.) The results of the FTC's final report next year will affect internet users worldwide as similar policies are likely to be adopted in other countries.

The FTC is asking for comments on its proposals by 31st January 2011. Their own suggested questions are listed in Appendix A of the report.

The Center for Internet Security (CIS) has announced and published an update (v1.1.0) to the Consensus Security Metrics; I discussed the previous version (v1.0.0) last year. As with the previous version, the aim of the document is to allow organisations to collect, analyse and share data on security performance and outcomes.

This version has no new Application Security metrics, but additional collection data attributes have been defined for technologies, business applications including status, risk assessments, security testing and completely new attributes for the current mitigation status of weaknesses discovered. There is also a new diagram showing the relationship between the various data attributes.

As mentioned above, the actual metrics are essentially unchanged, although the table for "Number of Applications" appears to be missing in the new document, and "Security Testing Coverage" is included but omitted from the contents list.

The Consensus Security Metrics includes more than suggested metrics for Application Security—there are a range of management, operational and technical metrics for Incident Management, Vulnerability Management, Patch Management, Configuration Management, Change Management and Financial Metrics. A new Quick Start Guide has also been produced by CIS to help organisations understand and implement the metrics. The document is a good if you are considering the introduction of security metrics, but be aware that metrics have a tendency to distort normal behaviour, especially if they have an affect on people's performance measurement too. Do remember to read "Security Metrics - Replacing Fear, Uncertainty, and Doubt" (ISBN: 0321349989) by Andrew Jaquith—he has a refreshing viewpoint on security metrics. Also see the information and resources at http://www.securitymetrics.org and https://www.metricscenter.net/.

As a related note, at last week's AppSec Washington DC 2010, Rafal Los presented a passionate suggestion for Five KPIs for Web Application Security Programs, which he had previously announced in a webcast in October. There was plenty of discussion at AppSec DC about these and it will be interesting to see how they firm up, and whether they can be incorporated into the CIS Consensus Security Metrics.