Video: PCI DSS VERSION 3.0: Manage PCI Compliance in ten minutes a day

Video Transcript

Slide 1

Welcome! I am going to be covering what the highlights or points of interest of the new PCI DSS Version 3 are and then look at how you can manage most of your PCI obligations in a few minutes each day – in an unscheduled section I am also going to talk a little about the recent breach at Target and if we have time, illustrate the points raised in a live demo, so lets get moving! This means I wont stop for questions during the session but will cover any submitted via the webinar chat option at the end or you can email us after the event if you have any more queries.

Slide 2

For those of you who don't know us we are a software manufacturer specialising in IT Security and compliance and have been providing solutions in this area since 2005. Some of our customers include retailers like WH Smith, Jack Wills and Harrods, and corporates like NBC Universal, RyanAir and Du Pont. We have a very strong affiliation and understanding of the PCI DSS and work with most of the 300 or so QSA firms around the world to help customers achieve and maintain PCI compliance.

Slide 3

Which brings us to todays session – Why is there a new version of the PCI DSS? Simply because Card data theft is still happening - the third revision of the PCI Data Security Standard is as much a re-launch as a revamp. This is more about refinement and clarification than any new technique or technology being needed to protect against card data theft, but while losses through card fraud are still on the increase, it is clear that something has to change.

Slide 4

In terms of the losses being experienced you can see why card brands would still be desperate for better care and attention to be applied to their card numbers - $11Billion lost last year. Before you shed too many tears for the card brands, bear in mind that the total of transactions now exceeds $21TRILLION. The card theft at Target involved around 70 Million card numbers and the cost of replacing these could be as much $10 per card, although losses if the cards are cloned could obviously run to hundreds of millions.

The second point, and this is also being proven right before our eyes in the case of Target, is that it is important to remember that PCI compliance ISN'T just a problem for the card brands that results in your organization having to spend time and money on, but is protecting your organization directly from a serious risk. The risk to your organization isn't simply financial either - other factors such as brand protection and customer trust, are also at risk and are lost when a breach occurs.

I'm going to take a few minutes to highlight the main changes introduced with Version 3 of the PCI DSS.

Slide 5

First question is when does this get introduced and if you have just sweated to get procedures in line with Version 2 of the DSS do you need to start again now on V3. Short answer is no, but you need to understand and begin to observe Version 3 now before it really becomes mandatory in 2015.

Slide 6

Taking the requirements in turn, Requirement 2 has been clarified in terms of clarifying that ALL accounts must be treated as vulnerabilities and therefore default settings must be changed and that your password policy should be extended to things like service accounts. Pass phrases now allowed but this is what I mean by the new standard being as much about galvanising merchants to take a fresh look at PCI requirements. Hardening or Elimination of Vulnerabilities is still the best way to fundamentally secure devices, and still either NIST or CIS checklists are the way to go – we build these into our products so you don't have to research or interpret the guidelines yourself. Topically, there is a suggestion that a default service account used in BMC Patrol may have been exploited to facilitate the Target breach.

Slide 7

6.5.6 – Insecure Handling of PAN and SAD in Memory
Just like with Buffer Overflow Protection and SQL Injection Attack mitigation, this is an appeal for application designers to be on their guard, but this time specifically for memory scraping malware and to design in safety features so that CHD and Secure Authentication Data is protected.

The call is to take a step back and consider using programmatic features that prevent unauthorized applications from accessing memory (some development environments are better than others for this). Also what happens during a crash? (lots of attacks take the form of disruption to the application in order to make it 'cough up' or dump data such as PAN and SAD). Can the application completely erase data when no longer needed?

In other words this is partly an application development challenge (hence being a Requirement 6 item) but also a malware protection issue too – an attacker will need a Trojan or other Malware to scrape memory so low level FIM can play a part in underwriting coded protection. In summary, get ready for some more challenging questions from your QSA, so ask your EPoS/eCommerce app providers/in house development team now what they make of this requirement.

6.5.11 – Broken Authentication and Session Management
The detail of this new requirement appears to be asking merchants to mitigate the risk involved with client-side takeovers: we must assume that trusted clients could become attack vectors. Client-side attacks are one of the most common ways hackers get access to data and as ever, hackers will go for the weakest link. The requirement also intends to put focus on man-in-the-middle style attacks as well. Services like Worldpay for example also

Primarily this is an application design issue (Requirement 6 prefix is a giveaway  ). It highlights a common vulnerability vs functional balance that is tolerated by developers because implementation can create user experiences that are annoying. For example, retail web sites could see users walk away from their shopping carts for a bit, only to return to a 'session timeout' message. OWASP knowledgebase is your go-to resource for development mitigation.

Slide 8

8.5.1 – Unique Authentication Credentials for Service Providers
This is also a bit of a 'we know you know this, but it still isn't always being done'. Standard security best practises within and outside of the PCI DSS are to use unique access credentials for EVERYTHING so you know who is the perpetrator when something untoward takes place. Its just standard, good practice. However it seems that service providers need a reminder that this does apply to them too and they need to use unique credentials (and not just 'customername+administrator as a username either!)

9.9 – Protection of Point-of-Sale (POS) Devices from Tampering
Again, we all know this, but based on breach statistics, card skimming and more elaborate variants thereof targeted on the POS equipment are still widespread. This is the ying to the yang of the first two highly technical new requirements to remind us that 'low tech' crime still works too. Being a Requirement 9 entry itemizes this as a 'don't let anyone touch the cardholder data processing equipment', but explicitly highlighting protection of endpoints since the V2.0 Req 9 places more focus on the 'central site' data centre

Slide 9

11.3 – Develop and Implement a Methodology for Penetration Testing
Another 'new' requirement that exists to emphasize focus on one of the standard practices that everyone already complies with, but maybe doesn't do it as well as they might. The market for Pen Testing has become highly commodotized with most vendors offering cost-engineered, highly-automated services. This inevitably leads to tests becoming more superficial (checkbox approach to compliance) so this new requirement is a 'tug on the leash', forcing the merchant to avoid bad habits and corner-cutting. Its something very key to NNT anyway in that we advocate that classic Security Best Practices are operated which help to minimize the 'boom and bust' approach to vulnerability management that the PCI DSS sometimes engenders. By this I mean that running an annual or quarterly set of scans, then having to drop everything for a week in order to patch and re-configure devices before repeating the process 3 months later makes life hard and also may render you unsecure for months at a time. NNT works on a continuous basis to continually track changes to devices and allow you to operate more of a trimming process to vulnerability management which is more effective, gentler on the network and hosts and gentler on your resources too!

12.9 – Additional Requirement for Service Providers on Data Security
Last one - The intention is to ensure that service providers properly understand and operate their PCI requirements fully. The DSS places the onus on the merchant to ensure they have a statement acknowledging this and, in turn, Merchants should be indemnified of cardholder data protection by their service provider.

For example, our own Compliance as a Service offering is operated from a fully PCI Compliant facility in the former Greenham Common Nuclear Warhead Silo (which as you might imagine, is pretty secure by design  )

Slide 10

So by way of illustration, I am very grateful to the perpertrators of the Target breach in getting their work done in time for the webinar today as it serves as a timely example of why the PCI DSS is so important. Much of what we have been told has come from Target themselves and from investigative journalists like Brian Krebs who if you don't already know him is a terrific daily source of cybercrime stories.

Slide 11

This is taken from Target themselves and confirms what was already feared about the breach – although it was only in operation for 2 weeks, this included the Thanksgiving period which is always a big shopping period. So we are dealing with a breach on an impressively large scale , but what has really stood at as much is that Target are the 2nd or 3rd largest retailer in the US. In other words, even the best resourced retailer can be caught out, one that you would assume would be the highest risk in terms of card transaction volumes and therefore the most scrutinised in terms of security. From a PR perspective, the public are asking how the most popular, most trusted retailers can get caught out like this.

As an aside, a QSA we work with says that the need for an Information Security Incident Response Plan is something that is always neglected by customers he works with, but should include contingency planning for a if a breach happens and who tells the authorities and press – looks like Target have worked hard on their one.

Slide 12

So much of the information I will use has been sourced from Brian Krebs excellent blog. He has published the following based on inside information he has. Target are much like many retailers in that their EPoS systems are XP based.

It isn't clear who the malware was introduced to the Target network but suggestions now are that a SQL Injection attack provided access to a server that was then used as a vantage point to access other devices including the EPoS network. The malware operated in conjunction with a control server elsewhere in the network – card data scraped from the POS software itself was collated back at the Control Server and then periodically uploaded by the thieves.

So this was a well-planned and executed breach and you may feel Target can be forgiven for falling victim to such a sophisticated scam.

Slide 13

In fact, it would seem that there has been an attempt to excuse the breach – this came from Brian Krebs research and the quote is attributed to a 'source close to the investigation'

Unfortunately this is no real excuse, since anyone in the Information Security knows that Anti-Virus is fallible as a malware defense. AV systems work by quarantining any files that score a hit against a repository of signatures of known malware. In addition, a good AV system will also track known patterns of malware behavior. In other words, AV is always working on old information.

The fact is that Malware can be modified to side-step AV operation. A modified malware strain effectively becomes a brand-new, never before seen variant, leaving the AV blind to its existence.

Since it is well-understood that AV needs help, the security standard developed to protect card data – the PCI DSS – has measures in place to block the loopholes left by AV.

PCI DSS Requirement 11.5 mandates that regular file integrity checks are run on all 'in scope systems'. A file integrity check ensures that all file attributes, security settings and permissions are maintained. In order to detect if a Trojan has replaced an existing system file, a cryptographic hash value is also recorded for each file being tracked. Hash algorithms such as MD5 and SHA1 work in such a way that even a tiny change to the file will result in a significant change to the hash value. In other words, your AV may well miss the malware, so use other technology to help.

Slide 14

Reports suggest that a trojan was used – winxml.dll – and a new service was registered

If you knew what to look for then you would spot these immediately, but this is where an automated FIM solution really comes into its own. Any changes to the filesystem of config settings will be reported to allow investigation – if it looks unusual or is an unexpected change then you could have a breach on your hands.

Slide 15

As I mentioned, the PCI DSS is a few steps ahead in this respect. FIM has always been a key security best practice and is a staple of the PCI DSS. Correctly deployed, FIM will identify security vulnerabilities in configuration settings (going back to requirement 2 and hardening checklists from NIST and CIS) and will also identify Trojans or new malware files. FIM can also be used to audit file access so if you have data that can be accessed – even though it shouldn't be – for example by a user with domain admin rights, then at least you can still be alerted.

Slide 16

I'm going to attempt to illustrate some of these points now in a demo – it will either work in which case it should be pretty entertaining, but if I flounder, it should still be entertaining for you at least, although I may not enjoy it as much!

Slide 17

Continuous Real-Time File Integrity monitoring provides zero tolerance to trojan malware

Continuous Change Detection underpins Secure Operation Change Management Processes

Industry-Standard Hardening Checklists for all Windows. Linux, Firewalls and Network Devices takes care of Reqs 1 and 2

Of course, you will need to put work into your card data usage understanding, your procedural documentation, your network segmentation, your scans and pen tests, your patching, your physical security etc…..but when you consider many organizations are struggling to even get started with PCI Compliance, our ten minute a day program of reviewing file changes, maintaining a hardened build standard and any unusual log events, this will provide a firm foundation in security best practices.

Slide 18

We have already helped all the organizations and would love to help you too – please fill out the brief feedback form and if you would like to take up the offer of a free PCI Security Audit from us please let us know through your feedback. A recording of the webinar will be available and slides with notes on request.

Thank you to all of you for attending.