Bruce Sussman of Crowe Chizek: Stopping Data Leakage and PCI-DSS Compliance
RICHARD SWART: Hi, this is Richard Swart with Information Security Media Group, publishers of BankInfoSecurity.com, and CUInfoSecurity.com. Today, we will be speaking with Bruce Sussman, the Senior Manager at Crowe Chizek, who has almost 20 years of experience in the banking information security and audit community. Good afternoon, Bruce.
BRUCE SUSSMAN: Good afternoon. How are you?
SWART: Very good. Weâ€™d like to sort of focus today on PCI Data Security Standard compliance issues, and I was wondering if you could start by telling our listeners, what are the requirements and key factors that a financial institution needs to know to achieve and maintain compliance with the PCIDSS Standard?
SUSSMAN: Well, first of all, an institution really needs to understand what their role is within the payment system, and by that, I mean would they fall within the classifications that the network used for either a service provider, a gateway, a merchant. Institutions really need to refer to the definitions that are maintained by the card network. So, for example, if you go out to Visaâ€™s site, using them as an example, they have very specific requirements for and definitions that a financial institution has to know. But mostly institutions really need to focus on, â€œWhere is there card data located?â€ â€œWho holds it if itâ€™s not that institution (in other words who is the service provider)?â€ â€œWhat is the data that is maintained? â€œIs it encrypted?â€ â€œWhat is their transaction volume?â€ And, â€œWhat are the particular payment applications that are being used, as well as the particular hardware and equipment?â€ Once all that information is in hand, then a financial institution would be well-equipped to go down the list of requirements that are maintained by the payment card security consortium known as PCICO. Those requirements are variously known as the â€œDigital Dozen,â€ and they basically relate to requirements for protecting card data when it is stored, or when it is processed or transmitted. So, there is a sequence to the process, but it really starts with understanding your role in the payment system, what data youâ€™re holding, what your transaction is, and then how that maps to the particular requirements. Sometimes institutions find that, in particular, they have no role in authorizing the transaction, or in settling it, and other times the analysis is much more complicated. So, it really depends upon what role you play within the payment system.
SWART: What role would a typical bank or credit union play? They are a transaction provider?
SUSSMAN: Not necessarily. Most institutions are not big enough to do their own transaction processing. And here, weâ€™re really talking about one of the three frameworks that PCI has. Weâ€™re focusing on the Data Security Standard, or DSS. So, most institutions, if they are issuing cards, and if they have ATMs, they may not bear the brunt of verifying compliance. Rather, if they outsource the task, they are going to have to make sure that their outsourcers, those organizations that do authorize or settle the transactions are compliant. On the other hand, if an institution services merchants, provides authorization, or settlements for any other institutions, then that is generally going to trigger much more granular requirements for validating compliance. So, all institutions have to be compliant, in the sense that they protect data when stored, processed or transmitted, but most banks, unless they are in a position of authorizing transactions or processing for others, are not going to have the same types of obligations as, letâ€™s say, a merchant bank, or a data service provider.
SWART:: Okay. Tell us more about what is actually required at that granular level, to achieve compliance, and also, what are some of the key challenges to achieving PCI compliance that you have seen in your clients?
SUSSMAN: Well, again, referring back to the â€œDigital Dozen,â€ there are some very basic requirements. Firstly, that card data, and by this we define as the card numbers that are used, both debit and credit, as well as the data that is used to authenticate the transactions, what is also called the CVV, or the CVC or the CID, if itâ€™s American Express, that that data not be retained after authorization. So, institutions really need to take a look at their processing practices and their applications, to find out if they are retaining card data that is not necessary. And, why would you say that is? Well, that is because if an institutions, the bad guys are going to be going after that data, so that they can put it on plastic, or use it to make fraudulent transactions. So, the first step, really, is getting rid of data that you donâ€™t need. The second step is, if you do have a valid reason to retain card data and the data that is used to authorize the transaction, you have to find out where it is, you have to find out how to protect it through access controls, very restrictively, and you have to find out how to structure your data network in a way that is not conducive to hackers monitoring or invading the network. And some of the challenges, in particular, with our finding all of that data, and in particular, encrypting the data once you have found it, and also logging access. Many institutions find it a challenge to log all access to the card data in a way that is manageable, meaning that you donâ€™t want to produce so much data that itâ€™s not possible to pick out those particular events that are anomalous, in other words, indicative of a hacker or some unauthorized person trying to access the card data. So, some of the challenges, again, are logging, encryption, and finding all of the card data, where it is located.
SWART: Great information. What about those institutions that are PCI compliant? What does that actually do, in terms of overall level of information security and safety? How much impact does it have on their security posture?
SUSSMAN: Well, you know, as with any other audit, you know, PCI is only a snapshot at any given time. So, itâ€™s no guarantee. But, on the other hand, there is not a single PCI compliant entity that I am aware of that has ever suffered a breach. So, while itâ€™s not an insurance policy, it is a pretty comprehensive, well-thought out standard, and if you follow it, you are significantly reducing, although not guaranteeing against the possibility of losing card data, data perhaps that you donâ€™t own, that youâ€™ve been entrusted with.
SWART: One of the major concerns of our listeners is data leakage. What are some best practices to protect against that?
SUSSMAN: Well, data leakage can occur in many forms. Remember, data is maintained in paper form, and itâ€™s maintained electronically. But, in all cases, itâ€™s really handled by people. So, the first step is training your staff against social engineering, peer trickery. You know, the fraudsters realize that organizations have been hardening their enterprise through encryption, through access controls. So, they try to trick people, they try to trick staff into giving up information that they shouldnâ€™t, and they do this by, you know, pretending to be service personnel, pretending to be technicians, social engineering. So, you really need to train your staff in information security awareness, itâ€™s critical. Also, train your staff and always make them aware of social engineering techniques. Indeed, it is a PCI requirement to have that sort of training, and itâ€™s also a PCI requirement to do what they call the â€œpenetration test.â€ The penetration test is where the hackers â€“ actually, consultants playing the role of hackers â€“ will attempt to invade the organization, using any method that they can, social engineering or accessing restricted areas, to attempt to gain access to data, data that is kept in paper form, or data that is kept on a PC, perhaps, that is unsecured. So, really, best practices, really, will relate not only to the technical side, and not only to encryption and logical access controls, but also to training staff in information security techniques and awareness, and protecting against social engineering, and also physical security â€“ we need to mention that. All of us have heard about dumpster diving, where the bad guys will look for data that is thrown out in the garbage, and indeed, it is a PCI requirement that any particular organization that has card data in paper form, have a process in place to get rid of it, to shred it securely, you need to reduce it down to white ash, using cross-shredding, so that the dumpster divers are defeated.
SWART: You keep mentioning â€œfraudsters.â€ What is the relationship between PCI compliance and an effective fraud prevention program?
SUSSMAN: Well, I think they go hand-in-hand, meaning the essence of PCI, the why it was born, was to protect card data from theft, from unauthorized use. So, every institution needs to anticipate how the data can be stolen, just as one would perform a risk assessment, or even build a contingency plan. So, in planning for PCI, it is essential to anticipate how an organization could be breached, and then map that possibility, that vulnerability, to a couple of things, to preventive control, such as encryption and access controls, to detective controls, such as logging and intrusion detection systems, and also to reaction controls, to an incident response plan, to a particular sequence of steps that would guide the institution in a couple of things â€“ how to recognize that a fraud may have occurred, how to recognize that data has been compromised, how to react, how to preserve the evidence, who to notify, and under what condition. So, if you look at the link between PCI and fraud, it is very, very strong. And indeed, there is a further link between PCI fraud and the breach legislation that is hitting the State Houses, you know, there is legislation in at least 35 states that require breach notification. Other states, such as California, Minnesota, and Texas, have gone even further, by requiring institutions to report fraud, and then to take particular steps to protect card data and indeed forbidding the storage of card data when it is no longer needed. So, there is a very strong linkage between PCI and anti-fraud management and now, compliance with state law. (Editor's Note: The Texas state legislature passed but subsequently tabled an act similar to the Minnesota Plastic Card Act. Texas may take up the issue during their next legislative session. Other states such as Massachusetts and Connecticut have also strengthened their breach disclosure and consumer protection laws as a result of egregious incidents (TJX) of PCI non compliance.)
SWART: Excellent insight. Well, what lessons can we learn from the recent TJX data breach?
SUSSMAN: TJX is a well-meaning organization that unfortunately got tripped up under the complexity of PCI requirements. They did a lot of things right. But one lesson that can be learned, really, is that all aspects of the organization, including those that relate to test servers and quality assurance practices and wireless networks, really need to be compliant. From everything that I have understood from the forensic reports, the organization did a lot of things right, but as far as we can tell, they were victimized because one server, one server, was found by the bad guys, and this particular server was a quality assurance server, and an unknowing contractor placed unencrypted data on that server. So, thatâ€™s the first lesson. The second lesson is that everything that is said about wireless security is true. We have learned, through reading the reports that the hackers broke in initially by exploiting an insecure protocol for wireless communication. Everyone in the security community had said, well, this particular algorithm was insecure, and the hackers proved that. So, really do pay attention to vulnerabilities that are published. They really do mean something. And the third PCI requirement for an incident reaction plan is, really, really, come home with the TJX case. Although TJX did many things right, for example, the CEO came out and recorded a video expressing contrition, unfortunately, they werenâ€™t prepared for the media reaction. They werenâ€™t prepared in every single aspect of preserving evidence, and then in managing their incident response. And in particular, they were not prepared to offer credit monitoring insurance, which really, although itâ€™s not a PCI requirement, is really something that is expected. So, the lessons, really, of the TJX incident are, make sure you secure data everywhere, even if it is quality assurance or tests. Make sure that your wireless networks are truly protected, not using weak encryption. And thirdly, make sure they have a very good incident response plan. And, although itâ€™s not related to PCI in particular, make sure that you understand the laws on data breach and disclosure, and are ready to offer credit monitoring insurance to anyone who feels at risk, because itâ€™s a lot cheaper to do that than to deal with the legal fallout from all of these lawsuits that have been filed by consumer groups and stateâ€™s Attorney Generals.
SWART: Great information. Well, you have extensive experience helping organizations recover from icidents, and I was wondering if you could talk about two things. One is how are threats, and how is IT security itself changing. And two is, based on those changes, what advice to give your clients, if there is a how best to recover from incidents when things occur?
SUSSMAN: Well, if you look at the nature of fraud, the ways in which hackers attack information, it is pretty clear that the days of the script kiddies are over, and by script kiddies, I mean the casual hackers, those folks who really were not professional in their aspirations. If you look at the way most frauds are successfully perpetrated, they are done by some incredibly talented individuals with knowledge of encryption networks, who are well organized and well funded. And consequently, institutions need tools, data protection tools, anti-fraud tools that are commensurate with the risk. Or, put it this way, itâ€™s not just enough to be content that youâ€™ve built a 10-foot wall, representing your security, your moat, because the bad guys are always enterprising and are ready to build a 12-foot ladder. In practical terms, what that means is that organizations need to have very good fraud protection tools that are based on experience, and even on neural networks, that the particular fraud tools that are out there today, that are best suited to stopping card fraud and intrusion of networks, are all neural in nature, and that holds true, whether youâ€™re seeking to protect a data network against intrusion, or whether you are looking for anomalies in authorized transactions or fraud activity. The fraudsters are so sophisticated that they actually build up inventories of card data that they have stolen, and they wait periods of time to use them, and then they use different inventories of stolen cards together, so that it is very, very difficult to manually identify a fraud and tie it to a particular incident, and that is where technology comes into play, because the neural networks have the ability to aggregate data and to discern patterns that are not humanly possible. Whereas before, institutions may have relied on manual techniques and some good old due diligence. Thatâ€™s still important. You really have to have neural networks in protecting your data network, having your card data. Itâ€™s absolutely essential. And the corollary, also is that the fraudsters really know who is not using those tools, and then they will target your institution. Thatâ€™s also been proven in some of the fraud cases of which I have become aware.