07 July 2015

Data protection

Posts relating to the category tag "data protection" are listed below.

12 August 2014

Application Security Verification Standard 2.0

Application Security Verification Standard (ASVS) for web applications version 2.0 has been published by OWASP. The ASVS standard provides a basis for verifying application technical security controls, as well as any technical security controls in the environment that are relied on to protect against application security vulnerabilities such as Cross-Site Scripting (XSS) and SQL injection.

Partial view of a page from the OWASP Application Security Verification Standard 2.0

ASVS Web Application Standard 2.0 has been comprehensively reviewed, reassessed and updated primarily by Sahba Kazerooni, Daniel Cuthbert, Andrew van der Stock and Krishna Raja, along with a dozen or so other contributors and reviewers.

The standard can be used to define application security requirements based on an assessment of risk, and to assist application security verification activities. Three new classes of requirement have been defined that did not exist in the previous 2009 edition:

  • V15 Business Logic verification requirements
  • V16 Files and Resources verification requirements
  • V17 Mobile verification requirements.

Furthermore, the following classes no longer exist, to focus on the application requirements, and also due to the merging of encoding/escaping within the input validation section:

  • V1 Security Architecture documentation requirements
  • V6 Output Encoding/Escaping verification requirements
  • V12 Security Configuration verification requirements
  • V14 Internal Security verification requirements.

For organisations already using the previous version, the numbering of matching requirements has not changed, but it does mean that there are also new requirements within each section, and some gaps in numbering where a previous requirement has been removed.

The standard defines verification requirements for three levels of verification, labelled opportunistic, standard and advanced. Appendix A of the document provides some example scenarios for the ASVS level that might be used for different industry sector.

If you have only read the OWASP Top 10, ASVS should be your next read. Expect to see mappings from ASVS 2.0 to the OWASP Testing Guide.

Posted on: 12 August 2014 at 17:38 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

29 June 2014

Right to be Forgotten

In mid-May, the European Court Of Justice ruled that Google must respect the "right to be forgotten".

I do believe the ruling exposes an imbalance in current Data Protection legislation that warrants attention. I also believe it raises the bar for all organisations that put people's personal data online.

If you are looking for clarity and a considered assessment of the court's judgement, information risk and security expert John Leach has published a well considered paper on the topic.

Look out for future Right to be Forgotten (RtbF) requests, and have processes in place to handle them.

John Leach and I worked together to research and write the ICO report Privacy Dividend in 2010.

Posted on: 29 June 2014 at 21:22 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

06 June 2014

High Street Spam Alert

Not all spammers are based abroad. Some are a lot closer to home than you might think. High Street retailer John Lewis has lost a court case, costing it dearly for spamming an individual called Roddy Mansfield who had browsed, but not bought from, related company Waitrose.

Photograph of a locked letter box with the label 'ISG POST' on it

The case was brought under the Privacy and Electronic Communications Regulations. Sky News, where Roddy Mansfield works as a producer, announced the decision. The damages are not yet confirmed.

John Lewis' defence seemed weak and contrary to the legislation which requires opt in, not opt out. It looks like they shot themselves in the foot. Perhaps time to update the terms and conditions here and here, and to retrain the lawyers. Maybe they should read this. The Direct Marketing Association (DMA) also seems to have put its foot in it.

More opinion and comments at The Register.

Do you know the consent status of all your marketing recipients, whether your own direct customers or obtained from other sources? Perhaps worth checking?

Posted on: 06 June 2014 at 04:35 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

03 June 2014

Personal Data Protection in Online Systems - Part 2/2 Security Controls

Yesterday I described the new report from the ICO, Protecting Personal Data in Online Services: Learning From the Mistakes of Others. Below is a list of the matching security controls for each issue mentioned in the report.

Examining the ICO report in greater detail, provides additional clues about the requirements expected in each class of vulnerability. The report "is not aimed at experienced security professionals", but rather at those responsible for the security of the online systems, and hopefully this list will be useful to those individuals.

My breakdown of the matching security controls, based on my interpretation of the report's text, are listed below.

Issue from ICO Security Report Derived Security Controls
Failure to keep software security up to date
  • Create and maintain a policy for software patching
  • Maintain a list of all software, including components (e.g. third-party libraries, frameworks), their versions, source and method of monitoring for security patches and other updates
  • Define who is responsible for the patching of each software component
  • Create, use and maintain a procedure for assessing security patches and other software updates, that includes a risk assessment
  • Apply software security patches in a timely manner
  • Do not use software that is no longer supported by the supplier/vendor/development company; or limit its use and undertake a risk assessment and apply additional controls
  • Create, maintain and operate a process for checking that security patches have been applied to all software components, or those that have not been applied have adequately justified, documented and applied mitigating controls
Lack of protection from SQL injection
  • Create and maintain a process for other people and organisations to report security issues about your applications
  • Create and maintain a procedure for assessing and fixing security flaws in custom application code, and include these issues in the software patching documentation (see above), and if SQL injection is found in one place, examine similar code elsewhere
  • Identify who is responsible for preventing SQL injection in each custom coded application (e.g. software such as websites developed by/for the organisation)
  • Require the default to be to use the safest server-side method for database queries supported by the API or framework
  • Ensure the prevention, detection and remediation of SQL injection vulnerabilities are included at multiple stages of the software development lifecycle (e.g. coding standards, peer/independent code review with audit trail, automated code review, automated vulnerability assessment, penetration testing before going live)
  • Use the software patching policy and processes (see above) for software components used by the custom applications
  • Include a requirement in contracts with third party development to build security into their development practices and inform you when they become aware critical vulnerabilities like SQL injection, and then provide patches
  • Use automated application vulnerability assessments (scanning) to help identify SQL injection, but ensure these cover all the application (e.g. for authenticated customers and administrators too)
  • Undertaking penetration testing in the production/live environment of custom-built applications (external and internal-facing) that interact with databases and other data stores, and repeat periodically
Exposure of unnecessary protocols & services
  • Do not use insecure protocols such as Telnet and plain FTP
  • Implement access control for all protocols (e.g for secure FTP disallowing anonymous access, preventing SMTP being used as an open relay)
  • Use firewalls to prevent external access to internal services
  • Remove, disable or block un-necessary services (see also decommissioning below)
  • Limit remote access to trusted IP addresses and enforce access using an encrypted method
  • Segment services so that a compromise of one does not lead to wider system compromise
  • Consider using a Virtual private Network (VPN) using strong credentials (such as two-factor authentication) for all remote access
  • Scan ports of all system components periodically to verify that only the intended services are available externally, internally, and from particular other locations
  • Document and periodically review all the services allowed
Exposure of decommissioned software/services
  • Maintain a schedule of all software/services in use
  • Ensure all system components (hardware, software, configuration files, databases, files, services, ports, DNS records, etc) are decommissioned when no longer needed, and maintain a record of how this was undertaken
  • Test/audit that decommissioned components no longer exist and cannot be accessed
  • For hardware disposal, ensure data is securely removed
Insecure storage of passwords
  • Create and maintain a password policy for all types of system users
  • Encourage, and allow, users to choose stronger passwords
  • Discourage users from having the same password on multiple systems
  • Discourage or prevent commonly used passwords
  • Never store or send passwords in plain text
  • Never encrypt passwords unless there are extremely robust key protection and key management processes in place
  • Use one-way hashing of passwords with a long salt value, unique for each user
  • Use a hashing method that is slow (e.g. PBKDF2, bcrypt or scrypt)
  • Do not use weak hashing methods such as MD5 or SHA-1
  • Review hashing best practice periodically, and build in considerations to allow future changes to the hashing method
  • Ensure password breaches are included in incident report planning
Failure to encrypt online communications
  • Identify and record all information that should be encrypted in transit
  • Ensure the encryption method (e.g. SSL/TLS) is configured correctly and that certificate are valid
  • Maintain a list of all certificates and ensure they are renewed before expiry
  • Consider using Extended Validation (EV) digital certificates to provide a higher level of identity assurance to users
  • Do not use SSL v2, and preferably enable TLS 1.2), disable weak ciphers (i.e.enable ciphers with 128 bi strength or greater) and avoid weak ciphers (e.g. RC4) or those that provide no encryption or no authentication i.e. null ciphers)
  • Ensure the information cannot be accessed without encryption
  • When web pages are sent over SSL/TLS, ensure every single component in the page (e.g. images, style sheets, scripts and third-party hosted content) is also sent over SSL/TLS
  • Never send session identifiers (e.g. cookies identifying an authenticated user) over unencrypted connections
  • Ensure SSL/TLS websites are only accessible by hostnames included in the certificate, and not by IP address)
  • Consider making websites completely "SSL/TLS only
  • Review transport encryption best practice periodically and update configurations as required
Processing data in inappropriate locations
  • Identify and maintain an inventory of all locations where personal data is stored, processed and transmitted
  • Do not allow unauthorised access (e.g. public access) to personal data
  • Do not use production data in development and test systems
  • Incorporate personal data access into systems design processes
  • Use network segmentation to assist with limiting access to personal data (e.g. segregate non production systems, segregate teams or departments with access to sensitive personal data)
  • Use redundancy/diversity to protect against accidental loss or destruction of, or damage to, personal data
  • Create and maintain policies for the storage, processing and transmission of personal data
  • Create, maintain and use procedures for transfers of personal data
  • Do not place copies of personal data in unprotected locations
  • Enforce appropriate access control in custom applications (e.g. websites)
  • Provide training about the access, use and transfers of personal data
  • Monitor transfers of personal data
Use of default credentials including passwords
  • Change all default passwords across all system components
  • Disable or remove guest and demonstration accounts
  • Use strong passwords to replace default ones (see above)
  • Avoid hard coding of access credentials (and never in software code), but use encryption if possible if necessary to store elsewhere (e.g. configuration files)

So, not such a short list. It is a combination of technical, administrative and physical controls, and not just applicable to online systems, but all electronic systems that store, process and transmit personal data, and generally regardless of whether it is sensitive personal data or not.

Posted on: 03 June 2014 at 07:48 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

02 June 2014

Personal Data Protection in Online Systems - Part 1/2 Security Vulnerabilities

The UK's Information Commissioner's Office (ICO) published a report in mid May about the most common classes of IT security vulnerabilities in online systems that result in failures to secure personal data.

The cover from the ICO report

The seventh data protection principle requires organisations to take appropriate measures to safeguard personal data. It states "Appropriate technical and organisational measures shall be taken against unauthorised or unlawful processing of personal data and against accidental loss or destruction of, or damage to, personal data".

Protecting Personal Data in Online Services: Learning From the Mistakes of Others describes the issues most commonly found to have been the root causes of inadequate protection of personal data in online systems.

There are some issues clearly related to poor management control such as incorrect decommissioning of business processes and inappropriate locations for processing of data. The other issues are more technical but are all the types of things well-organised and careful organisations ought to be getting right already.

I was interested to check which of these relate to infrastructure (I/S) components and which to applications (Apps). For the latter, also whether the latter appear in the OWASP Top Ten most critical risks.

Issue ICO Security Report Component OWASP Top Ten 1013
I/S App
Failure to keep software security up to date Y Y A9 Using components with known vulnerabilities
Lack of protection from SQL injection Y A1 Injection
Exposure of unnecessary protocols & services Y - -
Exposure of decommissioned software/services Y Y - -
Insecure storage of passwords Y A6 Sensitive data exposure
Failure to encrypt online communications Y Y A6 Sensitive data exposure
Processing data in inappropriate locations Y - -
Use of default credentials including passwords Y Y A5 Security misconfiguration

We can see there is a mixture of infrastructure and application security issues, and that some issues span both of these categorisations.

Simon Rice, ICO Group Manager, blogged about the release of the report, password storage, SQL injection, and answers questions about the report in a video interview.

Tomorrow, I will list the security controls for each issue, as discussed in the report.

Posted on: 02 June 2014 at 07:40 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

16 May 2014

Media Use and Attitudes 2014

OFCOM, the UK communications sector's regulator and competition authority, has announced its updated report on adults' use of media and attitudes. Partial view of one of the many charts from the OFCOM report Adults' Media Use and Attitudes Report 2014

Adults' Media Use and Attitudes Report 2014 (complete 95 page print version and TV/internet audience size annex) reviews facts and trends about media usage, devices and knowledge by age group. But sections "5.5 Media Regulation" and "6 Online Safety and Security" are most on topic for here. Some headlines from the report:

  • A quarter of adults (27%) believe that mobile content is regulated, and almost a half (46%) believe that the internet is regulated in terms of what can be shown and written
  • Seven in ten internet users feel that the websites themselves should monitor their content to avoid offensive content being posted by individuals
  • A majority of internet users trust government/ council websites (61%) and commercial websites and apps (59%) to hold their personal information securely
  • A majority (57%) of internet users use the same password for most websites
  • Awareness and use is higher for anti-virus software and firewalls and lower for email filters, home WiFi protection, deleting cookies from browsers and anti-spyware.
  • a majority of mobile phone users say they are aware of: screen locks (86%), PIN protection of SIM cards (68%), and software to help locate a lost phone (53%)

See also OFCOM's equivalent report from last year.

Posted on: 16 May 2014 at 07:30 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

18 April 2014

Data Subject Breach Notification and Privacy Impact

The EC Article 29 Working Party has published an opinion offering guidance to data controllers to help them to decide whether to notify data subjects in case of a personal data breach.

Photograph of a large crowd of people

Opinion 03/2014 on Personal Data Breach Notification provides advice to telecomms companies subject to mandatory breach notification under Directive 2002/58/EC. Whilst most readers of this blog will not work in this sector, the guidance itself is useful for consideration in any sector.

The opinion recommends organisations should be proactive and plan appropriately. It illustrates the effects of confidentiality, integrity and availability effects on personal data and the impact upon individuals.

The document recommends that all the potential consequences and potential adverse effects on individuals should be examined, and that data breaches should be notified to the data subjects in a timely manner, if the breach is likely to adversely affect the personal data or the privacy of the data subjects.

See also the Information Commissioner's Office (ICO) guidance on Incidents and breach notification.

Posted on: 18 April 2014 at 08:43 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

09 April 2014

Third-Party Tracking Cookie Revelations

A new draft paper describes how the capture of tracking cookies can be used for mass surveillance, and where other personal information is leaked by web sites, build up a wider picture of a person's real-world identity.

Title page from 'Cookies that give you away: Evaluating the surveillance implications of web tracking'

Dillon Reisman, Steven Englehardt, Christian Eubank, Peter Zimmerman, and Arvind Narayanan at Princeton University's Department of Computer Science investigated how someone with passive access to a network could glean information from observing HTTP cookies in transit. The authors explain how pseudo-anonymous third-party cookies can be tied together without having to rely on IP addresses.

Then, given personal data leaking over non-SSL content, this can be combined into a larger picture of the person. The paper assessed what personal information is leaked from Alexa Top 50 sites with login support.

This work is likely to attract the attention of privacy advocates and regulators, leading to increased interest in cookies and other tracking mechanisms.

The research work was motivated by two leaked NSA documents.

Posted on: 09 April 2014 at 10:02 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

04 April 2014

Regulation of Software with a Medical Purpose

I seem to have a series of regulation-related posts at the moment. Perhaps the time of year. An article on OutLaw.com discusses how mobile apps and other software medical purpose may be subject to regulation.

Photograph of shelves in a shop displaying rows of medications

The UK's Medicines and Healthcare Products Regulations Agency (MHRA) is responsible for regulating all medicines and medical devices in the UK by ensuring they work and are acceptably safe. It has issued new guidance on "medical device stand-alone software (including apps)" which is defined as "software which has a medical purpose which at the time of it being placed onto the market is not incorporated into a medical device". Thus "software... intended by the manufacturer to be used for human beings for the purpose of:

  • diagnosis, prevention, monitoring, treatment or alleviation of disease,
  • diagnosis, monitoring, treatment, alleviation of or compensation for an injury or handicap,
  • investigation, replacement or modification of the anatomy or of a physiological process,
  • control of conception..."

Guidance on Medical Device Stand-alone Software (Including Apps) describes the scope, requirements and software-specific considerations. Product liability and safety considerations are also mentioned.

This introduces the potential need for registration, documentation, self-assessment, validation, monitoring and incident reporting, especially if the software performs any form of diagnosis or assessment. The OutLaw.com article provides a good analysis and views from experts.

Posted on: 04 April 2014 at 10:11 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

31 March 2014

Regulator Weighs into the Consumer Software Sector

The US Federal Trade Commission has brought two companies to task over inadequate data protection in their mobile apps.

The settlements require Fandango and Credit Karma to establish comprehensive security programs designed to address security risks during the development of their applications and to undergo independent security assessments every other year for the next 20 years. The settlements also prohibit Fandango and Credit Karma from misrepresenting the level of privacy or security of their products and services.

In the proceedings against Credit Karma Inc, the complaint describes the company's website and mobile app which consumers can use to monitor and evaluate their credit and financial status. And, in the proceedings against Fandango LLC the complaint describes how the company has a website and mobile application that allow consumers to purchase movie tickets and view showtimes, trailers, and reviews.

The cases describe a number of problems with security but focus on how the apps had disabled SSL certificate validation leading to the possibility attackers could redirect and intercept network traffic, decrypt, monitor, or alter any of the information transmitted from or to the application, including personally identifiable information. The FTC also said the companies mis-represented the security of the apps to consumers.

The consent orders require the companies not to misrepresent how the apps maintain and protect the privacy, security, confidentiality, or integrity of information. Additionally they must establish and implement, and thereafter maintain, a comprehensive security program including in summary:

  • Designated employee to coordinate the security programme and be accountable for it
  • Assessment of security and privacy risks and safeguards that mitigate these
  • Security throughout the software development lifecycle including employee training and management; secure engineering and defensive programming; product design and development, secure software design, development, and testing; review, assessment, and response to third-party security vulnerability reports; and prevention, detection, and response to attacks, intrusions, or systems failures
  • Implementation, testing and periodic re-assessment of security controls, systems and procedures
  • Due diligence and assessment of service providers
  • Monitoring, review and improvement of the security programme.

Furthermore, these programmes are to be independently assessed initially and then biennially for 20 years by an independent third-party professional who is suitably qualified. The orders mention the assessor may be a "Certified Secure Software Lifecycle Professional (CSSLP) with experience in secure mobile programming; Certified Information System Security Professional (CISSP) with professional experience in the Software Development Security domain and secure mobile programming, or a similarly qualified person or organisation approved by the FTC.

It looks like the year for comprehensive security software development lifecycle initiatives such as Open SAMM, MS-SDL and the Bits Framework.

Posted on: 31 March 2014 at 09:11 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

More Entries

Data protection : Application Security and Privacy
ISO/IEC 18004:2006 QR code for https://clerkendweller.uk

Requested by 54.144.77.26 on Sunday, 2 August 2015 at 19:19 hrs (London date/time)

Please read our terms of use and obtain professional advice before undertaking any actions based on the opinions, suggestions and generic guidance presented here. Your organisation's situation will be unique and all practices and controls need to be assessed with consideration of your own business context.

Terms of use https://www.clerkendweller.uk/page/terms
Privacy statement https://www.clerkendweller.uk/page/privacy
© 2008-2015 clerkendweller.uk