Credit Card Data VulnerabilityWhen you visit a retail website and input your credit card information here are the main points where your personal information is vulnerable:
- Over your shoulder: You first shoulder check to ensure that no other person can see you input your precious credit card and even more precious verification number (that number on the back of your card near your signature that tells the credit card company that the person inputting this number is holding the physical card). Being the clever one you are you always hunch over and block anyone from seeing you key in those precious numbers with your free hand -- so far so good.
- From your computer: You have scanned and secured the computer you are working on to ensure that no one is recording every key that you press on your computer so you are certain that you have not allowed someone else to capture your unencrypted credit card information before it even leaves your computer… they can do this via the power cable you are connected to, if they are close enough they can monitor the signature from your keyboard or they have tricked you into installing a key-logger on your computer like this one for the Mac or this one for the PC (and these are the legit ones)... but again, your computer is clean and has anti-virus and anti-malware stuff installed (oh, and a firewall too) – so we've dodged another bullet.
- From your web browser: You are certain that the web browser we are entering your information into is itself secure and that it has secured the channel between your computer and the retailer's web server using a valid and verified SSL certificate (the little yellow lock) and you are certain that the web server on the other end is actually who they say they are and not someone else who has taken control of the retailer's website. If you're scratching your head at this one let me simplify it… you have the latest version of your browser software and you read any security warnings or pop-ups from your browser (typically there are none but when they do appear you did read them right?) – again, you're doing all the right things so far so you’re confident that you're following proper credit card security procedures...
- From the "website": You are certain that the web page that we are entering your information into is actually the retailer's server and not another site that has somehow tricked you into visiting their bad-guy website while masquerading as your target website. See #3 above and make sure you read the URL in your browser’s address bar, you know that long string at the top of your browser that should read something like: https://www.retailersite.com/something... and not something like http://www.retailersite.badguysite.com/something... but you are not worried here, you’re confident that the site you are visiting is your target site...
- From the web server: You are certain that no one has compromised the retailer's server and injected their own software between you and the retailer's e-commerce software – this of course is a trick question because this isn't your job and even I can't verify this one (even I have my limits). It's the retailer's and their service provider's responsibility and according to the news reports this is where NetSol appears to have fallen victim.
For the non-programmers in the room let's try an analogy (if you haven't left the room already). Suppose you visit your favorite restaurant and you give the waiter your credit card and he happily takes it to the point-of-sale (POS) terminal and swipes the card… no, the waiter is not the villain in this story (not this time), instead the guy who came the day before to "fix" the POS terminal swapped out the credit card reader with one that he made at home that reads the credit card information off of your card and records it to a little device inside the POS terminal that isn't supposed to be there. The device then takes the credit card information and passes it to the device which then encrypts it and sends it to the bank, etc. The problem isn't that the data wasn't encrypted it's that the data was intercepted before it was able to be encrypted and so your information has been compromised – again not by the waiter but by someone who planted a shim of some sort between where your information is input and the bank.
Now, let's look for someone to blame:
- Did the restaurant owner verify that the guy from the POS-company installed a fully compliant device? Of course not, he's not technical he just runs the restaurant. In our story the retailers assumed, rightfully-so that NetSol would take care of this (and it appears they did in the end).
- Did the POS-company knowingly plant this device? Unlikely, it's more likely that someone inside the POS-company did this or someone else knows enough about the device to swap it with their own device… one credit card terminal looks like another if someone has the time and access to swap the devices. In NetSol's case it was either an inside job including a former contractor or former employee, though this is unlikely, but possible, or someone externally gained access to the server or software somehow and compromised it (most likely).
- Did anyone at the restaurant verify that the guy fixing the POS-terminal was actually from the POS-company? Probably not, it's called social engineering and if someone shows up wearing the right clothes and the necessary name tag/ID the support staff aren't going to verify anything, they got stuff to do. Ah... this doesn’t apply to the NetSol story unless someone claiming to be NetSol tricked all of these retailers and from the sounds of it that's not the case... but it lets me round out my list with three things and it's a security issue nonetheless.
Let's get back to NetSol for a second and explain what they (and your current provider) should be doing:
- Source Code Control: No one should be able to modify their source code without them knowing about it. Now, I don't know their policies around letting customers edit the source code but assuming that their customer’s are not permitted or able to edit the source code then this was either an inside job at NetSol or someone got to the servers, which leads me to #2.
- Server Access Control: No unauthorized persons should be able to access the server's such that they can get to where the application is installed and change it. This is like physical security, i.e. you cannot swap something out if you can't get to it. This is covered by PCI DSS (see PCI folks I said I would cover this later) and it's just plain-old common sense network administration – only give the minimum of access and log and audit all of the time.
- Restrict Third-Parties: There is a third possibility namely that someone wrote a plug-in for the NetSol application that was popular and this plug-in somehow injected itself into the unencrypted stream of information or was able to access the data in an unencrypted format before they were able to encrypt it. This should not have been possible but since I don't know their application well enough to comment on it I'll just leave it as a possibility situation albeit unlikely in this case.
Okay doctor, what do I do now?So, you have your own store and you're sweating right now because you don't know if someone has done this to your application and you're asking yourself is there anything that a non-technical person can do to prevent this? What questions should I be asking my e-commerce software/service provider right now to ensure that I don't fall victim to this – oh, and if you are thinking of switching away from NetSol and I've been seeing a lot of companies advertising their software on the back of poor NetSol you should be asking them these tough questions too before you jump ship:
- Trustworthy Employees: What process do you have in place to ensure that the people who work on your source code have not planted a back-door or their own logging code into the application such that if they get tired or fired they just flip a switch and start skimming card or customer information? The right answers include employee contracts, background checks and code audits.
- Source Controls and Audits: What process do you have to ensure that someone hasn't compromised the software on the servers? The right answers include verifiable* code audits on all of the installed versions of their application to ensure that no-one outside of the authorized personnel have been able to update the software on your servers and the worst-case scenario is that there is a complete audit trail... oh, and saying that they use source control is like saying that you have a sign-in sheet at the front door to your office and that you are certain that the bad guys will sign their real name on the sheet as they pass by to do their dirty work – it ain’t gonna happen.
- Server Security: What process do you have to ensure that someone hasn't compromised the server itself? The right answer includes a combination of tools like Tripwire, anti-virus, root-kit scanning and standard system-administrator tasks that monitor and audit servers. Again, you need to verify that they actually do these things and not that they just say they do.
- Disaster Recovery Procedures**: What procedures do you follow when something bad like this happens? The right answer includes at a minimum an action plan related to securing the information and servers and working with you to meet disclosure requirements to your customers, your bank, etc. This is something that NetSol has reportedly been working to do with their merchants and their merchant's customers.
** Okay now I've offended all of the Business Resumption Planning (BRP) people by using their term "Disaster Recovery" but for our purposes this is when something bad happens and that's what BRP is for and so I'm using it... my blog, my terms.
Did I scare you?I hope I scared you just enough to realize the vulnerability that you may face each day with your software and not so much that you have shut down your online store out of fear of bad things happening. I happen to have been a system administrator and a programmer and I know that each group can get locked into thinking only about their individual piece of the system thus ignoring the system as a whole and leaving a hole just big enough for someone to take advantage of as it appears was the case with NetSol. I also know that with proper procedures and policies this can be avoided or at a minimum it can be detected and stopped with minimal damage to your company and its online reputation – as appears to have also been the case with NetSol in that they did catch it. Put yourself in the shoes of the retailers who must now report to their customers that their service provider, albeit a very big one, allowed their information to be compromised… would you as a consumer be placing the blame on NetSol or on the retailer?
What is NetSol doing about it?To NetSol's credit they have launched a website to answer questions for their merchants and their customers including letters and such that will go out to customers and they are offering free credit monitoring for all potentially impacted customers through a third-party agency.
Their incident website is here: Ecommerce Security: What Happened
There are still individual US State laws that must be followed and if you are interested follow the link.
Any questions?I hope I have given you enough to take action immediately but feel free to ask questions in the comments below or contact me with your questions directly:
Chris Kerslake, President, XModus
Phone: (604) 732-7337 x101
Sources for this article: Network Solutions Hack Compromises 573,000 Credit/Debit Accounts
 About the PCI Data Security Standard (PCI DSS)
 Ecommerce Security: What Happened (Network Solutions' website to explain the situation)
 Mac Key-Logger
 Windows Key-Logger
 Configuration Control - Tripwire
 Business Resumption Planning: Justification, Implementation & Testing
 State Security Breach Notification Laws (As of July 27, 2009)