Archive Page 2

07
Jan
15

SAQ A And SAQ A-EP Clarification

With the advent of SAQ A and A-EP, there seems to be confusion as to what meets what for each SAQ.  I thought I covered this rather well in my post titled ‘Of Redirects And Reposts’.  But apparently that was not clear enough.

For outsourced eCommerce solutions, the criteria from SAQ A states it can be used if and only if:

“The entirety of all payment pages delivered to the consumer’s browser originates directly from a third-party PCI DSS validated service provider(s).”

For some service providers it appears that there seems to be a lot of misunderstandings as to what constitutes “originates directly from a third party”.  A lot of processors believe that if their customers’ Web sites are not storing cardholder data (CHD) or sensitive authentication data (SAD) then they are out of scope regardless of the method used to process a customer’s payment.  What they seem to forget is that applications that process and/or transmit CHD/SAD are in-scope for PCI compliance just as those that store CHD/SAD.

For SAQ A and A-EP, the Council took their lead from Visa Europe as to what is meant by “originates directly”.  Visa Europe’s Processing eCommerce Payments guide has a great matrix that explains the difference between SAQ A and A-EP by payment processing type and merchant level.

Visa Europe SAQ A SAQ A-EP ROC Matrix

With redirects and iFrames, the merchant’s Web server never comes into contact with the CHD or SAD because the customer is communicating directly with the transaction processor’s server.  PayPal is a prime example of a redirect and meets the criteria of SAQ A.  With a direct post, JavaScript, XML or any other techniques, the merchant’s eCommerce server is at least processing and/or transmitting the CHD/SAD to the processor’s servers.  That is because there is some form of code/executable/script/etc. that is running on the merchant’s eCommerce server thus placing it directly in-scope.

Where things seem to get confusing is with processors that offer multiple methods of completing payments.  Unfortunately, it also appears to be just as confusing to the processors’ sales personnel as well.  We have encountered numerous instances where the processor’s sales people believe all of their solutions make the merchant out of scope when only the redirect/iFrame solution they have provides such a scope reduction.  All of their other solutions place the merchant directly in-scope.

The bottom line is that it is extremely important to get the transaction processor to explain how a payment is processed to determine whether your server is or is not out of scope.  Even if the sales person says the solution is an iFrame or a redirect, make sure to quiz them enough to ensure that they truly are delivering you an iFrame or redirect solution.

But a word to the wise.  Security professionals will question a merchant’s decision to not worry about the security of their eCommerce Web server because there still is a risk even with the redirect or iFrame approaches.  That risk is that the code/executable/script/etc. that invokes the redirect or iFrame on the merchant’s server gets tampered with or changed and now invokes a Web site that is not the transaction processor’s Web site.  As a result, a merchant’s customers’ CHD/SAD could be sent to Timbuktu and no one would be the wiser until goods/services are not provided due to non-payment.

As a result, security conscious merchants will, at a minimum, ensure their eCommerce servers are properly security hardened, patched current and will monitor the code/executable/script/etc. for changes.  Should a change be detected, the server would then be brought offline and fixed to ensure that transactions are properly processed.

Hopefully this provides everyone with clarity on how to use these SAQs peroperly.

One additional thing I would like to point out.  If you look at the Level 1 merchant line of the Visa Europe matrix, it shows ROC subscripted with either an ‘A’ or an ‘A-EP’.  I point this out because if you meet the criteria of either of the SAQs but are a Level 1 merchant, you can mark all of the ROC requirements not in the respective SAQ as ‘Not Applicable’ and only provide testing evidence for those requirements in the relevant SAQ.

01
Jan
15

The Three Hop Rule

At the 2014 Community Meeting, the PCI SSC responded to a question about network segmentation with what has come to be termed the “Three Hop Rule”.  The statement was made that if a device/system was “three hops or more” away from the cardholder data environment (CDE), then it was out of scope.  A lot of us in the room were taken aback by this statement.  And based on some questions of late regarding this subject, there is a lot of confusion out there regarding what the Council was trying to say.

First, the term “hop” is not a network security term nor does it even have any security implications.  The term “hop” is defined as:

“Data packets pass through routers and gateways on the way.  Each time packets are passed to the next device, a hop occurs.”

The count of three therefore is the number of hops or “hop count” between devices.  Hop count is defined as:

“Each router along the data path constitutes a hop, as the data is moved from one Layer 3 network to another.  Hop count is therefore a basic measurement of distance in a network.”

Nowhere in these definitions is there any statement about hops, the number of hops between devices and any correlation of hops and hop count as some form of security.  Hence why a lot of us were really concerned about this statement and likely why there is so much confusion and discussion resulting from the comment.

What we believe the Council was getting at was the number of network segments there are between a device/system and the CDE.  However, having three network layers between the CDE and devices/systems is also no guarantee of security.

What provides security at Layer 3 are the access control lists (ACL) or rules that allow or deny packets to traverse particular paths of the network.  ACLs can be implemented to control what devices and/or ports and services can communicate between various networks.  But just because there are ACLs implemented at each hop is also no guarantee that the number of hops between devices also secure the devices.

This is why the requirements in requirement 1 of the PCI DSS require that the QSA review all relevant ACLs to ensure that the network is truly segmented.  It is also why in v3, requirement 11.3 requires that the penetration testing also prove that the network is truly segmented.  As a result, the number of hops between the CDE and a device should not be considered a guarantee and never will be a guarantee that a device is out of scope.

The bottom line is that, in order to be truly out of scope, there needs to be ZERO hops between a device and the CDE.

26
Dec
14

PCI Compliance Is Getting More Rigorous

When Visa and MasterCard trotted out their security standards back in 2002 and 2003, the large eCommerce merchants that got to see them complained that they were too much.  Fast forward more than a decade and we still hear complaints that the PCI standards are too much.  Well if you are still complaining, things are about to get worse with version 3.  And the ever more consistent rumor is that business as usual (BAU) will be coming in v4.  If that comes to pass, I know some people that will likely jump out of windows as they did in the 1929 stock market crash.

So how is the PCI DSS getting more rigorous?

I spent some time analyzing the PCI DSS v3 as I did with v2.  From an analysis of v3 to v2, here are some of my findings.

  • There is an overall 11% increase in the number of tests in v3 versus v2.
  • Tests requiring some form of documentation have increased a whopping 83%. Not that 83% more documents will be required, just that there are 83% more tests where documentation is reviewed.  I will have more on this later in the post.
  • The number tests requiring interviews is up 48%. Again, not necessarily involving more people, just more questions to be asked and answered.
  • Tests requiring an observation of a process or activity are up 31%. As with the others, this is not a wholesale jump in new observations, but more an increase in things that must be observed.
  • Tests involving sampling are up 33%. This actually is an increase in the number of things sampled, but not all of the 33% increase are new samples.  This increase is the result of more clarifications from the Council to have QSAs explain what was sampled as it was implied in v2, but not explicitly requested.

Speaking of sampling, not only are the number of tests involving sampling increasing but the PCI SSC has told all of the QSAs that the days of “poor” or “inappropriate” sampling are over.  I have seen Reports On Compliance where QSAs have literally used a sample of one out of thousands under the rationale of “they are all configured the same”.  If you only tested one, how can you even draw the conclusion that the remaining thousands truly are the same?  You cannot and that is a big reason why the Council is getting picky on sampling.

The Council are also tired of incomplete samples.  The example most often quoted is there are 100 servers, half are Windows-based and half are Red Hat Linux.  A lot of QSAs were stopping there and sampling say five of each and calling their work complete.  Wrong!

What the Council is pointing out is that the QSA must go deeper in some cases when choosing their samples.  In the example above, the QSA needs to know the function of those servers so that they sample them based on their function such as database server, directory server, application server, etc.  In addition, the Council is also saying that it may be necessary to consider the applications involved as well to ensure that sampling provides a more complete picture of the environment.  In an assessment involving multiple applications, it might be necessary to sample database and application servers used by each application and not just a random sample of servers.

Finally, sampling might be higher for an entity’s first assessment or the first assessment by a QSA after a prior QSA.  The reason is that a higher sample size is warranted because all might not be as it is represented and minimal sampling would likely not reveal any issues.  This is common in the financial audit industry in situations where a new auditor is coming into the organization or the operations of the organization have been under increased scrutiny by regulators, banks or their prior auditors.

I earlier stated that documentation testing was up 83% and that was related to more testing of the same documents already being collected.  That is not to say that the amount of documentation is not increasing.  Regarding the amount of documentation required for v3 versus v2, I am estimating a conservative increase of around 100%.  I have been hearing horror stories regarding the amount of documentation being requested for v3.  I would not be shocked if the amount of documentation a QSA requires is up by 150% to 200% in some instances, particularly those situations where the QSA was not necessarily collecting all of the relevant documentation they should have been collecting.  A lot of this increase is that document counts now include observations which were considered separately in v2.

Based on this information, you should not be shocked if your QSAC increases the fees they are charging you for assessing your PCI compliance under v3.  Someone has to conduct all of those tests and review all of the extra documentation generated.  Even QSACs that have been doing the right thing all along are seeing impacts in the increases in testing required by v3.  But it has been definitely worse for those QSACs that were doing as little as possible to get an assessment done.  They are seeing the most impact from these changes and will likely find them highly onerous and difficult to justify the huge increases in professional fees required to cover their higher costs.  As a result, I would not be surprised if a number of QSACs stop doing PCI assessments because of the new requirements put on them.

But why are the changes occurring?

The primary reason is to minimize the “wiggle room” QSAs have in their testing so that assessments from one QSA to another are more consistent.  There has to be flexibility given to a QSA because organizations are never alike.  In addition what is compliant to one QSA can be non-compliant to another even within the same QSAC.  That occurs because every individual has their own sense of risk acceptance and avoidance.  This issue should be able to be taken out of the equation through discussion of the issue with the QSA and their superiors and, if necessary, development of mitigation strategies.

Under v2, a QSA that had a high risk tolerance could deem an organization compliant when the evidence would indicate that the organization is not compliant.  Or a QSA with a low risk tolerance could say one or more requirements are not in place in the same situation.  The new Reporting Template is an attempt to take the extremes out and reduce the wide swings in what is and is not compliant.  However, the new version of the PCI DSS does still allow some wiggle room for QSA/ISA judgment.

In addition to taking extremes in risk acceptance out of the assessment process, the Council is also trying to address the issue with QSAs that are judging organizations as PCI compliant when the QSA’s documentation does not support such a claim.  While the majority of QSAs thought this issue was addressed with the Reporting Instructions in v2, based on what the Council is telling us is that it apparently was not.  So the Council is getting stricter and stricter on their guidance as to what is acceptable through the language in the Reporting Template/Instructions as well as through their QSA training.

Another reason for the rigor is the breaches that keep occurring.  Each breach supplies information that might need to be incorporated into the PCI DSS.  One of the best examples of this is requirement 8.5.1:

“Service providers with remote access to customer premises (for example, for support of POS systems or servers) must use a unique authentication credential (such as a password/phrase) for each customer.”

This new requirement is in response to the significant number of breaches where the attacker gained access to a merchant’s cardholder data by knowing the remote access credentials of a vendor that is supporting the merchant such as those vendors that support point of sale (POS) solutions or card transaction processing.

Finally, the changes are also an attempt to circumvent some of the “legal” arguments that occur between the QSA and their client.  I am not the only QSA that has encountered clients that come up with very legal-like arguments and interpretations of what a particular test requires.  As a result, the Council has attempted to use wording in the tests and related testing guidance that reduces or even eliminates such interpretation arguments.  However, in my experience, clients that take this “legal” approach to their assessment are not going to stop.  They are not interested in security, they are interested in “checking a box”.  But the Council does no one any favors by only allowing QSAs and ISAs to read and have copies of the Reporting Template/Instructions until the client goes through their first PCI assessment under the new testing.  The Reporting Template should be a public document not one that only QSAs and ISAs have access.

21
Dec
14

Forensic Examinations And Facts

I am watching the news reports on the Sony breach and laughing at all of the “facts” that are being bandied about.  I want to use the Sony breach as a teachable moment and explain that the “facts” may not be as factual as represented by the media, forensic examiners or even the FBI.  I have done a number of forensic investigations and from my own experience there is a lot of effort required to prove conclusively that a particular device or actor is the actual attacker.

So let us take a look at the “evidence” we have at this point and see if the conclusions drawn should be treated as facts.

My first issue is how quickly the FBI and Mandiant have come out with the “fact” that North Korea is behind the attack.  According to the timelines I have seen, it was on November 21. 2014 when Sony was told by the attackers, GOP, that Sony had been hacked.  So in around three weeks of time the FBI and Mandiant have figured out, definitively, it was North Korea that was behind the attack.  Granted, Mandiant and the Bureau could have been investigating this long before, but given the way the news reports were written, I have to believe that Sony had no idea anything was wrong until November 21.

Why do I find this timeline spurious?  It took Mandiant over three years to trace things back to the Chinese for their report, APT1, last year and we are to believe that the FBI has the skill and manpower to trace a “sophisticated attack” (Kevin Mandia’s words to Sony) back to North Korea?  I find that hard to believe.  Not because the Bureau and Mandiant are not skilled, but that it is just impossible to cram a year’s worth of investigation into a few weeks, regardless of the manpower tossed at the investigation.

In my own experience, I typically had ideas as to what and how things happened within a few weeks, but now the difficult work of determining exactly how things went down began.  It can take months or even years to figure out an attack if it is ever figured out.  It is why NTSB investigations of airplane crashes take at least a year to have a report issued.  Any attack may not be as simple or uncomplicated as you initially think.

“Technical analysis of the data deletion malware used in this attack revealed links to other malware that the FBI knows North Korean actors previously developed. For example, there were similarities in specific lines of code, encryption algorithms, data deletion methods, and compromised networks.”

We do know for a fact that hackers reuse other attackers’ code.  Why reinvent the wheel if you do not need to?  Hence the variants of all of the attack code to not only evade anti-virus but to also enhance or improve techniques and methods.  Just because there are similarities in some lines of code, algorithms, methods, etc., does not mean that it was the North Koreans that were the actual actors.  It just means that the attackers used code attributed to North Korea.  Key word, “attributed”.  To me, a far better piece of evidence would have been if the code had been written in Korean or a North Korean dialect.

“The FBI also observed significant overlap between the infrastructure used in this attack and other malicious cyber activity the U.S. government has previously linked directly to North Korea. For example, the FBI discovered that several Internet protocol (IP) addresses associated with known North Korean infrastructure communicated with IP addresses that were hardcoded into the data deletion malware used in this attack.”

Hard coded IP addresses are evidence?  So does that mean that everyone is guilty if I write their telephone number on a napkin and that turns up as evidence?  No.  A better piece of evidence would have been log data that actually can tie those IP addresses to the data that was exfiltrated out of Sony.  Just because IP addresses are hardcoded in an application does not necessarily imply that the IP end point was in fact the actual endpoint.  Hackers regularly own other organizations’ and governments’ servers to obfuscate their actual location.  Just because there’s a hardcoded IP address in a piece of code does not necessarily mean that is the endpoint.  It just means that a device could be involved.

“Separately, the tools used in the SPE attack have similarities to a cyber attack in March of last year against South Korean banks and media outlets, which was carried out by North Korea.”

The attack on certain South Korean banks and TV stations in 2013 was never definitively pinned on North Korea, it was just suspected.  The prime piece of evidence was a Chinese IP address that was assumed to implicate North Korea.  So using the South Korean attack as though it was definitively proved to be done by North Korea is not a fact.

While I had some issues with the Mandiant report on China and their investigation methods, the information being offered as “facts” that North Korea is behind the Sony breach are positively appalling.  People want an answer immediately and so one is given regardless of accuracy or even believability.  However, this is a technology issue and so it is easy to feed the public supposed “facts” since only the true technology people in the world will know the difference.

Unfortunately a breach such as the one at Sony will take time, probably a lot of time.  I would not be surprised if we end up with a lot of “suspicions” and “assumptions” when a final analysis is done and released, if we ever get a definitive answer.  The reason I believe that is that I do not think Sony had the kind of security implemented and working given the amount of information that has been supposedly gathered by the attackers.  The other clue in this is that it was November 21 when Sony was notified by the attackers they had been breached.

The key take away here is that forensic examinations very rarely prove WHO the bad actor was that caused the breach.  This is particularly true when the attacker is outside the organization.  There are just too many ways that an attacker can obfuscate their actual identity/location.

What forensic examinations do provide is a road map of improvements and enhancements in an organization’s security measures and procedures to minimize future attacks.  Note that I did not say “prevent” future attacks.  I use minimize because security is never an absolute.  Anyone with an extreme desire to attack an organization will do so regardless of how well your security program is constructed and executed.

Bruce Schneier points out this very fact about determined attackers in his post on the Sony breach.  I have always referred to this as the ‘98-2 Rule’.  Properly implemented and managed information security keeps 98% of attackers out.  However it is the remaining 2% that are determined enough to figure out how to work around even the best security.  All any organizations can do about that remaining 2% is to put controls in place so that when the 2% get through, they are detected as soon as possible and their impact minimized.  This is why security frameworks are so important because they provide organizations with guidance as to what it does take to only have the 2% to worry about.

Given the limited evidence provided thus far, could it be that this is all a sophisticated marketing ruse that went sideways?  Would it not be apropos if Seth Rogen and his production company did the attack as a promotional stunt and the attackers they hired found out that Sony was ripe for such an attack and then went further than what they were supposed to?

Something to think about.

09
Dec
14

Significant Change And Periodic

UPDATED: Changed comments on requirement 10.6.2 to reflect the correct interpretation of that requirement.

No words or phrases in the PCI standards elicit more comments and questions than “significant change”, “periodic” and “periodically”.

So what do these mean?  Whatever you want to define them to mean as it is up to each organization to come up with formal definitions.  Those definitions should be based on your organization’s risk assessment.

Here are some suggestions as to appropriate definitions.

Significant Change

Significant changes are those changes that could impact or affect the security of your cardholder data environment (CDE).  Examples of significant changes are:

  • Changing devices such as firewalls, routers, switches and servers. Going from Cisco to Checkpoint firewalls for example is typically understood as a significant change.  However, people always question this concept particularly when going from a Cisco ASA 5505 firewall to an ASA 5520 or moving a virtual machine from one cluster to another.  The problem is that these moves can potentially introduce new vulnerabilities, network paths or even errors that would go unknown until the next vulnerability scan and penetration test.  And your luck would be that those tests are months away, not just a few days.
  • Changes to payment applications. This should be obvious, but I cannot tell you how many people argue the point on changes to applications.  Yet, application changes are possibly the biggest changes that can affect security.  Not only should applications be vulnerability scanned and penetration tested before being put into production, but code review and/or automated code scanning should be performed as well.  If any vulnerabilities are found, they must be corrected or mitigated before the application goes into production.
  • Upgrades or changes in operating systems. Upgrades and changes in operating systems should also be obvious as significant changes.  However, I have run into network and system administrators that want to split hairs over the impact of OS changes.  In my opinion, going from one version of an OS to another is just as significant as changing OSes.
  • Patching of operating systems or applications. While I do not think that patching necessarily results in a significant change, there are some patches such as updates to critical services such as .NET or the IP stack that should be considered significant.  If you are properly working through requirement 6.1 (6.2 in PCI DSS v2) for patch management, you should take this into consideration and indicate if vulnerability scanning and penetration testing are required after any particular patch cycle because of the nature of any of the patches being applied.
  • Network changes. Any time you change the network you should consider that a significant change regardless of how “minor” the change might appear.  Networks can be like puzzles and the movement of devices or wires can result in unintended paths being opened as a result.

I have a lot of clients that have an indicator in their change management system or enter “Significant Change” in the change comments for flagging significant changes.  That way they can try and coordinate significant changes with their scheduled vulnerability scanning and penetration testing.  It does not always work out, but they are trying to make an attempt at minimizing the number of special scans and tests that are performed.  But such an approach also has a side benefit when it comes time to do their PCI assessment as they can call up all significant changes and those can be tied to the vulnerability scans and penetration tests.

I would see this list as the bare minimum of significant changes.  As I stated earlier, it is up to your organization to develop your own definition of what constitutes a significant change.

Periodic and Periodically

Branden Williams was on a Podcast shortly after the PCI DSS v3 was released and made a comment that he felt that the number of occurrences for the words “periodic” or “periodically” were higher in the new version of the PCI DSS than in the previous version.  That got me thinking so I went and checked it out.  Based on my analysis, these words occur a total of 20 times in the PCI DSS v3 with 17 of those occurrences in the requirements/tests.  That is a 150% total increase over v2 and an increase of 113% in the requirements/tests.

First off, just to shatter some people’s perception of the word, “periodic” does not equate to “annual”.  Yes, there may be instances where an activity can occur annually and still meet PCI DSS compliance.  But that is likely a rare occurrence for all but the smallest organizations and is definitely not how the Council has defined it.

The Council uses the words “periodic” and “periodically” to reflect that an organization should be following the results of their risk assessment to determine how often or “periodically” they should perform a certain activity.  For some organizations, that might happen to work out to be annually.  But for most organizations it will work out to be something more often than annually.

So what requirements specific a periodic time period?  Here are some of the more notable occurrences.

  • 5.1.2 For systems considered to be not commonly affected by malicious software, perform periodic evaluations to identify and evaluate evolving malware threats in order to confirm whether such systems continue to not require anti-virus software.Typically this would be done annually, but forensic analysis of breaches has indicated that it needs to be done more often, particularly with Linux and other Unix derivatives. Based on threats semi-annual or even quarterly reviews may be needed for systems you believe to not warrant an anti-virus solution.
  • 5.2 Ensure that all anti-virus mechanisms are maintained as follows: Are kept current, Perform periodic scans, Generate audit logs which are retained per PCI DSS Requirement 10.7.Periodic scanning is always an issue with servers but, surprisingly, even more so with workstations. In my opinion, at a minimum, scans for viruses and malware should be done at least weekly.  This might need to be done daily if the systems are particularly at risk such as in call centers where the workstations my go to the Internet to be able to access competitor sales offerings.
  • 8.2.4.b Additional testing procedure for service providers: Review internal processes and customer/user documentation to verify that: Non-consumer user passwords are required to change periodically; and Non-consumer users are given guidance as to when, and under what circumstances, passwords must change.This requirement pairs with 8.6.2 which requires service providers with remote access to customers’ systems to not use the same credentials for each customer. A number of recent breaches have pointed out the issue such a practice can lead.  Not only are different credentials needed by the password for those credentials needs to change periodically, typically every 90 days.  This will likely spur the sales of enterprise credential vaults and similar solutions in the service provider ranks.But it is not just service provider’s credentials; it is also their customers’ credentials.  Service providers need to advise their customers to change their passwords periodically as well.  And that should also be at 90 day intervals at a minimum.
  • 9.7 Obtain and examine the policy for controlling storage and maintenance of all media and verify that the policy requires periodic media inventories.For this requirement, the PCI DSS already provides a required timeframe of at least annually.
  • 9.8 Examine the periodic media destruction policy and verify that it covers all media and defines requirements for the following:Periodic here typically means quarterly or even monthly if you have the volume of media to be destroyed. The key though is to secure the media until it is destroyed.
  • 9.9 Examine documented policies and procedures to verify they include: Maintaining a list of devices, Periodically inspecting devices to look for tampering or substitution, Training personnel to be aware of suspicious behavior and to report tampering or substitution of devices.Here periodic means at least daily, if not more often. I have clients that examine their points of interaction (POI) at every management shift change which works out to three or four times a day.  Given the POI is becoming the primary target of attacks, this will only become more important as time goes on given the current paradigm.
  • 9.9.2 Periodically inspect device surfaces to detect tampering (for example, addition of card skimmers to devices), or substitution (for example, by checking the serial number or other device characteristics to verify it has not been swapped with a fraudulent device).Again, periodic means at least daily, if not more often. I have clients that examine their points of interaction (POI) at every management shift change which works out to three or four times a day.  Given the POI is becoming the primary target of attacks, this will only become more important as time goes on given the current paradigm.
  • 10.6.2 Review logs of all other system components periodically based on the organization’s policies and risk management strategy, as determined by the organization’s annual risk assessment.This requirement allows systems to be ranked using an organization’s risk assessment to drive how often log data from systems have to be reviewed.  While systems that directly process, store or transmitcardholder data (CHD) must have their log data reviewed at least daily, other systems that are in-scope can have their log data reviewed less often based on the risk they present to the CDE systems.  Based on assessing the risk to these “connected to” systems, you might be able to justify weekly or even monthly review of log data. I doubt this will have a significant impact because most organizations have implemented internal or outsourced system information and event management (SIEM) solutions and are monitoring all in-scope systems in near real time.  But for those few organizations that are struggling with log reviews without a SIEM, this will afford them a bit of breathing space.
  • 12.10.4 Verify through observation, review of policies, and interviews of responsible personnel that staff with responsibilities for security breach response are periodically trained.It amazes me the number of organizations that claim to not have had an incident in the last year, even a virus or malware outbreak. Either they were totally dealt with by their anti-virus solution (hard to believe) or I am not talking to thepeople that deal with these issues (probably more likely).  As a result, testing (which can satisfy this training requirement) is only being done annually just like business continuity plan testing.Given the ever increasing amount of threats, this sort of training needs to be done more often than just annually.  Organizations should be at least testing their incident response plan on a quarterly basis so that people keep their skills up as well we just exercising the plan and finding any gaps or processes that need adjustment.

Hopefully we are now all on the same page with these terms.

04
Dec
14

It Is The QSA’s Fault

“Usually when PCI-compliant companies are breached, the real culprit is the assessor, the person who confirmed the company had met the PCI Requirements.” Jeff Multz, Dell SecureWorks

This is a very interesting approach for an employee at a qualified security assessor company (QSAC) to use to drum up business, toss all QSAs, including his own organization’s QSAs, under the bus.  I know that is not what he meant to do, but that is certainly what he did with this statement in his posting a few days ago.

I think most QSAs know where Mr. Multz is coming from.  He is more than likely venting over losses to QSACs that we all know are more interested in revenue generation than security.  They further that goal by incenting their QSAs to do as many PCI assessments as possible in the shortest amount of time as well as identify opportunities for selling the QSAC’s security appliances to solve compliance problems.  And to just pile on, they further their revenue generation by being the low cost provider through a focus on volume of work over quality.  As Kurt Vonnegut said in Cat’s Cradle, “In this world, you get what you pay for.”

Getting back though to Mr. Multz and his statement that QSAs are responsible for all breaches, let us see how that plays out with a few breaches.

During the Target breach, it was the QSA that was socially engineered and gave away the keys to the kingdom and missed all of the alerts generated by the FireEye software.  At Neiman Marcus, it was the QSA that missed the alerts for 60+ days that the malware was reinstalling nightly.  It was the QSA that swapped out the points of interaction (POI) at Barnes & Noble for malware infested POI.

Sorry Mr. Multz, but it was employees and/or contractors at all of these organizations, not the QSA that had a part in these breaches and all breaches for that matter.  I really do not see how you can hold a QSA responsible for the inaction and errors of employees/contractors.  Organizations are not going to pay to have QSAs on site, 24×7, to babysit all of their employees to maintain compliance with PCI or any other compliance program.  Not only that, no security framework is ever going to stop breaches, all they do is hopefully minimizing the impact when a breach occurs.

However, Mr. Multz was not done.

“The PCI Requirements were created so that organizations would focus on securing their networks, but many assessors only focus on meeting the requirements rather than security.”

From this statement it is painfully obvious that Mr. Multz does not understand what an assessment is about and how the assessment process works.  The job of a QSA is to execute the tests as defined in the PCI DSS Reporting Template and report the results of that testing – nothing more, nothing less.  Organizations are judged by a QSA as compliant with the PCI DSS whether they are just squeaking by or if they have a full on security program next to none.  Organizations do not get “extra credit” or “atta boys” if they have gone beyond the requirements.

While the original intent of the standards was to focus on securing cardholder data, that got morphed by the wonderfully misdirected marketing job that was done by certain card brands before the PCI standards came together.  For those of us around the security industry more than a decade ago, we advised Visa and MasterCard to stop pushing their cardholder information security program (CISP) and site data protection (SDP) standards as “The Way” that was going to stop breaches.  We explained that, properly implemented, CISP and SDP should minimize the number of PANs obtained, but it would not completely stop breaches.  It was only recently that the card brands started to realize this fact and stop pushing the PCI standards as a panacea of security.  If you have noticed with the rollout of EMV, Visa, MasterCard and the PCI SSC have stated that EMV is not a “silver bullet” solution and in other statements stated there are no “silver bullet” solutions.  That is a long way from a decade ago when their security standards were sold as the “be all to end all” for stopping breaches.  Unfortunately for QSAs everywhere, that message is out there and we have to deal with it every day.

All of this is not to say that QSAs cannot and do not make recommendations to organizations regarding their security programs and how and where it needs to improve.  I constantly make suggestions during my PCI assessments on how my client needs to improve their security posture.  However, it is ultimately up to the organization to put such changes in place, not the QSA’s responsibility.  If an organization chooses inaction, I will bring it up again and again.  But as the old proverb states, “you can lead a horse to water, but you cannot make them drink”.

Where the PCI DSS assessment process truly fails is the point in time approach (with the exception of vulnerability scanning and a few other select requirements).  To address that shortcoming, the Council has introduced the concept of business as usual (BAU) and it is my guess that we will see that concept placed into the standard in the next version.  It will be then that QSAs will have to test PCI compliance over a 12 month period similar to testing procedures financial auditors perform for annual financial audits.

As a result, the inclusion of BAU as part of the PCI DSS will likely be the straw that breaks the camel’s back for a lot of organizations.  This is because BAU will require organizations to track their compliance with the PCI DSS 24x7x365 as they should have been doing all along.  But from experience, I can tell you that there is no organization I have ever encountered that was compliant with any standard all of the time because people make mistakes.  As such, BAU is designed to shed light on those mistakes and require organizations to identify them and remediate them.  For organizations just squeaking by, this will probably make PCI compliance truly impossible to achieve.  If you are one of those organizations complaining about compliance with the current PCI DSS, just wait until BAU gets added.  Organizations that are truly interested in security are already implementing BAU because they see the operational value in integrating security controls with their other business controls.  BAU will show the true colors of those organizations that want security versus those that are checking a box.

And that gets me to Mr. Multz’s actual reason for his post, what makes a good QSA?  Good QSAs understand that the world is not perfect nor is security.  Good QSAs know that compliance with the PCI DSS does not and will not eliminate breaches.  Good QSAs know that the goal of PCI compliance is to minimize security control errors, provide an ability to recognize security control errors as soon as possible and then remediate those security control errors such that the security controls are only non-compliant for the shortest possible amount of time.

But just because a company has such errors does not automatically mean that they are not PCI compliant.  A good QSA only judges an organization non-compliant when the QSA has evidence that problems are consistently recurring and are not being corrected in a timely manner or corrected at all.

I appreciate Mr. Multz’s frustration but as a QSA I do not appreciate him tossing me under the bus with the QSAs that are doing a disservice to PCI compliance.  Like any industry, there are good service providers and there are bad service providers.  Those of us in this industry all know who the bad ones are and we hope they will get weeded out.  But from my own long experience in consulting, that does not always happen.

So in my very humble opinion, Mr. Multz needs to suck it up and deal with it, but stop tossing QSAs under the bus in the process.  QSAs are only the messengers.

23
Nov
14

Face It, You Are A Poor Judge Of Risk

“The oldest and strongest emotion of mankind is fear, and the oldest and strongest kind of fear is fear of the unknown.” HP Lovecraft

We have a pop quiz today.

  1. Are you more likely to die from an alligator attack or a shark attack?
  2. Are you more likely to win the PowerBall lottery jackpot or become a movie star?
  3. Are you more likely to die in a vending machine accident or from a lightning strike?
  4. Are you more likely to be elected President of the United States or to date a supermodel?
  5. Are you more likely to die from influenza or from drowning?
  6. Are you more likely to catch influenza or Ebola?

The purpose of this pop quiz is to demonstrate how poorly we humans evaluate and understand risks. I have to admit I got caught on a couple of these as I did the research.

If anything, the Ebola discussion has brought this issue of risk judgment to the forefront given the unfounded fear people have of Ebola. As a mathematician by schooling it has fascinated me as I watch the media reports and government officials cave into the spread of fear over something very highly unlikely to occur to anyone in the general population.

Do not get me wrong. If I were a health care worker anywhere in the world, I would have concerns about my risk of catching Ebola. After all, they are on the front line and Ebola has around a 50% fatality rate. Add into that the informative, but frightening, video that Dr. Sanjay Gupta of CNN did on the difficulty of removing a containment suit without potentially infecting yourself, and it confirms the threat a health care worker should be feeling if confronted with a potential Ebola patient that is symptomatic.

But for anyone outside of health care, there should be little if any reason to be concerned. Yet a good percentage of the public is irrational when it comes to Ebola regardless of the fact that it requires contact with a symptomatic person’s bodily fluids in order to be infected. But unlike a person with influenza, an Ebola infected person that is contagious does not have the mobility required to have contact with people unless those people come to them. As a result, all of these mental gymnastics that people go through about the possibility that an infection could occur on a bus or the subway are silly because the person with Ebola when they are contagious would look worse than a zombie off of ‘The Walking Dead’, assuming they could even walk at that point.

I am sure you are all saying that this is all good and well, but what is the point here in regards to PCI?

Glad you asked. I bring this up because the PCI DSS is heading more and more to be driven by risk and the assessment of that risk. Yet as I have hopefully shown by my quiz questions, people and their organizations are poor at understanding and determining risks. So organizations need to get much better at performing risk assessments (if they are performed at all) so that they can truly understand and manage risks. That said, a risk assessment does not have to be, nor should it be, a huge “death march” of a project. A proper risk assessment should answer the following questions.

  • What are the risks to the organization? This does not have to be an exhaustive, all inclusive list as you find in the various risk assessment methodology frameworks. But should include all of the most likely risks. For PCI compliance, this risk assessment only needs to address the risks to those things that are in-scope for the assessment. However, most organizations need the risk assessment for other reasons, so it often contains all risks, not just PCI risks. If it does contain risks outside of PCI, you should add columns for your other requirements so you can filter out just the PCI, HIPAA, GLBA, FISMA and any other risk frameworks.
  • What is the likelihood of the risk occurring? Typically, I use a scale of 1 to 5 where 1 is it occurs infrequently and 5 represents that it occurs often. If something never occurs, then it should be removed from the list.
  • If the risk occurs, what is the impact on the organization? Here I use a scale of 1 to 3 where 1 is low, 2 is moderate and 3 is high.
  • Multiply the likelihood with the impact and you get the risk rating.
  • Sort the risk ratings from highest to lowest and you have your risk assessment rating completed.

But hold on, you are not done just yet. Now you need to set your organization’s risk threshold. This will likely be a very contentious discussion as you will find that people within the organization have widely differing views on the level of risk they are willing to accept. However, it is important to capture the highlights of this discussion so that you have documentation for future discussions as you discuss future risk assessment results and reset the organization’s risk threshold.

Risks that fall below a certain risk rating are accepted and management formally agrees to accept them. Those above that level you develop methods of mitigating and managing those risks. Under my rating system, the lowest score that can be achieved is 1 and the highest score is 15. A lot of organizations might say that a total score of below 4 is to be accepted. For some organizations a better approach to accepting risk is sometimes to only accept those risks that have an impact of ‘Low’ (i.e., equal to 1). Therefore, all moderate and high impact risks are mitigated and managed.

Once you have your analysis done you will have a list of risks that require mitigation and management through monitoring and other methods.

Answers

  1. According to the Florida Museum of Natural History, between 1948 and 2005 there were 391 alligator attacks resulting in 18 fatalities whereas there were 592 shark attacks with 9 fatalities. That makes the alligator fatality rate almost three times as high as the shark fatality rate.
  2. The odds of winning the PowerBall are around one in 175M. While still incredibly long, the odds of becoming a movie star are significantly lower at one in 1.5M.
  3. Lightning is more deadly but do not underestimate that vending machine. According to the US National Oceanic and Atmospheric Administration (NOAA), the odds of being hit by lightning in the US are one in 1.9M. According to the US National Safety Council, there is a one in 112M chance of dying in a vending machine accident.
  4. The odds are in your favor if you are interested in dating a supermodel. Even better than becoming a movie star. You have a one in 88K chance of dating a supermodel according to Ask the Odds. The odds of being elected President are slim at one in 10M.
  5. The US Centers for Disease Control (CDC) estimate that the odds of drowning are one in 31.4. The CDC estimates that the odds of dying from influenza are around one in 345K.
  6. The CDC estimates that one in eight people will catch the flu in any given year and as seen in a previous answer, there is a one in 345K chance that a person will die as a result. Given the population of the US is around 315M and only four people have actually caught the Ebola virus in the US, there is around a one in 78M chance of catching Ebola in the US but that could change slightly if more infected people enter the US.



Announcements

FishNet 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 (http://www.fishnetsecurity.com/company/careers), search for 'PCI' 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.

Calendar

March 2015
M T W T F S S
« Feb    
 1
2345678
9101112131415
16171819202122
23242526272829
3031  

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

Join 1,148 other followers


Follow

Get every new post delivered to your Inbox.

Join 1,148 other followers