28 April 2015

Data protection

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

07 November 2014

75,000 GBP Fine For SQL Injection From ICO But With 90% Discount

Lancaster-based apartment booking company Worldview Limited has been fined under the Data Protection Act for allowing unauthorised access to customers' details. The company operates under two UK brands, Citybase Apartments and Central London Apartments.

Although customers' payment details had been encrypted, the means to decrypt the information - known as the decryption key - was stored with the data.

The Information Commissioner's Office (ICO) press release states that a SQL injection vulnerability that existed for 3 years was the root cause, so this might imply the the decryption key was either stored in the database or the database could be used to read the key from elsewhere, such as the file system. The information taken included 3,814 payment card details; this mentions that both primary account numbers (PANs) and three digit security codes were accessed, which is even more interesting. The terms and conditions (Citybase, Central London) state:

Your payment card details will be securely held for the purpose of processing the booking until the day of check in. On the day of check-in, the credit card details are removed from our systems.

That's the travel industry problem of stored card data.

Apparently the fine would have been £75,000 but this may have put the company out of business. However, I suspect the fact that Worldview Limited will also be paying forensic investigation charges, card re-issue fees, card monitoring fees and fines relating to their PCI DSS contractual obligations will also have been taken into account by the ICO. However, £7,500 is a lot less than Worldview should be spending to ensure their customer data is secure. The fine is reduced further to £6,000 if payment is made by 1st December 2014.

The monetary penalty notice is available on the ICO web site.

The two "site security" pages on both web sites (Citybase, Central London) put a lot of faith in the use of "industry standard Secure Socket Layer (SSL) encryption technology" only:

When you submit your card details the information is encrypted (scrambled) so that it can only be read by the secure server, making the transaction as secure as possible.

When Lush Cosmetics had an ecommerce incident in 2010-11 with a similar number of cards and other personal data compromised, there was no fine — just an undertaking (and of course the PCI DSS costs). I suspect this stronger response from the ICO reflects its view that SQL injection is a basic fault that is below any acceptable level of security.

Update 7th November 2014: Link to monetary penalty notice and details of early payment discount added.

Posted on: 07 November 2014 at 08:59 hrs

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

06 November 2014

OWASP Snakes and Ladders

In a month's time we will probably be in full office party season. I have been preparing something fun to share and use, that is an awareness document for application security risks and controls.

OWASP Snakes and Ladders Mobile Apps

Snakes and Ladders is a popular board game, with ancient provenance imported into Great Britain from Asia by the 19th century. The original game showed the effects of good and evil, or virtues and vices. In this OWASP version, the virtuous behaviours (ladders) are secure coding practices and the vices (snakes) are application security risks. I have created two versions so far:

I created the game to use as an ice-breaker in application security training, but it potentially has wider appeal simply as a promotional hand-out, and maybe also more usefully as learning materials for younger coders. To cover all of that, I use the phrase "OWASP Snakes and Ladders is meant to be used by software programmers, big and small".

OWASP Snakes and Ladders Web Applications

The game might be a useful transition from learning about the OWASP Top Ten Risks and before moving into the Top Ten Proactive Controls in a PCI DSS developer training session for example.

Snakes and Ladders Web Applications is available in German and Spanish, as well as in (British) English. Translations to Chinese, Dutch and Japanese are also in progress. The OWASP volunteers who are generously translating the text and performing proof reading are:

  • Manuel Lopez Arredondo
  • Tobias Gondrom
  • Martin Haslinger
  • Riotaro Okada
  • Ferdinand Vroom
  • Ivy Zhang

Print-ready PDFs have been published - these are poster sized A2 (international world-wide paper sizes). But the original files are Adobe Illustrator, so these are also available for anyone to use and improve upon. OWASP Snakes and Ladders is free to use. It is licensed under the Creative Commons Attribution-ShareAlike 3.0 license, so you can copy, distribute and transmit the work, and you can adapt it, and use it commercially, but all provided that you attribute the work and if you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar licence.

Just print out the sheet as large as you can make them. It is better to play using a real die and counters (markers), but you can cut out and make these from the paper sheet itself if you have scissor and glue skills.

You can also follow two mock games on Twitter which upload a position image every hour:

Please enjoy and share.

Further information, and all the PDFs and source files, are available on the Snakes and Ladders project website. Please keep in touch by joining the project mailing list.

Posted on: 06 November 2014 at 08:31 hrs

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

04 November 2014

Payment Checkout Flaws and Bugs

The announcement last week by researchers from Newcastle University about a problem with Visa's contactless cards reminded me to mention again commons issues with checkout and payment functions in web and mobile applications.

Photograph of customers in a household lighting stand during Clerkenwell Design Week 2014

The Visa fault relates to not enforcing the same limits on transactions when using foreign currencies. The paper is being presented this week at the 21st ACM Conference on Computer and Communications Security in Scottsdale, Arizona. While we hope we would not make similar mistakes ourselves, almost every web/mobile checkout/payment system I come across has some sort of problems.

I do not believe I have mentioned it previously, but if you are developing an online payment API, mobile or web payment application, you should read a paper from Microsoft Research issued in 2011. How to Shop for Free Online - Security Analysis of Cashier-as-a-Service Based Web Stores (presented at IEEE Symposium on Security & Privacy 2011 in Oakland, California) describes findings from research into the security of several web payment applications.

Many of these problems are data validation or authorisation issues, but can be labelled as "business logic flaws". My own checklist for reviewing payment application functionality is below:

  • Buy at arbitrary price
  • Buy at nil price
  • Buy without paying
  • Buy one at item at another item's price
  • Pay for one basket at another basket's price
  • Update the basket while paying for the original one
  • Voucher, gift card and discount enumeration or manipulation
  • Repeat order/payment
  • Missing "mandatory" steps
  • Refund after payment
  • Chargeback after payment
  • Pay customer instead of seller
  • Missing checks/enforcement of data validation/signing
  • Enumeration of accounts, customers, payment cards, baskets, orders, email addresses, phone numbers
  • Manipulation of out-of-band messages (e.g. emails, SMS, direct messaging)
  • Payment confirmation manipulation
  • Tax and currency conversion manipulation
  • Rate of use and floor limits
  • Staff/internal backdoors
  • Fraud opportunities
  • Test data/cards works/present
  • Third-party hosted content
  • Privacy contraventions
  • PCI DSS contraventions.

This does not describe every method, but I hope the list is of use to others anyway. Generic attacks (e.g. injection, path traversal, cross-site request forgery, man-in-the-middle, unpatched components) also crop up in ecommerce payment functions, like everywhere else.

Posted on: 04 November 2014 at 20:11 hrs

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

12 September 2014

ICO Seeks Feedback on Use of the Data Sharing Code of Practice

Further to my post on Monday about the new privacy seals consultation, the ICO has requested feedback on the use of one of its major guidance documents.

Photograph of the transparent cased Sinclair ZX-80 computer exhibit at the recent Barbican 'Digital Revolution' exhibition in London

The Data Sharing Code of Practice was launched in May 2011 and provides statutory guidance on all internal and external sharing of personal data. The ICO has requested feedback on how the code is being used by organisations, in the form of an online survey

The survey runs until 5th October 2014.

Posted on: 12 September 2014 at 08:11 hrs

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

08 September 2014

ICO Consultation on Privacy Seals Endorsement

The UK's data protection agency Information Commissioner's Office (ICO) has published a consultation on privacy seals.

The ICO will endorse at least one scheme for a minimum of three years and will review all endorsed schemes in the final year.

The privacy seals consultation comes closely on the heals of BSI's new application security kitemark, but is requesting feedback on the concept of endorsing privacy seals schemes.

The Framework criteria for an ICO-endorsed privacy seal scheme describes that the ICO's endorsement is conditional on the privacy seal scheme's operator achieving official accreditation by the UK Accreditation Service (UKAS). The ICO will invite proposals for a privacy seal scheme in autumn, with a view to selecting a provider early next year, and . launching the first round of endorsed schemes in 2016.

A pre-formatted consultation response document has been provided that can be returned to the ICO by email or post.

The consultation closes on 3rd October 2014.

Posted on: 08 September 2014 at 07:19 hrs

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

19 August 2014

SSL-Only and This & That

It should come as no surprise that Google has indicated it has begun noting the use of HTTPS (HTTP over SSL) on some web sites to contribute to ranking in its search results.

we'd like to encourage all website owners to switch from HTTP to HTTPS

The writing is on the wall for almost any site that is not SSL-only. I have worked with some organisations that have shifted to SSL-only to simplify session management protection and to provide some identity assurance. The often-mentioned processing overhead has never been an issue for customers or server-side. There is plenty of discussion about Google's announcement (such as here, here and here).

A few tips from the trenches if you are about to renew or buy a new SSL certificate:

  • Use 2048-bit key certificates
  • Ensure your certificate provider signs it using SHA-2 (not SHA-1 which will be deprecated at the end of 2016); even if you ask for this it may not be what you receive — check it (but note pre Microsoft Windows XP SP3, any outdated web browsers do not support SHA-2 signed certificates)
  • If you need multiple domains within the same certificate, but not a wildcard certificate, be very careful about certificate product selection because, while any number of domains might be supported, this is often used to differentiate products and thus cost
  • If anyone mentions elliptic curve cryptography (ECC) digital certificates or hybrid ECC, probably ignore them for now (unless you are a bank)
  • Make sure you set the HTTP Strict Transport Security header and never include any non-SSL content in pages (often a problem if third-party hosted content is included).

If you want to delve deep into the protocol or need more implementation guidance, I can highly recommend Ivan Ristic's newly completed book Bulletproof SSL and TLS. It is written in a quite engaging style and is very readable in a technical sort of way (the plot is a bit weak though). And, if your website is publicly accessible, his server testing tool at SSL Labs is probably the most comprehensive and easy to use method for verifying the configuration. If you want a local tool, look at Achim Hoffmann's O-Saft.

My most relevant previous related posts on SSL are:

Oh, and beware public shaming where SSL really ought to be in use already. Some regulators and organisations you may have contractual obligations to might comment too.

Update 23rd August 2014: See the post about HTTP Strict Transport Security (HSTS).

Update 7th September 2014: See also Google's announcement about support for SHA-1 SSL certificates in Chrome.

Posted on: 19 August 2014 at 19:16 hrs

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

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

More Entries

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

Requested by 54.87.72.149 on Saturday, 30 May 2015 at 07:12 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