07 March 2014

Standards

Posts relating to the category tag "standards" are listed below.

19 March 2013

Data Protection Risks for Mobile Apps

The European Commission's Article 29 Working Party on the Protection of Individuals has published its opinion on data protection risks for mobile apps.

Partial image of the recommendations for app developers in the European Commission's Article 29 Working Party on the Protection of Individuals 'Opinion 02/2013 on Apps on Smart Devices'

Opinion 02/2013 on Apps on Smart Devices describes the roles, risks and responsibilities of four groups: app developers, operating systems/device manufacturers, app stores and third parties. It seems slightly odd to lump together "rganisations that outsource the app development and those companies and individuals building and deploying apps", and think this will lead to confusion.

However, in the conclusions on pages 27-28, there are two useful lists under the headings "App developers must" and "The Working Party recommends that app developers", which would be suitable for consideration of inclusion within internal compliance standards for app development.

Posted on: 19 March 2013 at 08:28 hrs

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

29 January 2013

Anti Information Warfare Resources (US Federal)

The US Department of Defense's Cyber Security and Information Systems Information Analysis Center (CSIAC) has updated its chart about references concerning information warfare defences.

Small-scale image of the whole CSIAC Information Assurance (IA) Policy Chart - follow the PDF link below to view the chart at larger scales

The Cyber Security and Information Systems Information Analysis Center (CSIAC) is one of eight Department of Defense Information Analysis Centers (IACs) sponsored by the Defense Technical Information Center (DTIC). CSIAC was formed from the consolidation of three legacy IAC's - the Information Assurance Technology Assurance Center (IATAC), the Data and Analysis Center for Software (DACS), and the Modeling and Simulation Information Analysis Center (MSIAC) - along with the addition of the new technical domain of Knowledge Management and Information Sharing.

Sometimes digging through lists of NIST's Special Publications can be time-consuming, or you cannot find an information security regulation mentioned in a contract. The publicly available Information Assurance (IA) Policy Chart (PDF) lists and links to national and federal cyber security related policies and other guidance. The acronym "GIG" is used, meaning Global Information Grid. Topics include:

  • Procurement
  • Development
  • Education and awareness
  • Communications
  • Access control
  • Information sharing
  • Operations
  • Defensive measures
  • Risk management
  • Incident preparedness

Regardless of whether your organisation is based in the United States, has dealings there, if it is in the governmental sector or not, this is a helpful summary of materials that will assist your own information security efforts.

Posted on: 29 January 2013 at 07:41 hrs

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

18 January 2013

Proposed Amendments to EU Data Protection Framework

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.

Posted on: 18 January 2013 at 08:00 hrs

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

29 June 2012

PCI DSS Requirement 6.2 and Severity Ranking Spaghetti

The week after next OWASP AppSec EU begins in Athens where I am speaking. During my presentation I will discuss the newly mandatory requirement 6.2 in PCI DSS relating to ranking of vulnerabilities, with special emphasis on ranking the severity of vulnerabilities in software applications.

Requirement 6.2 Establish a process to identify and assign a risk ranking to newly discovered security vulnerabilities.

In Tricolour Alphanumerical Spaghetti I will also describe alternative ways of meeting PCI DSS v2.0 Requirement 6.2 and which is a mandatory requirement from 30th June tomorrow, previously just being considered a best practice. I will discuss risk ranking schemes and how to develop a method for evaluating vulnerabilities and assigning a risk rating relevant to your own specific environment and business needs.

PCI DSS requirement 6.2 influences other requirements where the prioritisation of vulnerabilities are referenced:

  • 2.2 Develop configuration standards for all system components. Assure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards.
  • 6.5.6 Develop applications based on secure coding guidelines. Prevent common coding vulnerabilities in software development processes, to include the following: ... All "High" vulnerabilities identified in the vulnerability identification process (as defined in PCI DSS Requirement 6.2).
  • 10.4 Using time synchronization technology, synchronize all critical system clocks and times and ensure that the following is implemented for acquiring, distributing, and storing time.
  • 11.2.1 Perform quarterly internal vulnerability scans.
  • 11.2.3 Perform internal and external scans after any significant change.

So, I am hoping it will be of use to those with PCI DSS obligations, as well as to organisations who simply want to know what the severity rating of a vulnerability, flaw, fault or weakness means. The presentation is being given at 15:20 hrs on Thursday 12th in the "Builders" track.

Immediately prior to the conference there are training courses. There are still some places left on my course Application Attack Detection & Response — A Hands-on Planning Workshop being held on Tuesday 10th July. This will be a highly interactive day with generous learning opportunities. Last time we did the course, the participants really enjoyed it and gave great feedback.

If you are going for the conference, why not take the opportunity to receive some training. On the next day, Wednesday, you could also register for the training course Elite Web Defense — How to Build Robust and Secure Web Applications being run by the excellent Jim Manico and Eoin Keary. Register for the training and conference here.

Posted on: 29 June 2012 at 08:25 hrs

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

30 March 2012

Application Security Gap Study

A new report from Ponemon Institute describes the results from a survey of developers and information security employees in the United States.

Key finding: Application security is often not a priority

2012 Application Security Gap Study: A Survey of IT Security & Developers provides useful data on the viewpoints from these important groups, and of course isn't necessarily encouraging reading. A very small proportion of the IT security budget is spent on application security, most do not have a standardised way of building security into new applications and security is most often addressed in later stages of the software development life cycle (SDLC). See the overview on the ISACA website.

The information could be used to help compare secure software development life cycle (S-SDLC) maturity, but the input of other groups such as product owners, architects, testers, QA, audit and operations would also provide useful data, and hopefully senior management might be able to provide an oversight of the all the processes and the organisation's needs and risk profile.

Posted on: 30 March 2012 at 09:20 hrs

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

14 February 2012

[In]Vulnerable SDLC

Weaknesses in software security? Long-term security advocate and practitioner Eoin Keary has written an article about the weaknesses in our approach to application security.

Construction staff waiting to begin their night shift outside the new Thameslink 2000 station at Farringdon in Clerkenwell, London, UK

Eoin describes the problems with past and current approaches, and has come to believe organisations should use a structured and repeatable method for addressing security in the software development lifecycle (SDLC) encompassing:

  • Secure design
  • Developer training
  • Common module/framework design and implementation
  • Code review
  • Integrated functional/security/anti-functional testing.

He also proposes that manual efforts are used in the SDLC, and in verification activities for runtime scanning, rather than in undertaking manual penetration testing. Eoin also highlights the need for ongoing, continuous monitoring, feedback and analysis in what he terms Enterprise Security Intelligence (ESI) — maybe that is Eoin's Secret Ingredient?

Read, learn, respond and implement what will work with your own organisation's risks and culture.

Posted on: 14 February 2012 at 07:22 hrs

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

05 February 2012

BITS Software Assurance Framework

BITS, the technology policy division of the Financial Services Roundtable, an industry body representing the US financial services industry, has published a Software Assurance Framework.

The 50-page guidance document describes an outline of recommended components of what they describe as a "mature, strategic program for secure software development" for software used within the US financial services industry. The framework was a collaborative effort that involved several financial services companies in conjunction with Microsoft, and it references the Microsoft-sponsored Forrester Consulting research which indicated that the use of a prescriptive secure software development lifecycle achieves the greatest return on investment (see also the similar Aberdeen Group research).

This is not a hands-on "how to" for software architects, developers, testers or operational staff, but instead describes a framework of activities that contribute to the specification, production, deployment and operation of secure software throughout the development lifecycle. In that respect, the comparable documents to refer to are BSIMM, MS SDL and Open SAMM, and indeed these are referenced in the BITS framework. Some organisations also build their software assurance efforts around the Capability Maturity Model Integration (CMMI).

So what does BITS consider to be the key components of a software assurance framework? Eight are defined and explained:

  • Education & Training
  • Security Software Assurance Development Standard
  • Threat Modeling
  • Coding Practices
  • Security Testing
  • Pre-Implementation Practices
  • Software Assurance Documentation Archive Best Practices
  • Post-Implementation Phase Controls

There is of course considerable overlap with the references mentioned above which describe actual practices in place, how Microsoft undertakes secure SDLC and a maturity model for software assurance respectively. I have tried to indicate below how the BITS key components broadly map to Open SAMM:

BITS Component SAMM v1.0 Business Function: Security Practice
Education & Training Governance: Education & Guidance
Security Software Assurance Development Standard Governance: Strategy & Metrics
Governance: Policy & Compliance
Construction: Security Requirements
Construction: Secure Architecture
Threat Modeling Construction: Threat Assessment
Coding Practices Governance: Policy & Compliance
Governance: Education & Guidance
Security Testing Verification: Design Review
Verification: Code Review
Verification: Security Testing
Pre-Implementation Practices Deployment: Operational Enablement
Software Assurance Documentation Archive Best Practices (Through all above security practices)
Post-Implementation Phase Controls Deployment: Vulnerability Management
Deployment: Environmental Hardening
Deployment: Operational Enablement

So quite a lot of overlap. There is an existing mapping of Open SAMM to BSIMM activities which could be used to extend the above mapping onto BSIMM. As the BITS framework has been developed in conjunction with Microsoft, I expected to see a much closer relationship with MS SDL, and yes this is the case.

BITS Component MS SDL v5.1 Phase: Process
Education & Training Training: Core Security Training
Security Software Assurance Development Standard Requirements: Establish Security Requirements
Requirements: Create Quality gates/Bug Bars
Requirements: Security & Privacy Risk Assessment
Design: Establish Design Requirements
Threat Modeling Design: Analyze Attack Surface
Design: Threat Modelling
Coding Practices Implementation: Use Approved Tools
Implementation: Deprecate Unsafe Functions
Security Testing Implementation: Static Analysis
Verification: Dynamic Analysis
Verification: Fuzz Testing
Verification: Attack Surface Review
Pre-Implementation Practices Release: Incident Response Plan
Release: Final Security Review
Software Assurance Documentation Archive Best Practices Release: Release Archive
Post-Implementation Phase Controls Response: Execute Incident Response Plan

There isn't a direct one-to-one mapping here, but I hope the above help navigate the document if you use Open SAMM or MS SDL and want to delve into another source of ideas for secure software development lifecycles. Although the BITS framework might be somewhat heavyweight for some non-financial services organisations, especially on the documentation front, it is perhaps an easier starting point than the closely related MS SDL, to begin working on building security into development (and acquisition) processes. Take what suits, makes sense and fits your own organisation's type of applications and tolerance of risk.

Most of the content will be relevant, and since it is spelt out in reasonable detail, this could be very helpful. Some notable nuggets deeper in the document are:

  • pp2-3 "teaching techniques of good design and their subsequent use can result in software secure not just against known attacks, but also against unknown attacks and attacks yet to come"
  • p20 "Security defects are "defects", not just "security defects"
  • p35 Security vulnerabilities identified in applications in production .... should not be treated as software defects, but as one part of the company's incident response process".

And on page 36 in the section relating to emerging threats in the post-implementation phase controls, there is a comment relating to the OWASP Top Ten and CWE/SANS Top 25 which seems out of kilter with the rest of the framework's text. The document states these as being valuable sources of information but "both represent an earlier generation of software security intelligence". I am not sure each of those sources set out to define the only threats to consider, and are instead a way of introducing the concepts to less-knowledgeable groups and encourage reading of the much deeper related materials. But perhaps this is more of a comment about PCIDDSS which specifically mentions these two sources. I wonder.

As you can see, worth the read.

Posted on: 05 February 2012 at 20:56 hrs

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

15 November 2011

Cross-Site Tracking Preference using Do Not Track

The W3C's Tracking protection Working Group has published two working draft proposals for implementing "Do Not Track" online.

Part of the W3C's W3C Working Draft 14 November 2011 on 'Tracking Preference Expression (DNT)'

The proposals will allow users to define whether or not data about them can be collected for tracking purposes. Thus the proposals include information on how consumers express their tracking preference, and also how the websites and related systems (e.g. affiliates) will acknowledge those preferences.

Tracking Preference Expression (DNT) (W3C Working Draft 14 November 2011) describes how users express their preference and how websites indicate whether they honour such preferences. The proposal is to utilise a new HTTP request header "DNT", a machine-readable web-accessible file defining the site's tracking policy and an HTTP response header for the site to communicate its compliance with tracking preferences.

Tracking Compliance and Scope (W3C Working Draft 14 November 2011) defines the meaning of a "do not track" preference and will set out practices for websites to comply with this preference.

These are very early drafts, with many unresolved issues. W3C hopes to have adopted standards by June 2012, but in the meantime is inviting review and comment. For websites hoping to adopt and promote compliance with this proposal, now is a good time to start defining a project with a view to firming up the requirements in April 2012 when a candidate recommendation will be published. The broad requirements can be seen from the current documentation.

Posted on: 15 November 2011 at 08:31 hrs

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

21 September 2011

AppSensor Summit at AppSec USA 2011

Following a successful training course yesterday with great group of delegates, today I attended the OWASP AppSensor Project working group at AppSec USA 2011.

Photograph of downtown Minneapolis where the OWASP AppSec USA 2011 conference is being held

The AppSensor Summit was held to review the project's recent developments and activities, and to gather ideas from existing and new contributors to create a future roadmap. It was good to meet at long last John Melton, AppSensor's lead programmer, and catch up with Michael Coates and Ryan Barnett.

The summit also attracted a diverse range of developers, architects, users and security vendors. There were probably about 10-12 people attending all day, with a few more popping in and out as their timetables and other commitments allowed. The discussions defined the contents for a new book, an AppSensor development life cycle, an integration plan and a new concept to modularise the analysis engine to simplify integration with application software. The idea of creating a set of example usage profiles was also suggested. I think my name is down to help mainly with a new version of the AppSensor book, but I hope I can contribute with some of the interface definitions for interactions with the analysis engine, and possible signalling/exporting functionality.

The meeting notes are available, so if you have any comments or suggestions, please add them there, or discuss them via the project's mailing list.

The talks at the conference begin tomorrow.

Posted on: 21 September 2011 at 22:30 hrs

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

12 August 2011

The Lush Topic of Security, Data Protection and PCI DSS

Do you remember Lush Cosmetics' rather public payment card data and personal data loss announced in January 2011? After 4 months of being compromised, the problem was recognised, customers were notified and the web site was shutdown.

Photograph of the entrance and display windows of a Lush Cosmetics shop in London

Lush had allowed people's data to be stolen via its own web site. We still await to hear what the fines and other penalties will be levied under the Payment Card Industry Security Standards Council (PCI SSC) Data Security Standard (DSS) if they are found to have been non-compliant at the time. However the UK's Information Commissioner's Office (ICO) became involved due to the related loss of 5,000 individual's personal data and confirmed in a press release on Wednesday this week that Lush Cosmetics had also breached the Data Protection Act 1998. Formed in 1994-1995, Lush Cosmetics has been a registered data controller (No. Z8189523) since late 2003.

As expected, no enforcement notice or monetary penalty has been issued, but Lush Cosmetics Limited's Managing Director, Mark Constantine, has signed an undertaking to ensure that personal data are processed in accordance with the seventh data protection principle concerning security, and in particular take the following measures to improve the protection of personal, and cardholder data:

  1. Appropriate technical and organisational measures are employed, and maintained, to prevent the unlawful processing of customer data, particularly within web based systems;
  2. Only the minimum amount of customer personal data is stored and that this is retained only for as long as a relevant business need exists;
  3. Computer systems storing customer personal data must be subject of regular penetration testing , with activity logs retained for an appropriate period of time and frequently interrogated for evidence of malicious attack;
  4. The processing of customer credit card data is conducted by a PCI compliant external service provider;
  5. The data controller shall implement such other security measures as it deems appropriate to ensure that personal data is protected against unauthorised and unlawful processing, accidental loss, destruction, and/or damage.

...as long as the Data Protection Act, or succeeding legislation are in force. So correctly a focus on Lush's web systems, including penetration testing of systems holding personal data. But also other appropriate security measures as necessary. Let's hope Lush aren't left thinking penetration testing is the answer — security needs to be considered at all stages of acquisition, development, deployment and operation.

And yes, that's right, the ICO is insisting on compliance with PCI DSS. The ICO made it clear in the press release of its expectations for PCI DSS compliance by other online retailers, that will otherwise risk enforcement action by the ICO.

This seems to be a valid approach, since fines, investigation costs, etc may still be levied for lack of PCI DSS compliance too. But I have some concerns with how Lush are portraying their squeaky-clean new status in the web site's terms and conditions:

Our website (www.lush.co.uk) is now operating under level one PCI-DSS compliance. If you don't have your geek-speak handbook around, that means Personal Card Industry - Data Security Standard. Level one is the highest level achievable; we don't want to take any risks with our customers' money or data. Although this doesn't guarantee that our website is impervious to hacking, it does guarantee that your card details are safe and secure. You can read more about PCI compliance here [missing link]

I'm not entirely sure that moving all cardholder data off-site to a PCI DSS compliant third party processor necessarily means much about the security of other data on the Lush web site and elsewhere at Lush, or much about systems outside the cardholder data environment. Is this just meaningless bubbly rhetoric to provide false assurance, or maybe Lush still does not understand what they are doing? Complying with regulatory and contractual mandates isn't the same as believing in "filling the world with perfume and in the right to make mistakes, lose everything and start again". Some of that "honest meaning" mentioned by Lush would be welcome here too.

Personally I think the PCI SSC should be a bit more strict about how their name can be used to endorse systems. Hey, clerkendweller.com meets PCI DSS compliance criteria too! There's no cardholder data to begin with...

Posted on: 12 August 2011 at 08:22 hrs

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

More Entries

Standards : Web Security, Usability and Design
ISO/IEC 18004:2006 QR code for http://clerkendweller.com

Requested by 50.17.107.233 on Friday, 18 April 2014 at 18:16 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 http://www.clerkendweller.com/page/terms
Privacy statement http://www.clerkendweller.com/page/privacy
© 2008-2014 clerkendweller.com