“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 self-
assessment 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.