Search

Brian Pennington

A blog about Cyber Security & Compliance

Tag

Payment Card Industry Data Security Standard

ADVICE FROM AN ASSESSOR: DevOps, Automation, Security and Compliance

By Andrew Barratt, QSA, PCIP.  Managing Director, International/Managing Principal, Payments, Application Validation
Coalfire; Manchester, UK, http://www.coalfire.com

Phew, the title of this post alone sounds like it could be quite a lot to deal with!

So what is DevOps?  DevOps is simply the blending of infrastructure operations processes and software development to enable faster changes to business applications/technology.  These processes share a lot of ideology with the Agile & Lean camps but are more fundamentally trying to bridge the traditional divide between the development world and the IT operations/Service management teams.

In practice, DevOps can mean a lot of different things to different audiences and sometimes it can be difficult to apply compliance requirements without getting a good understanding of what DevOps is for your company.

Terms such as ‘treat your code as infrastructure’ can often scare the life out of traditional auditors along with the fear that with rapid release and change comes rapid loss of control. These shouldn’t be scary but should be embraced and understood. In audit parlance these processes can become embedded, configurable application controls that require less substantive audit testing and sampling when under scrutiny and allow the focus to be on how they are designed to be a security control.

DevOps environments typically make heavy(think obsessive!) use of automation tools to enable rapid change and release processes to be possible at large and frequent scale. This is typically where the confusion starts to begin when evaluating these environments for security and compliance purposes. Typical service management controls such as change management on the surface may appear to have been cast aside in the rush to ‘be DevOps’. This rush to implement tooling can often lead to the underlying processes being weak or ill conceived. However this is common in other disciplines too. Poor planning = poor performance.

DevOps done well can bring a great set of tools and capability for building secure, scalable and compliant environments. Building on modern source control, streamlining change control and building dependency on the tools authentication and access control can quickly be used to demonstrate the control requirements of many compliance frameworks including the PCI DSS. Just doing things faster or without lots of paper forms and signatures on doesn’t necessarily equate to non-compliance.

The implementation of PCI DSS requirements 2 and 6 can be rapidly transformed using a DevOps approach. If we look at requirement 2 as being primarily focused on hardened configuration management traditionally seen as an ‘Ops’ area, whilst Requirement 6 focuses on change management and software development.

There is nothing fundamentally in these requirements (or in other areas of the DSS) that prevents a DevOps environment being used to support and implement PCI compliance if done carefully. Whilst the security and compliance mandate might tweak certain implementation decisions most of the tools marketed for ‘DevOps’ support building workflows that can be used for approval / review decisions and capture/log the necessary approval processes to support compliance. As the level of automation increases so can the ease of which compliance requirements be met.

Recently I worked with a client that had invested heavily in building their dev-ops tooling but had built in PCI requirements as part of this process so also incorporated automation of documentation production too.  Their focus was, and still is, to automate as much as possible into the release process to minimize the failure of an activity. Every time a new release was pushed all configuration documentation was also updated automatically (supporting requirement 2) .

This particular client used a software issue and tracking tool that could be used to demonstrate management approval for changes as well as to show that code review processes had been followed. As they continued to improve they were investigating automation of their code review processes so that static analysis tools were orchestrated immediately after changes were approved as part of the build process.

One of the biggest challenges they faced initially was the size of their team, they were small and specialist and in the past had struggled with creating segregation of duties between their test/production systems.  Moving to DevOps helped with this significantly. No developers were required to have access to production systems in any manner as the build and release process was entirely orchestrated by tools with an approval workflow that the developers couldn’t authorize alone. The tools were the only thing with the ability to push to their production systems and the workflow done under management approval. These tools were treated the same way as other in-scope systems but the overhead from this was so minimal that it enabled them meet security requirements without complicated manual processes and multiple sets of access permissions.

100 Percent of Retailers Disclose Cyber Risks

According to BDO’s analysis of risk factors listed in the most recent 10-K filings of the 100 largest U.S. retailers, risk associated with a possible security breach was cited unanimously by retailers, claiming the top spot, up from the 18th spot in 2007.

Since major retail security breaches began making national headlines in 2013, retailers have become acutely aware of the growing cyber threat and cyber-related risks. Between new point-of-sale systems and evolving digital channels, the industry faces unique vulnerabilities: Retailers are responsible for safeguarding consumer data as well as their own, in addition to protecting against potential gaps in security related to third-party suppliers and vendors.

2016 marks the 10th anniversary of our retail risk factor analysis, and throughout the decade, we’ve seen the retail landscape undergo a dramatic evolution in response to the recession, new and maturing e-commerce channels and evolving consumer preferences,” said Doug Hart, partner in BDO’s Consumer Business practice. “Retailers over the years have proven to be in tune with the industry-wide issues and trends that could pose risks to their businesses, and they are clearly not tone deaf when it comes to reacting to the urgency of cybersecurity

The following chart ranks the top 25 risk factors cited by the 100 largest U.S. retailers:

Top 20 Risks for Retailers 2016 2015 2014
General Economic Conditions #1 100% #1 100% #1 100%
Privacy Concerns Related to Security Breach #1t 100% #4t 99% #8 91%
Competition and Consolidation in Retail Sector #3 98% #1t 100% #3 98%
Federal, State and/or Local Regulations #4 96% #1t 100% #2 99%
Natural Disasters, Terrorism and Geo-Political Events #5 94% #7 96% #13 87%
Implementation and Maintenance of IT Systems #6 93% #4 99% #7 92%
U.S. and Foreign Supplier/Vendor Concerns #6t 93% #6 98% #4 96%
Legal Proceedings #6t 93% #9t 95% #8t 91%
Labor (health coverage, union concerns, staffing) #9 91% #7t 96% #5 94%
Impediments to Further U.S. Expansion and Growth #10 90% #12t 92% #17 78%
Dependency on Consumer Trends #11 88% #9 95% #6 93%
Consumer Confidence and Spending #12 87% #15 89% #8t 91%
Credit Markets/Availability of Financing and Company Indebtedness #13 85% #11 94% #11 89%
Failure to Properly Execute Business Strategy #14 82% #12 92% #11t 89%
Changes to Accounting Standards and Regulations #15 76% #14 90% #13t 87%
International Operations #16 73% #17 86% #15 80%
Loss of Key Management/New Management #16t 73% #19 80% #16 79%
Marketing, Advertising, Promotions and Public Relations #18 66% #25 68% #24 64%
Consumer Credit and/or Debt Levels #19 62% #27 65% #23 65%
Joint Ventures #20 61% #21 76% #18 74%

Additional findings from the 2016 BDO Retail Risk Factor Report:

Cyber Risks Include Compliance Measures

As the cyber threat looms larger, retailers are bracing for new and emerging cybersecurity and data privacy legislation. Risks associated with cyber and privacy regulations were cited by 76 percent of retailers this year. This is in line with the findings from the 2016 BDO Retail Compass Survey of CFOs, in which nearly 7 in 10 retail CFOs said they expected cyber regulation to grow in 2016. These concerns have been highlighted by President Obama’s recently unveiled Commission on Enhancing National Cybersecurity and continued debate in Congress over information sharing between the government and private industry.

Retailers have not escaped regulatory scrutiny. The industry is also subject to Europay, Mastercard and Visa (EMV) standards that bolster credit card authentication and authorization. Industry analysts estimate that just 40 percent of retailers are compliant with EMV standards despite the Oct. 1, 2015 deadline.

“Mandating EMV chip-compliant payment systems is an important first step in shoring up the industry’s cyber defenses, but it’s just the tip of the iceberg,” said Shahryar Shaghaghi, National Leader of the Technology Advisory Services practice group and Head of International BDO Cybersecurity. “Online and mobile transactions remain vulnerable to credit card fraud and identity theft, and POS systems can still be hacked and provide an access point to retailers’ networks. New forms of malware can also compromise retailers’ IT infrastructure and disrupt business operations. Every retailer will experience a data breach at some juncture; the real question is what mechanisms have been put in place to mitigate the impact.”

E-Commerce Ubiquity Drives Brick & Mortar Concerns

Impediments to e-commerce initiatives also increased in ranking, noted by 57 percent of retailers in 2016, a significant contrast from 12 percent in 2007. In 2015, e-commerce accounted for 7.3 percent of total retail sales and is continuing to gain market share.

As e-commerce grows and businesses strive to meet consumers’ demand for seamless online and mobile experiences, retailers are feeling the effects in their physical locations. The recent wave of Chapter 11 bankruptcies and mass store closings among high-visibility retailers has raised concerns across the industry. Ninety percent of retailers are worried about impediments to growth and U.S. expansion this year. Meanwhile, risks associated with owning and leasing real estate jumped 14 percentage points to 54 percent this year.

Heightened worries over the impact of e-commerce on physical locations are far reaching, driving concerns over market competition for prime real estate and mall traffic to rise 19 percentage points to 46 percent. Meanwhile, consumer demand for fast shipping fueled an uptick in risks around the increased cost of mail, paper and printing, rising 10 percentage points from seven percent in 2015 to 17 percent this year.

General Economic Conditions Hold Weight

General economic risks have been consistently top of mind for retailers throughout all ten years of this survey. Even at its lowest percentage in 2008, this risk was still the second most cited, noted by 83 percent of companies.

Despite the fact that since 2013, general economic conditions have remained tied for the top risk, concerns about specific market indicators have receded.

For more information on the 2016 BDO Retail RiskFactor Report, view the full report here.

About the Consumer Business Practice at BDO USA, LLP

BDO has been a valued business advisor to consumer business companies for over 100 years. The firm works with a wide variety of retail and consumer business clients, ranging from multinational Fortune 500 corporations to more entrepreneurial businesses, on myriad accounting, tax and other financial issues.

PCI SSC revises date for migrating off vulnerable SSL and early TLS encryption

Following significant feedback from the global PCI community and security experts, the Payment Card Industry Security Standards Council (PCI SSC) has announced a change to the date that organizations who process payments must migrate to TLS 1.1 encryption or higher.

The original deadline date for migration, June 2016, was included in the most recent version of the PCI Data Security Standard, version 3.1 (PCI DSS 3.1), which was published in April of 2015. The new deadline date, June 2018, will be included in the next version of the PCI Data Security Standard, which is expected in 2016.

Early market feedback told us migration to more secure encryption would be technically simple, and it was, but in the field a lot of business issues surfaced as we continued dialog with merchants, payment processors and banks,” said Stephen Orfei, General Manager, PCI SSC. “We want merchants protected against data theft but not at the expense of turning away business, so we changed the date. The global payments ecosystem is complex, especially when you think about how much more business is done today on mobile devices around the world. If you put mobile requirements together with encryption, the SHA-1 browser upgrade and EMV in the US, that’s a lot to handle. And it means it will take some time to get everyone up to speed. We’re working very hard with representatives from every part of the ecosystem to make sure it happens as before the bad guys break in.

Some payment security organizations service thousands of international customers all of whom use different SSL and TLS configurations,” said Troy Leach, Chief Technology Officer, PCI SSC. “The migration date will be changed in the updated Standard next year to accommodate those companies and their clients. Other related provisions will also change to ensure all new customers are outfitted with the most secure encryption into the future. Still, we encourage all organizations to migrate as soon as possible and remain vigilant. Staying current with software patches remains an important piece of the security puzzle

In addition to the migration deadline date-change, the PCI Security Standards Council has updated:

  • A new requirement date for payment service providers to begin offering more secure TLS 1.1 or higher encryption
  • A requirement for new implementations to be based on TLS 1.1 or higher
  • An exception to the deadline date for Payment Terminals, known as “POI” or Points of Interaction.

Merchants are encouraged to contact their payment processors and / or acquiring banks for detailed guidance on upgrading their ecommerce sites to the more secure encryption offered by TLS 1.1 or higher.

PCI Security Standards Council announces new board of advisors

The PCI Security Standards Council (PCI SSC), announced election results for the 2013-2015 PCI SSC Board of Advisors.

The Board will represent the PCI community by providing counsel to SSC leadership.

The Council’s more than 690 Participating Organizations selected individuals from the following organizations to represent their industry’s unique perspectives in the development of PCI Standards and other payment security initiatives:

  • Bank of America N.A.
  • Bankalararasi Kart Merkezi
  • Barclaycard
  • British Airways PLC
  • Carlson
  • Cartes Bancaires Cielo S.A.
  • Cisco
  • Citigroup Inc.
  • European Payment Council AISBL
  • FedEx
  • First Bank of Nigeria
  • First Data Merchant Services
  • Global Payments Inc.
  • Ingenico
  • Micros
  • Middle East Payment Systems
  • PayPal Inc.
  • Retail Solutions Providers Association
  • RSA, The Security Division of EMC
  • Starbucks Coffee Company
  • VeriFone Inc.
  • Wal-Mart Stores, Inc
  • Woolworths Limited

Board of Advisor members provide strategic and technical input to PCI SSC on specific areas of Council focus. Past board members have provided reach into key industry verticals and geographies to help raise awareness and adoption of PCI Standards; have shared their experience with implementing PCI Standards in presentations at the annual Community Meetings; and have contributed guidance on training product development and led Special Interest Groups (SIGs).

Active involvement from our Participating Organization base is critical to ensuring the PCI Standards remain at the front line for protection against threats to payment card data. Once again I am impressed by the turn out in the election process. It’s particularly encouraging to see new markets looking towards open global standards like the PCI Standards to help secure payment card data worldwide,” said Bob Russo, general manager, PCI Security Standards Council.

The Council and wider stakeholder community will benefit from the breadth of experiences and perspectives that this new board represents.” The board will support the Council’s mission to raise awareness and drive adoption of PCI Standards worldwide and will kick off its work in June with its first face-to-face meeting with Council management. “This year saw more European involvement than ever in the Board of Advisors election process. Although Europe contains mature EMV markets, this level of involvement in the PCI SSC confirms that the combination of PCI Standards and EMV chip is a powerful force for protecting payment card data,” said Jeremy King, European director, PCI Security Standards Council. “Our new board is a truly global group, and the Council will benefit greatly from its input as we continue to drive awareness and adoption of PCI Standards worldwide.

.

PCI Security Standards Council publishes card production security requirements

The PCI Security Standards Council (PCI SSC), has announced the publication of a standard for secure payment card production.

The standard consists of two sets of requirements:

  1. PCI Card Production Physical Security Requirements
  2. PCI Card Production Logical Security Requirements

Together, these documents provide card vendors with a comprehensive source of information describing the security requirements to follow for card production activities including card manufacture, chip embedding, magnet-stripe encoding, embossing, card personalization, chip initialization, chip personalization.

Formerly managed as separate requirements by each payment card brand, the Council aligned these requirements and solicited feedback from the PCI community to produce one set of criteria recognized across the industry. The resulting standard is designed to secure the components and sensitive data involved in the production of payment cards and protect against the fraudulent use of card materials.

It’s broken down into two core areas:

  1. Physical security requirements – for all card vendors, these requirements address the presence, movement, and accountability of a card, including tangible features such as the security of the premises, personnel access to secure areas, and CCTV surveillance.
  2. Logical security requirements – for card personalization vendors, these requirements address threats to the confidentiality of personalization data during data transfer, access, storage, and destruction; and all aspects associated with cryptographic key management, including the protection of issuer keys used in the personalization process.

The security requirements are available for immediate download here. Vendors should work with the individual card brands to confirm timing for when future security reviews must be performed against the new PCI Card Production Security Requirements.

In line with other PCI Standards, the requirements will be updated on a three-year lifecycle, based on feedback from the PCI community.

There are a lot of pieces involved in securely producing payment cards, from design all the way through delivery,” said Bob Russo, general manager, PCI Security Standards Council. “The publication of these requirements gives card vendors one set of criteria to follow, and as we’ve seen with our other standards, will help drive improved security across the payments chain

Sometimes it is a good idea to have in-house skills

After many discussions with people responsible for achieving and maintaining PCI DSS compliance within their organisation and hearing about their problems and pains, I often think about the skills they need and where they can get them. They could recruit, outsource or train with training being the most cost effective.

I noticed on the PCI SSC website the details of their “PCI SSC Internal Security Assessor (ISA) Program” and the benefits it can deliver to large or complex merchants so I decided to promote it as a way of achieving some of the required in-house skills.

Knowing many highly skilled QSAs I would always say that their extensive knowledge of different scenarios and industries makes them the back-bone of the PCI DSS, not just from an audit perspective but their advisory and guidance skills.

The ISA programme gives candidates the opportunity to build their PCI Security Standards expertise and strengthen their approach to payment data security, as well as increase their efficiency in compliance with the PCI Data Security Standards. 

About the Training

Employee Education is the Best Defense for protecting your Organization’s Data Assets.

To address concerns about PCI compliance and card data security, the PCI Security Standards Council operates the Internal Security Assessor Program to assist firms seeking to educate their employees on PCI compliance regulations.  The program trains, tests, and certifies organizations and individuals to assess and validate adherence to PCI Security Standards. 

Who Should Attend?

ISA training is intended primarily for individuals who already possess significant relevant security audit and assessment experience (including but not limited to Network Security, Application Security and Consultancy, System Integration, and Auditing). 

The Benefits:

  • Improve your understanding of PCI DSS and how it can help protect your customer data and your business
  • Help your organization build internal expertise
  • Facilitate interaction with a QSA for your organization
  • Enhance payment card data security and manage compliance costs
  • Earn CPE credits 

The Format: The Council recognizes that students may prefer different learning environments and offers ISA training in two formats: Instructor-led (ILT) and online ELearning. Same content. Same qualification. You decide what’s best for you. 

The ISA Training Program, for internal security assessment staff at ISA Sponsor Companies, is comprised of a four hour online pre-requisite course and exam called PCI Fundamentals followed by either an instructor-led course and exam or eLearning course and exam. Successful completion results in ISA qualification and PCI ISA certificate. 

Pre-Requisite Course Curriculum: This portion of the training assures that all participants attending the ISA Training Course have the same baseline understanding of the PCI SSC, card data environment, and the related terminology along with the industry relationships within the credit card transaction flow. It concludes with a multiple choice test.

  • Understanding the Payment Card Industry Security Standards Council and its role
  • Defining the processes involved in card processing
  • PCI roles and responsibilities
  • Understanding cardholder data
  • Defining network segmentation
  • PCI DSS assessments

ISA Course Curriculum Covers:

The ISA course is the next step for those students who have successfully completed the pre-requisite PCI Fundamentals course. This course builds on the knowledge gained in PCI Fundamentals and delves into the actual PCI DSS requirements and testing procedures. In addition it addresses topics such Report on Compliance (ROC) documentation, QA ROC review, and compensating controls to name just a few. Also included in the instructor-led course are case studies that provide the ISA candidate with a simulation of assessment scenarios that may aid them in solving common problems found in their own environments. A multiple choice exam immediately follows the instructor-led course.  The exam may be conveniently scheduled at a Pearson VUE Testing Center for students that take the eLearning course.

  • What is PCI and what does it mean to companies that must meet compliance with the DSS?
    • Industry overview
    • Terminology
    • Transaction data flow
    • Relationships between various organizations in the process
  • How the credit card brands differ in their validation and reporting requirements
  • PCI Data Security Standard (DSS)
    • Overview of 2.0
    • Testing procedures
    • What constitutes compliance
  • PCI Hardware and Communications Infrastructure
  • PCI Reporting
  • Real world examples
    • Overview of compliance issues and mitigation strategies
    • Compensating controls
    • Creating policies
    • Modifying cardholder data environment

How to Register. Three Steps to Join as a Sponsor Company and Have your Employees Attend ISA training

Step 1 Submit required Sponsor Company documentation by mail.

  1. Original signed agreement, page 13 of the Validation Requirements document
    • The representative noted as your company primary contact should be prepared to receive all PCI SSC related communications
    • It is not required that your primary contact be an officer of your company
  2. Copy of your company business license (Articles of Incorporation are also acceptable)
  3. A fully completed Individual Certification page for each employee you wish to send to training

Step 2 An invoice will be issued via email to the primary contact listed on the agreement page once the application is received. Applications are reviewed within 5 business days of receipt.

The fees for the ISA training will be based on whether or not your company is a member of the PCI SSC Participating Organization Program.

The Participating Organization Program is a separate program and membership is not based on your company compliance to PCI DSS or the submission of the Sponsor Company documents outlined above.

Step 3 Upon receipt of payment, the designated primary contact will receive instructions for the online pre-requisite portion of the training. Once the PCI Fundamentals training and test have been passed successfully, the primary contact will receive the location details for the instructor-led class or login credentials for the eLearning class. This will not be released until online PCI Fundamentals training has been taken and the test passed.

2013 ISA Training Course Schedule

Date Location Time Participating   Organization Price Non-Participating   Organization Price
15-16 April London, UK 09:00-17:30 $2250 USD $3595
3-4 May New Orleans, LA, USA 09:00-17:30 $1495 USD $2595
20-21 May Denver, CO, USA 09:00-17:30 $1495 USD $2595
10-11 June Orlando, FL, USA 09:00-17:30 $1495 USD $2595
14-15 July Toronto, Canada 09:00-17:30 $1495 USD $2595
21-22 August Boston, MA, USA 09:00-17:30 $1495 USD $2595
22-23 September Las Vegas, NV, USA 09:00-17:30 $1495 USD $2595
October Nice, France 09:00-17:30 $2250 USD $3595
November Kuala Lumpur, Malaysia 09:00-17:30 $1495 USD $2595

Full details can be found here.

.

Merchant sues VISA. Biting the hand that feeds you?

I know that if there were no merchants there would be no credit card companies and I know that the “alternative” payments market is growing, such as PayPal and V.me, but at this time it is fair to say that consumers still favour credit cards when it comes to online payments.

This is why when I read about a merchant suing a credit card company I was surprised. Not surprised that VISA had fined a merchant, not surprised that a merchant was upset at being fined but surprised it had got to court because that means normal reasonable commercial communication channels had failed.

On the 7th March Sports retailer Genesco filed a lawsuit against Visa to recover nearly $13.3 million in fines that the credit card company issued in January 2013 following a breach of the retailer’s systems.

The lawsuit argues that

  • Visa is not allowed to require other companies to pay penalties citing Visa’s own operating regulations and California law.
  • That Genesco was never out of compliance with PCI DSS regulations, and so it should not have been fined.

In December 2010 Genesco confirmed that a breach had happened within its credit card processing environment and speculation at the time was the hackers used a packet sniffer to siphon card data as it passed through the network.

The initial VISA fines of $5,000 via each of Genesco’s two banks was issued in June 2011 which is a standard charge and depending on your location will be 5,000 of the local currency for example, $5,000, €5,000 or £5,000.

Irrespective of the currency 5,000 is nothing more than a formal acknowledgement that the merchant is non-compliant to PCI DSS or was at the time.

If a merchant has never successfully completed an Audit or Self Assessment Questionnaire (SAQ) then they are non-compliant, bearing in mind that the standards were issued almost 8 years ago I think it is about time they were compliant.

However, in the case of a merchant who was successfully audited but then had a breach or failed to maintain the standard it is not so black and white.

Merchant who suffers a Data Breach

A PCI DSS compliant merchant who has a data breach is normally discovered by clever algorithms used by the card schemes, which based on fraudulent activity find the centre of the breach. Once the merchant at the centre of the breach is established they are required to undertake data forensics by an approved forensic company who using extensive skills and tools will establish how the credit card data was stolen for example via packet sniffing. The forensic report is shared between the affected parties, the merchant, the bank and the credit card companies.

The results of the forensic investigation may or may not show that the merchant had or had not been compliant to the standard at the time of the breach. It is reasonable to assume that the bad guys installed software or broke into Genesco and almost all scenarios for such a break in are covered by the PCI DSS and therefore the company could not have been taking adequate steps and was by definition not adhering to the requirements of the standard which means they were not compliant.

Merchant who fails to maintain the standard

It is very difficult to find a merchant who has failed to maintain the required standards unless

  • There is a breach
  • There is a whistle blower
  • A customer or someone similar notices practise that do not appear secure

At this point the merchant will be required to prove there are still abiding by the standard which may take the form of a forensics investigation, an audit, a letter from their QSA or a letter from their directors.

The non-compliance fine is not the biggest problem for Genesco it is the $13.3 million fine levied by VISA via Genesco’s two banks (Wells Fargo $12 million and Fifth Third $1.3million) for the costs incurred by VISA whilst resolving the breach e.g. credit card replacement, fraud cover, etc.

Visa’s imposition of the (fines) is a violation of Visa’s contract (with the banks), because at the time of the intrusion and all other relevant times, Genesco was in compliance with the PCI-DSS requirements,” the lawsuit stated. It added later,

“Visa does not even pretend that the Non-Compliance Fines represent actual damages that Visa incurred by reason of the Acquiring Banks‘ alleged failure to cause Genesco to maintain compliance with the PCI-DSS requirements”

The interesting thing for me is the nature of the way Merchants use VISA, MasterCard and the other credit card providers. The credit card company provides the facilities for the merchant’s (retailer) customers to buy from them in a secure and efficient way. They pay a percentage of the transaction to cover the costs (and profits) of the credit card companies and this percentage is agreed in a contract. The same commercial contract that agrees the other terms and conditions including the security required to perform the transaction.

To avoid confusion and rogue traders the credit card companies created the Payment Card Industry Security Standards Council who took the best security practises from the five credit card company members to create the Data Security Standard (PCI DSS).

This standard is an extension of the contract as will be the agreements for fees.

However because the cost of a data breach could never be known until it has occurred it is impossible to quantify the cost of a breach in a contract which is where I do have a great deal of sympathy for merchants because they are agreeing to fines but have no idea how much it is going to be or could be.

I remember in a meeting with several of the card companies and the discussion centred on repeat offenders i.e. merchants who kept being breached or who refused to become compliant to PCI DSS and whilst fines were mentioned it was agreed merchants might be tempted to absorb small fines if it was cheaper than achieving the required security standards and then the ultimate sanction was raised… STOPPING THEM FROM TAKING CREDIT CARD PAYMENTS.

What a sanction that is, because for almost all e-commerce business and most consumer driven business that would mean going out of business in a matter of weeks or possibly months.

As a consumer all I care about is being safe from the costs of the fraudulent activity against my stolen credit card but increasingly we as consumers are worried about the threat to our identity and expect when credit card details are leaked to be covered for all identity based threats resulting from the possible loss of data which increases the cost to the breached company, possibly via the credit card company.

I have a huge amount of sympathy for Genesco and every other merchant affected by a breach because they do not know what the possible cost to them will be. They cannot take out cyber-insurance against a specific amount “just in case”, they have to hope that the loss to the credit card company is not too great.

That is not a great way for a merchant to mitigate its risk and that cannot benefit the card companies who want prosperous and secure merchant to help them grow their profits.

The solution is simple, the credit card companies have to introduce and publish a schedule of fines from which a merchant can calculate their risk.

If a merchant knows, based on their transaction rate, that they could be liable for fines of $13.3 million then they can invest greater resources into breach prevention or seek to undertake insurance against the cost of a breach either way they can make an informed risk assessment.

Similarly if merchants who have not yet completed their PCI DSS compliance process know they could be fined for non-compliance PLUS X or Y for a breach they can will very quickly run a risk assessment.

let’s hope a result of this action is a clearer picture on fines because clarity in business and risk is essential.

.

PCI SSC releases PCI DSS Cloud Computing Guidelines

The PCI Security Standards Council has published the PCI DSS Cloud Computing Guidelines Information Supplement, a product of the Cloud Special Interest Group (SIG).

The guide is an excellent introduction to the “cloud” and offers specific and helpful guidance on what to consider when processing payments involving the cloud as well as the storage of sensitive data.

One of cloud computing’s biggest strengths is its shared-responsibility model. However, this shared model can magnify the difficulties of architecting a secure computing environment,” said Chris Brenton, a PCI Cloud SIG contributor and director of security for CloudPassage. “One of this supplement’s greatest achievements is that it clearly defines the security responsibilities of the cloud provider and the cloud customer. With PCI DSS as the foundation, this guidance provides an excellent roadmap to crafting a secure posture in both private and public cloud. 

The PCI DSS Cloud Computing Guidelines Information Supplement builds on the work of the 2011 Virtualization SIG, while leveraging other industry standards to provide guidance around the following primary areas and objectives:

  • Cloud Overview – provides explanation of common deployment and service models for cloud environments, including how implementations may vary within the different types.
  • Cloud Provider/Cloud Customer Relationships– outlines different roles and responsibilities across the different cloud models and guidance on how to determine and document these responsibilities.
  • PCI DSS Considerations – provides guidance and examples to help determine responsibilities for individual PCI DSS requirements, and includes segmentation and scoping considerations.
  • PCI DSS Compliance Challenges– describes some of the challenges associated with validating PCI DSS compliance in a cloud environment.

The document also includes a number of appendices to address specific PCI DSS requirements and implementation scenarios, including: additional considerations to help determine PCI DSS responsibilities across different cloud service models; sample system inventory for cloud computing environments; sample matrix for documenting how PCI DSS responsibilities are assigned between cloud provider and client; and a starting set of questions that can help in determining how PCI DSS requirements can be met in a particular cloud environment.

Merchants who use or are considering use of cloud technologies in their cardholder data environment and any third-party service providers that provide cloud services or cloud products for merchants can benefit from this guidance. This document may also be of value for assessors reviewing cloud environments as part of a PCI DSS assessment.

At the Council, we always talk about payment security as a shared responsibility. And cloud is by nature shared, which means that it’s increasingly important for all parties involved to understand their responsibility when it comes to protecting this data,” said Bob Russo, general manager, PCI Security Standards Council. “It’s great to see this guidance come to fruition, and we’re excited to get it into the hands of merchants and other organizations looking to take advantage of cloud technology in a secure manner.

For a link to the full document please use my PCI Resources page here.

.

PCI SSC releases its PCI DSS E-commerce Security Guidelines

Hot on the heels of the ATM Guidelines the PCI SSC has released the PCI DSS E-commerce Guidelines Information Supplement. 

The guidelines are designed to help e-commerce merchants to decide on which technologies and third party service providers to choose.

The e-commerce Special Interest Groups (SIGs) helped put the guidelines together and that meant using their knowledge of the marketplace to produce an industry specific document. 

Take SQL injections as an example. This is not a new attack, and something we’ve known about in the industry for years. Yet it continues to be one of the most common methods by which e-commerce websites are compromised, said Bob Russo, general manager, PCI Security Standards Council. “This can be addressed through simple, prudent coding practices, but merchants often don’t know where to start. These guidelines will help them better understand their responsibilities and the kinds of questions they need to ask of their service providers. In the case of SQL injections, one of the most important items to request of an e-commerce service provider is a description of the security controls and methods it has in place to protect websites against these vulnerabilities.

The PCI DSS E-commerce Guidelines Information Supplement provides an introduction to e-commerce security and guidance around the following primary areas and objectives: 

  • E-commerce Overview – provides merchants and third parties with explanation of typical e-commerce components and common implementations and outlines high-level PCI DSS scoping guidance to be considered for each.
  •  Common Vulnerabilities in E-commerce Environments – educates merchants on vulnerabilities often found in web applications (such as e-commerce shopping carts) so they can emphasize security when developing or choosing e-commerce software and services.
  • Recommendations – provides merchants with best practices to secure their e-commerce environments, as well as list of recommended industry and PCI SSC resources to leverage in e-commerce security efforts.

 The document also includes two appendices to address specific PCI DSS requirements and implementation scenarios:

  1. PCI DSS Guidance for E-commerce Environments – provides high-level e-commerce guidance that corresponds to the main categories of PCI DSS requirements; includes chart to help organizations identify and document which PCI DSS responsibilities are those of the merchant and which are the responsibility of any e-commerce payment processor.
  2.  Merchant and Third-Party PCI DSS Responsibilities – for outsourced or “hybrid” e-commerce environments, includes sample checklist that merchants can use to identify which party is responsible for compliance and specify the details on the evidence of compliance.

E-commerce continues to be a target for attacks on card data, especially with EMV technology helping drive so much of the face-to-face fraud down in Europe and other parts of the world, said Jeremy King, European director, PCI Security Standards Council. “We are pleased with this guidance that will help merchants and others better understand how to secure this critical environment using the PCI Standards.

For a link to the full document please use my PCI Resources page here.

Create a free website or blog at WordPress.com.

Up ↑

%d bloggers like this: