Posts by: Paul B

Changes to the Issuer Identification Number (IIN) standard

The numbers on payment cards are going to become longer. This is because of changes which are being made to the international standard (ISO/IEC 7812) under which Issuer Identification Numbers (IINs) are issued. The changes have come about because of the increasingly dwindling number of IINs that remain open for registration.

IINs currently appear as the first six digits on payment cards. The leading digit is the major industry identifier (MII), followed by five digits, which together make up the IIN. But due to an increasing demand for these unique identifying numbers, the International Organization for Standardization (ISO) is expected to publish revised standards which will change IINs from six to eight digits. The overall Primary Account Number (PAN), which is generally understood to reflect the IIN plus the unique number assigned to an individual or company, may consequently increase in length to reflect this change.

Visa announced in July 2015 that it expected that they would continue to support a PAN length of 16 digits. This was after stakeholder consultation within the industry. A change that is seemingly as minor as this turns out to have some significant ramifications to any entity that accepts payment cards in that the application are generally designed to expect card numbers of certain lengths, depending on the card issuer. Changing these values would require updated software in all devices or systems that accept a payment card – no small task.

So what about the security implications of this change? If the IIN is increased to 8 digits and the PAN remains 16 digits, the unique value assigned to the card has in effect been reduced from 10 to 8 digits. Does this pose a potential security weakness to card numbers? This point has not been missed by the industry and discussions are afoot to try and counteract this change.

The draft of the revised standard has been approved by ISO members and is due to be published in early 2017. Businesses and organisations which require IINs should be aware of these imminent changes and should begin a process of planning and analysis to identify any potential system and process impacts. At the moment it is all conjecture, but it seems likely that something will have to change at a standard level before vendors start to make updates to their software and merchants start rolling these changes out.


The main points of the revised version of the ISO/IEC 7812 standard are:

  • The Registration Authority (RA) will start assigning eight-digit IINs to any institution applying for a single IIN or block of IINs.
  • Issuers with eight-digit IINs will be required to issue a minimum PAN length of ten digits. The maximum will continue to be 19 digits in length, (with Visa supporting the current standard of 16).
  • Existing six-digit IINs will be converted into a block of a hundred eight-digit IINs. As the majority of issuers are unlikely to need all one hundred of these, they are encouraged to return any unused eight-digit IINs to the RA.
  • Any ISO/IEC standards referencing ISO/IEC 7812-1 should be reviewed for potential impacts.

All users of ISO/IEC 7812-1 are strongly advised to begin planning and analysis to identify any potential system and process impacts associated with their plans to adopt the new standard.

The security implications of the extended IIN lie in the detail. Visa are currently undertaking systems analysis and development, which they expect to be complete by 2019, three years ahead of the proposed change. Currently the PCI standard is only built to accommodate the masking of the first six and last four of the sixteen digit card number. It may be that the PCI council will have to have a look at changing the standard to accommodate this new field length without altering the security posture of the masking.

Information Security Consultant, SRM's Principal PCI DSS QSA and Payment Card Industry expert, Paul B is a regular contributor to the SRM blog.

A Cautionary Christmas Tale


‘Twas the night before Christmas, and all through the house,

Not an iPad was stirring, nor PC or Mouse;


The shopping had been done on the internet with care,

In hope that the presents soon would be there;


The payments were processed, at least in their heads,

Until they found out their account was in shreds;


What should have resulted in toys in gift wrap;

Had led them into an elaborate trap,


The fraudsters had found an outdated website;

And changed the checkout so it wasn’t quite right,


Away to the next site, Dad went like a flash;

Not knowing his card was in the fraudsters stash


The website looked fine but ‘twas misdirection;

He’d fallen foul of Sequel Injection,


The site wasn’t bad, that should be made clear;

But the standards ignored, no PCI here.


With hackers so many, so lively and quick;

The change was so easy, it was done in a click,


So please spare a thought, when you next do your shopping,

And check that the site that you found while you’re hopping,


Is up to the standard to which we’re reliant;

And make sure it’s one that is PCI compliant.


Information Security Consultant, SRM's Principal PCI DSS QSA and Payment Card Industry expert, Paul B is a regular contributor to the SRM blog.

The Internet of Things and how your doorbell might just be attacking Amazon

We hear a lot about the Internet of Things (IoT) on the web nowadays and the TV is full of adverts for Central heating systems that you can control from your smartphone or tablet. There are Wifi enabled doorbells that contact you on your phone when the postman is leaving you a package at home and IoT light bulbs and power sockets can be bought at your local DIY store nowadays too. It looks as though this is mainstream now, and not just for us techie blokes who like something new to talk about in the pub.

The big unanswered question at the moment is how safe are these things? There have been some horror stories about Wifi enabled Baby monitors exposing images of sleeping children to the world and the most recent case of the Mirai malware found on IoT devices demonstrates just how susceptible any internet connected device can be to exploit. In the Mirai case, malware was deployed to various devices globally but it seems that a large proportion of them may have been IoT devices. The malware was responsible for a huge Distributed Denial of Service Attack (DDoS) aimed at the domain name server, Dyn on October 21st. This in turn disrupted services as far and wide as Amazon, Netflix, Paypal, Twitter and Github…serious stuff then, but how on earth did this happen?
To the average user, these IoT devices are just appliances that you plug in and forget about, so how could they be developed into a threat? Well, by their very nature, they are not to be thought of in the same way that I think about my good old fashioned Duallit Toaster. These devices are intelligent and programmable and can be susceptible to malware in the same way as your desktop computer. The same security precautions should be taken to ensure that they do not pose a threat.


The Mirai Malware turns the infected device into a member of Botnet, a collection of devices that can communicate with one another for various means, (the word Botnet is derived from the words Robotic and Network.) This piece of malware has been responsible for several DDoS attacks in the last 12 months but the attack of the 21st Oct seems to have been the most significant in size. It would appear that the number of IoT devices that are becoming infected is on the increase and there is strength in numbers – in fact, Botnets rely on this.

So, what can be done? Well, it is often hard to tell if your Webcam or Doorbell has become infected as it still operates as normal. It might get a bit temperamental at times, (but don’t we all). It is important however to ensure that the firmware is updated regularly and that any default passwords and accounts are removed upon installation. The Malware checks for open default accounts and utilises these to gain control of the device. It has been the advice of many security experts over the years but now it really does hit home – Remove any default accounts and passwords from any device before you intend to use it and check that the firmware is kept up to date. It might go against the grain to patch your doorbell or your webcam but it might just be possible that it is launching at attack on a global website, whilst you sip your coffee……food for thought indeed!

Information Security Consultant, SRM's Principal PCI DSS QSA and Payment Card Industry expert, Paul B is a regular contributor to the SRM blog.

Multi Factor Authentication – why is this something that is so commonly misunderstood?

“The single biggest problem in communication is the illusion that it has taken place.” said George Bernard Shaw. This can be true in so many aspects of life and unfortunately, it is all too often reflected within the world of Information Security. It is common for many of us to think we have got to grips with a solution to a problem, only to realise half way through that the problem is not quite as we envisaged.

Take the case of “Multi Factor Authentication” (MFA), meaning the use of multiple methods of authenticating ourselves to one another, or to a computer system or application. We had all become used to the phrase “Two Factor Authentication”, meaning that we need two different credentials to provide this authentication. Seem simple enough to extend this out to “Multiple” means of authentication right?

Well – as it turns out, this is still an area that causes confusion, even before we changed the wording to make things even more vague! So, what is the problem? Let’s go back to the start.

We all use MFA without giving it much thought on a regular basis. Whenever we go shopping or take money out from an ATM, we are using MFA. In short, in any Chip and Pin transaction there must be multiple authentication methods, and these usually fall into the following categories:

  • Something you know (such as a password or PIN)
  • Something you have on your person (such as a Bank card or a USB stick generating a Token)
  • Something you inherently are (such as a biometric like fingerprint or retinal scan)

When accessing a system that requires you to authenticate yourself in more than one way we present two or more of these values to the authentication system. So why is there still confusion?

Well – it is easy enough to get this mixed up. Take the following scenario into consideration; “I log onto a system with my username and password, and then I access a database application with a separate user name and password. That is Multi Factor isn’t it?” – NOPE!……this is single factor being used multiple times, and is often the cause for much confusion.

In order for Multi Factor authentication to be truly implemented, at least two of the above means of authenticating yourself must be presented as part of the same log on procedure. So I present my User name and Password to my access application, which then also requests my fingerprint. This is two factor authentication. MFA is any access method that requires 2 or more authentication factors.

In the case of the trip to the shops, when I purchase something I present my payment card (something I have) and then I must enter my PIN, (something I know). 2 Factor Authentication. Apple Pay brings in another element in that it uses biometrics as the second factor, which is another step up the security ladder.

This is something that will affect us all in our daily lives as security tightens up to reduce identity theft and online fraud. How many of us have been given a PIN reader for use with our online banking accounts? This is generating a ‘second factor’ token for you to use alongside your password.

The PCI DSS version 3.2 now requires the use of Multi Factor Authentication for administrators accessing Payment Card systems from within the local network. MFA was previously reserved for remote access but the additional security that MFA brings is such that it is a useful tool, even from within trusted systems.

So, MFA is here to stay and when it is implemented well it should be easy and intuitive to use. There are lots of solutions out there, so finding one that suits your needs should no longer be a barrier to increased security.

Information Security Consultant, SRM's Principal PCI DSS QSA and Payment Card Industry expert, Paul B is a regular contributor to the SRM blog.

What are the common failure points of repeat info-security assessments?


Maintaining Compliance with any Information Security Standard is often a long and winding journey. You never quite know what is over the horizon or around the bend, so what things should we look out for when the times comes for that difficult second audit?

Long and Winding road

‘To lose one parent may be regarded as a misfortune; to lose both looks like carelessness’. So said Oscar Wilde. Of course, he was referring to human relationships rather than info-security audits and, like Mr Worthing in ‘The Importance of Being Ernest’, sometimes it is no one’s fault when a second misfortune strikes. But in the case of repeat info-security audits, we can see from the common failure points that there are lessons to be learned.

Common failure points in repeat assessments are:

  • Staff are not accountable and as a result, various tasks have not been completed. For example, the six-monthly Firewall Review. If it has not been diarised and no one has been given the task, who will remember?
  • Internal scanning is not always performed with the same diligence as external scanning. In reality they both require the same approach.
  • Payment procedures have been introduced that are at odds with the established methods for processing card data. A defined payment strategy is a great help here.
  • System patching: critical patches have not been risk assessed and may not have been applied within the 30 day window. A robust patching procedure is essential to limit exposure to risk.
  • Vulnerability scanning has identified errors that have not been fixed within the correct timescale or have not followed the correct change control or remediation process. Please note, an auditable process is required here.
  • Storage of encrypted card data: as part of the data discovery process, unencrypted card data is often found on desktops and servers. This is often in the form of unsolicited emails but breakdown in the payment strategy can lead to staff using unapproved methods of communication with customers.

A repeat info-security assessment tells you that whatever you did first time round was not sufficient to keep your organisation compliant. Like an MOT, a security audit is only a ‘snapshot’ of an environment at a given time. All too often, a security assessment is seen as a ‘tick box’ exercise rather than a programme of ongoing maintenance. For more on developing an effective Info-Security strategy, read our blog on ‘Navigating the minefield of info-security compliance’.

Information Security Consultant, SRM's Principal PCI DSS QSA and Payment Card Industry expert, Paul B is a regular contributor to the SRM blog.

SRM Blog

SRM Blog