It has been a while since I sat down to write a post for my blog. The monsoon season has just set in this part of the world. The days are hot and it rains heavily on occasion causing one to just enjoy the comfort of his bed a little more than usual.
This was a piece, which had been in the works for sometime now. I had planned to write it, close on the heels of the Savvis lawsuit (for the CardSystems breach), but I missed my cue. Anyway, here goes. This lawsuit has been abuzz in blogosphere because some of the banks that were processing their card transactions through CardSystems (which was involved with one of the largest credit card breaches in history), have decided to file a lawsuit against Savvis, the organization that attested to the compliance of CardSystems, with the Visa compliance requirement called CISP (Cardholder Information Security Program). The CISP was the predecessor to someone we all know lovingly as the PCI-DSS (Payment Card Industry Data Security Standard). A little background here. CardSystems was one of the largest credit card processors in the US, and they were involved in a breach which compromised over 40 million card numbers. Savvis was the company, which certified CardSystems as compliant with the standards. Now, four years later, Merrick Bank has filed a case against Savvis, alleging that it has been negligent in certifying CardSystems. Frankly, I am not aware of whether Savvis has been negligent or not, but blogosphere and online news portals have gone wild with the news. The Security gurus are quoting their same old lines of the inadequacy of PCI Compliance and are questioning the 'rigour' of the standard in the protection of cardholder information.
My intention with this piece is 1) To introduce the some people out there to the concepts of "Reasonable Assurance" and "as on date"; Two concepts which have been in lost in the rhetoric which several security folks have been dishing out relentlessly. 2) Drive home my point of Risk based compliance, another concept which has been dulled with wrong interpretations of the PCI Standards 3) and hope that a few organizations would actually understand the concept of PCI being risk-driven as opposed to a dull checklist, requiring their meek submissiveness.
The security world has much to learn from the Financial audit and assurance world. No auditor will be able to guarantee that an organization's financial statements are free from error or misstatement. The auditor has to do everything that a prudent person in his place would do and in the end, signs off on a report which states that a "reasonable assurance" can be provided with respect to the financial statements. The auditor is not god, and the laws are quite aware of that and have provided for a similar treatment. Moreover, the auditor does not have to look for fraud, another basic truth in the financial audit world. The auditor must perform a risk assessment and gain an understanding of Internal control, before he performs his audit tasks. Contrast this with the security world. Information Security assurance, being nascent as it is, has not promulgated such basic truths to its practicing professionals. It still (subtly) preaches the utopian ideals of "Perfect security" Furthermore, PCI as a standard still has a very hazy understanding of what assurance the QSA actually provides. Is it "Reasonable Assurance" or is it a guarantee, because if it is a guarantee, then QSAs should pack their bags and quit the business, because that is impossible to provide. When it comes to reasonable assurance, the only defense that an auditor should provide in his alleged negligence, is his working papers and evidence. So my advice to people who are QSAs, please keep your workpapers and evidence in perfect auditor, they are your only saving grace tomorrow when fingers are pointed at you.
Another important concept which people usually miss out with PCI Compliance is the "as on date" concept. When an assessor certifies an organization for PCI, the certification is done as on date and not for the "period ending". I have seen several companies take the proverbial snooze after their PCI Compliance. 8/10 organizations I have seen have serious issues with their applications, or their network configurations or their log management and review. They would have slipped into non-compliance several times during the year and would have remained so till the the recertification for PCI Compliance. An assessor cannot be held responsible for the negligent organization on a future date, unless he has wrongfully or negligently assessed the misgiving as compliant as on the date of certification. I would like to add, at this juncture that I am not aware of whether Savvis was actually negligent or not. Its negligence can only be established once its made to produce evidence of its assessment and its work papers in front of a court. My advise to assessors is to go ahead and fail organizations which have not demonstrated compliance throughout the year.
When it comes to Risk based compliance, my views have already been aired, but I would like reiterate some practical angles to the same. Several clients ask me, "Where does it say that this has to be done in the PCI Standards?" The greatest advantage of the PCI Standards is also its weakest point. Its clarity. Several organizations interpret PCI to be a checklist requirement set which they need to fulfill and be done with. The PCI has acquired a reputation of being a standard which prescribes exaclty what to do and how to do it and that it is inflexible in its approach. True, it is specific, which is why, when a recommendation outside its realm, but very much in the realm of specific risk is given, it is quickly shot down by an organization as not being specific in the requirement. I have several (often heated) arguments with clients who ask me questions like, "Where does PCI say that Internet access to these partiular set of users should be blocked?", My reply to them is that PCI is a baseline set of controls to be applied to any environment storing, processing or transmitting cardholder information. For such specific requirements, a risk assessment is in order, which narrows down certain risks which are specific to the environment. If the risk of individuals having access to cardholder information as well as the Internet (where cardholder information can be sent over email or over the internet in any way) is high, then it is only prudent that you mitigate the risk and not let it become your Achilles Heel. My advice to organizations. Dont look at PCI as a checklist for truly being secure. Treat PCI as a baseline and add to it controls for the risks which are specific to your environment.
I would like to conclude by stating this. PCI Compliance, like anything else in Information security, is at its growing phase. There are bound to be a few teething problems with respect to the standard and its expectations. An organization intent on pursuing PCI Compliance should not be misguided by the pure view of the 12 requirements of PCI, but to understand the risks before going into requirements.
This was a piece, which had been in the works for sometime now. I had planned to write it, close on the heels of the Savvis lawsuit (for the CardSystems breach), but I missed my cue. Anyway, here goes. This lawsuit has been abuzz in blogosphere because some of the banks that were processing their card transactions through CardSystems (which was involved with one of the largest credit card breaches in history), have decided to file a lawsuit against Savvis, the organization that attested to the compliance of CardSystems, with the Visa compliance requirement called CISP (Cardholder Information Security Program). The CISP was the predecessor to someone we all know lovingly as the PCI-DSS (Payment Card Industry Data Security Standard). A little background here. CardSystems was one of the largest credit card processors in the US, and they were involved in a breach which compromised over 40 million card numbers. Savvis was the company, which certified CardSystems as compliant with the standards. Now, four years later, Merrick Bank has filed a case against Savvis, alleging that it has been negligent in certifying CardSystems. Frankly, I am not aware of whether Savvis has been negligent or not, but blogosphere and online news portals have gone wild with the news. The Security gurus are quoting their same old lines of the inadequacy of PCI Compliance and are questioning the 'rigour' of the standard in the protection of cardholder information.
My intention with this piece is 1) To introduce the some people out there to the concepts of "Reasonable Assurance" and "as on date"; Two concepts which have been in lost in the rhetoric which several security folks have been dishing out relentlessly. 2) Drive home my point of Risk based compliance, another concept which has been dulled with wrong interpretations of the PCI Standards 3) and hope that a few organizations would actually understand the concept of PCI being risk-driven as opposed to a dull checklist, requiring their meek submissiveness.
The security world has much to learn from the Financial audit and assurance world. No auditor will be able to guarantee that an organization's financial statements are free from error or misstatement. The auditor has to do everything that a prudent person in his place would do and in the end, signs off on a report which states that a "reasonable assurance" can be provided with respect to the financial statements. The auditor is not god, and the laws are quite aware of that and have provided for a similar treatment. Moreover, the auditor does not have to look for fraud, another basic truth in the financial audit world. The auditor must perform a risk assessment and gain an understanding of Internal control, before he performs his audit tasks. Contrast this with the security world. Information Security assurance, being nascent as it is, has not promulgated such basic truths to its practicing professionals. It still (subtly) preaches the utopian ideals of "Perfect security" Furthermore, PCI as a standard still has a very hazy understanding of what assurance the QSA actually provides. Is it "Reasonable Assurance" or is it a guarantee, because if it is a guarantee, then QSAs should pack their bags and quit the business, because that is impossible to provide. When it comes to reasonable assurance, the only defense that an auditor should provide in his alleged negligence, is his working papers and evidence. So my advice to people who are QSAs, please keep your workpapers and evidence in perfect auditor, they are your only saving grace tomorrow when fingers are pointed at you.
Another important concept which people usually miss out with PCI Compliance is the "as on date" concept. When an assessor certifies an organization for PCI, the certification is done as on date and not for the "period ending". I have seen several companies take the proverbial snooze after their PCI Compliance. 8/10 organizations I have seen have serious issues with their applications, or their network configurations or their log management and review. They would have slipped into non-compliance several times during the year and would have remained so till the the recertification for PCI Compliance. An assessor cannot be held responsible for the negligent organization on a future date, unless he has wrongfully or negligently assessed the misgiving as compliant as on the date of certification. I would like to add, at this juncture that I am not aware of whether Savvis was actually negligent or not. Its negligence can only be established once its made to produce evidence of its assessment and its work papers in front of a court. My advise to assessors is to go ahead and fail organizations which have not demonstrated compliance throughout the year.
When it comes to Risk based compliance, my views have already been aired, but I would like reiterate some practical angles to the same. Several clients ask me, "Where does it say that this has to be done in the PCI Standards?" The greatest advantage of the PCI Standards is also its weakest point. Its clarity. Several organizations interpret PCI to be a checklist requirement set which they need to fulfill and be done with. The PCI has acquired a reputation of being a standard which prescribes exaclty what to do and how to do it and that it is inflexible in its approach. True, it is specific, which is why, when a recommendation outside its realm, but very much in the realm of specific risk is given, it is quickly shot down by an organization as not being specific in the requirement. I have several (often heated) arguments with clients who ask me questions like, "Where does PCI say that Internet access to these partiular set of users should be blocked?", My reply to them is that PCI is a baseline set of controls to be applied to any environment storing, processing or transmitting cardholder information. For such specific requirements, a risk assessment is in order, which narrows down certain risks which are specific to the environment. If the risk of individuals having access to cardholder information as well as the Internet (where cardholder information can be sent over email or over the internet in any way) is high, then it is only prudent that you mitigate the risk and not let it become your Achilles Heel. My advice to organizations. Dont look at PCI as a checklist for truly being secure. Treat PCI as a baseline and add to it controls for the risks which are specific to your environment.
I would like to conclude by stating this. PCI Compliance, like anything else in Information security, is at its growing phase. There are bound to be a few teething problems with respect to the standard and its expectations. An organization intent on pursuing PCI Compliance should not be misguided by the pure view of the 12 requirements of PCI, but to understand the risks before going into requirements.
No comments:
Post a Comment