Stakeholders in the US Department of Commerce's National Telecommunications and Information Administration (NTIA) have been discussing visibility of privacy notices and opt ins for mobile applications.

A meeting of the Privacy Multistakeholder Process: Mobile Application Transparency group in February reviewed feedback on a discussion draft on proposals for voluntary [privacy] transparency screens (VTS) in mobile apps. Mock-ups of the short notice screens were also presented.

The Mobile App VTS requires mobile app developers and publishers to [voluntarily] provide information about what data is collected from consumers, and details of any data sharing with third parties.

The group's next meeting is on 14th March 2013.

See also previous posts about Privacy and Terms of Use Labelling, Privacy, Labelling and Legislation, Privacy Labelling, Security Labelling, Software Assurance Labelling, Adverts and Privacy Notices, and Privacy Notices Code of Practice.

On Wednesday this week, Trustwave has published the full version of its latest global information security report. It is comprehensive, information-rich, and well designed.

2013 Trustwave Global Security Report (registration required) provides information from their incident investigations, updates from law enforcement agencies around the world (including SOCA), threat intelligence (attack sources, motivations, emerging techniques, attacks and defences), and some international perspective viewpoints. The sources used to aggregate data and draw conclusions from include their vulnerability scanning, penetration testing and incident response investigation services, publicly disclosed data breaches, email sources, published vulnerabilities, and analysis of malicious web sites. Even this cannot be said to be completely representative, but it is amongst the better data available.

Based on the incident investigation information, payment cardholder data was the primary target because it is highly saleable for subsequent use in fraudulent transactions. Secondly personal data is noted as having some monetary data. The primary targets were retail, food & beverage and the hospitality sector via their e-commerce and retail channels (web sites and point of sale/payment processing). These of course reflect organisations that are required to, or felt the need to, engage a company like Trustwave to perform incident investigation. Thus there will be a bias towards medium and larger organisations with personal, credit and debit card data.

Where large quantities of data were compromised, the incident investigations identified weak administrative credentials, SQL injection and remote file inclusion as the primary vulnerabilities, with data being exfiltrated using HTTP and HTTP over TLS, RDP, SMTP and SMB protocols due to missing egress firewall controls. The report recommends building a defence in depth strategy with multiple layers of security. In terms of important applications, a holistic approach that builds security in throughout the development and operation is required. In the section on international perspectives for EMEA, the report notes there is an increasing trend of medium-sized and non-banking organisations developing strategic application security programmes, where assurance activities are based on the business risk each application presents.

Information points from the WASC Web Hacking Incident Database are also presented. These relate to publicly reported incidents of web applications during 2012 that have an identified outcome. This does not pretend to be fully representative of all web application attacks, but it does represent many significant events. The most common attack methods were denial of service followed by SQL injection.

The top 10 application vulnerabilities (I believe the label on the table on page 50 possibly mistakenly includes the word "mobile") highlights how common cross-site scripting (XSS) and cross-site request forgery (CSRF) are, based on a sample of application penetration tests. Separate information is also presented for mobile application penetration tests, comparing the findings to the OWASP Mobile Top 10.

The other part of the report of interest to application software designers and architects is the statistical analysis of nearly 3.1 million encrypted passwords from Active Directory servers. In order of number of occurrences "Welcome1" is the most common password, followed by "STORE123", "Password1", "password", "Hello123", and "12345678". "training" and "Welcome2". "STORE123" sounds very like point of sale (POS) systems. These results and analysis of password composition and markup will be useful where there is a desire to limit the use of common passwords and formats.

Definitely worthwhile reading.

The SANS Analyst Program has published a white paper by Jim Bird and Frank Kim.

SANS Survey on Application Security Programs and Practices describes the results of a sponsored survey of 700 employees with responsibilities for security, management and software development. The aims of the survey were to identify the drivers for application security programs, the greatest risks, how resources are prioritised, what practices are being undertaken, which tools and services are used, programme challenges, and the maturity and effectiveness of the programmes.

Similar to the 2011 report from Forrester Research, the most import driver for application security programmes (secure software development life cycles) are regulatory/compliance requirements with Payment Card Industry (PCI), US Sarbanes–Oxley Act (SOX) and the US Health Insurance Portability and Accountability Act (HIPPAA) being the most common.

The comprehensiveness of application security programmes is reviewed for internally-developed, outsourced application development, and commercial off the shelf (COTS) applications. Apart from policies and vulnerability awareness, and risk assessments/due diligence of third parties, the survey primarily reports on technological controls and practices. These are static analysis code review, dynamic analysis (e.g. vulnerability scanning), manual penetration testing, and use of web application firewalls (WAFs) and using WAFs for virtual patching.

There is no mention of other practices that can contribute such as defining security requirements, producing guidance materials, training, design and architecture reviews, secure deployment (see more in the Software Assurance Maturity Model, BITS Software Assurance Framework, BSIMM, etc).

See also the related Application Security Gap Study and Protection Against Business Logic Attacks.

Two organisations have recently announced skill standards in the software security and wider information assurance areas.

The UK's The National Skills Academy has announced new draft IT National Occupational Standards (NOS) for information security. These are for:

• Information Security Risk Assessment and Management
• Secure Development and Information Security Architecture
• Information Security Testing and Information Assurance Methodologies
• Operational Security Management
• Incident Management, Investigation and Digital Forensics
• Information Security Audit
• Information Governance

Secondly, as part of the Build Security In Software Assurance Initiative, the US Department of Homeland Security's Office of Cybersecurity and Communications has announced its draft Software Assurance (SwA) Competency Model. This was developed to create a foundation for assessing and advancing the capability of software assurance professionals. The draft model is supported by other materials on the related Software Assurance Curriculum web site from CERT.

The current hot topic in the news is the revelation that horsemeat has contaminated the UK's food supply chain. This follows on from recent findings that suggest halal food supplied to some prison contained pork.

The outrage about eating horses and about retail products not containing ingredients other than those listed on the label has raised concerns about how the integrity of the food supply chain can be ensured. There is much more legislation around food standards (for example coffee and juice), and better labelling, but food appears to suffer from similar risks as the software supply chain.

Well there are usually no easy answers, but for once it seems the software assurance community is ahead of food standards. If you don't want unknown ingredients in acquired software code, take a look at:

• Notional Supply Chain Risk Management Practices for Federal Information Systems, NISTIR 722, Interagency Report, NIST, 2012
• Software Assurance in Acquisition and Contract Language, Software Assurance Pocket Guide Series, Software Assurance, US Department of Homeland Security, 2012
• Software Supply Chain Risk Management: From Products to Systems of Systems, Technical Note CMU/SEI-2010-TN-026, Software Engineering Institute, Carnegie Mellon University, 2010
• Evaluating and Mitigating Software Supply Chain Security Risks, Technical Note CMU/SEI-2010-TN-016, Software Engineering Institute, Carnegie Mellon University, 2010
• An Assurance-Based Approach to Minimizing Risks in the Software Supply Chain, SAFECode, 2010
• Framework for Software Supply Chain Integrity, SAFECode, 2009
• Software Supply Chain Risk Management and Due Diligence, Software Assurance Pocket Guide Series, Software Assurance, US Department of Homeland Security, 2009

For some light relief on the horsemeat story, see the jokes here and here.

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

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

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

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

The topic of information security is also addressed:

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

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

I just came across KPMG's review of information leakage from corporate web sites, published in September.

Hopefully nothing new, but the report sums up the typical state of configuration of many web sites. Most web sites leak information publicly which is useful to an attacker to craft their subsequent search for vulnerabilities. KPMG simply reviewed the public-facing resources on 2,000 companies, from a wide range of sectors, in the Forbes 2,000 list to identify many missing security basics.

Publish and be Damned, Cyber Vulnerability Index 2012 is a quick read; what can you expect to discover?

• Large number of sensitive file locations and "hidden" functionality such as administrative interfaces (with banking the worst affected sector)
• Exposure of sensitive information in millions of online forum and newsgroup postings (with software & services the worst sector)
• Thousands of web servers with missing security patches or out-dated software (with Japan, Switzerland and Kazakhstan the worst countries, and Utilities the worst sector)

How well would your organisation do?

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.

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

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

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

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

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

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

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

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

There's an intriguing new project aiming to raise awareness and increase understanding of information security.

The Analogies Project plans a series of initiatives to communicate contribution of information security to society. The first initiative will be a book showing the relationship between life, information and information security.

The founder Bruce Hallas will be speaking about the project at the next meeting of white-hats.co.uk tomorrow morning. Booking required.