The blessing and curse of PCI-DSS

This is a post I have been meaning to write for some while, as I have been pondering the benefits vs. challenges of various standards / legislation.  I’m not thinking about challenges of implementing PCI-DSS (Payment Card Industry – Digital Security Standard), more the challenges of working in environments where compliance trumps security.  As per the title, this post will focus on PCI-DSS, but I think it’s likely most of the issues will apply to various standards / regulations that are subject to compliance audits of some sort.

On the positive (blessing) side PCI-DSS is mostly a good standard, enforcing things like encryption in transit over public networks, separation of duties, minimising access to card data etc.  It has forced some level of security practice onto companies that may previously have had relatively lax controls in place.  The standard has also considerably raised the profile of security / meeting security requirements within many organisations.

On the negative (curse) side PCI-DSS is seen by many organisations as the be all and end all of security, despite the fact that is it the bare minimum you have to achieve in order to be permitted to handle / process card date.  In addition it focuses almost solely on card data, ignoring concerns around things like PII (Personally Identifiable Information).  This leads to a focus on ‘box-ticking’ compliance, rather than designing secure systems from the ground up which would by definition be compliant with most (any?) sensible standards.

With the movement towards a more continuos monitoring style proposed for the latest release of PCI-DSS the focus on obtaining compliance yearly may be something we are moving away from.  However this will do little to address companies attitudes towards broader security and the belief that obtaining and maintaining PCI-DSS compliance means systems are completely secure.

On balance I think standards / regulations like PCI-DSS are a good thing as they force companies to at least achieve some minimal levels of security.  The challenge for security professionals is to get project teams and the wider business to accept that these standards are the bare minimums.  Considerably more secure designs / solutions need to be implemented if we want to actually meet our duty of care to our customers whose data we hold and process.

What are your thoughts?

How successful have you been in moving to security being ‘front and centre’ and compliance with regulations being a by product of this, rather than the focus being on compliance rather than security?




Data breaches visualisation

Came across this recently and think its a pretty decent demonstration of the continuing frequency and severity of data breaches;

You can hover over any of the circles then click for more information about that breach.

This also shows how companies never seem to learn and we are seeing more breaches of a very similar nature to those we were seeing several years ago.

It’s time to learn from our mistakes and actually design and build secure systems, not just tick compliance boxes!  This is definitely one of my personal bug-bears, as an example, many companies that must maintain PCI compliance care about this for obvious reason, but too often projects and system owners only care about this and not actually being secure or making systems and ‘non PCI’ data secure.  This is despite the payment card industry being very clear that PCI-DSS is the bare minimum standard you must achieve to be permitted to handle card transactions, not the standard you should aim for to be a secure business and keep your customers data secure.

It’s time to get better at communicating the risks to the business and working to ensure secure design and implementation is at the forefront of any solution.


PCI-DSS Virtualisation Guidance

In what was obviously a response to my recent blog post stating
more detailed guidance would be helpful (yes I am that influential!) the ‘PCI
Security Standards Council Virtualisation Special Interest Group’ have just
released the ‘PCI DSS Virtualisation Guidelines’ Information Supplement.

This can be found here;

This is a welcome addition to the PCI-DSS as it makes the
requirements for handling card data in a virtual environment much more clear.
The use of the recommendations in this document along with the reference
architecture linked to in my previous post will provide a solid basis for
designing PCI-DSS compliant virtual environment.

The document itself is in 3 main sections. These comprise;

– ‘Virtualisation Overview’ which outlines the various components
of a virtual environment such as hosts, hypervisor, guests etc. and under what
circumstances they become in scope of the PCI-DSS

– ‘Risks for Virtualised Environments’ outlines the key risks
associated with keeping data safe in a virtual environment including the
increased attack surface or having a hypervisor, multiple functions per system,
in memory data potentially being saved to disk, Guests of different trust
levels on the same host etc. along with procedural issues such as a potential
lack of separation of duties.

– ‘Recommendations’; This section is the meat of the document that
will be of main interest to most of the audience as it details the PCI’s recommended
actions and best practices to meet the DSS requirements. This is split into 4

– General –
Covering broad topics such as evaluating risk, understanding the standard,
restricting physical access, defence in depth, hardening etc.   There is also a recommendation to review other guidance such as that from NIST (National Institute of Standards Technology), SANS (SysAdmin Audit Network Security) etc. – this is generally
good advice for any situation where a solid understanding of how to secure a
system is required.

– Recommendations for Mixed Mode Environments –

This is a key section for most businesses as the reality for most of us is that being able to run a mixed mode environment, (where guests in scope of PCI-DSS and guests not hosting card data are able to reside on the same hosts and virtual environment via acceptable logical separation), are the best option in order to gain the maximum benefits from virtualisation.  This section is rather shorter than expected with little detail other than many warnings about how difficult true separation can be.  On a bright note it does clearly
say that as long as separation of PCI-DSS guests and none PCI-DSS guests can be configured and I would imagine audited then this mode of operating is permitted.  Thus by separating the Virtual networks and segregating the guests into separate resource pools, along with the use of virtual IPS appliances and likely some sort of auditing (e.g. a netflow monitoring tool) it should be very possible to meet the DSS requirements in a mixed mode virtual environment.

– Recommendations for Cloud Computing Environments –

This section outlines various cloud scenarios such as Public / Private / Hybrid along with the different service offerings such as IaaS (Infrastructure as a Service), PaaS (Platform as a Service), SaaS (Software as a Service).  Overall it is highlighted that in many cloud scenarios it may not be possible to meet PCI-DSS requirements due to the complexities around understanding where the data resides at all times and multi tenancy etc.

– Guidance for Assessing Risks in Virtual Environments –

This is a brief section outlining areas to consider when performing a risk assessment, these are fairly standard and include Defining the environment, Identifying threats and vulnerabilities.

Overall this is a useful step forward for the PCI-DSS as it clearly shows that the PCI are moving with the times and understanding that the use of virtual environments can indeed be secure providing it is well managed, correctly configured and audited.

If you want to make use of virtualisation for the benefits of consolidation, resilience and management etc. and your environment handles card data this along with the aforementioned reference architecture should be high on your reading list.