Showing posts with label PCI DSS Compliance. Show all posts
Showing posts with label PCI DSS Compliance. Show all posts

Monday, 24 December 2012

BREAKING NEWS - Really? - PCI Compliance is Mandatory

If you're thinking "That's hardly breaking news?" I would tend to agree. However, it is still providing plenty of copy even though the PCI DSS was introduced seven long years ago. At the time it was 'mandatory' and 'urgent' but the problem now is that, so many firms have avoided or delayed measures that overcoming the apathy often associated with PCI compliance is getting more difficult.

I read this last week on Bankinfosecurity.com

PCI SSC: Firms Must Perform Rigorous Risk Assessments

I couldn't agree more with one of the points made by Bob Russo, General Manager of the PCI Security Standards Council (PCI SSC). Mr. Russo is quoted as saying "The standard requires an annual risk assessment, because the DSS (data security standard) validation is only a snapshot of your compliance at a particular point in time. Therefore, it is possible that changes that have been made to a system since the previous evaluation could have undermined security protections or opened up new vulnerabilities"

In other words, real time file integrity monitoring coupled with  continuous server hardening checks is essential for PCI compliance - read more about both areas here.

And then two days later, I was sent a link to this article

Even the tiniest firms face fines for failing to protect credit card details

This is more interesting because the Daily Mail is about as mainstream as you can get in the UK - whatever you think about the newspaper's editorial leanings, this was published as contemporary, newsworthy copy for it's readers. The angle is about small firms needing to adhere to the PCI DSS requirements - again, not really news, as right from day one, anyone handling cardholder data has been burdened with a duty of care over it. Most small firms either run transactions directly to their bank or via an on-line service like Worldpay, so their main concerns for PCI compliance is to be aware of the risks and take care of the basics, such as

1. Don't write down, or store in any other form, cardholder details. If you need to regularly re-use a customers card details, you'll either need to ask for them again each time, or use your banks 'vault' facilities (based on tokenized card data)

2. Check you Pin Entry Device regularly and don't let anyone tamper with it. Card skimming is still one of the biggest card theft opportunities - see this video for the basics. In the UK, Chip and PIN has significantly reduced the risk but in the US and other parts of the world where card handling checks are limited to a superficial signature (that is rarely even checked against the card), card skimming still pays dividends. Of course, just because Track 1 data from a card is stolen in the UK, the card can still be cloned and used anywhere in the world where Chip and PIN is not enforced.

3. Make sure you are learning from the PCI DSS - work to use as many of the measures as you can. Even if you are using an online service to process a card payment transaction, the PC used to enter the details could be compromised by a key logger or other malware designed to steal data. Hardening your systems in line with Best Practice checklist guidance, Firewalling, Anti Virus, File Integrity Monitoring and Logging will all ensure your systems are secure and that you have the visibility of potential security threats before they can be used to steal card data.

If you can follow some of these basic steps then you'll be able to ensure that your company doesn't end up as headline news for the next card data theft story.



Wednesday, 7 December 2011

PCI Compliance In 10 Minutes A Day - Using File Integrity and Log File Monitoring Effectively

PCI Compliance Is Hard for Everyone!
In some respects, it can be argued that, the less IT 'stuff' an organization has, the fewer resources are going to be needed to run it all. However, with PCI compliance there are still always 12 Requirements and 650 sub-requirements in the PCI DSS to cover, regardless of whether you are a trillion dollar multinational or a local theatre company.

The principles of good security remain the same for both ends of the scale - you can only identify security threats if you know what business-as-usual, regular running looks like.

Establishing this baseline understanding will take time - 8 to 24 weeks in fact, because you are going to need a sufficiently wide perspective of what 'regular' looks like - and so we strongly advocate a baby-steps approach to PCI for all organizations, but especially those with smaller IT teams.

There is a strong argument that doing the basics well first, then expanding the scope of security measures is much more likely to succeed and be effective than trying to do everything at once and in a hurry. Even if this means PCI Compliance will take months to implement, this is a better strategy than implementing an unsupportable and too-broad a range of measures. Better to work at a pace that you can cope with than to go too fast and go into overload.

This is the five step program recommended, although it actually has merit for any size of organization.

PCI Compliance in 10 Minutes per Day
1. Classify your 'in scope of PCI' estate
You first need to understand where cardholder data resides. When we talk about cardholder data 'residing' this is deliberately different to the more usual term of cardholder data 'storage'. Card data passing through a PC, even it is encrypted and immediately transferred elsewhere for processing or storage, has still been 'stored' on that PC. You also need to include devices that share the same network as card data storing devices.
Now classify your device groups. For the example of Center Theatre Group, they have six core servers that process bookings. They also have around 25 PCs being used for Box Office functions. There are then around 125 other PCs being used for Admin and general business tasks.
So we would define 'PCI Server', 'Box Office PC' and 'General PC' classes. Firewall devices are also a key class, but other network devices can be grouped together and left to a later phase. Remember - this isn't cutting corners and sweeping dirt under the carpet, but a pragmatic approach to doing the most important basics well first, or in other words, taking the long view on PCI Compliance.

2. Make a Big Assumption
We now apply an assumption to these Device Groups - that is, that devices within each class are so similar in terms of their make-up and behavior, that monitoring one or two sample devices from any class will provide an accurate representation of all other devices in the same class.
We all know what can happen when you assume anything but this is assumption is a good one. This is all about taking baby steps to compliance and as we have declared up front that we have a strategy that is practical for our organization and available resources this works well.
The idea is that we get a good idea of what normal operation looks like, but in a controlled and manageable manner. We won't get flooded with file integrity changes or overwhelmed with event log data, but we will see a representative range of behavior patterns to understand what we are going to be dealing with.
Given the device groups outlined, I would target one or two servers - say a web server and a general application server - one or two Box Office PCs and one or two general PCs.

3. Watch...
You'll begin to see file changes and events being generated by your monitored devices and about ten minutes later you'll be wondering what they all are. Some are self explanatory, some not so.
Sooner or later, the imperative of tight Change Control becomes apparent.
If changes are being made at random, how can you begin to associate change alerts from your FIM system with intended 'good' changes and consequently, to detect genuinely unexpected changes which could be malicious?
Much easier if you can know in advance when changes are likely to happen - say, schedule the third Thursday in any month for patching. If you then see changes detected on a Monday these are exceptional by default. OK, there will always be a need for emergency fixes and changes but getting in control of the notification and documentation of Changes really starts to make sense when you begin to get serious about security.
Similarly from a log analysis standpoint - once you begin capturing logs in line with PCI DSS Requirement 10 you quickly see a load of activity that you never knew was happening before. Is it normal, should you be worried by events that don't immediately make sense? There is no alternative but to get intimate with your logs and begin understanding what regular activity looks like - otherwise you will never be able to detect the irregular and potentially harmful.

4....and learn
You'll now have a manageable volume of file integrity alerts and event log messages to help you improve your internal processes, mainly with respect to change management, and to 'tune in' your log analysis ruleset so that it has the intelligence to process events automatically and only alert you to the unexpected, for example, either a known set of events but with an unusual frequency, or previously unseen events.
Summary Reports collating filechanges on a per server basis are useful This is the time to hold your nerve and see this learning phase through to a conclusion where you and your monitoring systems are in control - you see what you expect to see on a daily basis, you get changes when they are planned to happen.

5. Implement
Now you are in control of what 'regular operation' looks like, you can begin expanding the scope of your File Integrity and Logging measures to cover all devices. Logically, although there will be a much higher volume of events being gathered from systems, these will be within the bounds of 'known, expected' events. Similarly, now that your Change Management processes have been matured, file integrity changes and other configuration changes will only be detected during scheduled, planned maintenance periods. Ideally your FIM system will be integrated with your Change Management process so that events can be categorized as Planned Changes and reconciled with RFC (Request for Change) details.

Monday, 18 July 2011

The PCI DSS - Want Some More Advice?

Where to start with PCI Compliance? The PCI DSS is well thought out, utterly comprehensive but man - it's big!
The PCI DSS is also not at all easy to understand, and even less easy to apply to your personal situation. The headlines are as follows:
The PCI DSS is also not at

  • 12 Requirements
  • but 230 sub-requirements
  • and some estimates of 650 detail points

The PCI DSS in 2011 still remains an ongoing challenge for the overwhelming majority of PCI Merchants. The following is based on the feedback we have had from working with a number of casino resorts, theme parks, ferry services and call centers over the past few months and the statistics make interesting reading for any other PCI Merchant wanting advice about PCI compliance.

Typically, one in every two Tier 2 and Tier 3 Merchants admit they do not understand the requirements of the PCI DSS. If you are either still working on implementing compliance measures identified in pre-audit surveys, or are not compliant and doing nothing about it, or are leaving everything to the last minute, don't be too hard on yourself - nine out of ten Merchants are at the same stage.
In fact, it is fine to have a phased, prioritized approach and the PCI DSS Council fully recommend this strategy, mindful that Rome wasn't built in a day.

Prioritizing PCI Compliance Measures
With so much ground to cover, prioritizing measures is a must, and indeed the recently released 'Prioritized Approach for PCI DSS Version 2.0' from the PCI Security Standards council website is an essential document for anyone working out where to start.

Although the PCI DSS is sectioned loosely around twelve headline Requirements in terms of technologies (Firewalling, Anti-Virus, Logging and Audit Trails, File Integrity Monitoring, Device Hardening and Card Data Encryption) - and procedures and processes (physical security, education of staff, development and testing procedures, change management), you soon realize that there are threads that run horizontally through all requirements.

In this respect there is potentially a good argument for the creation of other versions of the PCI DSS oriented around procedural dimensions, such as password policies for all disciplines and devices, or change management for all disciplines and devices, and so on. Whilst the Prioritized Approach gives a good framework for planning and measuring progress, it is strongly advised that you also look up at every step and see which other requirements can be taken care of by the same measure being implemented.

For instance, file integrity monitoring is only specifically mentioned in Requirement 11.5, however, good FIM software solutions will underpin Requirement 1, requirement 2, and requirements 3, 4,5,6,7,8,10, and 12.
The general advice is that, even though it is very daunting, if you can get 'intimate' with the PCI DSS, both in spirit and in detail, then as with everything else in life, the better informed you are, the more in control you will be, and the less money and sweat will be wasted.

If you consider Requirement 1 of the PCI DSS, this is oriented around the need for a firewall and a fundamentally secure network design. However, you quickly end up with a secondary list of questions and queries. Do we need a diagramming tool? Do we need to automate the monitoring of firewall rule changes? (Incidentally, this is a task easily done using a good file integrity monitoring product) What is our Change Management Process? Is it documented?

Summary
The PCI DSS may well challenge your pre-conceptions about what an Information Security Policy comprises - but there is plenty of help to draw upon.
In summary

  • Use vendor offers - a free trial of event log server software will allow you to see first-hand how much notice you are likely to be dealing with in your estate and how straightforward or otherwise an implementation might be before you spend any money

  • Use the PCI Security Standards Council website - tools like the Prioritized Approach spreadsheet will help breakdown the full PCI DSS into a more manageable series of steps and priorities

  • Look for quick wins and the best 'bang for buck' measures - implementing File Integrity Monitoring software for PCI compliance can take a big bite of the overall requirements and may be one of the simpler and affordable steps you take

Friday, 15 July 2011

The PCI DSS - Need A Little More Advice?

How much does PCI Compliance cost?
The first question that any organization will ask about PCI compliance is 'What does it cost?' (The second question typically being 'What happens if we don't get ourselves compliant?' but we can come back to this question later).

The issue of cost is a good question to ask up front but as you may have already discovered, one that is very difficult to get a straight (and reliable!) answer to.
In fact an article appeared recently in Secure Computing Magazine based on some research a vendor and an independent research organization had carried out. The premise of the article was that the 'average' cost of compliance was typically £4M more expensive than not being compliant, based on the average cost of achieving compliance being £2M, whilst the cost of non-compliance was £6M.

You could suggest that, for product vendors within the marketplace, this is great news and that most will have a vested interest in making things seem more complicated and consequently more expensive than they are. Then there is also the issue of the need to use a Qualified Security Assessor or QSA. A QSA is trained and accredited by the PCI Security Standards Council, so their knowledge is excellent but it comes at a price.

Conversely, there is plenty of free advice available from the PCI Security Standards Council website (and from vendors too), so you can get yourself educated and in control of your organizations PCI compliance program before engaging the services of a QSA.

What is the cost of non compliance with the PCI?
Of course, there is another dimension to the question 'How much does PCI Compliance cost?' You could instead ask 'What happens if we don't get PCI Compliant?'

One approach is to assess how much your brand and reputation is worth? If your business hits the headlines for the wrong reasons due to a breach - and it will be mainstream press now, not just the IT or Retail Industry Press - then customers will be thinking twice before they hand over payment card details to you.
Therefore it isn't just the fines, the cost and hassle of a forensic investigation of your security measures, or even the risk of increased transaction fees and more demanding audit pressure. There are now a growing number of US states bringing in legislation, such as in Nevada where the SB 227 Amendment specifically states a requirement to comply with the PCI-DSS. Similarly in the UK, the Information Commissioners Office will fine any organization that is found to be in breach of the UK Data Protection Act which compels organizations to protect customer personal information.

The bottom line is that if your organization loses customer personal information this is going to result in exactly the wrong kind of publicity. A customer can easily cancel a credit card and get a new number, but if you lose their address and date of birth this is impossible to reset, and they will not thank you for doing so!

What are the benefits of PCI compliance?
Where is the upside? In respect of a PCI Log Management solution, this will not only provide an advanced warning security system but one that can also alert you to impending hardware problem. How much is it worth to know in advance that you need to replace that till hard drive before it actually fails on the Saturday before Christmas!

The PCI DSS also provides a well-thought out and comprehensive off-the-shelf security policy, with a ready-made mature industry and knowledge base to draw upon that can double up to govern personal information too. Other industries are trying to adopt ISO27K but this simply doesn't have the pedigree or maturity of the PCI DSS.

Eduardo Perez is now Chairman of the PCI Security Council. Perez was featured in Secure Computing Magazine making it clear he wanted to dispel the 'wait and see' mindset of many merchants by saying that, despite what you will continue to read, there are simply no magic or even silver bullets for the PCI DSS. The message was clear - Forget about 'buying' an off-the-shelf solution to the PCI DSS.

Merchants are advised that they will need to work at achieving PCI Compliance and as much as you can automate some aspects and buy products for other requirements such as Event Log Management and File Integrity Monitoring, you will always be compelled to adopt all dimensions of best practice in security management. This means removing any complacency about being compliant or cutting corners - the PCI DSS should be a pervasive factor across all functions and departments of any organization using payment card holder data.

Expect tokenization and p2p encryption to be embraced by the PCI security council but don't expect any relaxing of other measures - they want more layers of protection, with more double-checks, safety nets and good old fashioned common sense. For instance, there will always be a need for file integrity monitoring software to ensure encryption applications have not been compromised, coupled with log management software to track any access or changes to systems.
Some advice from our customers, QSA colleagues and us

  • Don't let vendors and suppliers or even your QSA tell you what you should do and buy - get educated. There is lots of free advice around, not least from the PCI Security Council themselves.

  • don't assume you need to spend sacks of money on products and replacing everything you have - re-organize your network to reduce scope, recycle - use your older firewall to partition your network and reduce scope, use your existing processes and procedures but just formalize and document, and reduce your use of card data where possible, reduce those with access to data

  • Look for quick wins - contemporary log management and intelligent audit trail systems can be implemented quickly and even file integrity monitoring, always seen in the past as being expensive and complex are now affordable and automated

  • make your own decisions about the risks and potential for theft, then confirm with QSA - don't ask for guidance unless absolutely necessary

Wednesday, 6 July 2011

The PCI DSS - Want Some Advice?

If you are a Payment Card Merchant looking for advice on getting PCI compliant then you are in good company. The following is based on information which a number of retailers and associated payment card service providers have been telling us over the past few months with respect to the PCI DSS.

Whilst we find there is strong understanding within Tier 1 merchants (6 million transactions per year), these organizations, in common with smaller merchants, are keen to hold off on major spending. Regarding the likely cost of any PCI DSS initiative this is covered in a subsequent article.

There is some good common sense in taking a 'wait and see' strategy. The future of the PCI DSS may well see some changes introduced, but this is actually not a good reason to delay implementation of a serious security strategy now. The big talking points of the moment include Tokenization and End to End Encryption (aka Point to Point Encryption) and both will have a role to play in the future, but right now there are plenty of good PCI DSS measures that should be implemented.

Furthermore, the entire premise of the PCI DSS is that a wide and diverse range of security measures are required, employing a combination of technological defenses and sound procedural practice.
For instance, Event Log management and File Integrity Monitoring are both essential requirements of the PCI DSS and can often be implemented quickly and for minimal expense while at the same time taking care of around 30% of PCI DSS requirements. You can calculate your own PCI compliance score by using the PCI Security Council's Prioritized Approach Tool spreadsheet, available to download free from the PCI Security Council website.

The PCI Security Standards Council website provides a wealth of information for understanding and navigating the PCI DSS. User forums such as the LinkedIn PCI DSS Compliance Specialist and vendor blogs and websites are also good sources of free information. Typical estimates suggest as many as 35% of retail, hospitality and entertainment organizations still do not understand compliance requirements.

However, understanding the way in which other organizations have dealt with the challenges you are facing is the best way to ensure you approach PCI Compliance with a clear vision of where you are likely to end up in terms of investment and procedural development. There are a number of cautionary tales in the marketplace to heed, such as a Tier 1 Retailer jumping in feet-first with a logging solution, only to find that they needed to employ a team of eight additional personnel to run and manage the system. This actually says more about the need to be careful about how you implement PCI Compliance measures and to go into it with your eyes open rather than the real demands of a good PCI event log management system, but it serves to illustrate how it is easy to get this wrong if you do not get good advice before you begin spending money.
Nearly all vendors will provide a free trial of any PCI compliance software solution and you would do well to make sure that where your PCI DSS program requires you to make investments and changes to in-house procedures, make sure you can see the big picture for day to day operation.

Implementation of a PCI log server needn't take very long and the overall process of implementing a syslog server trial will show you what you need to log and how much work will be needed.
For instance, Windows Servers will need some form of Windows syslog agent to be installed so that events can be forwarded from the Windows Server to the central PCI log server to be backed up centrally. However, you will also need to implement changes to either the Group Policy or Local Security Policy with respect to audit settings, and also review windows event log settings so that logons, privilege usage, policy changes, object access, creation and changes are all being audited and backed up in accordance with the PCI DSS.

You'll then need to implement logging for your Unix and Linux hosts, AS/400 and mainframe, together with configuring syslog logging for firewalls, switches and routers.

The whole process need not take more than a few hours but as well as showing you how much work is likely to be required to get your estate PCI compliant, you will begin to appreciate the PCI DSS philosophy in requiring not just access controls, preventing access to card holder data, but why active monitoring of changes is vital, coupled with a full, forensic-detail audit trail.

Tuesday, 21 December 2010

PCI DSS 101 - All The Background You Need For Understanding The PCI DSS - Part 2

This is the second of a two part article intended to provide a backgrounder in understanding the PCI DSS. See Part 1 for the following
• What is it, and why is it important?
• The 12 Point PCI DSS
• So who exactly is subject to the PCI DSS?
Sounds like a lot of work and expense - what is the cost justification for the PCI DSS?

Trying to understand the actual cost of payment card fraud is not straightforward - by their very nature, fraudulent transactions are hidden.
Visa Europe report a level of fraud around 6 cents for every €100 spent. It is important to realize that this is the cost of fraud for Visa Europe itself (as opposed to the total cost associated with card fraud which would include lawsuit costs between merchants, acquirers and issuers). All the same, in 2009, those cards were used to make purchases and cash withdrawals to the value of more than €1.3 trillion. Doing the math, this would place an estimate on the cost of fraud to be €780M - just for Europe, and just for Visa.

In order to extrapolate these numbers, based on Visa Inc. Q1 FY 2010 earnings statement, Visa's global network processed payments totaling $4.4 trillion. Assuming Visa held a 38.3% market share of the credit card marketplace and 60.7% of the debit card market, the total value of payment card transactions for the world would be around $8.5 trillion.

If Visa's notional 6 cents for every dollar formula was applied, this would give an estimated value of fraud for the global payment card market of $5.1 billion - although again, this is purely for the card companies themselves.
Compare this figure with other sources that suggest the overall cost of UK Plastic card fraud was nearly £610m in 2008, an increase of more 14% over 2007 (figures published by APACS, the UK Payment Industry). Extrapolating this number at the same 14% per annum increase would give a 2010 figure of over £730M (approx. $1.2 Billion) just for the UK. Figures from the UK Card Association claim card fraud reduced by 20% in their most recent figures, based on January to June 2010 so these figures may be lower than estimated.

Global estimates for the cost of Online fraud - including identity theft and all payment-card abuse and organized crime - reached around $78bn last year (according to research house Global Uncertainties). If you are reading this as a Card Merchant though, the figures that will be more interesting for you are what the potential costs for you are. For Visa members, failure to report any suspected or confirmed loss of transaction data the member will be subject to a penalty of $100,000 per incident, rising to $500,000 depending on the scale and seriousness of the breach. Regarding remediation costs, most estimates cost this at between $90 and $302 per record.

The cost of compliance may also increase by way of making a compromised Tier 2, 3 or 4 merchant subject to Tier 1 merchant PCI DSS requirements, with the more stringent auditing process being required.
The absolute penalty for a payment brand is to disqualify a merchant from being able to process card transactions.

It is worth mentioning that in one of the few publicized breaches, Heartland Payment Systems (corporate.visa.com/media-center/press-releases/press974.jsp) are agreeing to pay $60M in compensation to card issuers that have suffered losses as a result of the criminal breach of Heartland's systems. The loss of customer trust and the corporate shame of being exposed as an organization that has compromised their customers' personal data could ultimately be far more expensive.

What happens in the event of us being breached?
Visa provides the following Steps for 'compromised entities'
1. Immediately contain and limit the exposure. Prevent further loss of data by conducting a thorough investigation of the suspected or confirmed compromise of information.
2. Alert all necessary parties immediately. Including
• Your internal information security group and incident response team.
• Your merchant bank.
• Visa Fraud Investigations and Incident Management group
• Your local office of the United States Secret Service
3. Provide all compromised Visa, Interlink, and Plus accounts to your merchant bank within 10 business days
4. Within 3 business days of the reported compromise, provide an Incident Report document to your merchant bank

Is PCI-DSS Compliance Required by Law?
The Minnesota Plastic Card Security law doesn't make PCI a legal requirement but it does mandate that companies storing credit card information that subsequently suffer a breach will need to reimburse the card issuer for any costs associated with the breach. In other words, it reinforces a key PCI requirement rather than legislating for it.

Similarly, Nevada has the Security of Personal Information Law and the Nevada Senate Bill 227 in which SB 227 Amendment specifically states a requirement to comply with the PCI-DSS.
Also, The Washington House Bill 1149 (Effective Jul 01, 2010) "recognizes that data breaches of credit and debit card information contribute to identity theft and fraud and can be costly to consumers."
Massachusetts is introducing 201 CMR 17.00 which seemingly borrows heavily from the PCI DSS.
Several other states are making attempts to enforce PCI DSS-aligned legislation such as Texas, California, Illinois and Connecticut.
Beyond these specific examples of PCI DSS-aligned laws the overwhelming majority of US states, Puerto Rico and the Virgin Islands have legislation that requires disclosure of data breaches.

Summary
Understanding the PCI DSS and how to implement it for your organization will take time, care and attention but many of the measures required can be automated and simplified using contemporary software technology.

Tuesday, 7 December 2010

PCI DSS 101 - All the Background You Need for Understanding the PCI DSS - Part 1

What is it, and why is it important?
The Payment Card Industry Data Security Standard was designed as a comprehensive list of best practice measures and processes for handling, processing, storing and transmitting payment card data.

The PCI DSS was formulated by the payment card companies such as Visa and MasterCard in response to the growing number of instances of theft and misuse of payment card details. The first version of the PCI DSS was released in December 2004 and mandates a wide range of measures required to ensure the protection of payment card data.

The measures are summarized in the 12 section PCI DSS but a high-level overview can be broken down into 3 main areas
• Active Technological Security Measures (firewalls, intrusion detection systems, anti-virus, file-integrity monitoring, data encryption)
• IT Security Best Practices (masking of card data within applications, configuration 'hardening', regular updates to password and security keys, regular vulnerability scans and penetration tests, review of all security and audit logs)
• General Security Best practices (such as physical building security measures and personnel awareness of IT Security measures)
Today, the PCI Security Standards Council has been established by the major payment card brands and is the body "responsible for the development, management, education, and awareness of the PCI Security Standards".

The 12 Point PCI DSS
The latest version of the PCI DSS is Version 2.0. It retains the same 12 Core requirements as previous versions of the standard, which in turn branch into more than 250 controls - the full standard can be accessed at pcisecuritystandards.org but the following is a summarized 'plain English' version
1. Use a firewall - typically the core 'Card Data Processing' systems are segregated from the Corporate Network using an internal firewall in addition to any external internet-facing firewall
2. Secure system access through configuration hardening - use non-default passwords, SSL/TLS and SSH for any system access, disable unnecessary services and protocols to minimize accessibility
3. Use masking and encryption of cardholder data to ensure that data is unreadable if stolen, but only ever store as little data as possible
4. Use encryption for any cardholder data when being transferred over public networks
5. Use anti-virus software, regularly updated
6. Increase the inherent security of all systems through configuration hardening i.e. remove known vulnerabilities through patching and configuration settings
7. Use Identity and Access Management controls to minimize access to cardholder data system on a strict 'need to know' basis
8. Assign a unique ID to each user and enforce strong authentication
9. Lock your doors - utilize physical security measures to restrict access to systems such as door locks, badge readers and video cameras
10. Track and monitor all access to all network resources and cardholder data - centrally backup event and audit log trails, especially for logons
11. Get a Vulnerability Scan and Penetration Test by an Approved Scanning Vendor performed every 3 months and after nay significant network change. Use file-integrity monitoring to protect critical system and configuration files
12. Adopt an Information Security Policy to ensure there is an appreciation of the PCI DSS objectives by all employees and contractors

So who exactly is subject to the PCI DSS?
Regardless of what the tangible cost of payment card fraud actually is, there is no alternative for any card merchant but to comply with the PCI DSS. However, the burden of proving your compliance with the standard does vary according to the volume of transactions being processed.
Any merchant storing, processing or transmitting Primary Account Numbers (PAN) must comply with the PCI DSS.
Processing is often one of the key qualifiers in that, a PC used to access a secure on-line payment portal can still be defined as 'within scope' of the PCI DSS which means even small organizations are still subject to the PCI DSS. For instance, card 'skimming' techniques are widespread, generally targeting the card reader or PIN entry device, or via software installed on the PC making the transaction.
The PAN must be rendered unreadable while the Cardholder Name, Service Code and Expiration date can be stored in readable format.

Card data that absolutely must not be stored comprises
• the Track 1 and Track 2 data (all the cardholder and card data is stored within two tracks on the card magnetic stripe and chip embedded on chip and pin cards)
• the Card Verification Value (CVV - typically the three digits printed onto the card signature strip) and of course
• the PIN data (the card PIN number used to authorize a transaction on a Chip and PIN card)

All card transactions represent a risk, including ecommerce transactions. For Visa Merchants,
Level 1 - Merchants processing more than 6 million transactions annually are required to have an on-site PCI Data Security Assessment and quarterly network scans. On-site assessments may be completed internally or by an outside Qualified Security Assessor or QSA.
Level 2 - Merchants processing 1 million to 5,999,999 transactions annually are required to complete a Self-Assessment and perform quarterly network scans.
Level 3 - Merchants processing 20,000 to 1,000,000 e-commerce transactions annually are required to complete a Self-Assessment and perform quarterly network scans.
Level 4 Merchants process less than 20,000 e-commerce transactions annually and all merchants across channel up to 1,000,000 VISA transactions annually and are required to complete an annual self assessment and annual security scans.

Wednesday, 29 September 2010

PCI DSS Compliance - Be in Control in Four Moves

The security standard calls for a broad range of security measures, but beyond the use of firewalling, intrusion protection systems and anti-virus software, the understanding of the requirements and responsibilities of the merchant are very often poorly understood.

This guide simplifies the scope of the balance of PCI DSS measures to just four areas.
- File Integrity monitoring
- Event Log centralization
- Security Vulnerability scanning for device hardening
- Change Management process
Understanding and implementing measures to address these four areas will make any QSA happy and get you compliant - and keep you compliant - in no time at all.

File Integrity Monitoring
As a mandated dimension of the PCI DSS, FIM verifies that program and operating system files have not been compromised.

Why is this important? The principal benefit of using FIM technology is to ensure that malicious code has not been embedded within critical application and operating system files. The insertion of a 'backdoor' or Trojan into core program files is one of the more audacious and elegant forms of hacking, and also one of the most dangerous.

The PCI DSS (Payment Card Industry Data Security Standard) specifies the following "Deploy file-integrity monitoring software to alert personnel to unauthorized modification of critical system files, configuration files, or content files; and configure the software to perform critical file comparisons at least weekly" and also that for log files "Use file-integrity monitoring or change-detection software on logs to ensure that existing log data cannot be changed without generating alerts (although new data being added should not cause an alert)".
Contemporary compliance management technology will provide pre-defined templates for all folders and files that should be tracked for File-Integrity, also allowing you to specify additional program folders and files unique to your environment, for instance, your core business applications.

File Integrity Monitoring technology conducts an initial inventory of all filesystems specified and 'fingerprints' all files using secure hashing technology, generating a unique checksum for each file. The system will then audit all files being tracked on a scheduled basis every 24 hours (even though the PCI DSS calls only for weekly checks) with any changes, additions, deletions or modifications being reported to you.
The latest generation of File Integrity Monitoring software also operate in a 'live tracking' mode for ultra-secure environments where file changes are detected and reported in real-time.

Other options to consider are to track and identify actual changes to file contents, useful when tracking configuration files to provide you with a complete audit trail of change history - this can be applied to any form of files such as text and xml.

Continuous Vulnerability Scanning
All security standards and Corporate Governance Compliance Policies such as PCI DSS, GCSx CoCo, SOX (Sarbanes Oxley), NERC CIP, HIPAA, HITECH, ISO27000 and FISMA require Windows and Unix Servers, workstations, and firewalls, routers and switches to be secure in order that they protect and secure confidential data.

'Hardening' a device requires known security 'vulnerabilities' to be eliminated or mitigated. A vulnerability is any weakness or flaw in the software design, implementation or administration of a system that provides a mechanism for a threat to exploit the weakness of a system or process. For the PCI DSS, it is a requirement that all 'within scope' sites are scanned for vulnerabilities every quarter. This gets expensive in a large scale, multi-site estates, as well as being a time-consuming management overhead.

Perhaps the biggest issue is that the results of any scan are only accurate at the time of the scan - any configuration changes made after the scan could render devices vulnerable and in a worst case scenario, devices could be left vulnerable to attack for a 3 month period. The ideal solution is to continuously track configuration changes. This is the only real way to guarantee the security of your IT estate is maintained. Using continuous configuration tracking technology allows you at any time to see the Compliance Score of any server and which settings need to be changed to re-harden the config. Any changes made should be reported, including Planned Changes which should also be reconciled with the original Request For Change or RFC record.

Secure, Centralized Event Log Management
Log analysis is a key weapon in the fight against any cyberattack. By gathering logs from all unix and windows servers, applications and databases, firewalls and routers, the method and pattern of an attack can be understood. Identifying the method and source of any attack allows preventative measures to be continually improved. This is why all security policies place log retention at their core. PCI DSS compliance requires logs to be gathered and reviewed daily, and retained for at least one year. Similarly for GCSx Code of Connection or CoCo compliance - Audit logs recording user activities, exceptions and information security events are to be retained for at least 6 months.

For any compliance initiative, it will be necessary to gather logs from all
- Network Devices
- Windows, Unix and Linux servers
- Firewall or IPS and IDS devices, Email and Web Servers
- Database and Application servers - even IBM Mainframes
- All other potentially useful sources of log information

Although the scope of most compliance standards will be largely satisfied at this stage, far greater value can be extracted from Centralizing Event Logs. Contemporary event and audit log management technology ensures all event logs are analyzed and correlated automatically, applying a comprehensive series of rules pertinent to any Security or Governance policy. Any breach of compliance will be alerted immediately allowing pre-emptive action to be taken before a problem arises. The best log management solutions provide pre-defined rules templates, allowing you to be in control of compliance straight out of the box.

The following is a checklist of features available in today's best log management software -
- All Security and Governance Policies supported via pre-packed Compliance Rule Templates
- Real Time Security Warnings i.e. violation of file integrity monitoring rules
- PCI DSS and GCSx Code of Connection supported 'out of the box'
- Web-based Dashboard and integration with Servicedesk as standard
- Powerful, keyword-based Event Log mining across any combination of devices and applications
- Complete solution for all Security Information and Event Management (SIEM) requirements
The latest generation of centralized log server software allows you to focus on true exceptions and important events by masking off the sometimes overwhelming flood of logs. Use the pre-built Compliance Templates and build your own keyword and logic-based correlation rules, allowing you to manage what really matters to your organization from a security and compliance standpoint.

Change and Configuration Management
ITIL Best Practises identify Change Management as one of the key, central processes that should be understood and assimilated into an IT Service Delivery operation. Change Management as a process is intended to ensure that when changes are made, they are first verified as being completely necessary and adding some value to the organization, and if so, that changes are then well planned, documented and clearly communicated to ensure any potential negative impact from the change is understood and eliminated or minimized. The entire experience and knowledge of the enterprise is harnessed and greater efficiencies can be gained from 'one visit' fixes - i.e. a number of required changes can all be delivered during one planned maintenance window. A well maintained Configuration Management Database (CMDB) will often be used as a means of better understanding the 'downstream' effects of changes and or their impact on a number of critical business services.

Crucially for any organization subject to Corporate Governance-driven security standards, changes to any IT system can affect its security. Installing application updates may introduce new vulnerabilities and making any configuration change may also render systems less secure and more prone to a security breach. The latest change and configuration management software tracks all changes to your infrastructure, exposing all unplanned changes and reporting clearly on the intended - and uniquely, the actual outcome - of any planned change. All network device configurations are automatically and securely backed up, with the option to remediate any unauthorized configuration change. Server configurations are tracked against either pre-defined security policies or your own personalized policy, with any deviations highlighted.
And once firewalls, servers, workstations, switches and routers are all in a compliant state, you need to ensure they remain that way. The only way to do this is to automatically verify configuration settings on a regular basis. Why? Because unplanned, undocumented changes will always be made while somebody has the admin rights to do so - legal or otherwise! The configuration change tracking solution will alert you when any unplanned changes are detected as well as keeping an audit trail of planned changes, reconciled with the request for change details.

This provides a unique 'Closed-Loop Change-Management Safety Net' - when changes need to be made to a device it is vital to ensure that changes are approved and documented - we make this easy and straightforward, reconciling all changes made with the RFC or Change Approval record. An open API allows integration with most service/help desks or other change management systems to establish a link between the change approval process and the actual changes that are made.

Tuesday, 29 June 2010

PCI DSS Compliance in 2010

The Payment Card Industry Data Security Standard, or PCI DSS, is still confusing for card payment merchants in 2010.

A recent survey of PCI DSS knowledge and understanding revealed the following facts:
• 35% of retail/hospitality/entertainment organisations surveyed still do not understand compliance requirements
• Whilst there is a strong understanding within Tier 1 merchants (6 million transactions per year), 44% of Tier 2 and Tier 3 merchants do not understand the PCI DSS requirements
• 90% are either still working on implementing PCI DSS compliance measures identified in pre-audit surveys, or are not compliant and doing nothing about it, or are leaving it to the last minute

What do you need to do as an IT Service Provider to your Organization?
A number of automated 'compliance auditing' solutions for PCI DSS are available that typically provide the following functions
Compliance Auditing (aka Device Hardening) - typically, 'out of the box' PCI DSS as well as 'made to order' reports allow you quickly test critical security settings for windows servers and desktops, unix servers, linux servers and network devices, including wireless devices, and firewalls. The best solutions will provide details on your administrative procedures, technical data security services, and technical security mechanisms. Generally, these reports will probably identify some security vulnerabilities within the configuration settings to begin with. Once repaired though, you can generate these reports again to prove to auditors that your servers are compliant. Using inbuilt change tracking you can ensure systems remain compliant.
Change Tracking - once your firewalls, servers, workstations, switches, routers etc are all in a compliant state for PCI DSS you need to ensure they remain so. The only way to do this is to routinely verify the configuration settings have not changed because unplanned, undocumented changes will always be made while somebody has the admin rights to do so! The PCI DSS compliance software solution will alert when any unplanned changes are detected for server software using file-integrity monitoring, or firewalls and intrusion protection systems, and any other network device within your 'Compliant Infrastructure'.
Planned Change Audit Trail - when changes do need to be made to a PCI DSS server, firewall or network device, you need to ensure that changes are approved and documented. An automated software solution for PCI DSS makes this easy and straightforward, reconciling all changes made with the RFC or Change Approval record
Device Hardening must be enforced and audited. A good PCI DSS compliance auditing solution will provide automated templates for a hardened (secured & compliant) configuration for servers and desktops and network devices to show where work is needed to get compliant, and thereafter, will track all planned and unplanned changes that affect the hardened status of your infrastructure. The state of the art in compliance auditing software covers registry keys and values, file integrity monitoring, host integrity monitoring, service and process whitelisting/blacklisting, user accounts, installed software, patches, access rights, password ageing and much more.
Audit Log Management - All audit and event logs from all windows servers, Unix servers, Linux servers, firewalls and intrusion protection devices must be analyzed, filtered, correlated and escalated appropriately. Audit Log and Event log messages must be stored in a secure, integrity-assured, repository for the required retention period which for PCI DSS is 12 months.
Correlation of Security Information and Audit Logs - in addition you should implement Audit Log and Event Log Gathering from all devices with correlation capabilities for security event signature identification and powerful 'mining' and analysis capabilities. This provides a complete PCI DSS compliance safety net to ensure, for example to name just a few, virus updates complete successfully, host intrusion protection is enabled at all times, firewall rules are not changed, user accounts, rights and permissions are not changed without permission and patches are implemented.

Monday, 10 May 2010

Complicated, Expensive and Time-Consuming - But the PCI DSS Isn't Going Away

Around $12Billion is wasted on unused gym memberships each year, confirming that good intentions can get you as far as signing up, but not necessarily to work out. So every year around the world, good intentions to exercise more regularly and to get fit once and for all still remain unfulfilled.

And even in May 2011, 6 years after the PCI DSS was introduced, the number of PCI Merchants who are only partially compliant with the PCI DSS vastly outweighs the small numbers who are.
Reasons given by PCI DSS merchants for not progressing their PCI compliance program range from -

- Duck it! "The future is too unclear to make any investment..."
- Paralysis! "We don't want to make mistakes like xyz..."
- Ignore it! "We don't need to bother - we've been OK so far and we view the risks as low..."
- Go Slow! "We have kept some updated procedural stuff back and if we drip-feed this to the Bank over the next two quarters then we are covered for the next few months..."

Aside from the threat of fines for non-compliance and increased transaction fees, the biggest motivator for getting compliant is the knowledge that cybercrime is now considered worthy as mainstream headline news. Get breached, lose your customers' card data and/or personal information and you will be publicly named and shamed before the lawsuits start arriving. Talk to the guys at TJ Maxx or Sony's PlayStation Network and they will be able to tell you that dealing with the fallout from a breach is way more expensive, embarrassing and tough than any PCI DSS program could ever be.

How much does it cost to procrastinate, delay and ignore the requirements of the PCI DSS?
Wouldn't it be a better use of resources to embrace the PCI DSS, understand its intentions and methods, then apply these to your organization? You need a security policy, so why not take the 'off the shelf' option on offer in the knowledge that this is a well-thought out, widely implemented and tested standard that works?

But be careful who you ask for advice
There is always a steady stream of 'vendor-speak' advocating '3/4/5/6 Easy Steps to PCI Compliance' and right now the promise of Point to Point Encryption and Tokenization are the latest 'Silver Bullets' being hailed as the Merchant's saviour.
However, Eduardo Perez, the Chairman of the PCI Security Council, was quick to counter any assertions about Magic or Silver Bullets for the PCI DSS, saying that there simply is no such thing in an article published in Secure Computing Magazine in April 2011.
Until then there is no alternative but to roll up your sleeves and get on with implementing the measures necessary to get your organization secure.

A reminder of the headline technological security measures needed -
- Firewall and Intrusion Protection needed (PCI Requirement 1) both at the network perimeter and internally
- Change Management (PCI Requirements 1,2,6,8,10 and 11) underpins all PCIDSS requirements, in as much as once your PCI Estate is secure, you need to ensure you keep it that way, so reducing changes and for those that are made, make sure they are planned, documented and approved. Ideally use automated continuous configuration monitoring to reconcile changes that are made with details of the intended change. Changes to files, registry keys, installed software, user accounts, security policy and audit policy settings, services and service states all need to be monitored.
- Device Hardening (PCI Requirements 2,6,8,10 and 11) a configuration and set-up process for all servers, EPoS devices, PCs and network devices, whereby the 'built-in' weaknesses and vulnerabilities present are removed or minimized. Use an ASV vulnerability scan to identify the existence of vulnerabilities and once the server or EPoS device is hardened, use a continuous configuration assessment agent to validate that vulnerabilities are not re-introduced
- Anti-Virus with automatic updating (Requirement 5)
- Centralized Event Log Management (PCI Requirement 10) gives both a pro-active security monitoring capability and a full, 'forensic' audit trail to use in the event of a breach. Use a Windows Syslog agent to forward events from servers and tills to the central server, and use the native syslog capabilities of firewalls, routers and switches to audit logon and log off activity. Event logging for the PCI DSS is best implemented using an automated log parsing system that can intelligently identify true security incidents
- File Integrity Monitoring (PCI Requirement 11.5) essentially, this requires the PCI Merchant to keep tabs on any changes made to the configuration of firewalls, switches and routers in the network, and use the file integrity monitor to ensure that windows operating system files and program files on EPoS devices and servers don't change. FIM for the PCI DSS is also used to track any access to Card Data files.