Article

New Approaches to the SWIFT and PCI-DSS Framework

swift-pci-dss
UNIX, Linux
Posted:
March 13, 2017

 

THE WORLD OF COMPLIANCE

At the official start of summertime 2016 in Britain we are starting to consume the labour of last autumn, five gallons of alcoholic homemade cider (yum!) made from eight apple varieties grown in mine and my neighbors’ gardens. I’m very VERY careful sterilizing glassware, containers, and buckets: there was this unfortunate incident three years ago (no, you don’t want to hear the horrible details), enough to say I watch each step like a hawk to ensure a batch does not become tainted.

Why am I bothering you with my alcoholic side-line?

  • The latest version of the Payment Card Industry Data Security Standard (PCI-DSS) framework arrived at the end of April with a loud thud, and a fair amount of “OMG!” content for anyone processing credit or debit cards worldwide.
  • During the four weeks long of May 2016 the Society for Worldwide Interbank Financial Telecommunication (SWIFT) has been hammered by their member organizations, worldwide press, national central banks and infosecurity commentators to begin a major change in its security posture after more than 100 million US dollars has been defrauded from banks in Asia, Africa and South America.

As I understand it hard cider cannot be sold in the USA unless it is pasteurized. In the UK non-commercial homemade cider is usually straight from nature. After ten years of practice, (so a fair track record of not poisoning my neighbors) a bottle or two this year will be entered at my village’s Produce Show for competition in September. It is nice when friends say they like what you make, it is a whole other ballgame submitting to formal judging, with a hope of a RHS Class certificate and/or silver trophy if you win.

For both SWIFT and PCI, the assurance offered by their brands has taken a nose-dive, the security threat landscape has changed drastically publically in the last six weeks. Both infrastructures and the assurance and change management processes around them have traditionally been fix for a period of years. They are both going to have respond in an ongoing and timelier manner to evolving threats of attack.


PAYMENT CARD INDUSTRY, A STATIC TO DYNAMIC THREAT POSTURE

In the past PCI’s policies and recommendations ran on a three year major version change cycle. Credit card processing organizations (like retailers, transportation companies, insurers and banks) would setup processing servers and services based on the latest PCI-DSS recommendations. PCI-DSS projects would have the overhead cost of running the services, and work out a flat payment margin for their end customers for a three or five year period.

This has not stopped PCI-DSS certified end-companies from being hacked (for example Target and Anthem in North America), additionally elsewhere security protocols have been easier to break with modern desktop PC technology (SSL V2 & V3). As a result PCI has issued version 3.2 of their requirements:

  • Web interfaces that process card payments need to move from SSL to TLS (by 2018)
  • Remote administration access to card processing SWIFT and PCI-DSS: New Approaches Needed for Assurance in a World of Non-Stop and New Requirements infrastructure (servers and network routers) MUST use Two Factor Authentication by Spring 2017.
  • Card processing Service Providers, usually intermediaries for SME retailers will need to separate PCI services and infrastructure for each end-customer. This is going to be commercially interesting, as margins for these suppliers can be wafer-thin, and aggregating their services and making the PCI transaction-handling infrastructure as small as possible to reduce compliance costs has been their approach so far. Now that is going to have to change radically.
  • Organizations that have actually been hacked (PCI compliant or not) have additional severe “Naughty Step” assurance and compliance processes, that will keep a brand-new full time project team busy, and holding the toes of executives to a hot fire to account for process and other operational changes. How that is going to pan-out is up for debate.
  • Version 3.2 will be the last major version published. Going forward there shall be a series of Appendices for specific verticals’ challenges, or specific technical architecture weaknesses. These can be published at any time.
  • Version 3.2 takes effect from 1st November this year. For those organizations who only carry out their PCI audit annually, this will be a major shock before calendar year-end.

There is a tricky and conflicting set of actions that you need to consider:

  1. Passwords, SSH keys, and other “simple” ways of authentication are dead, dead, DEAD! Two Factor Authentication solutions were required for remote service teams in the past. Now it impacts all support staff. Your management staff in the store, your PCI service provider, and any third party consultants who periodically visit your site(s). You need to plan for this new project NOW, as you have less than a year to bring it into production. If not in place at your next PCI audit, you will need to show an effectively deliverable plan to your auditors to meet the 2017 deadlines.
  2. Service providers serving SME customers will need to intrude further into end-customer systems, ensuring customer’s own support staff are using 2FA correctly. If not, the end-to-end PCI audit fails. This is an interesting added value service component deepening the relationship between the two parties. The customers must have 2FA, but may have no skills to implement themselves. Low hanging fruit for the taking by those providers who see the opportunity, and who can begin the sales development process now.
  3. Payment card Service Providers however need to split and segregate their processing infrastructure, ensuring a service failure for one of their (retail) customers will not impact others. Providing verification to auditors, and at the same time assurance to the business owners of end-customers could get expensive.
  4. Take up of the switch-over to TLS from SSL is generously slow, as making changes to every retailer’s systems world-wide will take time. Now PCI have started incremental changes to their framework, it would only take one serious breach to accelerate that timeframe, and you should hustle to get your changes completed asap.


SWIFT – A DECADE OLD INFRASTRUCTURE NEEDING TO RESPOND SWIFT

last updated their major network architecture (SWIFTNet) and security practices in 2005, when services were switched to an IP based set of solutions. Message format for SWIFT Payment Orders is now XML based, and transaction security was enhanced with a relationship management application (RMA) which went live in 2009. Many of SWIFT’s solutions are offered as turn-key products, exactly the same infrastructure and processes are replicated in thousands of financial services organizes, typical deployment models creating a common technical attack footprints replicated hundreds of times worldwide. However (say a bank) member’s own surrounding security practices can be appallingly weak.

A vague five point plan was announced recently, focused at its community and membership:

  • Improve information sharing globally (very nonspecific)
  • Enhance SWIFT related tools for customers ( amongst non-specific security changes recommending 2FA, but not mandating it)
  • Enhance guidelines and audit frameworks (starting to think along the lines of the PCI framework)
  • Support increased payment pattern controls (a mandatory approach required by their members to stem the odd behaviours seen in more than $100 million losses over the last six months)
  • Enhance support by third party vendors (Surprise! – SWIFT solutions are part of multi-vendor infrastructures. The day of the SWIFT Terminal are long gone)

But so far this has not been enough to reassure the marketplace. The brand has been affected, and so result SWIFT has this week just announced a sanctioning scheme to cut off access to SWIFT services to member organizations with poor overall security. (https://www.swift.com/customer-security-programme)

It sounds like finally SWIFT will publish an evolving baseline security requirements framework, with a hard business sanction of withdrawing services if it harms SWIFT’s brand, image, and commercial reputation. Just like PCI has been doing for the past five years.

Dragged kicking and screaming, always on the back foot, the SWIFT cooperative is changing its posture and communications with its membership almost weekly.
 

TAKE-AWAY

PCI and SWIFT operate in the same marketplace, the assurance that financial transactions remain safe, and have been “branded” as safe. Both PCI certification and SWIFTnet have taken hits over the last two years.

PCI is significantly younger than SWIFT, however it looks like some version of its framework will be taken up by its elder brother. The threat to its brand has forced SWIFT to announce a hard commercial threat, similar to the one PCI has been operating on for years.

“If you are not certified, and continually audited, we will withdraw our services, and your transactions cannot use our networks”. That tends to focus the mind if you are a Board level executive.

 

LOOKING FOR COMPLIANCE SOLUTIONS?

Learn how BoKS ServerControl can help you meet, and stay compliant.

Related Products

Related Solutions