Professional Documents
Culture Documents
By Anton Chuvakin
May 2009
ABOUT AUTHOR:
This is an updated author bio, added to the paper at the time of reposting in 2009.
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:
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.
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.”
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.
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 self-
assessment questionnaire (SAQ) and getting scanned.
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.