I am constantly approached by clients whom are taking customer credits and asked the following question “Why do we need to be PCI compliant?. No one is asking us to”.
Now the obvious answer to that question is, “Because you are taking customer credit cards”. However, because the Merchant Bank or Card Brands have not asked the client to show or otherwise prove PCI compliance and it is not a federal regulation such as HIPAA, SOX, or GLBA, they feel they are not responsible for PCI compliance. Many times you will see this type of response in Level 3 and 4 merchants.
So correct, PCI is not a Federal Regulation such as HIPAA, SOX, or GLBA. Federal Regulators will not be knocking on the doors of Level 3 and 4 merchants to perform formal PCI Audits. PCI is however, a contractual obligation which is put in place with the merchant and merchant bank. I would almost guarantee that if any of the merchants actually reviewed the contract put in place with the merchant bank, PCI verbiage is stated within. In addition, certain states have now put PCI verbiage within state legislation. Nevada has a state law which reads:
“data collectors who are doing business in Nevada and who accept credit cards or other payment cards for the sale of goods or services to comply with the current version of the PCI DSS.”
Three other states have also amended or created state law which has PCI verbiage. Actual requirements for organization operating within those states are less strict than that of Nevada.
Finally, even if your organization is not obligated to be PCI compliant by either of the above methods, the FTC has a catch all with regards to improperly protecting sensitive customer information. Section 5 of the FTC Act which is around “unfair and deceptive trade practices”, can be used against organizations that have been breached and it can be proven that they organization was willfully neglectful in protecting that information. I would say, that it should be pretty easy to prove willful neglect if a company chooses not to protect cardholder data when PCI has been around since 2006.
In summary, it’s safe to assume that if you are taking cardholder information, you are responsible for the protection and security of it. Not to mention, just from an overall reputation and best practice standpoint it makes sense. Business owners need to start putting themselves in the shoes of end users. How would they like if it someone chose to take their sensitive information and did so in an insecure fashion.]]>
A month ago, the PCI SSC announced the three new SIGs which will be introduced at the beginning of 2012. The following SIGs were elected out of a shortlist of seven topics:
The one that I am most interested in participating in and seeing the results of is the Risk Assessment SIG. Although IT Risk Assessments has been a term that has been used for decades now, they are still rarely performed, and when they are, they are almost always performed poorly especially in regard to effectively considering threat. Most times, especially within small to medium size businesses, the organization simply calculates risk based of the number and CVSS score of vulnerabilities associated with an application or system. Certainly, this is a factor within the overall risk equation, but is not the only thing to consider. It will be interesting if this SIG guides organizations on how to perform an effective Risk Assessment, and further, if PCI DSS controls can be chosen based off this assessment. If the latter is true, it will be interesting as to if the QSA can make an opinion as to the effectiveness of the Risk Assessment and the controls chosen. Basically, if the PCI SSC does adopt a more risk based approach to assessments, it could have both adverse and positive side effects. Positive side effects are obvious, as the company can choose controls based off their Risk Assessment. This will make compliance easier as well as less costly for the subject organization. However, if the Risk Assessment is performed poorly and the organization has chosen controls off a poor risk assessment approach, this could definitely be an issue. This would further be complicated if the QSA doesn’t really have any say as to what an effective Risk Assessment should be. These are the same problems that plague ISO 27001 certification. ISO 27001 mainly determines whether or not an organization’s ISMS is operating in a manner consistent with how they say it is running. However, it doesn’t take in consideration as to how they say they are running it is actually the secure way in which to do so. This is one of the shortcomings of ISO 27001 certification.
In summary, I’m all for a risk based approach to PCI if this is the direction the SSC and the member card brands decide to move in. It just needs to make sense and that the implementation of a risk based approach doesn’t actually lessen/weaken the security of an organizations cardholder environment.]]>
A case that was passed down in Israeli recently further validates that many countries still strongly consider the right of employees in the marketplace over their employers. Further information on this case can be found below:
This is one of the main differences between privacy in the US and that of other countries. In other countries, the person who the data is actually about owns that data. In the US, the entity that collects the data from an individual owns the data.
I do find it a bit uneasy that the judge in this case sided with the employee who knowingly agreed to an email monitoring policy, even as vague as that policy may have been, but then decided to email trade secrets anyway. I think employers do need to have some control and some sense of ownership over the information which is transmitted through their network. As far as how this affects the US, I agree with the article that it probably won’t affect much. Again, the US has typically sided on the case of the employer in most of these types of situations. One thing to watch out for however, is how this type of legislation will affect US companies who either have remote offices or vendors/service providers in one of these other countries in which do more strongly value employee rights. For these companies, policies should almost definitely be updated and communicated to reflect this type of legislation simply to avoid future issues.]]>
Time and time again I am challenged by clients and security professionals alike on what is the real benefit of penetration testing. Though this seems like an age old debate with many famous hackers and security professionals weighing in, I am not entirely sure I understand the argument undermining the importance/benefits of penetration testing. Below are arguments from both black and white hat security professionals:
White Hat – “Pen testing can show one of two things: your security sucks or your security is better than your pen tester”
Black Hat– “The very concept of “penetration testing” is fundamentally flawed. The problem with it is that the penetration tester has a limited set of targets they’re allowed to attack, while a real attacker can attack anything in order to gain access to the site/box. So if a site on a shared host is being tested, just because site1.com is “secure” that does NOT in any way mean that the server is secure, because site2.com could easily be vulnerable to all sorts of simple attacks. The time constraint is another problem. A professional pentester with a week or two to spend on a client’s network may or may not get into everything. A real dedicated hacker making the slog who spends a month of eight hour days WILL get into anything they target. You’re lucky if it even takes him that long, really.”
Though I understand the point of the above arguments, I believe the logic behind these statements is fundamentally flawed. The point they are trying to make is that an organization is never going to be entirely secure and that an attacker with dedicated time and resources WILL in all cases break in, so performing a pen test is only validating something already known. I see penetration testing differently. Penetration testing is not designed to make an organization 100 percent secure but to make them MORE secure (assuming identified vulnerabilities are remediated) and MORE aware what they were before the penetration assessment was performed. It also is a good means to test current logical and physical security controls. From my experience, many security professionals responsible for an organization’s security do not understand the full ramifications of vulnerabilities and thus can become complacent in fixing them.
A vulnerability scanner returns one vulnerability on Company A’s external presence. The vulnerability identified was Cross Site Scripting or SQL Injection. A report is issued to Company A showing a “High” risk rating based on this vulnerability. Company A may not understand how a single vulnerability can translate into a “High” risk rating and thus chooses to ignore or at least delay remediating this vulnerability until time and resources become available. Does this mean Company A’s security is bad? I would say if that if Company A had an external presence of 50 servers and 10 applications, and only one vulnerability was identified, the answer would be no. Company A may very well have good security, but as with everything else in life, mistakes happen. Now let’s assume a penetration assessment was performed on Company A’s external presence instead. Not only would the penetration assessment identify this vulnerability, it would attempt to exploit it. Let’s go on to say that this vulnerability is in fact exploitable and allows for full system compromise. What is a client going to react to more? A report stating they have one critical vulnerability stating what could happen or a report stating they have one critical vulnerability and, oh yeah, by the way we compromised your entire domain controller? A client who just had their entire domain controller compromised is going to be more inclined to fix the vulnerability in a timely manner than one reading a report stating what could happen if not fixed.
How can one argue that this penetration assessment was not beneficial to Company A? It effectively made Company A more aware as to the dangers associated with a critical vulnerability, which in turn made them take a proactive approach to fixing the problem almost instantaneously, thus reducing their overall risk rating.
This is one simple example. I can go on and on about the benefits of penetration testing. Security is about managing and reducing risk to an acceptable level. A penetration assessment isn’t intended to reduce an organizations risk to zero percent, but then again neither is any security assessment. Any time an organization connects a device to a network it assumes a certain amount of risk. It’s understood that zero-day vulnerabilities will always surface and cannot be prevented. So sure, a dedicated attacker could decide to spend 6 months developing an exploit for an unknown vulnerability, however this is going to take a more sophisticated attacker which makes this a less likely scenario.
A penetration assessment is simply used as a means to identify vulnerabilities and provide proof of concept examples on exploiting these vulnerabilities. By doing so, it effectively better explains ratings associated with vulnerabilities which in turn produce much more conscious/aware security professionals. A much more aware security department will be able to better help reduce the overall risk for an organization.]]>