GDPR and PCI DSS: appropriate bedfellows?

At a recent meeting of the UK Merchant PCI Working Group I mentioned that there was some soft case law in the form of ICO enforcement action which helps to answer the question of whether PCI DSS is sufficient to meet GDPR’s requirement for organisations to implement “appropriate technical and organisational measures” in respect of the security of cardholder data.

As PCI DSS and GDPR are probably my two specialist subjects, I’ve written a short paper that looks at the ICO’s historic enforcement action and which hopefully answers the appropriateness question.

Paper (PDF): GDPR and PCI DSS: What’s appropriate?

Privacy Risk Assessment Workshop

On January 20th (a Saturday!) I spent a few valuable hours with fellow practitioners in a privacy risk workshop kindly organised by Professor Eerke Boiten at De Montfort University in Leicester.

I presented a brief overview of the way I’ve started to carry out very basic risk assessments focussed on privacy impact to Data Subjects.

This is the paper I showed that describes my simple privacy risk assessment methodology.

Feel free to use it, modify it, discuss it and improve on it. I think Eerke will organise another event so if you’re interested follow me @withoutfire, @EerkeBoiten or any of the other participants (@SandreJ, @TrialByTruth, @LynnFOI, @TheABB, @FOIkid, @RMGirlUK, @MissIG_Geek) for further discussions.

PECR and Affiliate Marketing

Over the past 12 months, the ICO has developed a significant approach on the use of affiliate marketing and the applicability of the Privacy and Electronic Communications (EC Directive) Regulations 2003 (PECR).

In November 2016 the ICO undertook a review of the use of affiliate marketing in the gaming industry [1]. When writing to affiliate marketers the ICO clearly described how it viewed the affiliates’ role:

“The ICO’s opinion is that where and affiliate sends an SMS on the half of or promoting the website of, a gaming company, then that affiliate is the sender of that communication and must comply with regulations 22 and 23 of the Privacy and Electronic Communications (EC Directive) Regulations 2003.” [2]

Article 22 of the PECR states:

22 (1) This regulation applies to the transmission of unsolicited communications by means of electronic mail to individual subscribers.
22 (2) Except in the circumstances referred to in paragraph (3), a person shall neither transmit, nor instigate the transmission of, unsolicited communications for the purposes of direct marketing by means of electronic mail unless the recipient of the electronic mail has previously notified the sender that he consents for the time being to such communications being sent by, or at the instigation of, the sender.

I have emphasised the word instigate in 22(2) because it is the interpretation of this word that is important in this matter. In November 2016 in the press release announcing the Monetary Penalty Notices (MPNs) issued to Silver City Tech Ltd and Oracle Insurance Brokers Ltd the ICO stated:

“Affiliate firms are like postmen, delivering the message. It’s the people behind the message whose job it is to make sure it complies with the law. They must make rigorous checks to ensure the rules have been followed.” [3]

The ICO’s position appears to be that the affiliate is the transmitter (sender) of a communication but that that the beneficiary is the instigator of the transmission of a communication. Potentially leaving both the instigator and sender of an electronic marketing communication open to enforcement action.

This analysis is further backed up by the MPN [4] and Enforcement Notice [5] issued to Vanquis Bank Limited (VBL) in October 2017 where the ICO clearly states that the beneficiary of the affiliate marketing company’s activity is the instigator of the communication, and therefore has an obligation to comply with PECR Article 22.

Whilst VBL did not send the emails itself, it contracted with the third party affiliates to send the messages on its behalf. The aim of the messages was to promote VBL credit cards. The Commissioner is therefore satisfied that VBL was the instigator of the direct marketing email messages. [6]

As the instigator of the direct marketing e-mail messages, it was the responsibility of VBL to ensure that valid consent to send those messages had been acquired. [7]

My view is that the ICO is using the ambiguity in PECR to ensure that companies cannot just pass the blame for inappropriate marketing by determining a relationship as affiliate marketing where the relationship is more correctly described as a postman paid by results. The ICO’s position is that this type of affiliate relationship is essentially the same as a contract with a mailing house to deliver a company’s marketing message – a relationship where the company benefiting from the marketing would be wholly responsible for compliance with PECR and making sure it had consent from the recipients of the electronic marketing message. The fact that a third party’s reward is based on results rather than a fixed fee for sending messages is immaterial in the ICO’s view.

Although an affiliate marketer is a data controller in its own right – and in PECR terms the sender of the message – identifying the beneficiary of the activity as the instigator of the marketing message allows the ICO to use PECR (not the DPA) to target known brands with a reputation to protect, and companies with more positive balance sheets than affiliate marketers. I suspect this is a calculated move as the ICO has determined that targeting the beneficial initiators will be a more successful enforcement strategy.

The ICO’s test therefore will be the degree to which the affiliate appears to be a reward-based postman or an independent company that also promotes other companies’ products/services alongside their own. I suggest that this assessment would look at the arrangement the benefitting company has with the affiliate and to what degree it has control over the volume of email sent, the format, targeting and language used in the message.

It is possible that the ICO’s approach based on the interpretation of instigator in this way would be open to challenge at the Information Tribunal, however none of the parties that have been subject to this interpretation have yet appealed.


  1. | 10 November 2016
  2. ICO letter to gaming companies, revealed in Disclosure IRQ0662096 | 23 January 2017
  3. | 29 November 2016
  4. |
    4 October 2017
  5. |4 October 2017
  6. VBL MPN (n4) paragraph 44, and VBL EN (n5) paragraph 13
  7. VBL MPN (n4) paragraph 45, and VBL EN (n5) paragraph 14

Velocity Checking: One lesson everyone can learn from Tesco Bank

Like many credit and debit card acquirers, when Tesco Bank’s fraud system detects what it thinks is a fraudulent transaction on a cardholder’s account it sends the customer an SMS saying “please contact the bank”. It’s pretty obvious that it doesn’t have any sort of velocity checking on this function — which is why, on the weekend of 5-6 November, over 20,000 Tesco Bank customers received such a text message. Many reported spending a few hours on hold to the contact centre.

You can be sure that if you send out 20,000 SMS fraud alerts, a large percentage of those people will contact you — and Sunday morning is not when the contact centre is going to be fully staffed!

What went wrong

The fraud system should have not treated each fraudulent notification in isolation, but it should have also created a consolidated view across the entire system. As soon as the consolidated view noticed it had sent out an abnormal number of alerts in a 10-minute period then it should have:

  • Paused sending out alerts to customers
  • Sent an alert to the SOC saying “Help, I’ve seen fraud on 2,000 accounts in 10 minutes which is five times more than normal. I think we’re under attack and can you get more people in the call centre for tomorrow morning?”

Of course – the system could also have been clever enough to notice that all these alerts were caused by the same sort of abnormal transaction (in this case magnetic stripe contactless debit card transactions from outside of the UK) and the system could have also set this transaction type to auto-decline. This would have perhaps had the benefit of stopping the fraud continuing.

Lessons for everyone

It’s not uncommon for developers to think of a problem in isolation: “if X happens then assume this account is being attacked so do Y” but developers should also think of the system-wide view. There must be something in a system to address the question “is it just one account that’s being attacked, or is this part of a systemic attack?” Fixing this can be as simple as writing to a log that another process is monitoring — looking for patterns and abnormal velocities — which can then follow its own business rules to detect and respond to systemic attacks.

We can all learn this one lesson from Tesco Bank: think systemically. If you have a system that sends SMSs to customers asking them to call you, or something that locks accounts after ‘n’ bad attempts, how would your organisation respond if 20,000 people tried to call you at the same time?

Consider the OWASP AppSensor

There’s some great thinking about how to get applications to think on a system-wide basis in the OWASP AppSensor project.

Was Tesco Bank hacked?

I’ve read some pretty amazing articles and blogs in the last week that show quite a misunderstanding about how criminals steal money, how payments work and how the new General Data Protection Regulation would both punish Tesco Bank and simultaneously remedy all ills. Cyber security and financial crime is a complex subject and I thought I’d try to look at whether (or how) Tesco Bank was “hacked” a couple of weeks ago.

The short tl;dr version is:

  • No, I don’t think Tesco Bank was hacked – but I think someone else that has lots of Tesco Bank debit card numbers has suffered a breach of confidentiality.
  • Tesco Bank had a problem with how it authorised Magnetic-Stripe-Contactless transactions. That problem could have been misconfiguration, programming error or criminal control of the authorisation system.

If you’re interested in the long version …

I’m going to start with a quick review of the way that money can be taken from current accounts.

1. How criminals steal money from current accounts

Ignoring kinetic / analogue methods, there are two conceptual main ways for a criminal to extract money from customers’ current accounts:

  1. Push transactions – where the funds are pushed from the customer’s account to the criminal’s
  2. Pull transactions – where fund are pulled from the customer’s account.

1.1 Push Transactions

  1. The criminal can compromise the bank’s internal systems, and transfer money directly from multiple customer accounts to accounts owned by the criminals via faster payments / BACS.
  2. The criminal can gain access to the customer’s online banking credentials and then login to online banking, masquerading as the customer and initiate money transfers (faster payments/BACS) or standing orders to accounts owned by the criminals. Criminals can gain access to these credentials either by:
    1. Compromising the bank’s internal systems
    2. Tricking the customer into downloading / installing malware onto their machine which captures the banking details (or manipulates transactions within the browser) – e.g. the Zeus, Panda and Dyre banking trojans.
    3. Sending phishing emails to customers to encourage the customer to divulge their credentials to the criminal
    4. Where banks use simple authentication methods to manage login such as simple ID and password, criminals could re-use IDs and passwords captured from other sites.
  3. Compromising the bank’s webserver and deliver rogue JavaScript to the customer’s browser included in the online banking web page. The criminal JavaScript can then act as a browser-based key- or form-field logger.

1.2 Pull Transactions

  1. The criminal can submit false direct debit instructions.
  2. Where customers have a debit card associated with a current account the criminal can submit a false debit card transaction to the bank. This allows the criminal to get cash, or goods which they then can resell for cash. This transaction could be one of eight types.
    1. A magnetic stripe transaction with PIN to withdraw cash from a non-chip enabled ATM
    2. A magnetic stripe transaction without PIN to purchase physical goods (that the criminal can resell to get cash) from a retailer (in a non-chip and PIN region)
    3. A magnetic stripe equivalent contactless transaction in pre-chip markets (such as the USA)
    4. A Chip and PIN transaction to withdraw cash from an ATM using the cardholder’s card
    5. A Chip and PIN transaction to purchase physical goods from a merchant using the cardholder’s card.
    6. A chip-based contactless transaction (as used in Europe)
    7. An online, e-commerce transaction to purchase physical or digital goods from a retailer
    8. An on-line e-commerce transaction to top up a pre-paid card or pay off a credit card balance – effectively using the debit card to transfer cash to another type of account.

2. What we know

Tesco Bank has reported that about 9,000 accounts were affected and that £2.5 million had been taken from current account customers.

In the immediate aftermath on the morning of Monday 7 November the Bank initially suggested that 20,000 accounts were affected, and that it had stopped potentially fraudulent transactions on 20,000 more.

2.1 What transactions were blocked?

The Bank has been very careful not to use the word hacked. Initially the Chief Executive used the phrase “a systematic, sophisticated attack” and on the Bank’s update page it answers the question

    “Should I change all of my online banking and personal details that you hold?”

with this:

“Tesco Bank has not been subject to a security compromise and it is not necessary for customers to change their login or password details.”

This statement rules out Push methods 1,2 and 3 above as if the online banking system or Tesco Bank’s systems that control this had been compromised, users would have been forced to change their credentials.

Looking at both Tesco Bank’s own online forums and those of Money Saving Expert , it is possible to conclude that the “sophisticated attack” was a pull-type attack using debit cards. The following posts are from Tesco Bank representatives (with my emphasis) on the Tesco Bank community forum:

“Yesterday evening, we identified some suspicious activity in a small proportion of our customer’s current accounts. We have taken steps to protect these account holders and are contacting affected customers by text message. We can reassure our customers that they will not lose out as a result.

All of our customers can continue to access their accounts through online banking and can make chip and pin transactions.”

“We have taken the decision today to temporarily stop online transactions from current accounts. This will only affect current account customers. While online transactions will not be available, current account customers will still be able to use their cards for cash withdrawals, chip and pin payments, and all existing bill payments and direct debits will continue as normal.”

“Hi @TescoBank, does the section above refer to online card payments to retailers, or to Faster Payments I want to make from my account online, or both?
Hi @xxxxx, this refers to online payments to retailers. You should be able to make a Faster Payment as normal from your account by logging into online banking.”

“Hi @xxx, your card has been cancelled but rather than place a full block on the account you are still able to use the card at an ATM and for chip and pin transactions. You’ll be unable to process contactless or online transactions.”

“If you’ve received this text then we will need to have a new card issued to you. Whilst you’re waiting on this you should still be able to use your current card for chip and pin and ATM transactions but not online or contactless ones. Please continue to monitor your account over the next 7 – 10 working days for any suspicious activity and if you notice anything please get in touch.”

These statements rule out the pull method 1 and pull methods using chip-based debit card transactions described above although there is an apparent inconsistency in allowing chip and PIN but blocking a contactless transaction (as contactless in the UK uses the chip as part of the transaction).

2.2 Unused cards compromised?

Additionally a number of customers complained about debit card transactions using cards that had “never been used” (it seems from forum posts that a number of people used their account as a savings vehicle rather than a traditional current account, given the 3% interest paid).

“I have not used this card in a card machine or used it online”

“Given that both myself and my daughter received the suspicious activity text message for cards which arrived in sealed envelopes and have NEVER BEEN USED there is no doubt that Tesco security is sadly lacking.”

“I received both text messages however, what concerns me more is the fact I’ve never used my Tesco Bank card (online, in-store etc). It is still attached to the welcome letter.”

“I have never used any of my cards at any time and never ever done an online transaction using this account, it’s been purely used as a savings vehicle.”

2.3 Contactless fraud report

On the 13th November, the Sunday Times (and Sun) reported that:

“The money was stolen from Tesco Bank accounts by a criminal gang purchasing thousands of low-priced goods using contactless mobile phone payments at retailers in the US and Brazil, including Best Buy.”

So it appears that there have been fraudulent online debit card transactions (and if the Times story is true, contactless debit card transactions) attempted against somewhere between 9,000 and 40,000 Tesco Bank accounts, which were successful against 9,000 accounts. Given the amounts that have been quoted in the forums by account holders (£20.63, £9.33, £827.30, £533.00, £549.31, £28.50 etc) these were not fraudulent ATM transactions as the amounts reported do not appear to translate to round-number values (in GBP or USD), so the transactions look like they happened in a retail environment.

3. Ways to make fraudulent debit card transactions

To make a fraudulent e-commerce retail transaction a criminal would need a combination of the customer’s debit card number (the 16-digit primary account number or PAN), the card holder name, card expiration date and CVV2 security code I say ‘a combination’ because it depends on how much information Tesco Bank requires to authorise a transaction, and how much information the merchant captures at an e-commerce sale.

It is also possible to use the debit card number, expiration date and CVV2 in a normal merchant terminal if the data is keyed into the system using the keypad in a face-to-face environment such as a store (normally used when the chip/mag stripe fails or to process a mail-order/telephone order transaction).

3.1 The contactless conundrum

It’s interesting that both the Times and Tesco Bank themselves mentioned contactless. I was confused when the post on Tesco’s online form said “you should still be able to use your current card for chip and pin and ATM transactions but not online or contactless ones” because in the UK a contactless transaction uses the same security as Chip and PIN; the contactless transaction uses the chip which actually digitally signs the transaction, making fraud really hard because you can’t just steal data and make a clone chip card.

However, the Times reports that the fraudulent transactions occurred in the US and were reported as “contactless mobile phone payments”. If this is true (and I’ve not been able to verify this from a second source) it narrows down the way that the criminals worked because Tesco Bank does not support the two common ways of making contactless debit card transactions: ApplePay and AndroidPay for its Visa debit cards (only ApplePay is supported on the Tesco Bank MasterCard credit card). Given the way that cards are loaded into ApplePay and Android pay, that’s not something the criminals can forge (as far as I am aware) because it requires the active participation of the issuing bank. So if the Times is correct then here’s what I suspect has happened.

In the US a technology was developed called LoopPay ( which used an electromagnetic field to make an old-fashioned magnetic stripe transaction on a non-contactless terminal. The consumer ‘loaded’ their card details into LoopPay and it could be used with any magnetic-stripe reading terminal by just holding the device near the terminal. The LoopPay system generated an electromagnetic field to ‘give’ the data that would be on the magnetic stripe to the old-fashioned card reader.

This technology was bought by Samsung and the hardware to generate the magnetic field is built into the latest Samsung phones. Although using the Tesco Bank debit card is not officially supported by SamsungPay, it would be possible for a criminal to have used the technology to just load Tesco Bank card details into a Samsung phone by writing their own software. When I worked at Visa Europe we were very sceptical about this technology because it doesn’t allow the merchant to validate the signature and all the security features on the physical card (there’s a reason the whole industry spent fortunes on holograms to stop people making fake cards). So that’s one option if mobile phones were used – I’m going to call this ‘electromagnetic magnetic stripe emulation’ or EMSE.

There’s also another possibility: in the US there’s an old-fashioned sort of contactless transaction that pretends to be a magnetic stripe, it was developed before the chip (EMV) version of contactless which is what we use in Europe was deployed. It isn’t as secure as the chip version and wasn’t widely supported in the US – but it could also be that the criminals worked out how to load a Tesco Bank card into an Android phone which emulated the US Magnetic Stripe Contactless (MSC) type of transaction. If the Times story is true then my instinct is that the attack would have used either EMSE or MSC.

Even then the criminal would need more than just the card number – there’s a secret card verification value (CVV) encoded on the magnetic stripe alongside the account number that the card issuer (i.e. Tesco Bank) should validate when it approves a magnetic stripe transaction.

4. Two key questions

There are two key questions to be answered:

  1. Where did the criminals get the data from that they used to make fraudulent debit card transactions?
  2. How did they make those transactions in a way that they would be authorised by Tesco bank, and not identified as fraudulent transactions and rejected?

4.1 Data

Firstly then as there were fraudulent transactions made against (let’s say) 20,000 Tesco Bank current accounts – where did the criminals get the card data from?

There are six possible options:

  1. They stole it from another online retailer.
    I’m going to suggest this as the least favourite option because the attack was just against a Tesco Bank. If the criminals stole this much debit card data from another retailer, then lots of banks would have been attacked, because if the criminal got the details of 20,000 accounts out of Tesco Bank’s 130,000 accounts it means they have lots more HSBC, Lloyds and Barclays to use. And given that Tesco Bank only has 130,000 accounts out of a UK population of around 30 million debit cards, the only place that a criminal would be able to get say 20,000 would be a retailer taking something like 90 million card payments a year. Of course this could have happened, and the criminals only targeted Tesco Bank, or every bank was targeted and only Tesco Bank had a ‘problem’ with how it authorised transactions. But if this were the case I think we’d have heard about it. If this has happened, there’s a very big data breach from a retailer hiding in the wings.
  2. They aggregated it from lots of other online breaches over the past few months because they were particularly targeting Tesco Bank as they were aware it had a problem with how it authorised online/magnetic stripe transactions and so would provide a way of extracting cash that they couldn’t do from the other UK banks. Again, because of the small number of Tesco Bank cards in circulation, this seems to be unlikely.
  3. They obtained the card data from on-line banking attacks against the customers through phishing or malware on the customer’s machine. Tesco Bank was the subject of several high-volume phishing attacks earlier this year. However this is unlikely given that the Bank has made the assertion that customers need not change their passwords.
  4. They stole it from Tesco Bank.
    I’m going to suggest this is unlikely. Given that the public statement that “Tesco Bank has not been subject to a security compromise” and given the way that the Bank handled its press incident response this week, I’d be astounded if the bank was lying about this and would risk the enhanced regulatory wrath that a deliberately misleading public statement would generate.
  5. They stole it from another part of the Tesco group (such as Clubcard accounts) that has access to Tesco Bank debit card numbers or Tesco retail stores where Tesco Bank debit cards would be more highly utilized.
  6. They stole it from a third party — such as the company that made the cards or one of the third-party processors that Tesco Bank uses. This is not impossible as it is well-known that Tesco Bank outsources many of its core banking systems. But again I come back to Tesco Bank’s own statement that the bank hasn’t been subject to a security compromise and again I’d be surprised, given how closely the regulator will look at this incident, if this was weasel-speak to cover up a third party breach. I’m also aware of the security audits (from Visa etc) that the card manufacture and personalisation companies have to go through and I’m going to say this is an outside possibility.

Made up random card numbers?
There’s also another (improbable) option, that the criminals didn’t steal the debit card data, they just made Tesco Bank debit card numbers up at random, and tried them!

The numbers of all Tesco Bank debit cards will start with the same first six digits – this is known as the Bank Identification Number or BIN. For an example let’s assume this is 468738 – the criminal could guess a valid card number would be 4687 3800 0000 0008 (because of the way the checksum works with card numbers, this is the first valid card number that would begin with 4387 38 – the next one is 4687 3800 0000 0016). So the criminal can generate many thousands of valid card numbers and perhaps this technique — combined with some aggregated data from other cards to help them narrow the range of cards down — would give them data that they could use to try to get transactions authorised.

This is relatively unlikely (moreover it isn’t a very “sophisticated” attack), but until we know more it must be considered a theoretically feasible attack. However, given the comments in the Times suggesting that the fraudulent transactions happened in retail stores, an attack based on generating ‘random’ valid card numbers seems highly unlikely because the chance of success of randomly generating a valid issued card number is so low, a criminal wouldn’t waste this on a cash-out-mule who puts themselves at some degree of risk by making an in-store physical transaction.

4.2 Authorisation

The Tesco Bank authorisation systems authorised transactions that they shouldn’t have. There are a few reasons this may have been so.

  1. They were not set up to properly validate the CVV2 value for an e-commerce transaction.
  2. They were not set up to properly validate the CVV for a magnetic stripe transaction.
  3. They had never been configured to recognise a magnetic-stripe-contactless transaction and so these transactions bypassed the normal authorisation route.
  4. A criminal had gained unauthorised access to the debit card authorisation system and had re-configured it to permit rather than decline these type of transactions.

5. My Hypothesis

My best guess at the moment is that the criminals secured a large batch of real Tesco Bank debit card numbers; I think it’s most probable that it came from a leak from a third party or related company. Given the number of cards used, a merchant breach (or an aggregation a number of previous breaches from merchants) seems unlikely. Additionally this does not correlate with the customers’ claims not to have ever used their cards on the Bank’s forum.

The criminals then used this data to make online and physical electromagnetic magnetic stripe emulation contactless or the US magnetic stripe contactless transactions.

But remember both a magnetic stripe transaction and an e-commerce transaction generally need more than just the account number for the transaction to complete. The magnetic stripe contactless needs the card verification value (CVV) which is encoded in the magnetic stripe and the e-commerce transaction the card verification value 2 (CVV2) which is normally printed on the reverse of the card. This data is transmitted along with the account number and expiration date to the card issuer (in the case Tesco Bank) so it can validate that the real card has been used.

So either

  • the data for the CVV and CVV2 came from the third party that would have had both the account number and these numbers – which could only be one of just a couple of Tesco Bank’s core outsourcing partners; OR
  • Tesco Bank didn’t recognise the ‘magnetic stripe contactless’ transaction type and therefore did not validate the CVV when the Bank authorised the transaction, and the criminals just submitted ‘random’ CVV values.

Given that it is currently reported that both fraudulent Magnetic Stripe and E-commerce transactions were made the only place a criminal could have got the data elements to make both those types of transaction (account number, CVV from the mag stripe and CVV2 from the back of the card) would be one of the Bank’s core processors (either the company that personalised the debit cards, or the company that authorises transactions). I’m really sceptical of a data breach at one of these two core processors (although it would be William of Occam’s preferred explanation).

My guess is that the authorisation systems at Tesco Bank, which should have spotted that these transactions were fraudulent, were either misconfigured, or were in the control of a criminal and therefore didn’t validate the CVV or CVV2 values when faced with a ‘magnetic-stripe-contactless’ transaction.

6. What action might be taken against Tesco Bank?

Some commentators have suggested that the Information Commissioner’s Office, through the Data Protection Act (and its successor the General Data Protect Regulation) would have cause to take action against Tesco Bank. The ICO is the least of Tesco Bank’s worries – even if there was a contributory breach at a third party service provider to Tesco Bank. The Bank is regulated by the Financial Conduct Authority and the Prudential Regulatory Authority (part of the Bank of England). Both bodies have the capabilities to levy unlimited fines, replace management and — in the worst case — remove Tesco’s banking license. The FCA and BoE do not like to see bank security problems on the front page of a newspaper — they are concerned about the effect that this has on the general public’s trust in the banking system. If it turns out that the fraud was enabled by a misconfiguration or criminal attack on Tesco Bank’s debit card transaction authorisation system, then their financial regulator will question whether the Bank had adequate systems and controls in place to prevent financial crime and will take the appropriate action.

Additionally, as the fraud was committed on Visa debit cards, I assume my ex-colleagues in Visa Europe will have some strong words with Tesco Bank!

Notes and sources

I’ve prepared this analysis from public news reports, statements from Tesco Bank and from information in public forums found on the Internet. My good friend and ex-colleague, Colin Whittaker of Informed Risk Decisions, helped with the analysis of the possible options.

Thirty-two really fun PCIP, QSA or ISA revision questions

I put together this series of sample PCIP questions and answers to help a friend who was revising for her PCIP exam. She passed and so I hope you also find them useful. It is a while since I actually took a PCI SSC exam and so these questions might not reflect the way that the PCI SSC currently asks questions or how they phrase their answers, however they should provide a useful knowledge test so you can discover your strengths and weaknesses.

The answers are contained in a downloadable PDF – there’s a link to it at the end of the questions.

The PDF is password protected – and the password is encryption

If you’d like some more training then I can recommend my PCI courses at Pluralsight:

Payment Card Security, Processing, and the PCI Standards
PCI DSS: The Big Picture

So here are the questions. For each one there is only one correct answer. Enjoy.

Q1 What information must be included in the network diagram?
A: Firewalls, routers and switches
B: Connections between other networks and the CDE excluding wireless networks
C: All connections between the CDE and all other networks
D: Wireless access points and firewalls

Q2: A merchant only accepts payments via the telephone and they enter the cardholder data directly into a webpage provided by their acquirer. Which SAQ is most likely to be the one the merchant should use?

Q3 How frequently should cardholder data that is beyond the specified retention period be deleted?
A: Immediately

B: Weekly
C: Monthly
D: Quarterly

Q4 If video cameras are used to monitor physical access to the CDE, how long should the logs be kept for?
A 1 month
B 3 months
C 6 months
D indefinitely

Q5. Who can approve the configuration of routers and firewalls protecting the CDE?
A: A QSA must approve the configuration
B: No specific approval is required, the person in charge of making changes to configuration just needs to make sure that that all changes are correct
C: A senior executive must approve the configuration
D: Someone independent from the person that changes the configuration must approve the configuration

Q6 When is it OK for a merchant to store the CVV2 / CVC2 value
A: When it is encrypted using strong cryptography
B: When the merchant does not store, process or transmit PANs as well
C: It is never permitted for a merchant to store the CVV2/CVC2 value
D: Temporarily, before a transaction is authorised by the acquirer

Q7 Which PCI credentials entitle someone to sign a Report on Compliance
B: ASV and QSA
C: QSA and ISA

Q8: Which PCI standard helps secure physical devices used to read cardholder data such as magnetic stripe and EVM chip readers

Q9 Which PCI standard would have requirements that controlled how an issuer looked after blank payment cards before they were personalised with the customer’s name and PAN?
A: None – card without PAN are not covered by PCI Standards
D: PCI Card Production

Q10: Where does the standard require the use of a DMZ
A: Systems that provide authorised publicly accessible services must be in a DMZ
B: A DMZ is required to store cardholder data
C: A DMZ is required between wireless networks and the CDE
D: The standard doesn’t require the use of a DMZ

Q11: Sarah uses her laptop at home and also when she is in the office and connected to the CDE. Which of the following controls should be applied to Sarah’s laptop to comply with PCI DSS?

A: The laptop should be tested by the IT department before Sarah connects it to the CDE
B: Sarah cannot have access to the USB ports on the laptop
C: The laptop must have personal firewall software or an equivalent installed
D: Sarah cannot access wi-fi networks

Q12: Which entity in the payment ecosystem provides consumers with payment cards
A: Card brands
B: Card brands and issuers
C: Issuers
D: Card brands and acquirers

Q13 When can you use cardholder data in test environments?
A Never
B When troubleshooting
C Only when authorised by a QSA
D When supervised by a PCIP and deleted after use

Q14: Which of the following is not considered sensitive authentication data (SAD)
A Service code
D Full magnetic stripe track data

Q15 Is it OK to use Telnet for administrative access to the routers in your CDE?
A: Of course
B: Yes, if it is encapsulated in an encrypted VPN
C: Yes, if the routers do not support SSH
D: It is never OK to use telnet for administrative access

Q16 In the payment process what step typically follows authorisation?
A Clearing
B Acquiring
C Settlement
D Funds release

Q17 Which of the following is not an example of multi-factor authentication?
A: A username, password and certificate
B: A fingerprint and a password
C: A username, password and secret phrase
D: A smart card and an iris scan

Q18 What special provisions apply to public facing web applications?
A: None
B: Use automated code automated application vulnerability security assessment tools or methods AND a web application firewall
C: Use automated code automated application vulnerability security assessment tools or methods OR a web application firewall
D: Use real-time security monitoring tools

Q19 How many hours of CPE must a PCIP accumulate each year?
A: 5 Hours
B: 10 hours
C: 20 hours
D: 40 hours

Q20 A company’s mainframe doesn’t support encryption – so it is unable to comply with requirement 3.4 – what should the company do?
A: As this is a legitimate technical constraint, the company should develop appropriate documented compensating controls
B: Ask the QSA if it can ignore requirement 3.4
C: As the mainframe does not support encryption, mark the requirement as not applicable (N/A)
D: Request a PCI waiver from the PCI SSC

Q21 Which PCI standard would apply to a merchant that had purchased and was using a validated PCI P2PE solution?
D: None because the merchant only has encrypted data

Q22 Where does the standard require the use of firewalls?
A: Between the internet and the CDE, a DMZ and the internal network, between wireless networks and the CDE
B: Between the internet and internal networks
C: Between the wireless networks and the CDE, between the internet and the CDE
D: The standard does not require the use of firewalls, they are just recommended

Q23 Which of the following can be used to transmit cardholder data?
A Email
B Instant messaging
D Encrypted communications

Q24 How quickly should critical patches be applied?
A: As soon as possible
B: Within 7 days
C: Within one month
D: Within 3 months

Q25 When should a company make use of a compensating control?
A: When it cannot afford to implement a PCI DSS control
B: When its own risk assessment suggests a PCI DSS requirement is not needed
C: When a QSA runs out of time in the company’s annual assessment
D: When the company cannot meet the requirement due to legitimate technical or documented business constraints.

Q26. Which words in the right order complete this sentence? In a four-party model, a merchant transaction flows from the merchant to the _________, then the _________ and finally to the __________
A: Issuer, Acquirer, Card Brand
B: Card Brand, Issuer, Acquirer
C: Acquirer, Card Brand. PCI SSC
D: Acquirer, Card Brand, Issuer

Q27 Why would a merchant typically use a QIR?
A: After a compromise of cardholder data
B: To prepare for a new PCI DSS assessment
C: To purchase a PCI DSS compliance certificate
D: To implement a PA DSS application

Q28 Are stateful firewalls _______ for connections into the Cardholder Data Environment?
A: Recommended
B: Required
C: Optional
D: Not mentioned

Q29 If PAN is to be stored in a database, which of the following is not an acceptable way of storing a PAN?
A: Encrypted using strong cryptography and key management
B: Split into two parts, each half stored in a separate table
C: A one-way hash based on strong cryptography
D: Truncated

Q30: What entities may conduct external vulnerability scans?
D: A Penetration Tester

Q31 How quickly must inactive accounts be removed or disabled?
A: After 30 days’ inactivity
B: After 90 days’ inactivity
C: After 180 days’ inactivity
D: After one year of inactivity

Q32: What sanction does the PCI SSC not have against a PCIP who is in contravention of the PCI SSC Code of Professional Responsibility?
A: Issue a warning to the PCIP
B: Issue a warning to the PCIP’s employer
C: Suspend the PCIP from all PCI Programs
D: Revoke the PCIP qualification

And here’s a link to the answer sheet. Remember, this is password protected and the password is encryption. If this is useful please make a donation to a charity that means something to you 🙂

Webcast on Thursday 11th August

On Thursday 11th August at 6pm London (or 10am if you’re in San Francisco) I’ll be giving a webcast of my popular RSA Conference presentation, “How to Explain Cybersecurity to the Board Using the Simple Metaphor of fire”. You can register here:

I presented this on the first day of RSA Conference in February and I assumed that because it was the Monday before the conference proper started not many people would come. I was really wrong. The room was full and I understand some people couldn’t get in. Some of the feedback I had afterwards included:

Speaker provided clear and constructive recommendations to facilitate discussion of technical subjects with non-subject matter experts. Very enjoyable.

This was a fantastic presentation and provided a great insight on a different way of thinking about presenting security with a publicly recognizable twist. Will definitely use his analogies in the future.

So if you’d like to find a simple way to explain some of the cyber security principles to colleagues and your C-suite this webcast may be useful. If you can’t attend in real-time I understand that a recording will appear on the RSA Conference website afterwards.

In memoriam requirement 1.3.3

It is rare for the DSS to get smaller, each version typically adds a few requirements based on lessons from forensic investigations of breaches of cardholder data. However, in the summary of changes from version 3.1 to version 3.2 published this week I noticed:

1.3.3: Removed requirement as intent is addressed via other requirements in 1.2 and 1.3.

Perhaps, the resident threnodist at Private Eye (a satirical British newspaper) would mark its passing thus:

So farewell then requirement 1.3.3
“Prevent direct internet connections to the CDE”
was your request

People asked, does that require
a proxy server
or just a firewall?

You inspired
pedantic discussions
on the meaning of “direct”

Although you are gone
Your proxy servers live on

EJ Thribb (17½)

Is your employees’ privacy one of the first casualties in the battle to secure your information systems?

I’m speaking about the trade off between network security and employee privacy at the International Association of Privacy Professionals (IAPP) European Data Protection Congress in Brussels on the 2nd December.

In the face of modern cyber-threats, communication monitoring and surveillance are essential for the protection of corporate information. But monitoring technology is often intrusive of the privacy of system users and, ironically, the capabilities of modern cyber-solutions can bring increasing privacy risks for system users. What are the threats to user privacy of IT monitoring and surveillance tools that allow network communications to be retained for subsequent analysis and replay? What are the legitimate expectations of privacy in the workplace? How can the tensions be reconciled? Here, we will examine the threats presented to the privacy of system users by latest-generation monitoring technologies. We will explore the challenges involved in reconciling the need for robust system security with legal obligations to respect the privacy of system users. We will also consider strategies for managing these challenges and associated legal risks, including PIA and security risk assessments.

What you’ll take away:

  • An understanding of the privacy risks posed by latest-generation monitoring technologies.
  • Strategies for minimising privacy risks, including an appreciation of the role of consent in programmes of workplace surveillance both now and under the draft GDPR.

I’m really pleased to be co-presenting with Heledd Lloyd-Jones, a specialist privacy lawyer with Bird & Bird. Heledd sparked my interest in the intersection of privacy and information security seven years ago when I attended her brilliant ISEB Protection training course.

There are lots of other really interesting sessions at the conference, I’m really looking forward to The Ten Million Dollar Question: Managing Privacy Risks in Your Supply Chain and Cloud Privacy: How Do International Certification Standards Fit with the Proposed EU Regulation?

Registration for the conference is open now.