Computer Security Day

It's been a long while since I posted here. Time is flying by. A colleague at work sent the following security PSA to all Shift4 employees and he was gracious enough to let me re-post here for the world. Good info...

COMPUTER SECURITY DAY

Computer Security Day is observed annually on November 30.

Identity theft, credit card fraud, ransomware, and more endanger our online experiences every day.

History of Computer Security Day
Computer Security Day began in 1988, around the time when computers were becoming commonplace in business and government and in the home…when they no longer cost $10,000.  The Internet, as we know it today, was also an infant.  While hacking and computer viruses have been around since the early days, evolving and increasingly sophisticated malicious technologies will continue to be a threat to online computer activities forever.  Computer security had already become a major concern by the end of the 80s so Computer Security Day was created to educate users and raise awareness.

Here is a checklist you can follow to help secure your computer at work and at home:

·         A password is required to access my computer.

·         Windows Update is enabled.

·         I use antivirus software and make sure it is updated daily.

·         My Windows Firewall is on.

·         I keep my computer applications patched up to date.

·         I remove unused computer applications.

·         I always use strong passwords.

·         I don’t share or write down passwords.

·         I log off my computer when I’m not using it.

·         My home wireless network is secured with a strong password and strong encryption.

·         I regularly backup my important data to an offline device.

·         I use caution when I browse the Internet.

·         I suspect foul play when my browser is redirected to another web site.

·         I don’t allow my web browser to store or remember my passwords.

·         I regularly delete temporary Internet files.

·         I don’t open attachments or click on links in email from people I don’t know.

·         I make online purchases only on well known, reputable web sites.

·         I look for “https” in the address bar before submitting personal and payment information.

·         I don’t save my credit card information on web sites.

·         I don’t use my debit card online.

·         I don’t use the same password for all online services.

Enjoy!

Shift4 Secure Payment Processing DOLLARS ON THE NET®     IT'S YOUR CARD®    4Go® Stephen Ames, CISA, CISSP Senior Director, Security Compliance
Shift4 Corporation 1491 Center Crossing Road Las Vegas, NV 89144-7047	702.597.2480 ext. 46700 fax 702.597.2499 www.shift4.com sames@shift4.com

"In the pursuit of security assume nothing." -sga

Earth to Media, Earth to Media, Come in Media…

Target breached, and EMV would have done nothing to prevent it. Period! I realize there are a lot of EMV fans out there stating differently, but please reference people that really know EMV -- its advantages and its limitations -- before releasing propaganda pieces painting EMV as the silver bullet it is not and calling it news.

What EMV cannot do: EMV does not protect the PAN, expiration dates, CVV2 or even PINs in anyway. While information as to whether or not PINs were stolen in the Target breach is sketchy, all the other information was stolen and EMV does not protect any of this.

What EMV can do: EMV is very good at preventing the stolen information from being used to create forged cards to be used for card-present (swiped) purchases, but if history repeats itself, the stolen information will primarily be used for card-not-present (ecommerce) purchases. Until EMV and/or the card brands address card-not-present purchases, EMV is nothing more than a one legged stool.

The Great Token Divide

Recently I had the privilege of deciphering a USPTO process patent to determine what is claimed and then to determine if any of our technologies infringe upon it. I have received several of these requests as of late, and I'll be writing on the others in coming months. Currently in the payments space, patents are all the rave – hence the recent spree of research requests.

Before I begin, let me be perfectly clear. I think process patents should go the way of the dodo. I believe that most process patents do nothing more than stifle innovation by giving a monopoly or barrier to competition to the first to file – whether or not the process existed or was in use by competitors prior to the filing. There is a key requirement to patents that, in theory, prevents what I call frivolous patent filings: "Inventive step and non-obviousness." But there is a loophole here: The United States Patent and Trademark Office. Simply make a claim with sufficiently confusing details and jargon, throw in a few references to other parts of the same patent, and poof – patent approved!

Now that I briefly side-tracked this post with my rant on process patents, let me get back to an old favorite subject of mine – and the thing that scared me most about this most recent patent I reviewed. That subject is how scary implementations of tokenization can be thanks to the Great Bastardization of Tokenization by the PCI SSC.

I began my research after receiving this email:

Hey Steve,

I’m no expert on patents, but wouldn’t this fall under prior art from us?
http://www.hispanicbusiness.com/2013/12/4/patent_issued_for_system_for_protecting.htm...

The article references US patent 8,595,850.

US patents can be very confusing to read. When researching for possible infringement the Claims section is the most important part. The rest of the patent text is used as background info and sometimes claim context to justify to the USPTO that the patent passes their "inventive step and non-obviousness" requirement.

This patent makes 7 claims, but claims 2-7 each refer back to claim 1. So here is claim 1 with the important information highlighted:

1. A method of generating a token using computing equipment associated with a token generating organization, comprising: with the computing equipment, receiving a token request from a token requestor over a communications network, wherein the token request includes a number; with the computing equipment, mapping half of the number to a half-token; with the computing equipment, modifying the half-token; with the computing equipment, mapping the modified half-token to an additional half-token; with the computing equipment, modifying the additional half-token; and with the computing equipment, combining the modified half-token and the modified additional half-token to form the token.

Based on my reading of the originally referenced article and the patent description, what I think they are doing is pre-calculating a “half-token table.” Basically, this appears to be a shuffled list of all possible 3-digit numbers (000-999 randomly shuffled). They then pull three digits of the primary account number (PAN) that they want to “tokenize” (most likely they are preserving the first 6 and last 4, so starting at the 7th digit and tokenizing through the 12th digit – assuming a 16 digit PAN), they look up the corresponding token for the 3 digits. Then they take the next 3 digits in the PAN, and using the first “half-token,”  they do a little magic and sprinkle some holy water and “tokenize” the second half. In the article and within the patent description there are several references that this is a reversible process and this is the scary part. In encryption terms, the entire shuffled half-token table would be considered the key. If it’s ever exposed, all the unprotected tokens that are based on this file become instantly decipherable.

These tokens are obviously mathematically related to the PAN and I believe this vendor calls them "vaultless tokens" because the PAN does not need to be stored – they can be recreated (decrypted) from the token and the "half-token" table. This mathematical relationship was specifically forbidden in the original tokenization definition, but PCI SSC – with the help of the Tokenization Special Interest Group (other vendors with non-tokenization solutions that wanted to ride on the tokenization coattails) and in the name of vendor neutrality – allowed for schemes like these to be called tokens.

Now, security wise, here is the difference between tokens generated under this patent, which still qualify as PCI-compliant tokens, and TrueTokens^®, which are non-mathematically related. To compromise the tokens generated under this patent, all one needs is a copy of the "half-token" table and all the tokens generated by the table can be decrypted. But with TrueTokens, to compromise the PANs one would need a copy of the entire "vault" which contains both the PANs and the key(s) used to encrypt the PANs within the vault. PCI requires PANs to be encrypted when stored and mandates proper key management – not so with the "half-token" table.

By accommodating mathematically related tokens in PCI's definition of tokenization, they opened the door for weaker tokenization solutions like this. The problem is, QSAs must either dig deep into the details of each tokenization solution they come across to determine whether the merchant is using a legitimate tokenization solution (like TrueTokenization), or a tokenization in name only (TINO) solution, which wears the tokenization name badge but provides non of the security and scope reduction. This type of solution analysis adds costs to an audit. Unfortunately, the QSAs alternative is to assume that every solution is a TINO, which impacts scope (adding another cost).

Obviously, Shift4 does not infringe on this patent, because we wouldn’t release garbage like this if our life depended on it. That's my take on this patent. I welcome your thoughts.

Until next post…

The Zero-Day Flaw

Remember the days when a flaw was a flaw and an exploit of one of these flaws was an exploit? Now-a-days people and vendors throw around Zero-Day Flaw like it's a marketing term. There is no such thing as a flaw, only updates that add features and "enhance security" and emergency hot fixes that plug zero-day flaws that hackers somehow create. I predict that the next generation of marketization will be the dropping of "flaw" and reframe the term as Zero-Day Hack. This way there is no implication of a flaw.

To me, this is akin to people using the word "opportunities" for the word "issues", "issue" for "problem", "not being truthful" for "liar".

Dog Pile!!!

I've done it again. You can see my latest rant Dog Pile!!! that conveys some of my, let’s say “passionate” thoughts on placing more burden on merchants for breaches. Enjoy.

Cybertheft Crackdown My Butt

I've read several stories of late flaunting some high profile cases where it seemed law enforcement and judges were finally cracking down on cybercrimes and cybertheft. I thought we finally made the turn and were prosecuting the perpetrators (hackers) of these crimes the way they should have been prosecuted all along. Then I read this today: http://www.bankinfosecurity.com/rbs-worldpay-sentence-too-light-a-5058/op-1

In a nutshell, the mastermind of the RBS WorldPay hack, where $9 million was pilfered from U.S. bank accounts, was sentenced to 30 months in prison and ordered to pay $89,000 in restitutions. Let's see, $89,000+30 months for $9 million, that comes out to a $297,000 per month. That's a pretty good payoff. I understand that he had accomplices' so he did not pocket the entire $9 million; but many wannabe hackers reading this will see it as $9 million for 30 months. This sends a strong message: Cybercrime pays!

Until sentences are large enough to discourage the crime, nothing will change: More money will need to be spent for cyber security -- more hacking -- more money -- more hacking -- and so on…

Tokenization, the Newest Horse - err, Camel - in the Stable

As the old saying goes, "a camel is a horse designed by a committee." This saying perfectly describes the recently published PCI DSS Tokenization Guidelines from the PCI SSC. While the original intent of the document was a noble one, the final version fell way short.

The problem with having multiple blogs is to post onto multiple blogs. To avoid content duplication, please go here to read my post: http://blog.shift4.com/2011/08/tokenization-the-newest-horse-err-camel-in-the-stable.html

Beware Mac users - as popularity grows, so does the target on your back

It's been a while since my last post. I hope to start posting somewhat regularly again in the near future. It's been a madhouse around here as we have been building a new data center from scratch; new hardware, more hardware, new O/S, more memory, new software, new, new, more, more, better-stronger-faster everything, etc., etc. In the last few weeks we've been migrating various services and customers to it; throw in our annual PCI audit and presto -- no time. You'll hear more about this entire project in the next few weeks. For now, suffice it to say it's been a busy time.

Over the years I have posted on several forums my belief that no operating system is inherently secure simply because it is not Windows. Many anti-Windows zealots tout that Linux or Mac or whatever is much more secure based on the number of reported hacks and vulnerabilities: "Hey, simply look at the number to prove my point." And this argument always has a reference to some vulnerability report showing Windows (some big number), their O/S of choice (some little number). I always point out a very similar report showing market share: Windows (some big number), their O/S of choice (some little number). My argument is that hackers go to where the money is -- the market leader.

Well an interesting read that just came out the other day: Coming soon to a Mac near you -- serious malware. When I read this article I had to check back to the author a few times to make sure it was not me as an alias. Give it a read if you have some time.

Do as I Say, Not as I Do

The latest breach involving Heartland Payment Systems is all the buzz. Some are surprised and/or appalled “yet another high profile breach.” Others question the timing of the announcement theorizing some public relations attempt to hide the announcement within the presidential anointment, oops, inauguration ceremony. What caught my eye is the latest campaign: Heartland CEO Calls For Industry Cooperation To Fight Cyber Criminals And Adoption Of End-To-End Encryption. While I agree with end-to-end encryption, I feel this is nothing more than a case of “do as I say, not as I do.”

My issue is the last paragraph of the above linked press release: “For the past year, Carr (Robert O. Carr, Heartland’s founder, chairman and CEO) has been a strong advocate for industry adoption of end-to-end encryption — which protects data at rest as well as data in motion — as an improved and safer standard of payments security. While he believes this technology does not wholly exist on any payments platform today, Heartland has been working to develop this solution and is more committed than ever to deploying it as quickly as possible.”

The technology already exists, just not in the terms that Carr may be implying. I think Carr is referring to chip cards of one sort or another, but there is nothing stopping a company from doing end-to-end encryption within their own network. While PCI does not currently require end-to-end encryption within a LAN, PCI is meant to be a “minimum” security standard – it is not a be-all, end-all blueprint for secure payments.

I try not to advertise for Shift4 within my blog, but Shift4 internally does end-to-end encryption within its network. The weakest point in the whole chain is the final hop to the bank or processor (which we have compensating controls in place to isolate and minimize the exposure at these points – but this is beyond the scope of this rant). Here, I would argue side-by-side with Carr to force all banks and processors to require application layer encryption at this hand-off point instead of solely relying on VPN encryption. Shore up the weakness of this layer, problem solved provided that the banks and processors internally do end-to-end encryption and you don’t have to wait for PCI rule change, nor do you have to toss out the baby with the bath water by switching to chip cards.

Switching to chip cards may solve some issues, but viewing chip cards as a panacea, I feel, will be a big and extremely costly mistake for merchants if other layers in the end-to-end data path are ignored. If merchants think PCI is expensive now, wait until they need to purchase and deploy all new hardware and fork out the POS software upgrade fees required to support this new hardware platform.

PCI: Compliance vs. Security

Last week Shift4 Corporation hosted the 2007 Real Security Summit. There were many sessions on various topics given by speakers with a wide range of expertise. Most of the information given was anywhere from interesting to scary, and all was useful. The range of topics included security, privacy, liability and compliance -- most everything you must know if you do anything with payment or privacy information. The two of the scariest topics were the link between credit card fraud and terrorist funding and the full liability to a merchant in the event of a data breach.

While all the information I would consider valuable, one quote by Heather Mark, stands out in my mind dealing with how many merchants and vendors deal with PCI: "Teaching to the Test." I’ve known what this phrase meant ever since my high school days but have never thought of it in terms of PCI. For anyone who has never heard the term, this is when an instructor does not teach the fundamentals and concepts of a subject but instead focuses on the answers to the test. This is a side-effect of the "No Child Left Behind" program -- many teachers are teaching to the test instead of teaching the subject at hand. Teaching to the test is depriving our kids from a rich education just like teaching to the test will deprive our industry from the overall goal of PCI -- security. Both programs, No Child Left Behind and PCI, are good programs with good intentions but they fail from the same problem, what I call "the compliance factor." If you are only looking at PCI as checkboxes required for compliance, then you are missing the point of PCI.

I’ve always addressed this topic as Security through compliance vs. Compliance through security. Some might think these two terms net the same end result but in reality they do not. Think of compliance as the very minimum that must be met to be considered "secure enough." With Security through compliance, the minimal was done to make the application or data center secure. With Compliance through security, your application or data center is already secure, you allocate resources to security and privacy, you have trained your personal on security and compliance is almost a side-effect of this security.

Sure, go through the PCI requirements and make sure you have every checkbox checked but then go further. Look at your data requirements. The easiest and best way to keep sensitive data out of the hands of hackers is to not store it. Encryption will fulfill some of the PCI checkboxes but if you don’t absolutely need the data, not storing it is a more secure alternative. There are people out there that want your data. What would happen to your company’s reputation in the event of a data breach? Again, think beyond checkboxes.

Yes, privacy and security can be difficult and an ever changing target but I urge everyone to look at this as more than checkboxes. Be vigilant.

Until next time…