Search

Brian Pennington

A blog about Cyber Security & Compliance

Tag

Penetration test

Call Centre Security and PCI Compliance

An Indian call center
Image via Wikipedia

Credit Card data is the Crown Jewels for hackers and the financial lifeblood of many companies. An Account Data Compromise, also known as a breach can lead to bad press and a bad reputation, you only need to Google Play.com or Lush to see the impact.

With the 18th March 2011 launch of the PCI Councils “Protecting Telephone Based Payment Card Data” on Call Centres it is worth noting that, according to research from Connected World 36.7% of contact Centres claimed to be fully compliant with the Payment Card Industry Data Security Standard (PCI DSS).

However, the majority (89%) admitted to not understanding PCI DSS, the requirements nor penalties.

There are many business and regulatory requirements that impact Call Centres, especially the recording of telephone calls, for example in the United Kingdom, the Financial Services Act.

The act of recording a call can break the rules of PCI DSS as most calls will involve the recording of ALL the data. Data such as, CAV2, CVC2, CVV2 or CID, which should never be recorded. Storing the PAN and Expiry data is acceptable so long as the data is encrypted and the Merchant has acted on all the questions within SAQ D or undertaken a formal Audit if they are a level 1 Merchant.

The number one piece of advice for Call Recording is DO NOT DO IT unless you really have to.

However, the recording of the calls and storing of Credit Card Data in an encrypted format are small parts of the issue facing Call Centres.

By considering the following points and reviewing the documents on the PCI Resource page  you can go a long way towards achieving a PCI compliant Call Centre.

  • Employee vetting is the first step in ensuring a secure Call Centre.
  • There needs to be a formal employee induction programme where employees learn about the company’s policies (rules) and the ramifications of breaching the policies.
  • Specifically, there needs to be a documented Policy on how employees handle Calls and Data resulting from the Calls, especially Credit Card Data?
  • The Merchant needs to communicate the Policy to all employees that have access to Credit Card Data.
  • Do employees regularly receive training on the Policy and its importance? They should do.
  • Are employees made aware of their IT Security responsibilities?
  • Security Awareness training needs to be provided, for example, how to deal with the threat of computer viruses, how to report suspicious activity, etc
  • Security Awareness has to be promoted, for example, on posters and in newsletters.
  • Do supervisors/managers enforce a clear desk Policy? For example, no MP3 players, no note pads or any other methods to record information.
  • Access to photocopiers and scanners needs to be restricted.
  • Restricting physical access to the Call Centre should be considered.
  • Call Centres should be restricted to employees only and visitors need to be escorted.
  • All paperwork leaving the Call Centre should be shredded to avoid the unnecessary risk or Personally Identifiable Information (PII) finding its way into the public domain.
  • Consideration should be made to CCTV
  • Do all employees have unique logon identities?
  • Are strong passwords enforced?
  • Are passwords changes enforced every 30 days, or less?
  • Are password changes significantly different after every change? For example, not simply adding a 1 or a 2 at the end of previous password.
  • Home and remote workers need to have local security installed, for example, personal Firewalls and Anti Virus.
  • Do systems and servers that store credit card data, for example, CRMs and Databases, have access restricted on a need to know basis?
  • Are logs taken and stored for system and networks where data is stored?
  • Is the Merchant’s network and systems attached to the network adequately protected against viruses, hackers and other threats?
  • Are these systems regularly scanned and patched for vulnerabilities. PCI DSS requires that all systems and networks with the scope of the card data environment be scanned by an Approved Scanning Vendor at least quarterly.
  • Is the Merchant’s security regularly tested? For example, by having Penetration Tests.
  • Does the Merchant have a plan on how to deal with a breach and is this plan tested? This is often called an Incident Response Plan and can be tuned to deal with all types of breaches for example, the Epsilon Email Breach.

In summary, PCI DSS is not the only area on compliance affecting the Call Centre but PCI DSS does help focus the business on what security, processes and procedures are required to achieve best practice.

.

77% of Hospitality Sector Mistakenly Believe They Are PCI Compliant

Orthus Limited, on the 7th March 2011, released the results of a survey conducted of 1000 Level 4 Merchants in the United Kingdom hospitality sector to verify their PCI DSS compliance status. 

The survey indicates 77% of 1000 Level 4 Merchants were compliant to PCI DSS when in fact they were not compliant:

The rest of the survey and its finding are below:

  • Of the respondents claiming to be PCI compliant, 94% stated they had conducted the required vulnerability assessment scanning.
  • Of the respondents claiming to be PCI compliant, only 36% stated they had conducted required security penetration testing.
  •  Of the respondents claiming to be PCI compliant, only 9% stated they had security policies.
  • Of the respondents claiming to be PCI compliant, not 1 had conducted the required wireless scanning.
  • Only 24% of the respondents stated they had executed a self assessment questionnaire (SAQ).
  • Of the 24% who had executed a SAQ, less than 50% had stated they had submitted it to their Acquirer.

“The results of the survey are disturbing and indicate that businesses do not understand the PCI DSS requirements and what constitutes compliance. Almost all of the Level 4 Merchants surveyed who mistakenly believed they were compliant stated that they were told by a vendor that compliance entailed conducting vulnerability scanning. Upon completing the scanning, the Merchants understood themselves to be compliant and therein lay the problem. Merchants are getting their information primarily from vendors who have a vested interest in selling their product.”

“Misinformation is a significant problem in the market.  Vendors are selling their products as facilitating PCI compliance and buyers are not doing their homework” says Orthus Data Compliance Specialist, Courtney Bryan.  “If the vendors are affiliated with an Acquiring Bank their products are even perceived as required for compliance so after a Merchant purchases them, they naturally assume they are now compliant” states Bryan.  

“Something has to be done about this problem. Merchants need unbiased advice and assistance with implementing this risk management framework to prevent card data theft and fraud. There is a real knowledge void in the market about what constitutes PCI DSS compliance and until it’s addressed – vendors will continue to exploit it while the Merchants carry the risks” says Bryan.

Orthus can be found at http://www.orthusintel.com and the press release for the survey “PCI Compliant: Are You Really Sure?” has cathy.jacobs@orthus.com as the contact

Eight must-fix flaws prior to an application penetration test

An excellent article by Neil O’Connor for SearchSecurity.

 The full article is HERE but Neil’s Eight must fix flaws are listed below:-

 1.         Trusting client-side validation

2.         Blacklisting for input validation

3.         Improper error handling

4.         Forgotten/change password functionality

5.         Unencrypted communications/authentication

6.         Lack of auditing and logging

7.         Not reusing good security API or already tested code

8.         Not following Microsoft best practice development guides

For PCI DSS the guidance for requirement 6.6 is:-

Attacks on web-facing applications are common and often successful, and are allowed by poor coding practices. This requirement for reviewing applications or installing web application firewalls is intended to greatly reduce the number of compromises on public facing web applications that result in breaches of cardholder data.

  • Manual or automated vulnerability security assessment tools or methods that review and/or scan for application vulnerabilities can be used to satisfy this requirement

 

  • Web-application firewalls filter and block non-essential traffic at the application layer. Used in conjunction with a network-based firewall, a properly configured web-application firewall prevents application-layer attacks if applications are improperly coded or configured.

Create a free website or blog at WordPress.com.

Up ↑

%d bloggers like this: