Monthly Archives: September 2015

EMV Chip cards: Overview

When you shop at a store with a credit card it is typically done by swiping your card to conduct the transaction. The swiping action allows the credit card terminal to read your credit card number off of a magnetic strip on the back of the card. The downside to the magnetic strip technology is that it is very easy and cheap for the bad guys to reproduce. A common way for the bad actor to get your credit card number is to use a skimmer, a small device that goes over the normal reading mechanism, to steal the data. Once this is done, they can then create a new card with the same information and then attempt to use it at a store.

What is an EMV Card?
In an effort to reduce card present fraud, cards are making the switch to EMV (Europay, MasterCard, Visa) cards. EMV cards use a smart chip, rather than the magnetic stripe, to provide the information needed to complete the transaction. Unlike the old magnetic cards that you swipe, the EMV cards are “dipped” by inserting the chip side of the card into the card reader. The card stays in the device for a few seconds until the transaction is complete. One of the features of the chip is that it sends a unique token for use with each transaction making it harder for a malicious user to replicate the data, even if it is retrieved.

The EMV cards are also much more costly to create, which adds to the complexity for a theif creating fraudulent cards.

Two Options: Chip + Pin and Chip + Signature
There are two ways that EMV cards are used. The first way is called Chip and Pin. In this scenario, a user has a numeric pin that has to be input when using the card in person. This is very similar to how a debit card works today. The requirement of the pin helps protect the card from being replicated by a bad actor, or used by someone that may have stolen the actual card from you. Of course this can be a tricky scenario when you have multiple credit cards when trying to remember the pin for each card.

The other way is called Chip and Sign. In this scenario, the card owner doesn’t have a pin, but rather is required to sign for the transaction. This is very similar to how most credit cards still work today. This is actually much easier to bypass because you may be forging just a signature, not trying to come up with a pin number.

Reduces Risk for Card Present Transactions
I mentioned earlier, this only adds security to the Card Present scenario. This doesn’t change anything for the Card Not Present (shopping online) scenario. Also, know that it will be a while before we see chip only cards. For the time being the newer cards will have both a chip and the magnetic stripe. This is because it is going to be a while before every vendor makes the switch to EMV. Keeping the magnetic stripe also reduces the security a bit since there will still be a lot of places that won’t upgrade and will still use the magnetic stripe.

For Consumers
The biggest change is that you will use your card by “dipping” it, rather than swiping for in person transactions. The goal is to reduce your card being replicated by a bad actor and having funds racked up on your account. Most credit cards are zero liability so this may or may not be very noticeable to most consumers. Hopefully it will at least cut down some of the card present fraud that happens. Only time will tell.

For Businesses
The liability is changing with the push for EMV cards. If you are not following the recommended approaches, such as requiring EMV vs. the magnetic stripe, you may find yourself liable for any fraudulent charges. Make sure that you are validating the cards and the card holder when accepting credit cards to help reduce your liability. Update to accepting the EMV chip data vs the magnetic stripe.

Final Thoughts
This won’t solve all of the problems, but it is a step in the right direction. The United States is one of the last countries to adopt the chip technology. Many of the credit cards will be chip and sign, but you may get a few that are chip and pin.

Remember, no matter what technologies get added to protect our credit cards, it is still your responsibility to monitor your statements and report any fraudulent charges. it is part of the responsibility of having a credit card.

Versioning the SDLC to Indicate Security Level

I recently saw a tweet that mentioned how trending SecDevOps is becoming. For those that don’t know, that is the “secure” devops, or shall I say devops with security injected. It really got me thinking about not only devops, but also the Software Development Life Cycle (SDLC). We keep saying security can’t be bolted on and that it needs to be built in, yet we keep bolting it on.

For years, we have talked about how the SDLC doesn’t have security built in and how we can create a “secure” SDLC, or the Secure Development Lifecycle (SDL). My concern is that as long as we have an SDLC and a “Secure” SDLC, or a DevOps or “Secure” DevOps, we will always have the insecure implementation. In addition, we are lacking a way to determine what security enhancements are built into “your” SDLC.

So why not version these items? Rather than creating a “Secure” SDLC (or SDL) lets look to create SDLC 2.0. Now this wouldn’t be the end all for a secure SDLC, but it could be used to build a maturity model to help identify what controls are in place. Like BSIMM or OpenSAMM, it creates the opportunity for a maturity model to form. This maturity model not only provides goals for the organization to grow towards, it also makes auditing easier. Imagine going through a PCI audit and instead of answering a bunch of questions on your secure SDLC you can select what version you conform to. We seem to have too many different ways of doing things around application security which makes it more confusing. Development programs know SDLC, so versioning it vs. BSIMM or OpenSAMM may have some better traction. This is just a thought.

The same concepts go for versioning devops, or any other framework we are using. This is not something that could possibly happen overnight, but if properly implemented could be very beneficial. I would be curious if there are any thoughts on this, or if it has even been thought of previously. Is this possible? What would go in each version to help build up to a mature program?