Archive for the 'Uncategorized' Category


Information Supplements Versus The PCI DSS

At various times over the years, the Council has repeatedly told QSAs, Participating Organizations (PO) and anyone else that has asked questions about statements in the Information Supplements the following.

“Information Supplements only offer guidance to organizations and do not replace or supplant anything stated in the PCI DSS.”

So what are the point then of the Information Supplements?

Boy is that a good question. As a QSA, I often ask myself that very question after some of the inane conversations with clients and prospective clients regarding Information Supplements and their supposed “guidance”.

The first thing everyone should remember about Information Supplements is that they are developed and written by a committee at the suggestion of the Council, POs or as part of special interest work groups. These committees are made up of personnel from interested POs, QSAs, ISAs, vendors and anyone else willing to participate in their development. They are edited by a representative from the Council and reviewed by the Committee and are then submitted to all POs, QSAs and ISAs for review and comment. Similar in concept to the development and review of RFCs by the IETF.

The other key point about Information Supplements are that they are developed to give QSAs, ISAs and organizations ideas and guidance on how best to appropriately meet the requirements of the PCI DSS and the Reporting Template testing. Again, as the Council has repeatedly stated, the Information Supplements do not replace the explicit guidance and testing requirements in the PCI DSS and the Reporting Template. They are merely suggests on an approach.

Yet time and again, QSAs and ISAs get these priceless documents tossed in our faces and are told we do not know what we are talking about. “The Information Supplement says …” is always put out there as the justification as to why an organization is doing something it should not be doing or as the rationale for why the organization is not in compliance with the PCI DSS. And we again are forced to explain that the Council never has said that an Information Supplement replaces the guidance and testing in the PCI DSS or the Reporting Template.

The first question anyone, and I do mean anyone, should ask about any statement in an Information Supplement is, “Does the PCI DSS and/or the Reporting Template explicitly say the same thing?” Those are the only two documents that matter and the only documents that your organization will be assessed against. If it is not explicitly called out in either of those documents, then it is not accurate and does not reflect the compliance requirements.

As an example. I was on a conference call recently regarding the Council’s Information Supplement on penetration testing. This supplement was issued in March, 2015 and is possibly one of the most confusing and contradictory pieces of “guidance” we have ever encountered. In fact, it has created more confusion than it has actually clarified. In my very humble opinion, the Council would be better off taking it out of circulation because of all of the trouble it creates for QSAs, penetration testers, ASVs and clients. It is possibly one of the worst written of the Information Supplements and, while people both on the Committee that developed it and externally supplied the Council with numerous suggestions for changes, those changes were not incorporated into the document. Why those changes were not incorporated is anyone’s guess. But we in the PCI community ended up with possibly the worst expressed and misunderstood guidance available.

As usual, the client was arguing over the scope of their penetration testing. I get the fact that organizations want to minimize costs and scope as much as possible. However when you listen to some security professionals arguments on this topic, you just wonder how they got to their positions as they argue over not testing systems and devices that are painfully obvious to be in scope.

And as also is usual, the first piece of confusion regarding scope is in Section 2, page 5, first paragraph after the bullets and states the following.

“It is not a requirement to test from within the CDE to the servers inside the CDE; and testing exclusively from within the CDE perimeter will not satisfy the requirement. However, when access to the CDE is obtained as a result of the testing, the penetration tester may elect to continue exploring inside the network and further the attack against other systems within the CDE, and may also include testing any data-exfiltration prevention (data-loss prevention) controls that are in place.”

One would think that to any reasonably intelligent information security professional, the first part of the sentence, “It is not a requirement to test from within the CDE to the servers inside the CDE;” would be considered a pure line of garbage. Never mind that none of the recognized penetration testing methodologies ever suggest such an approach. But people arguing never consider that fact. Nope. The people arguing are so focused on cutting their PCI compliance bill that it does not matter that the statement is pure and unsupported garbage. It is considered the gospel truth. Otherwise, why would the Council allow such a statement? Good question. We have asked the Council that question and the answer back is? You guessed it.

“Information Supplements only offer guidance to organizations and do not replace or supplant anything stated in the PCI DSS.”

Again, never mind it is in no way supported by the guidance provided by the PCI DSS for requirement 11.3 which says:

“The intent of a penetration test is to simulate a real-world attack situation with a goal of identifying how far an attacker would be able to penetrate into an environment. This allows an entity to gain a better understanding of their potential exposure and develop a strategy to defend against attacks.”

But argue that point they do even when you point out that arguing this point is basically arguing that any attacker would stop at the perimeter of the CDE and would go no further.

Seriously? If you believe that fact, you must also believe in Santa Claus, the Easter Bunny, the Tooth Fairy and any other of the multitude of mythical fictional creatures. Or you are just lying to yourself and are in serious denial about your organization’s security posture. But argue on they do.

Then you pair that to the second part of that first sentence of this paragraph that says, “… and testing exclusively from within the CDE perimeter will not satisfy the requirement.” Just adds to the out of scope argument.

As I point out when bitch slapped with this terrible writing, if you go back and carefully re-read the second part of the first sentence, what it points out is that penetration testing from only inside the CDE is not sufficient to meet the penetration testing requirements of the PCI DSS requirement 11.3. In no way does that sentence say or even further imply that the CDE is out of scope. It is actually saying that penetration testing should be done from within the CDE, but that penetration testing only inside the CDE does not meet 11.3. But people will still argue that the CDE is out of scope.

That the CDE is in scope is further supported by the definitions of “critical systems” from section 2.2.1 of the document which defines that not only are systems within the CDE in scope, but also those that are outside the CDE but could affect the security of those systems inside the CDE (i.e., what the Council and the Open PCI DSS Scoping Toolkit refer to as “connected to” systems). However, people arguing over scope rarely, if ever, tie these two section together and then argue that because they are in separate sections they cannot be possibly together even though the entire document is about only one subject, penetration testing and requirements in 11.3 of the PCI DSS.

So before you go off telling your QSA or ISA that the Information Supplement says something. Think about what the information supplement says. Is the guidance from the Information Supplement even implied in the PCI DSS? Read the guidance in the PCI DSS and the testing procedures from the Reporting Template. If the PCI DSS or the Reporting Template do not explicitly have the same language in them that the Information Supplement has, then the Information Supplement is merely a suggestion.

And if the guidance from the Information Supplement does not make sense, pull your head out of your posterior and use some God given common sense. Ask your QSA or ISA to explain it, before going off halfcocked and thinking that someone could actually think such things made sense.

But again, why would the Council allow such statements? Good question. We have asked the Council that question and the answer back is? You guessed it.

“Information Supplements only offer guidance to organizations and do not replace or supplant anything stated in the PCI DSS.”

Clear as mud? You bet.

But what did you expect? It is PCI.

For all of you in the United States, have a happy and safe Thanksgiving holiday.


Why Security Fails

I am writing this more than anything because I am dreading taking my lawn mower apart to replace the cable that engages the self-propulsion system. From what I have seen online, some sadistic engineer has made this an ugly job of taking the bottom end of the mower mostly apart just to get to the drive system to unhook the cable in the first place. But I digress.

The primary reason security fails at most organizations is the level of complexity involved in their IT. Organizations have legacy systems, other internal systems, outsourced systems, cloud solutions and a sundry variety of third parties and business partners. With all of these solutions in play, is it any wonder why organizations cannot identify whether or not they have been breached? Where do you start and where do you end? How do you determine if it is a false positive or real? It is such a hard task in fact, that no one wants to or has the time to take the effort to research every incident or they do only cursory research resulting in what they think happened.

Next to complexity the next reason security fails is the reliance on security tools. It is not that tools are not important, but there is mistaken belief that tools are all that you need to be secure. Tools are necessary to identify and focus personnel on potential issues, but tools by themselves are not the complete answer. All security professionals have to do is look to the ubiquitous intrusion prevention system (IPS) that almost every organization has as the prime example of a tool that does not live up to its potential. IPSs are installed but are hardly ever enabled to actually prevent intrusions nor can they truly prevent all intrusions even when fully enabled.

But tools bring other issues. You have organizations that seem to have every security tool under the sun. Now let us be clear here. Organizations may have lots of security tools; however in my experience very few of those tools are ever fully implemented. There are lots of reasons for this but one of the biggest is the revolving door of security leadership. A leader comes in and they have their own security vendor alliances and push their vendor tool agenda. However, that leader either moves on or gets ejected and the next security leader comes along with their security tool world view. As a result, organizations acquire a lot of tools but none are ever fully implemented because of the leadership revolving door.

The second reason security tools tend to miss full implementation is that the implementation runs into significant issues that halt or slow their implementation. There are two reasons for this situation. The first is vendor hyperbole about their solution. My example of the IPS is a prime example of hyperbole. How many IPSs were bought under the promise that it was a “silver bullet” solution?

The second reason tools miss full implementation goes back to the first reason security fails – the complexity of the environment. Environmental complexity makes implementation of anything difficult and, in some cases, impossible. In the case of security tools, the most common situation that stymies a tool’s rollout is the acquisition of a new company. Resources get reallocated to the acquisition and when the fire drill is over, people have forgotten about the tool implementation that was going on before that drill. In the end, the tools do not fully integrate into the environment for whatever reason and therefore leaves gaps in coverage.

But the last reason tools fail is due to a lack of ongoing care and feeding. The tool gets implemented and then gets turned over to the team that will keep it functioning into the future. As time goes on people rotate through the area, training on the tool is not kept up, maintenance on the tool suffers and slowly but surely the tool becomes ineffective.

My favorite example of this was a SIEM implementation at one of my clients. When it first went in it was amazing what it identified both from a security perspective, but also a variety of operational issues that had never had any exposure. However over the next five years, the SIEM system became a backwater for security. There was a belief by IT and security management that the SIEM was somehow self-managing and did not need high caliber personnel. That last year I reviewed the SIEM I was interviewing one of the personnel responsible for it and they said that they had practically tuned out all of the false positives. I inquired why and was shown in the demonstration of the SIEM. Sure enough, very few alerts were even generated and those were few and far between. But then it became alarmingly clear as to why when the person pulled up the systems network map generated by the tool. Most of the corporate network was missing. Further review of the SIEM generated diagram indicated that the organization’s move from their corporate data center to a better equipped co-location facility had apparently not been reflected in the SIEM. How this occurred was a discussion over the next months and it was never clear how the ball got dropped.

Then there are the organizational culture issues. A lot of personnel seem more interested in trying to dodge responsibility and accountability like it is the plague. The more I encounter this attitude, the more I think this behavior can be traced to employers making their employees feel like they are a dime a dozen and can be replaced on demand. But I also believe it is a result of the ugly corporate cultures that have been created over the last couple of decades.

There is no denying that some organizations have created corporate cultures that stress “dog eat dog”, “step over the bodies” and similar tactics if you intend to get ahead. I chalk this up to Jack Welch and his GE corporate culture which he claimed weeded out all but the best of the best. But it is also the result of our own culture and society through reality shows like ‘Survivor’, ‘The Apprentice’, ‘Big Brother’ and similar shows that glorify underhandedness and other questionable tactics versus the virtue of pure teamwork to getting ahead. Because these corporate cultures want people to go after one another, is it even possible that any progress is accomplished in corporations. That is because everyone is so scared of being attacked and losing their job, they do anything to avoid that possibility by tossing anyone else under the bus at the first sign of trouble. It rapidly devolves into a gross and disgusting exercise in a swirling mess of finger pointing and the “Blame Game”.

You then add into this toxic environment IT Operations and/or IT Security personnel who are culturally emasculated thanks to that terrific previously discussed corporate culture borrowed from GE. These people care, but only to a point. The culture just implies that the boss will end your career if you ever bring them “bad news” because people are a dime a dozen. All this results in a situation where people might recognize an alert or something awry, but are reluctant to bring it to anyone’s attention because of the adverse consequences that will likely result. After all, it is the low level minions that get let go first in these situations long before the CISO or CSO. And those minions do not get the great golden parachutes that higher ups get. So why should they bother to put their necks out?

All you have to do is to take a look at the Neiman Marcus and Target breaches. In both cases security operations personnel received alerts indicating something might be wrong. In both cases, these personnel wrote off those alerts and moved on. According to the media, at least in the case of Target these personnel notified higher ups who in turn contacted their security solutions providers and then those people were told to ignore the alerts because they were likely false positive results. However, such a response reinforces the misconception that the tools are not factual when more research should be done to prove that fact.

A long time ago, I paraphrased Tom Hanks’ character Jimmy Dugan in the movie ‘A League of their Own’. “Security is supposed to be hard. If it wasn’t hard, everyone would do it.” Security is hard enough even without all of the other barriers some organizations put in the way.

As a result, is it any wonder that organizations outsource security to a managed service provider? Outsourcing takes security out of the corporate culture and away from internal politics. It also puts all of the tool implementation responsibilities on the outsourcer’s back, not your organization. As long as the outsourcer is kept in the loop regarding changes to the environment, you can have much better assurance that your environment is actually being monitored. And that is where most outsourcing arrangements end up going bad is that the outsourcer is unware of changes made and therefore cannot maintain security because now there are gaps.

Regardless of whether you outsource or you get your organization to own up to the responsibilities required to maintain security, security requires a significant commitment of any organization.

Oh and for those of you that ended up curious about the outcome of my lawn mower project. I finally stepped up after writing this post and got the drive cable replaced. It turned out to be quite the project, but thanks to the Internet and a few postings by people, I had a decent path to follow. The hardest part of the project was that the aforementioned sadistic engineer mounted the cable attachment on the top of the drive mechanism making it a true exercise in patience and manual dexterity to reconnect the new drive cable to the transmission. It took more time to get just that one task done than the teardown and reassembly processes. However, I now have a self-propelled lawn mower again.


QSAs Need More Certifications

Branden Williams has a great posting out on this topic that everyone that is a QSA needs to read. He brings up a number of good points that need to be discussed.

That said, I wanted to take on one of his discussion points and go a bit deeper. And that is the coming requirement that multiple certifications will be required as of July 1, 2016.

Note: The requirement to possess at least one industry-recognized certification is effective as of January 1, 2016 for new QSA Employees. For QSA Employees qualified and added to the search tool prior to January 1, 2016, this requirement is effective July 1, 2016 (for example, upon annual requalification after June 30, 2016).”

The document lists two types of certifications; “Information Security” and “Audit”. Under Information Security list you have the Certified Information Systems Security Professional (CISSP) and the Certified Information Security Manager (CISM).

Under the Audit list you have the Certified Information Systems Auditor (CISA), GIAC Systems and Network Auditor (GSNA), Certified ISO 27001, Lead Auditor, Internal Auditor, International Register of Certificated Auditors (IRCA), Information Security Management System (ISMS) Auditor, Certified Internal Auditor (CIA). How the Council developed this list of qualified certifications is beyond me as there are some others that I would think should be listed here.

I too face the issue that Branden faces. While I have multiple certifications, I no longer hold the CISA certification that I would need to remain a QSA after June 30, 2016. As a result, I would have to go back and obtain my CISA again after letting it lapse years ago. Why my Certified in Governance of Enterprise Information Technology (CGEIT) would not be acceptable and qualify me I have no idea.

But there is a larger issue here that I think needs to be discussed. Given how the Council has broken these certifications out, one would assume that they are looking to make QSAs better assessors by improving their auditing skills. I am also assuming that they are preparing QSAs for the onslaught of conducting true audits under the coming integration of business as usual (BAU) standards that will be introduced into the PCI DSS v4.

Based on those assumptions, I would argue that only the IRCA and CIA certifications have anything to do with certifying someone as capable of conducting a proper audit in addition to being a CPA. All of the other certifications they specify under the “Audit” category are focused on a particular auditing standard such as CoBIT, ISO 27K or similar and have nothing to do with improving a QSA’s auditing skills or preparing QSAs to become true auditors.

But that brings up an even more interesting question to ponder. Is the PCI SCC going to adopt the AICPA’s Statements on Standards for Attestation Engagements AT-101? This standard is what tells CPAs how to properly conduct audits. AT-101 lays out an extensive list of requirements for conducting an audit from planning, execution, work papers, client representations, report creation, report publication and everything in between.

A number of years ago when I worked at an accounting firm, we were approached by a few clients interested in conducting their PCI assessments to the AT-101 auditing standard. As we investigated what it would take, we and our clients quickly came to the realization that conducting a PCI assessment to AT-101 standards was going to be very costly and time consuming. The reason was that AT-101 has specific and rigorous evidence gathering and sampling requirements that go an exponential level beyond what any QSA does today for a PCI assessment.

With the introduction of BAU into the mix, QSAs are going to have to test compliance with certain requirements over the assessment period. Based on my analysis of v3, I am estimating that there are at least 213 requirements that could have testing over some period of time. As a result, AT-101 auditing standards could easily be applied to those requirements. Such an application would lend much more credence to a PCI assessment and better prove that organizations are complying with the PCI DSS.

Most departments in organizations have never been through an actual audit other than possibly their finance and accounting areas. As a result, the rigor involved with an audit will be a very new and frustrating experience for IT and the other areas involved with PCI compliance. If you think the PCI assessment process is annoying and painful now, wait until you see what you have to look forward to in the future if this is where I would bet the Council is headed.

Regardless, the PCI haters will really have something to complain about if this comes to pass.

My recommendation? Move as quickly as possible to reduce your PCI scope now.


What Drives Your QSA

David Froud has a great blog post out on LinkedIn titled ‘Why All QSAs Must Lie’. While the title is a bit misleading, it explains a lot as to why your QSA (accountant, auditor, etc.) act the way they do.

David provides some good things to keep in mind when you are wondering why your advisors are acting the way they do.


SSL and TLS Update

At the beginning of March, a new vulnerability to SSL and TLS was announced called FREAK. This compounded the announcement last fall of POODLE that caused the PCI SSC to abruptly call SSL and “early” TLS (i.e., TLS versions 1.0 and 1.1) as no longer acceptable as secure communication encryption.

In April, the PCI SSC issued v3.1 of the PCI DSS and gave us their take on how to address POODLE. Their plan is to have organizations remediate SSL and “early” TLS as soon as possible but definitely by June 30, 2016. While remediating SSL and “early” TLS, organizations are required to have developed mitigation programs for these protocols until they are remediated. There are some exceptions to the June 30, 2016 deadline for devices such as points of interaction (POI) but those exceptions are few and far between and still require some form of mitigation.

Reading the explanations for the POODLE and FREAK vulnerabilities, while they are technically possible over the Internet, they are much more realistic to be performed successfully internally. As such, these vulnerabilities are more likely to be used as part of an attacker’s toolkit when compromising a network from the inside. This is not good news as an organization’s internal network is much more vulnerable since a lot of appliances and software have SSL and TLS baked into their operation and will not be quickly remediated by vendors, if they are remediated at all (i.e., you will need to buy a new, upgraded appliance). As a result, organizations need to focus on their internal usage of SSL and “early” TLS as well as external usage.

The remediation of these vulnerabilities on the Internet facing side of your network should be quick. Stop supporting SSL and TLS versions 1.0 and 1.1 for secure communications. While I do know of a few rare situations where taking such action cannot be taken, most organizations can simply turn off SSL and TLS v1.0/1.1 and be done with the remediation.

As I pointed out earlier, it is the internal remediation that is the problem. That is because of all of the appliances and software solutions that use SSL/TLS and vendors are not necessarily addressing those issues as quickly. As a result the only approach is to mitigate the issues with appliances that are at risk. Mitigation can be as simple as monitoring the appliances for any SSL or TLS v1.0/1.1 connections through log data or using proxies to proxy those connections.

The answer to SSL and TLS vulnerabilities are to remediate as soon as possible. If you are unable to remediate, then you need to mitigate the risk until you can remediate.


By All Means, Do As Little As Possible

I write this because I have had enough of arguing over the lowest common denominator when it comes to securing networks, servers and applications. Reading the articles in the various media and trade journals, one would get the distinct impression that putting forth any sort of effort is beyond a lot of peoples’ capacity.

Do you people complaining about the difficulty of achieving compliance with a security framework ever listen to yourselves? I would say the answer is “No” because if you did, you would understand where I am going.

Do you realize that you are arguing over doing the bare minimum? I would guess that would be a resounding “No” because, again, you would understand where I am going.

If none of this rings a bell, then maybe this does. When was the last time anyone told you that only doing the minimum was acceptable? If they did, then they are people I would not want to associate with because they are likely on their way out the door as you will be shortly once that breach occurs.

All security frameworks are a bare minimum. They do not guarantee security of anything. What they do is define the “best practices” or “common knowledge” of what it takes to have a reasonable chance of being secure. But it gets worse. Security frameworks require perfect execution, i.e., being compliant 24x7x365, in order to succeed. And as those of you complaining are rudely finding out, that just does not happen when people are involved.

In order to address the shortcomings of people, security frameworks are layered. You must have heard the phrase “layered approach” time and again during security discussions. The layers are there so that when people fail, their failure does not result in a total failure of an organization’s security posture. Where things go wrong is when there are multiple failures. It does not matter that things are layered when the vast majority of those layers are circumvented by multiple failures.

Oh, you do not think that is how a breach happens? Read the Verizon DBIR or PCI reports on breaches and it lists out the multiple processes that failed that led to the breach, not just a spear fishing email or the breach of a firewall. Those were the start of it all, but it was a lot of other things that ultimately led to the success of the breach.

Another rude awakening for management and security professionals alike is how easily all of that security technology they have invested in does nothing once a phishing email corrupts an insider’s account. That is because a lot of organizations’ security posture is like an M&M candy – hard on the outside with that soft chocolate center on the inside. If you go back to the Verizon reports, read the details of how many attacks came to fruition over insider accounts being corrupted. They may not necessarily be categorized as insider attacks, but an insider was compromised as part of the successful attack.

Which brings me to security awareness training and the fact that people consistently complain that it is worthless. Did you people really believe that one session, once a year is really going to change peoples’ bad habits? If you did, I have some property I would like to sell you. You must harp on this topic constantly and consistently. I know that is not what you want to hear, but people only learn by being told repeatedly to stop their bad habits. Even though a lot of people approach this subject by making it annoying and painful, it does not have to be that way. But it is the only way to have an effect and it will not happen overnight and not everyone will learn the lessons. Security awareness takes years and lots of patience, but it does eventually pay off.

The bottom line is security is a war between you and the people that want your organization’s intellectual property, card data, medical records, financial information, whatever information you are trying to protect. Wars are won or lost on the strategy used and the battle intensity of the soldiers involved. Wars and battles are not won with mediocrity which is the approach upon which you are arguing. Mediocrity in war is how people die, not how they survive.

Let me know how that mediocre approach works out. That is, if you are even around to let me know.


PCI Compliance Certificates Rear Their Ugly Head Again

Apparently, a bad practice started a number of years ago is appearing in other parts of the world.  That practice is PCI Compliance Certificates.

I wrote a post a number of years ago about this practice and provided the direct quote from the PCI SSC’s FAQ on the subject.  If you need more proof, go to the PCI SSC Web site and click on FAQ and search for ‘PCI DSS Compliance Certificate’.

This is a marketing ploy and it needs to stop.

These certificates are not worth the paper they are printed on and anyone purporting them to have meaning is uninformed, or worse, lying.

I would highly recommend that if you encounter anyone that tells you such nonsense, they should be immediately reported to the PCI SSC –  qsa AT pcisecuritystandards DOT org. Include their name and the name of their organization in your message.

UPDATE: Only a few minutes after I put up this post I received just such a certificate from a major bank as proof that their business partner was PCI compliant. Unbelievable.


Optiv Security is looking for experienced QSAs for their PCI practice. If you are an experienced QSA and are looking for a change, go to the Web site (, and click on the 'Check Out Our Openings' button and apply.

If you are posting a comment, be patient, as the comments will not be published until they are approved.

If your organization has a PCI opportunity, is in need of assistance with a PCI issue or if you would like the PCI Guru to speak at your meeting, you can contact the PCI Guru at pciguru AT gmail DOT com.

I do allow vendors to post potential solutions in response to issues that I bring up in posts. However, the PCI Guru does not endorse any specific products, so "Caveat Emptor" - let the buyer beware. Also, if I feel that the response is too "sales-ee", I reserve the right to edit or not even authorize the response.


November 2015
« Oct    

Enter your email address to subscribe to the PCI Guru blog and receive notifications of new posts by email.

Join 1,401 other followers


Get every new post delivered to your Inbox.

Join 1,401 other followers