BT has announced a trial of its Carrier-Grade Network Address Translation (CGNAT) where Internet Protocol (IP) addresses will be shared between subscribers.

Concerns have been expressed about the ability for some application to work if they rely on the assumption that IP addresses are unique, and also how this affects the identification of individual people.

Out-law.com provides a good review of the issues and information from BT, but links to the sources are not provided. BT has apparently stated they will still be able to identify individuals despite using CGNAT.

But the issue of identification does not only relate to newsworthy "illegal online activity" but also for wider privacy protection of completely legal activity where it is clear that IP addresses really must be considered as personal identifiers, especially when they can be combined with other data sets. Something to be considered in privacy impact assessments.

The UK's Information Commissioner's Office (ICO) Head of Policy, Steve Wood, recently discussed the issues around data anonymisation on the ICO blog. Anonymised data is information that does not identify any individuals, either in isolation or when cross referenced with other data available, and he suggested the need to develop an effective and balanced risk framework for personal data anonymisation to protect privacy and yet provide opportunities to exploit the data.

Anonymisation is another technique that can be used to reduce the risk from the loss or unauthorised access to personal data, along with data minimisation, pseudonymisation, aggregation, masking, encryption and tokenisation.

Following the ICO's public consultation earlier in 2012, a new code of practice has been issued under the Data Protection Act that focuses on managing the data protection risks related to anonymisation. Anonymisation: Managing Data Protection Risk Code of Practice intends to assist organisations that need to anonymise personal data, identifies the issues to consider, discusses whether consent is required, confirms there are fewer legal restrictions on anonymised data, and describes the legal tests required under the Data Protection Act.

The code provides guidance on a decision making process to help when considering the release of anonymised data that includes establishing a process to take into account the:

• likelihood of re-identification being attempted
• likelihood the re-identification would be successful
• anonymisation techniques which are available to use
• quality of the data after anonymisation has taken place and whether this will meet the needs of the organisation using the anonymised information.

The key point behind the code is the need to make a risk-based decision, and this could form part of a privacy impact assessment.

I very much like the examples and case studies in the three annexes. The case study in Annex 1 includes an example of how the "scope of personal data" can be minimised in the same way the "scope for PCIDSS" can be. In the latter, the storage of encrypted card holder data by an organisation that does not have access to the encryption keys can be deemed out of scope of PCIDSS requirements. In the code's case study, the partial redaction of data, means the originating organisation must still consider the information as personal data (because it has the full version of the data, and the key to reverse the redaction), but another party that only has the redacted data set does not need to treat the information as personal data. Parallel compliance examples.

The section on governance, discusses the need for assigning responsibilities, providing staff training, having procedures to help identify difficult cases, keeping up-to-date with legislation, the use of privacy impact assessments, being transparent with the individuals concerned, reviewing possible consequences, and preparing for an incident when re-identification has occurred.

A very comprehensive report by the Boston Consulting Group, that assesses the value of digital identity, has been published by Liberty Global.

The Value of Our Digital Identity, describes consumers increasing awareness and desire for control and how user control increases the willingness of users to share data. The report highlights how unlike some commodities, as the volume and variety of digital data grows, so does its value. And this data explosion is being driven by digital services & media, online data transactions, the internet of things and the current boom in social media, In turn this can fuel economic growth.

The report attempts to define what digital identity is, quantifies the current and potential economic value of digital identity for organisations and consumers, identifies important trends and offers a set of guiding principles that could help responsible organisations benefit from the value of digital identity.

Topics included that may be of particular interest to those involved with application design and implementation include:

• Problems when there is a lack of transparency for users about how their personal data is collected and used
• The benefits of offering the right to be forgotten
• How the the form of consent should be based on the type of data requested
• The need for convenience (usability)
• Sector-specific variations in user behaviour
• The requirement to increase data security (and not just using technical controls)
• Why there should be flexibility in regulation to allow users to make their own choices
• How digital identity can be used to provide differentiation from competitors

The report suggests that organisations need to establish and promote a trusted flow of data, or otherwise there are significant lost opportunities for value generation. Read, digest and implement.

ENISA, the European Network and Information Security Agency, has published a report on the economics of privacy.

Study on Monetising Privacy - An Economic Model for Pricing Personal Information examines approaches used to analyse the interaction of personalisation, privacy concerns and competition between online service providers. The report describes existing work on the economics of privacy, discusses a theoretical model and the results of experiments to validate versions of different the model.

The research found that consumers are making economic decisions based on personal data exposure, but there is a need for flexibility from regulators and transparency in services, to enable a more efficient privacy market.

A new paper has been published by Joseph Bonneau, Sören Preibusch, and Ross Anderson of the Computing Laboratory at the University of Cambridge, which estimates the difficulty of guessing 4-digit Personal Identification Numbers (PINs).

In A Birthday Present Every Eleven Wallets? The Security of Customer-Chosen Banking PINs, the authors describe the history of PINs, standards & practices, and present a model to quantify resistance to guessing. The authors examined data on human-selected 4-digit PINs from two data sources and provide an analysis of the likelihood of a thief obtaining a wallet containing a bank card, which also has date-of-birth data, being able to guess the PIN.

And the conclusions? Well, banks (and others) should implement a blacklist of simple PINs, and no part of a person's date of birth should be allowed in the PIN which really means moving away from customer-chosen PINs.

In response to last month's proposals for reform to data protection legislation by the European Commission, the UK's Ministry of Justice has announced a call for evidence on the proposals.

The call for evidence is seeking information from data controllers, data processors, rights groups, information policy experts and others on what might be the impacts and benefits of the potential changes. The aim is to provide the Government with information it can use during the forthcoming negotiations relating to the proposed framework.

Let's hope this helps to develop a practical, workable framework. Whatever the outcomes, building privacy concerns into systems and processes from the start will reduce the subsequent administrative burden. Have your say now — rather than when it is too late. Responses can be submitted by post, email and using the online form to answer the questions:

• How will the proposals affect you, or the bodies you represent?
• Wherever possible we would like quantifiable costs and benefits and real-life examples of the potential impact of the proposals.

The call for evidence closes on 6th March 2012.

Having travelled to Dublin the day before the training courses begin at OWASP AppSec Europe 2011, I have had time to catch up on some reading in my accommodation at Trinity College.

Alexander Neumann, Johannes Barnickel, Ulrike Meyer of the IT Security Group at RWTH Aachen University have published Security and Privacy Implications of URL Shortening Services. The paper includes a thorough review of related work and their own research into the security and privacy risks of URL shortening services (USS).

The risks discussed include:

• redirecting people to malicious web sites
• exposure of "secret URLs" (by search engine or enumeration)
• tracking by the USS provider
• information leakage (via HTTP referer header)
• use to attack web sites
• loss of shortened URL
• SSL-only circumvention

The paper is a useful reference for undertaking privacy impact assessments (PIAs) relating to the use of USS, or for designing similar systems.

On a related topic, Elke Roth-Mandutz from Georg Simon Ohm University, is discussing "A Critical Look at the Classification Schemes for Privacy Risks" at AppSec EU this Friday morning.

I will keep you updated with the talks I attend on Thursday and Friday.

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.

After arriving in Dublin last night, I walked to Trinity College this morning and had a little time for a coffee and to greet people I knew before we moved into the lecture theatre.

Following the welcome to OWASP Ireland 2010 by Eoin Keary, Fabio Cerullo & Rahim Jina of the OWASP Ireland Board, John Viega delivered a thought-provoking keynote speech on "Application Security in the Real World". John described real-world problems and approaches to application security need to prove their value. He described seven practices: awareness & training, assessments & audits, development & Q&A, vulnerability response, operational security, compliance and security metrics which, when applied appropriately can demonstrate a return on investment.

OWASP Board members Eoin Keary & Dinis Cruz provided an overview of OWASP's current status, its activities including many of its projects and of the global committees. They described how OWASP's mission "is to make application security VISIBLE for buyers and INVISIBLE for developers". Samy Kamkar was given a brief slot to describe how cross site scripting (XSS) can be used against user's routers to eventually gain the MAC address and ultimately a user's geolocation using Google data.

After a short break and opportunity to look at the sponsor booths, the conference split into two streams for the rest of the morning. Fred Donovan spoke on the topic of "Counter Intelligence as a Defense", describing how gathering information and taking approved action can help identify, assess and potentially neutralise threats to an organisation's ability to conduct business, and to enhance the protection of corporate assets and customer data. He also described sources of information including web application firewalls (WAFs), server logs, application logs, the media, list servers, MITRE, honeypots and from the source of the threat itself. some of the impediments and do's and dont's in this pro-active approach.

Ryan Berg gave a lively and fast-paced description on the "Path to a Secure Application". He described what isn't working, and the need to mitigate the damage that attackers can do, rather than assuming you can keep them outside your network, He provided numerous examples of how security can be built into to all stages of the software development process, but made the point that organisations should make efforts to improve their existing application development processes, rather than creating new ones.

Dan Cornell described how Android and iPhone smartphone applications are coded, deployed and, how and when the source code can be reverse engineered. He presented an example Android application and some tools to demonstrate how embedded URLs, file paths and host names can be extracted to help determine its workings. He recommended that, like other applications, smartphone applications should undergo threat modelling, care should be taken on what information is stored and where, and to be careful when consuming any third-party services, and ensure that enterprise web services are approved and deployed securely.

After lunch which was held in the beautiful Dining Hall of Trinity College Dublin, Professor Fred Piper (Royal Holloway College) presented the second keynote on "The changing face of cryptography". Prof Piper described that people do not need to attack algorithms when they can attack the implementation or cryptographic system instead. He provided an engaging and personable talk about algorithms, implementation weaknesses, real-life cryptography and the related political and social issues, clearly demonstrating his wide and deep knowledge.

Tyler Shields' presentation "Application Security Scoreboard in the Sky" described the results from Veracode's State of Software Security, which I have discussed before but is worth remembering as a good source of information when building business cases for secure development processes. The first volume had examined the differences between open source, commercial and out-sourced software. The second volume is due to be released in the next fortnight.

Rory Alsop & Rory McCune (co-chairs of OWASP Scotland) "The 'Real' Application Security Pentest." described why penetration test companies and purchasers of their services need to understand the requirements clearly and to make best use of the budget. They described that penetration testing is increasingly being used but there are inconsistencies in how it is undertaken and customers don't always receive what they want. The speakers described common myths and what buyers should do.

Vinay Bansal and Martin Nystrom jointly presented Cisco's experiences of "How to Defend Fragile Web Applications". Cisco know they are constant attack on their perimeter, but they have to concentrate their resources on defending DMZ & internal systems and minimising the damage from compromises. Cisco use architectural assessments, developer training, secure coding techniques, verification practices and more recently using web application firewalls (WAFs) in a reverse proxy mode using Apache httpd, ModSecurity and ModProxy. They described the problems and benefits of using WAFs in front of Cisco's tens of thousands of applications, and how they are trialling using the WAFs for virtual patching, where the applications cannot be modified.

The final keynote "Hackers and Hollywood: The Implications of the Popular Media Representation of Computer Hacking" was presented by Damian Gordon (School of Computing, Dublin Institute of Technology). Damian gave a light-hearted look at "Hackers and Hollywood: The Implications of the Popular Media Representation of Computer Hacking". He has researched whether or not movies accurately portray hackers and the implications of that portrayal, based on filtering 200 potential movies down to 50 clearly relating to computer hackers and not just cyberpunk, sci-fi or where hacking is only a peripheral activity. The conclusion? Movies are doing quite well but are missing out on some hacking features such as denial of service, phishing, organisation identuty theft and e-harassment of employees. Maybe next year?

Congratulations for a very successful and informative day to all the organisers, helpers and speakers. A little late, but off to the social event...

A few weeks ago I mentioned two new research papers about the use of passwords on website. Another new paper from Microsoft Research and Harvard University discusses how to avoid, and protect web sites from, users selecting popular passwords.

The paper Popularity is Everything: A New Approach to Protecting Passwords from Statistical-Guessing Attacks describes online and offline threats and defences against the sue of common popular passwords.

Password implementation policies can be guided by legacy approaches and various standards, but as mentioned previously, economics plays a large part too. Following a much publicised successful brute force against Twitter accounts, the company increased its password requirements. But rather than forcing passwords to be more complex, they instead took the decision to prevent the use of 370 common passwords. Whilst the list is culturally-biased, due to other breaches, there is similar data from other sites (e.g. here and here). But how does banning popular passwords help, and if the lists of common passwords are known, does this matter?

Firstly I'll mention here a couple of typical online tools for determining password complexity:

• Password meter providing an indication of complexity
• Hammer of God providing an estimate of how long it would take to obtain the password using a brute force attack

Don't put your real passwords into these sites or any other checkers! But these types of tools do not take into account popularity (e.g. '123456') or common manipulations (e.g. is 'P@ssword' really that much more secure than 'password'?). If attackers try popular passwords first (i.e. a dictionary attack), the time to break into a user's account may be much shorter.

The research paper, which does include some mathematics, suggests that simple passwords should be allowed providing they are not subject to statistical guessing attacks and proposes attack detection methods.

Good reading and inspiration for password-based authentication systems. I'm off to the station now, to get a train to Newcastle which was cancelled last night.