In this paper, we will look at how organizations approach PCI compliance projects and what impact they have on the organization security. In particular, do they approach PCI requirements literally, as a simple compliance checklist? Or do they assess what the compliance requirements seek to accomplish and how to apply it to their business? In addition, we will look at how to simplify this process for those who consider both PCI compliance and information security to be overly complicated.
“Security First” or “Compliance First” By Anton Chuvakin May 2009 ABOUT AUTHOR: This is an updated author bio, added to the paper at the time of reposting in 2009. Dr. Anton Chuvakin (http://www.chuvakin.org) is a recognized security expert and book author. He is an author of books "Security Warrior" and "PCI Compliance" and a contributor to "Know Your Enemy II", "Information Security Management Handbook", "Hacker's Challenge 3", "OSSEC HIDS" and others. Anton has also published numerous papers on a broad range of security subjects (all papers are linked from his portal http://www.info-secure.org). In his spare time, he also blogs at http://www.securitywarrior.org In addition, Anton has presented at many security conferences across the world; his recent engagements include speaking at events in the United States, UK, Singapore, Spain, Canada, Poland, Czech Republic, Russia and other countries. At this time, Anton is building his security consulting practice, focusing on logging and PCI DSS compliance for security vendors and end-user organizations. Dr. Anton Chuvakin was formerly a Director of PCI Compliance Solutions at Qualys. Prior to Qualys, Anton worked at LogLogic, where he held the title of Chief Logging Evangelist, tasked with educating the world about the importance of logging for security, compliance and operations. Before LogLogic, Anton was employed by a security information management vendor in a strategic product management role. Anton holds a Ph.D. degree from Stony Brook University. DISCLAIMER: Security is a rapidly changing field of human endeavor. Threats we face literally change every day; moreover, many security professionals consider the rate of change to be accelerating. On top of that, to be able to stay in touch with such ever-changing reality, one has to evolve with the space as well. Thus, even though I hope that this document will be useful for security at the time when you are reading it, please keep in mind that is was possibly written years ago. Introduction Payment Card Industry Data Security Standard (PCI DSS or, often, just PCI) has literally revolutionized the way many organizations treat security. While many regulations promised to “take information security from the wire closet to the boardroom”, PCI actually accomplished that for many organizations, and not only the large ones. While following all of the PCI DSS guidance will not magically “make you secure” or prevent all possible incidents, the standard contains many of the commons sense security requirements. However, before we explore the relationship between compliance (in particular PCI DSS compliance) and security, we need to take a quick look at what PCI DSS is. PCI DSS was unified from card brand individual security mandates, established to increase the security of card-accepting merchants and thus reduce the risk of electronic credit card transactions. Historically, PCI security requirements came from card brands trying to deal with a deluge of card fraud. Since early 2000s, payment card data theft has hit organizations of all sizes. The biggest known breach to date was the theft and sale of more than 100 million credit and debit card numbers from a major card processor. As of today, compliance with PCI is mandatory for any merchant or any other organization that accepts payment cards as all deadlines for compliance have already passed. In this paper, we will look at how organizations approach PCI compliance projects and what impact they have on the organization security. In particular, do they approach PCI requirements literally, as a simple compliance checklist? Or do they assess what the compliance requirements seek to accomplish and how to apply it to their business? In addition, we will look at how to simplify this process for those who consider both PCI compliance and information security to be overly complicated. Many security professionals often highlight the fact that since security was the motivation to establishing the compliance requirements, addressing security will lead to compliance (it will obviously lead to security as well). Thus, the “Security FIRST!” slogan was born. However, addressing security is very challenging, given today‟s complex networks, rapidly developed applications, growth of “Web 2.0,” and other advances in information technology. Dr. Dan Geer, a noted security expert, once said that “security is perhaps the most difficult intellectual profession on the planet.” As a result, many organizations have not been able to focus on security and instead have been looking for “an easy way out” of its complexities. Compliance vs. Security It might be something that few people admit, most experts criticize and – that is the inconvenient truth! – a lot of people actually do. Namely, despite all the talk about “„compliant‟ does NOT mean „secure‟”, “unified compliance” and “do security first!” (succinctly highlighted by one expert in his presentation called “How Focusing on Compliance Can Get You Killed!”), there is a sizable population that treats PCI DSS compliance as just another tactical IT project implemented in a silo‟ed and minimalistic way. To illustrate this, let‟s picture this fictional situation: a medium-size organization‟s management finally “gets the PCI message” and decides that it is important to deal with PCI DSS compliance. Maybe their acquiring bank introduces them to PCI or maybe their service provider starts reminding them about “that PCI thing.” What happens next? In the “compliance first” mindset, illustrated here, the management summons an IT manager (since probably the company is not big enough to have a full-time security staff) and hands him a copy of the 12 PCI DSS requirements, a mandate to “do this!”, and no additional IT budget. As a result, the IT manager is supposed to “address PCI compliance,” while working under these constraints. What happens next? The IT manager reviews the requirement list and notices that he already has some of the things implemented. For example, a network diagram (PCI Req 1.1.2) is proudly displayed on his cubicle wall. How about the rest of the guidelines though? Here is how some of the requirements, his responses and some of his unspoken thoughts stack up: Requirement 5.1 “Deploy anti-virus software on all systems commonly affected by malicious software” - Upon reading this, the IT manager will happily confirm “OK, we have anti-virus! Great!” However, thinking whether it is deployed on all „at-risk‟ systems will likely be left alone as “too complicated.” Requirement 5.2 “Ensure that all anti-virus mechanisms are current, actively running, and capable of generating audit logs.” In this case the manager will probably think something along the lines of “What do they mean here? I guess the anti-virus tools do run, don‟t they?” Similarly, a more complex issue of antivirus audit logs, mentioned in this Requirement, will likely be skipped or “deferred.” Requirement 6.6 “… Installing a web-application firewall in front of public-facing web applications” Thinking that this requirement actually refers to a network firewall deployed in front of a website (Web site + firewall = web firewall …) is actually not that uncommon! Every security professional, however, will know that in reality this refers to a different dedicated application security device: WAF or web-application firewall. In this company‟s case, the IT manager will probably not think along these lines. Requirement 10.6 “Review logs for all system components at least daily.” The IT manager might remember that syslog server that was deployed a few months ago is still there. While only thinking of syslog servers when logging is discussed in not uncommon, PCI DSS Requirement 10.6 actually covers log review and just “having the syslog server up” will not satisfy it. Requirement 11.4 “Use intrusion-detection systems, and/or intrusion-prevention systems to monitor all traffic in the cardholder data environment and alert personnel to suspected compromises.” Similarly, installing and launching Snort with the intention of looking at IDS/IPS alerts later is what often comes to mind here. Many IT managers have heard that “IDS is a pain,” but they still hope that deploying an NIDS will “make them compliant.” Overall, the IT manager goes requirement by requirement and figures out what is on his network vs. what is in the document; sometimes he plans to make a change here and there. After looking at the last Requirement 12 and making these changes, he considers himself “done” with PCI DSS project. Is this organization compliant now? The answer is “It depends.” If they are not to be audited, they might well consider themselves “compliant with PCI DSS” as long as they can pass the scanning requirements (Requirement 11.2) . But will they be considered compliant if they are audited after a breach? Is this organization more secure now? The answer also is “It depends.” There is a good chance that if the IT manager was aware of the risks to his company (and few smaller organizations are) and have taken simple actions to deal with these particular risks (and almost no such organization does), he would have been more secure. However, there is definitely some possibility that the security of this organization has improved due to the PCI DSS effort. For example, if the IT manager changed the password policy to a more stringent one or disabled a few default accounts, then for sure the organization‟s security would have improved. In any case, this organization now feels better about answering the PCI selfassessment questionnaire (SAQ) and getting scanned. PCI Validation via Scanning PCI DSS Requirement 11.2 calls for quarterly external scans by a PCI Approved Scanning Vendor (ASV). Such scan must come up with no “PCI-scope vulnerabilities” Here is an example of vulnerabilities considered to be reasons for PCI scan failure: “Vulnerabilities with a CVSS v2.0 base score of either 4.0 or higher will cause PCI compliance to fail on the scanned IPs. Vulnerabilities that may lead to SQL injection attacks and cross-site scripting will result in a non-compliant status on the corresponding IP.” ASV scanning serves as a simple validation mechanism for PCI requirements as well as help to make organizations aware of possible vulnerabilities to card holder data. As everybody in the security profession realizes, new vulnerabilities in software applications and platforms are discovered daily; frequent vulnerability scanning helps organizations identity them and then remediate, thus increasing security. This would be an example of “Security FIRST!” thinking. On the other hand, what happens at a “Compliance first!” organization? Specifically, what happens if such an organization rescans their PCI environment, right before planning to submit the report on compliance (RoC) to their acquiring bank and then finds out that new vulnerabilities have recently been discovered in the software they use? Sadly, it is not uncommon that an organization will consider this situation to be the one where “somebody broke their compliance.” (!) In fact, sentiment such as the following might well occur: “Why is this scan showing vulnerabilities if we were just about to report the success of our compliance project? Why are you breaking our hard-earned PCI compliance? How about we replace you with another product that just shows us compliant?” To summarize, it really doesn‟t matter how many times security experts pontificate about “security first!” If some organizations don‟t “get security” with all of its complexities and ignore it for years, “compliance first” becomes a real choice for them. At least they can understand it! And then later, “compliance first” becomes “compliance ONLY,” “checklists” replace “risk awareness,“ “flowcharts” replace thinking about their threats and vulnerabilities. What happens next? Obviously, they get hacked and have their credit card data stolen! And CNN writes a great inspirational story about them! To top it off, the PCI Council also fines them since they were NOT even compliant... At this moment, they suddenly get a security epiphany! As a result, making the choice “Security FIRST” or “Compliance FIRST” is not that hard. Still, if upon reading this, you excitedly choose „Compliance First!"‟, please at least make sure that “Security SECOND” happens. A useful reminder here would be that HMS “Titanic” (which, as we all know, sunk in 1912 upon colliding with an iceberg). It was reported that the ship “did meet all of the safety requirements of the time. And that a big part of the problem was that the safety requirements were drafted in 1894 at a time when there were rapid changes in the size and design of ships of this kind. Those regulations indicated that all passenger ships over 10,000 tons required 16 life boats, and that‟s how many the Titanic had.” In other words, “Titanic” was compliant, a perfect example of “Compliance First!” Making PCI-Driven Security Easier Security might be hard and PCI compliance might not be easy either; however, we still need to think about how to make it easier for organizations to focus on getting compliant while improving their security. So, how does one make PCI compliance easier, while improving security in the process? Making PCI easier while also improving security will make lives of many IT security professionals easier as well. To start, let‟s recall that there were times when only an expert was able to perform a magic of a vulnerability scan. Today, nobody would argue that vulnerability management is much easier even though it cannot be said that “it became easy.” In any case, when people think about “making PCI easier” they often split into two groups. The first group would often ask to “make PCI easier” by letting them just “skip” the requirements. It is reported that sometimes they would be inclined to just say “Yes” on the PCI Self Assessment Questionnaire (SAQ) without thinking what is really involved in satisfying the requirements that it covers. The second broad group typically knows that their security program makes them PCI – compliant; they engage just to make it easier for them to prove it. As one can guess, the organizations that fit into group #1 and group #2 are very different: while some in group #1 might confuse a firewall with a fire extinguisher, the #2 group is often concerned with relating their “risk-focused” approach to PCI‟s mostly “control-focused” approach. Moreover, in group #1 people sometimes say things like “PCI is already easy; you just need to „get scanned‟ and answer „Yes‟ to a set of questions.” Still, it is possible to make PCI easier while focusing on security even for those who just “want it gone:” make doing the right thing (that leads to risk reduction) easier for them while making doing the wrong thing (that increases risk for their business) harder. On the other hand, while in group #2, one sometimes hears things like “we have a good security program and we manage our information risk well – why should we spend extra time on PCI? We are probably in a good shape already!” These organizations are likely doing a good job with security and want to use all that they do for security to quickly “prove compliance.” In this case, making PCI easier will include making it easier to assess, validate and prove compliance and overall make the whole “audit experience” a little less painful and less costly. And, it goes without saying, without sacrificing any of their hard-built security programs! Conclusions To conclude, if you refuse to make an effort to understand information security and risk (despite all of the complexities), PCI compliance becomes a way to make certain decision to accept risks “illegal.” In other words, if you refuse to understand your risks and then to plan controls to address them, compliance becomes a “boilerplate” list of controls that you just have to do. Whatever your situation is, there are ways to compliance while building or preserving security: make proving compliance easier, make boring audit process simpler thus allowing more time for becoming more secure (but not “more secure than needed”), make choosing the right thing easier (and the wrong thing harder)… Even the choice between “Security First!” and “Compliance First!” becomes easier as a result. Dr. Anton Chuvakin is a Director of PCI Compliance Solutions at Qualys. Anton (http://www.chuvakin.org) is also a recognized security expert and book author. He is an author of a book "Security Warrior" and a contributor to "Know Your Enemy II", "Information Security Management Handbook", "Hacker's Challenge 3", "PCI Compliance”, "OSSEC HIDS" and others. Anton also published numerous papers on a broad range of security subjects. In his spare time he also blogs at http://www.securitywarrior.org In addition, Anton have presented at many security conferences across the world; he recent speaking engagements include presenting in the United States, UK, Singapore, Spain, Canada, Poland, Czech Republic, Russia and other countries. Anton holds a Ph.D. degree from Stony Brook University.
Pages to are hidden for
"“Security First” or “Compliance First”"Please download to view full document