 |
| |
| Indhold |
1. Changes from VISA, MasterCard and the PCI Council
2. News about the PCI standard in general
3. Clarifications from the PCI Council
4. New guidelines concerning wireless security
5. PCI challenges for issuing banks
6. Increasing incidence of card theft
7. FortConsult among Top 3 in Europe
|
| |
| 1. Changes from VISA, MasterCard and the PCI Council |
| Since the last newsletter, a number of changes have taken place that will be relevant for various types of businesses. We will review the most significant changes below. |
|
| |
1.0 Background
For those readers of the newsletter who are new to the PCI area, we will begin by outlining the division of labour between the credit card companies and the PCI Security Standards Council: |
|
| |
| The PCI Security Standards Council develops the Payment Card Industry Data Security Standard (PCI DSS) based on input from its members. These members include both "users" of the standard, e.g. banks, supermarkets and airline companies, as well as representatives for the credit card companies, e.g. VISA, MasterCard, JCB and American Express. In addition to maintaining the standard, the PCI Council is responsible for ensuring that QSAs satisfy the professional and formal conditions that are required to be an accredited QSA. This also includes the training of QSAs and help in the clarification of interpretations of the standard. |
|
| |
| The PCI Council cannot demand that particular groups of enterprises comply with the standard; only the credit card companies can do this. |
|
| |
| The credit card companies define the overall lines, but it is the acquiring banks in each country which decide to what extent they will follow the credit card companies' requirements with respect to compliance with PCI DSS, or whether they will put more stringent requirements in place for certain enterprises in order to reduce the risk of card theft in the country concerned. |
|
| |
| VISA Europe operates as an independent organisation and manages the compliance requirements stipulated on the European market itself, including making sure that these requirements reflect the actual circumstances in Europe. MasterCard manages all compliance requirements from the USA and stipulates the same requirements in all parts of the world. |
|
| |
| The credit card companies try very hard to coordinate the requirements between the different companies, but it is not always possible to realise this in full, and as such the same compliance requirements do not always apply. Ordinary users of the PCI standard, however, will most commonly find that their acquiring bank will declare an overall set of requirements in accordance with their own interpretation of the compliance requirements. |
|
| |
1.1 Changes in merchant levels
During the first half of 2009, MasterCard made changes to its requirements concerning compliance with PCI DSS for level 2 merchants. Earlier, level 2 merchants were able to make do with quarterly PCI scans and the completion of a self-assessment questionnaire. After the change level 2 merchants are now supposed to have an annual audit conducted by a QSA and later on it also became possible to have the audit performed by an internal accountant who has attended a course conducted by the PCI Council. Level 2 merchants comprise smaller businesses with 1-6 million transactions per year. They will typically have fewer resources in the IT area and it will thus be a major challenge for them to undergo an audit. The new requirements have generated a great deal of discussion, since in Europe there is more focus on dealing with the challenges facing small shops in the payment area by means of new technology. |
|
| |
| Each acquiring bank has to stipulate the new requirements on behalf of MasterCard, although the majority have so far adopted a wait-and-see attitude and are hoping to find an alternative solution prior to MasterCard's deadline of 31 December 2010. |
|
| |
1.2 New requirements from VISA to member banks' sub-suppliers
From 1 October 2010, VISA will require that all VISA member banks use only sub-suppliers that are PCI compliant. This compliance shall be validated in accordance with VISA service provider levels. This means that suppliers with less than 300,000 transactions per year can make do with self assessment and scans, whilst the remaining suppliers will require an annual PCI audit. Since the sub-suppliers' core business typically involves bank transactions - including credit cards - in our opinion it makes sense that there is a requirement that security is validated on an annual basis. Indeed, if enterprises whose core business is processing credit cards do not have to be validated as PCI compliant, then the question has to be asked, who does? |
|
| |
| VISA has announced this requirement to the member banks, and we will have to wait and see how quickly it will be passed on to third party suppliers. It is clear that for many of these types of companies the deadline is extremely short, and we are of course willing to help with advice in this regard should you require it. |
|
| |
1.3 VISA demands that software security standard PA-DSS becomes mandatory throughout the EU
The Payment Application Data Security Standard (PA-DSS) is - as described in previous newsletters - the new sister standard to the Payment Card Industry Data Security Standard (PCI DSS). PA-DSS applies to software which processes card data. Whereas PCI DSS concerns enterprises that handle credit card transactions, PA-DSS applies to enterprises which develop payment software and credit card solutions that are used in shops, banks, ATMs and e-commerce. To date, the enterprises that have to comply with PCI DSS have been able to choose whether they wish to use PA-DSS in collaboration with their sub-suppliers. In certain countries, such as Sweden and Denmark, the acquiring banks have already had a demand in place for some time that point-of-sale devices and cash-till software must comply with PA-DSS. However, VISA is now demanding that PA-DSS be implemented throughout the EU. After 1 July 2010 all new installations must use solutions that are PA-DSS compliant, and by 31 December 2012 at the latest all merchants (including small businesses) must either use solutions which are PA-DSS compliant or be PCI DSS compliant themselves (where PCI DSS compliance also includes the software itself). |
| |
| 2. News about the PCI standard in general |
2.0 New PCI standard by the end of 2010
The life cycle of the PCI standard is such that a new standard is introduced every second year. The PCI Council uses the first year following the introduction of a new standard to provide information about the standard, while the following year is spent preparing the next version. We have now embarked on a year in which focus will be on preparation of a new standard and the PCI Council is thus carrying out a number of activities in connection herewith. |
|
| |
| During the summer, for example, we asked our members, users and QSAs about their wishes with regard to the next PCI standard. This provides enterprises like us at FortConsult with a good opportunity to influence the process so that we can already begin to make life easier for our customers. We have hitherto been limited by the fact that we could not respond to the standard until it was presented. Now we have the opportunity to shape the development of it in accordance with the practical issues which we know that enterprises face on a daily basis. Furthermore, when we are also involved in the creative process, we can of course refine our analytical tools to a much greater extent. |
|
| |
| In addition, the PCI Council has embarked on work looking at the technologies that can help merchants to reduce their risk without things getting either too complicated or too expensive. The idea is that suppliers of equipment or outsourcing partners will supply solutions which either reduce the PCI scope on the part of the merchant or even completely obviate the need for PCI. However, this will primarily be a possibility for shops and thus not for other types of enterprises which currently come within the scope of PCI DSS. Several of the solutions which are on the table will not eliminate the risk of card theft. Instead, the risk will be transferred to the developer of the solution or to the service provider. |
|
| |
The PCI Council has only recently commenced work in this regard, but initial analysis has led to a number of promising new technologies that are due to be analysed in more detail. These are:
- End-to-end encryption
- Magnetic stripe imaging
- Tokenization
- Virtual terminals
These technologies have been chosen following an appraisal of their technical robustness, of how easily the technology can be implemented and maintained by the merchant in question, how easily it can be integrated into existing acquiring systems and how much extra work it entails for the service provider. |
|
| |
| From a European perspective we would have welcomed a more far-reaching outcome. Many countries have already implemented the EMV chip, and thus magnetic stripe imaging does not have any relevance. End-to-end encryption has also already been implemented at many locations. On the other hand, we are seeing tokenization becoming more commonplace, and, although the concept itself is nothing new, we consider it to be very promising. In Europe we can thus expect a standard which better matches the technology we already use than one which contains ground-breaking new solutions that will make it significantly easier to be a merchant. We hope, however, that this will be the step which alters the PCI standard's requirements to reflect the risk picture at the many European enterprises that do not use magnetic stripe/track data, but more advanced solutions based on EMV. |
|
| |
| We should, however, emphasise the fact that the PCI Council has not yet reached any definitive conclusions, and the work that will be taking place during the next year may result in the above areas being rejected and others taking their place. In relation to work already in progress in which new technologies and risk mitigation are being looked at in a broad perspective, we expect that the next version of the PCI standard will consist of a comprehensive update that will have an impact on many of the involved parties. We will return to the content of the new standard as soon as we know more. |
|
| |
2.1 Moving towards a more robust PCI standard
In our opinion, the PCI Council - having existed for three years - is beginning to find its feet, which is illustrated by the fact that their interpretations have become increasingly precise. However, this does not alter the fact that there will continue to be areas where these interpretations change over time. For instance, we can see that the material we use in connection with our own training has changed quite considerably in a number of areas over time. This in itself indicates that it is a fluid area. As a professional auditor, this of course represents quite a challenge, since our customers rightly expect to receive advice that they can expect to last for a reasonable period of time. We therefore hope that the PCI Council's latest clear declarations will prove to be more viable than previous declarations. |
|
| |
| Since we began conducting audits some four years ago, we have regularly heard customers say that they have had different QSAs giving different answers to the same question. The PCI Council has also been criticised many times for the same reason. This is why the PCI Council has now taken the step of increasing the degree of precision in its material produced for QSAs, whilst at the same time following up on the work of the QSAs (see below). The benefit of this is that customers can be more confident of receiving the same answer from all QSAs. Unfortunately, however, this solution does have a downside, namely that QSAs cannot take individual considerations into account. One of the main reasons for the existence of different requirements is that each QSA was able to look at the problems in a pragmatic way and evaluate the risk of each customer's specific set-up. We have thereby been able to customise our work and focus on reducing the risk of card theft and taking a slightly less rigid view of the compliance requirements. Unfortunately, this degree of latitude has now been considerably reduced. |
|
| |
2.2 Skills development programme for major QSAs
In order to make work with the PCI standard more straightforward and efficient, the PCI Council has commenced a quality assurance programme that is aimed at ensuring that QSAs interpret the standard uniformly in all areas. Initially, this will include the major QSAs, and this means that we at FortConsult will take part in the first round in Europe. In practice, this means that the PCI Council's employees will carry out a thorough review of the reports we have submitted, evaluate them and grade them. For our customers, this means an extra degree of security that our work does indeed match the interpretations required by the PCI Council and that our consultancy services in the future will be very similar to those provided by other major QSAs, As mentioned earlier, this may mean that we are unable to take the individual considerations of each customer into account to the same extent as previously, since in future there will only be a very small degree of tolerance with regard to what is allowed. At the same time, the QA programme will mean that all QSAs will have to spend considerably more time documenting what is observed during the audit on site. Unfortunately, at the end of the day, this will mean that customers will experience higher prices. At FortConsult we have already adapted our routines in relation to the new requirements such that we can as far as possible limit the extra hours consumed. However, several other QSAs have either discontinued or heavily modified their price structure. We regret that customers will be affected by the new QA programme in a number of areas, but at the same time we hope that all will benefit from the more consistent enforcement of the standard, irrespective of national boundaries or the QSA carrying out the task in question. |
| |
| 3. Clarifications from the PCI Council |
3.0 Masking of credit card numbers
Some customers have expressed a wish to use an alternative card number masking system than the standard method in accordance with PCI DSS, in which the first six and last four digits are visible. We have been asked to evaluate whether customers can mask card numbers such that the first eight and the last two digits are visible. The reason for this wish is that in certain cases customers need to be able to register the type of card used, e.g. in connection with charges imposed on foreign credit cards. |
|
| |
| The PCI Council has clarified that the use of alternative masking methods is not permissible. The council is aware of the possible problems this may cause for a number of customers, but will not allow a relaxation of the rule, since any changes will make it easier for hackers to combine fragments and thus make it easier to reveal the full number if they intercept transactions from several places with different masking methods. |
|
| |
3.1 When should a penetration test be carried out?
Section 11.3 of PCI DSS concerns penetration tests, and it is stipulated that a penetration test must be carried out in connection with "any significant change". The question is thus what is understood by the term a "significant change". In this case, the PCI Council clarifies that a penetration test must be carried out in connection with:
- upgrading of the operating system
- addition of a sub-network
- addition of perimeter systems, such as a web server
On the part of FortConsult, we would like to clarify that it is not always necessary to perform a full penetration test in connection with changes to the set-up. In some cases, it is sufficient for enterprises to have just some of the components tested. It is up to you to assess which areas are affected by the change and which must therefore be tested again. If in any doubt, you should test everything or discuss the matter with us. It is important that you are aware of this clarification, since in future it will be a point that we check when conducting an audit. |
|
| |
3.2 All traffic means all traffic
Section 11.4 of PCI DSS concerns the use of IDS to monitor "all traffic" in the system. In this case, the PCI Council has clarified that "all traffic" quite simply means all traffic. Some customers have enquired whether less would be sufficient, but this is not the case. For some enterprises this means that not enough systems are currently being monitored, since a number of enterprises have concentrated solely on Internet-facing systems. We recommend that you check whether all systems within the scope of PCI DSS are included in IDS monitoring. The same applies to section 11.5 concerning file integrity monitoring, where all systems within the scope of PCI DSS must be included. |
|
| |
3.3 Employees have a duty to familiarise themselves with security policy
Section 12.6.2 of PCI DSS stipulates that all employees must confirm once a year that they are familiar with the enterprise's security policy. This is a point that is often overlooked, and we therefore remind you that this must be ensured. At the same time, we would like to take this chance to remind you that according to section 12.6.1.b all employees shall take part in security awareness training once a year. |
| |
| 4. New guidelines for wireless security |
| New guidelines have been issued by the PCI Council that describe in a detailed yet easy to understand manner the security problems that can occur in conjunction with wireless connections. It is an excellent document which we highly recommend. Many enterprises are experiencing that the issue of wireless security is very much on the agenda, and many are unsure of what it means for their particular set-up. We occasionally find that enterprises are completely unaware that there are wireless connections within their PCI DSS scope. |
|
| |
| In any event, it is a good idea to have your set-up looked at with a view to establishing optimum wireless security and also in this regard establishing whether you comply with PCI DSS. The PCI Council's document is very comprehensive and you are welcome to contact us if you require advice in this regard. One of our experienced PCI consultants, Warren Platt, is not only a QSA, but also a specialist in wireless security and affiliated with the SANS Institute as a mentor on its wireless training course. Incidentally, Warren is one of only six experts in the world to be awarded the esteemed GIAC-GSNA gold certification within wireless security. |
|
| |
| The PCI Council's guidelines are available at: www.pcisecuritystandards.org |
| |
| 5. PCI challenges for issuing banks |
| Issuing banks in Europe have traditionally not concerned themselves with PCI DSS, even though they make up a key element in the credit card chain. VISA and MasterCard have seemingly presumed that the security of the issuing banks was in order and have therefore not done much to follow up on their agreements with the issuing banks in terms of security. They have referred to the agreements they have concluded and not done much more than that. |
|
| |
| In line with PCI DSS being implemented in every other link of the chain, the number of enterprises that store credit card data has been significantly reduced, and there is therefore increased focus on the issuing banks as the weakest link in the chain. The problem with the issuing banks is that they often have a lot of card data and that this data is used in several of the banks' internal departments, in consultancy services, in marketing, etc. In many cases the banks have outsourced their IT, thereby shifting the direct responsibility for protection of card data away from the day-to-day handling of data, and this may somewhat blur the issue of security. Although the card data is protected elsewhere in electronic form, there is nothing to stop an employee from, for example, printing something out and leaving it lying around somewhere. The banks will also typically have some sort of collaboration with sub-suppliers who have access to card data or systems with card data. |
|
| |
| At FortConsult we have considerable experience with the challenges facing issuing banks with regard to PCI DSS. This includes providing assistance to several of the biggest banks in Scandinavia and a large number of European banks' operating centres with respect to complying with PCI DSS, and we can therefore provide good advice as to what you can do right now if you are an issuing bank. |
|
| |
There are three rules of thumb:
- Start early. Identify as quickly as possible any discrepancies in relation to PCI DSS, so that you have plenty of time to implement any measures and can incorporate them into day-to-day operations. Your IT department should be aware of PCI DSS in the planning and start up of all new projects, so that you do not have to make wholesale changes at a later date. You can, for example, make sure that new applications comply with PCI DSS or PA-DSS. When employees are given new laptop computers, the machines will then already be adapted to the standard.
- Have the card data you handle classified and stimulate awareness concerning security amongst the employees. Perhaps your employees are not sufficiently aware of the fact that they are dealing with sensitive data and how it should be handled.
- If relevant, make sure that PCI DSS is on the agenda in any contact with your sub-suppliers.
Finally, it is a good idea to ensure that ownership of PCI DSS is centred in the business part of the enterprise and not in the IT department. PCI DSS issues cover your enterprise's activities across the board and are not only IT-related. In fact, many of the issues are buried in the famous "human factor". |
|
| |
| The PCI Council has announced that before long it will issue a brief concerning the issuing banks and PCI DSS. As soon as this is made available, we will return to this matter. |
| |
| 6. Increasing incidence of card theft |
| Problems concerning the theft of credit cards continue to rise. According to stories in the media, it would appear that this problem is much worse in the USA than here in Europe, but since, unlike in Europe, enterprises in the USA are legally bound to make all card theft public, the picture is easily distorted. |
|
| |
| Considerable attention was thus drawn to an incident during the spring when it was revealed that hackers had managed to penetrate the booking system at a hotel in Ebeltoft and steal card data from the system. The case as such was not particularly remarkable since such events occur regularly, but in this case it was reported in the public domain. It was a good example of an enterprise where there was inadequate focus on PCI DSS, thus leaving the enterprise particularly exposed. If the hotel had complied with the standard, the hackers would not have been able to operate in the way that they did. |
|
| |
Here in Scandinavia most attention has been focused on theft via ATMs and unfortunately this traffic continues to represent a major problem. This indicates that the need for focus on PCI DSS has certainly not diminished in any way - in particular with regard to the parts of the systems that are perhaps not the obvious places to start. In Scandinavia the majority of thefts take place as physical attacks where a small skimmer unit has been installed in the ATM. The link below describes an American case that is similar to those in Scandinavia. Note how creative the attackers have been.
http://www.youtube.com/watch?v=m3qK46L2b_c |
|
| |
PCI DSS is primarily designed to ensure that card data is not stolen whilst in an enterprise's custody. The link below describes a case in Eastern Europe with an ATM attack which could probably have been thwarted if the systems had complied with PCI DSS.
news.cnet.com |
| |
| 7. FortConsult among Top 3 in Europe |
| Finally, news on the internal front. On VISA's latest list of certified service providers, FortConsult now occupies third position in terms of the QSAs that have audited the highest number of enterprises. |
|
| |
| In 2004 FortConsult became the first and only IT security firm in Scandinavia to be certified by VISA and MasterCard to perform security scans, which was followed in 2005 by our authorisation to conduct audits. This has provided the basis for the extension of our customer portfolio to the whole of Europe. |
|
| |
| Among the reasons for our growth are without doubt our many years of experience of having solved a large number of PCI tasks, the fact that we operate out of a single office in Copenhagen and that we find it easy to share our knowledge and experience - both amongst our security experts, but also across our different areas of expertise. For you this means that you always receive up-to-date and relevant advice concerning very specific PCI DSS issues so that you do not risk commencing projects which later prove to be inadequate or inappropriate. |
|
| |
Best regards
Lars Syberg
PCI Product Manager
FortConsult A/S |
