I keep reading articles and blog posts about all sorts of security solutions and how to secure an organization from the onslaught of network attacks. However, all of these discussions seem to assume that everyone is a Fortune 500 company. Threat intelligence, hack backs, APT, etc. are discussed as though everyone has the ability to implement the recommendations presented.
Important statistics that all of us in the security profession need to remember is that the vast majority of organizations are not Fortune 500 organizations. As of 2008 (the latest statistics I could find from the US Census Bureau), there are almost 6 million businesses in the United States. The Fortune 500 therefore comprises 0.0084% of the total businesses in the US. To make matters worse, organizations that employ less than 100 employees make up 98.1644% of all employers in the US. I would guess that these statistics would be relatively consistent around the world.
The reason these statistics are important is that security professionals need to pull their collective heads out of their posteriors and stop making security so hard that it is impossible for the 98.1644% to implement.
Do you now understand the frustration of most business people?
They do not have a security staff of tens or even hundreds to tackle security issues. They are lucky if they have an IT person or two. If they can afford it, they outsource and do everything possible to make themselves secure, but they only can do so much and their resources are extremely limited. Particularly so given the Great Recession that they just survived.
Margins for small businesses are very slim. You can argue all you want that today’s businesses are only competitive if they leverage technology and that technology comes with prerequisites. However, have we created an environment where the hurdle to be in business is now so high that small businesses are just going to be targets regardless?
As a result, I challenge the security community to come up with realistic solutions to security. We need to develop common sense, simple but effective security methods so that the 98.1644% of organizations are reasonably protected. Granted, security is not perfect, but we have got to stop discussing security and privacy as though every business is a Fortune 500. They are not and our solutions and recommendations need to reflect that fact.
This brings me back to the PCI DSS. If all of the requirements of the PCI DSS could be executed 99.9999% of the time every day, would it keep an organization secure (recognizing that security is not perfect)? I believe it would. But it’s that consistency of execution that is the problem regardless of organizational size.
So let us refocus our priorities and help the vast majority of the world get secure.
I have tried to do that with this blog, but I too have been seduced by the big dollars that the Fortune 500 toss my direction. In my very humble opinion, I think we need to get back to our roots and do more for the vast majority that are struggling with security.
That said, in the process of simplifying, maybe there will be some opportunities for the fortune 500 to find solutions that are less complex. It could be a win-win for everyone.
It seems I am late to post to this blog since I posted to this http://www.dallasnews.com/business/columnists/pamela-yip/20140622-businesses-should-be-open-about-data-breaches.ece before seeing this email alert.
The Guru and I have had many back and forth in many debates in his blog (Scott and Pinhead). It seems the Guru is finally seeing the problem from the direction I have been coming from for years. The problem is not the merchant acceptance of card payment information. The data is encoded on a magnetic stripe (1950’s technology) that is easily counterfeited. The real problem is that the brands and issuers have made the information that is counterfeit-able valuable. Even the recent announcement to move to EMV many state that it does not “fix the problem” because the PAN is available in the clear. The fact that PAN data is valuable is not the problem of the merchant. PCI DSS is not a security standard, it is a best practices document and in some areas very prescriptive. The DSS can help to mitigate the risk of compromise, not eliminate it. To pretend that the DSS is fix is not productive.
I do agree that “security community ” should work in the real world to help solve the problems we face now, however, when the “standards” are created in a ‘committee of the few, or the one’, this will never happen.
Scott Spiker
@cipherithm
We agree that the paradigm is broken, but we disagree on the fix. My fix is to go to a single use code. That could be implemented on smartphones and devices such as Coin very easily. The card brands have the solution because they tried this about 15 years ago but didn’t have the portable solution.
Thank you so much for your insite in this subject of PCI. I really want to know if you have any advice you could give me to descope applications with iframes for credit card acceptance. The main question is whether an application is not in scope for assessment if it uses an iframe to input a credit card to a service provider (third party vendor like TD Beanstream of TD Bank). In this solution, there is no credit cards in our servers and the acceptance and transmission is in iframe, however, the code that redirects acceptance is in our servers. In this situation, are the servers that holds the code connecting systems? Any advice you can give me is very much appreciated Thanks Ruwanmali
There is no data flowing through your server, but your server is a key part of the payment process. And from your customers’ perspective, the iFrame is probably assumed to be part of your Web site. So your customers will believe that you are responsible if a breach ever occurs.
The risk in your example is that the code that invokes the iFrame is changed to point to an attacker’s iFrame that then collects your customers’ cardholder data (CHD). As a result, at a minimum, you should be monitoring the code that invokes the iFrame for any changes. If a change occurs, an alert should be issued and you should probably take the Web site down until you can fix it. Add in putting the server behind a firewall, anti-virus, patching, log collection and analysis, vulnerability testing and annual penetration testing and I think you get the picture that it is not out of scope, but it also does not have to meet all of the requirements in the DSS either. In my very humble opinion, such a server needs to meet basic security requirements with some enhanced monitoring to ensure the code that invokes the iFrame does not change without your knowledge.
However, not all QSAs agree with this advice. In reading the January 2013 eCommerce information supplement from the Council, they highly recommend this approach but do not mandate it. That said, given today’s attack prone environment, do you really want to risk it? If you do, best of luck to you.
I can’t agree more. Whenever we ask a question – if I am PCI compliant, am I secure – the answer is always “NO”. Then why don’t we just use an effective pentest tool to cover technical part of the security, and go through physical and management security separately to replace PCI?
So combine basic security practice and PCI ! Turn the PCI into a process – making sure the pentest is as complete/often as possible to cover what the PCI requires instead of letting those QSA junk tell you how to secure your business while charging you tons of money.
What you are suggesting is what the Council is referring to as “business as usual” or BAU in v3 of the PCI DSS. BAU is the integration of security practices into an organization’s daily procedures and culture.
The QSA process is a necessary “evil” to ensure that organizations are doing their best to comply with the PCI DSS. However, security is never perfect, so there will always be gaps. The key is, does the organization recognize those security gaps in a timely manner and then fix them? That is where most organizations fail is that gaps occur, they do not get fixed and, oops!, a breach occurs. All you have to do is look at Target or Neiman Marcus to see examples of those failures.
I have yet to encounter an organization that can execute all of the requirements of the PCI DSS 100% of the time, every day of the year. If organizations were able to accomplish that feat, there would be very few breaches.
Right! Security should be a daily work, not a waste of money+time on QSA+PCI. My point is pentest and other tools are used to monitor and push for daily security (to cover PCI as well). QSA/PCI is just a step to simply verify. Currently we put cart in front of horse – this is the biggest business vulnerability to let hacking guys having advantages on all of us – we waste time and money to not efficiently deal with security.
PCI process should be focusing on pushing vulnerability scan and pentest (+physical/management security) instead of inventing its own rules and let QSA be the king to question the poor organizations.
If we are not doing an efficient security, we let the hackers+QSA+PCI ruin our business. Please don’t fool ourselves by arguing that QSA+PCI is necessary – my point is – don’t put the cart in front of the horse. Yes, they are necessary, but …
The trouble is that the 98.1644% typically do not have a clue as to what is and is not “best practices” when it comes to security of cardholder data (CHD). That is what drove the development of the PCI DSS in the first place as the card brands’ names were being tarnished by the plethora of breaches of eCommerce sites and retailers on an almost daily basis. Had merchants been doing their part to secure themselves, the DSS would not exist.
While the PCI DSS provides security guidance, most people do not take the time nor have the time to research and understand what the DSS is telling them. They rely on friends, neighbors and their uncle’s brother’s nephew that is computer savvy for advice because it is free. But, you get what you pay for and most times free advice is worth just that, exactly what you paid for it – nothing.
That is the point of this blog is to provide guidance to the 98.1644% without dinging them a fortune for the advice. I answer peoples questions and occasionally the odd project comes from it.
Thank you very much on the help. Now nail down to a common issue dealing with PCI – network segmentation/isolation. Can I have my CDE in a separate domain and/or VPNs ? And non-CDE support/admin go through firewall/VPN settings to get connected to the CDE? Of course, there should be monitoring proof/logs/evidence that no card data leakage through the holes.
Separate domains typically don’t work as well as one would think mostly because people try and use one-way trusts and other bizarre techniques to allow user accounts to be managed in one but not the other.
I would recommend that you read the Open PCI Scoping Toolkit (http://itrevolution.com/pci-scoping-toolkit/) to understand the types of different systems that can exist in a PCI environment. Then read my diatribes on network segmentation that I have documented under Post Series References (https://pciguru.wordpress.com/post-series-references/).
How to secure payments?
The pressure should definitely be onto the banks and their service providers, not onto the merchants.
Asking small merchants to put expensive security band-aids around to render PCI compliant the non truly secure solutions provided by their banks, that is totally counter productive!
Thank you Guru. You have nailed one of my biggest frustrations with the PCI DSS rule set. The rules came from the big end of town who have very high levels of resourcing. I expect the vast majority of business outside of the top 500 cannot even understand the rules, let alone fully and reliably implement them. The banks and card brands are happy to provide more and more rules. Where is the re-engineering on their part, to make security inherently more easy to achieve, by design?
What a fantastic piece. You have perfectly voiced the frustrations of the many millions of small businesses out there.
It is a constant battle to keep up with the “Big” rule makers who seem to have nothing better to do.
This week another new problem arrived in the post. Mastercard are changing the way they want to handle pre-authorisations, so a fairly simple system seems to be getting all complicated. The letter tell sme “you must change your software to handle this” I cant afford to change software just like that.
They really are opening themselves up for someone clever to come along and pull the rug out from under them.
Like I always say in my comments. I want a service, I dont want “their” problems, I am the customer make it easier for me. At the moment there may be no where else to go, but as oon as there is small businesses will have no loyalty, we get treated like dirt!
Thanks again for a great piece.
D