Startup Security

I want to briefly touch again on PCI and payment applications, as I keep getting scared out of my security hat. There’s a fantastic tech startup group in Seattle and somebody recently asked about processing credit cards on the mailing list. One of the commenters pointed to the Rails ActiveMerchant plugin, which can be used to access payment gateways such as Authorize.NET, Paypal, and over 30 others. The following piece of code, found on the ActiveMerchant page, is what rang some bells in my head when I saw it.

# Create a new credit card object
credit_card = ActiveMerchant::Billing::CreditCard.new(
  :number     => '4111111111111111',
  :month      => '8',
  :year       => '2009',
  :first_name => 'Tobias',
  :last_name  => 'Luetke',
  :verification_value  => '123'
)

if credit_card.valid?

  # Create a gateway object to the TrustCommerce service
  gateway = ActiveMerchant::Billing::TrustCommerceGateway.new(
    :login    => 'TestMerchant',
    :password => 'password'
  )

  # Authorize for $10 dollars (1000 cents)
  response = gateway.authorize(1000, credit_card)

While ActiveMerchant itself is not a risk, I simply want to reiterate how you use the library is very important when it comes to handling credit cards. This code, if used in the manner above, puts your web server in scope for PCI compliance even if you are never writing the credit card number to disk. While you should be doing nearly everything in the PCI standard anyway in order to properly protect your assets, PCI can be a tricky field to navigate. I’ve said it before and I’ll say it again: if you want to avoid the complexity of introducing PCI compliance into your environment, do not store, process, or transmit a credit card number and use an offsite payment gateway instead.

If you have further questions about this, feel free to leave a comment, contact me (damon at startupsecurity.info), or visit PCI Answers for anything and everything related to PCI including contact information for one of the most knowledgeable PCI resources around, Mike Dahn.

Since Mike recently linked here from his PCI Blog (Cloud computing security and PCI), let’s take a brief look at what PCI means for a startup.

PCI Compliance

PCI Compliance has probably been one of the strongest driving factors of security compliance in the US in recent years, particularly for retailers. So what is it? PCI stands for Payment Card Industry and the PCI Data Security Standard is an accepted standard among the payment brands (Visa, MasterCard, Amex, Discover, etc) that defines a set of 12 requirements that merchants who handle cardholder data must be compliant with. *you can breathe now* With that broad statement, there are a few things to point out.

Cardholder Data

Straight from the PCI website…

Cardholder data is defined as the primary account number (“PAN,” or credit card number) and other data obtained as part of a payment transaction, including the following data elements:

• PAN
• Cardholder Name
• Expiration Date
• Service Code
• Sensitive Authentication Data: (1) full magnetic stripe data, (2) CAV2/CVC2/CVV2/CID, and (3) PINs/PIN blocks)

This effectively means that if you store, process, or transmit a credit card number, alone or in combination with the data listed above, you are subject to PCI DSS. I should note, however, that there are different requirements based on your size and processing volume and you should contact your acquirer, payment brand, or local Qualified Security Assessor (QSA) to determine your PCI DSS validation requirements.

The Requirements

So, 12 requirements, huh? Yup. Each with several sub-requirements, too. While you can read the details on the PCI DSS site (click “Download the Specification”), I think it’s more important for startups to realize that there are very specific requirements surrounding the handling of cardholder data and to consider those requirements when extending into such areas as e-commerce. Ultimately the goal is to manage the risk of storing cardholder data by means of network segregation, data encryption, audit logging, policy and security testing (among others). Options are also available for outsourcing credit card transactions, which can relieve the strain of PCI compliance for a startup.

One More Thing

Are you a software developer building a payment application but not actually storing cardholder data yourself? You still need to be aware of PCI and the Payment Application Data Security Standard. This ties in to my previous post about third-party components and is PCI’s attempt to ensure safe handling of credit card data for payment applications created by software vendors.

Well yesterday’s post was certainly fun and exciting, as the topics of vulnerability and exploitation tend to be. But there’s definitely a lot more for a startup to worry about than Cross-Site Scripting, including various state and government regulation and compliance. This post is largely US-centric, so International readers may want to continue solely out of curiosity.

History

Back in 2003, California Senate Bill 1386 was put into effect. In brief, “it requires an agency, person or business that conducts business in California and owns or licenses computerized ‘personal information’ to disclose any breach of security (to any resident whose unencrypted data is believed to have been disclosed).” [source, sb-1386.com]

Effectively, this means that if you maintain “personal information”, as defined by the bill, of a California state resident in an unencrypted form and there is a breach of security that results in an unauthorized individual gaining access to said data … you must report the breach.

Now this is generally considered to be a good thing as if my social security number gets hijacked, I should be made aware of that.

Present Day

As of September 16, 2008, at least 44 states have breach notification laws. This means a couple things for you, the startup.

1. You need to identify what information you store about your customers
2. You need to identify what data falls under these laws in each state
3. You need to be aware of security breaches
4. You are legally required to report breaches that result in unauthorized access to unencrypted personal data

I’ve talked about it before, but this data identification and classification process should be part of a threat model and documented very clearly. So what is this data? Well it’s different in every state, but a few of the common ones are:

• Social security number
• Driver’s license number
• Passport information
• Credit card number

However, depending on your application, you may have sensitive personal data that you are not intentionally storing.

What Data Are You Storing?

One of the questions I have, and can’t answer completely as I Am Not A Lawyer, is what about services that store my data?

• If I DM somebody my credit card on Twitter and Twitter gets compromised, are they responsible for disclosing that to me?
• If I upload my passport into Evernote for safekeeping and it is compromised, are they responsible for disclosing that to me?

As I read the law, and if I interpret Evernote’s Privacy Policy and Twitter’s Privacy Policy properly, that is the case.

*** Please note that to my knowledge, neither Twitter nor Evernote have had breaches that revealed sensitive information. I’m simply using them as examples of data storage services where my data is not encrypted. ***

How Often Does This Happen?

Well if we look at a listing of data breaches since 2005, there have been a total of 245,201,693 records containing sensitive information involved in security breaches. That’s 81% of the US population, by the raw numbers and simple math.

Tell Me How To Fix It

If you are aware of sensitive information that you are storing as part of your application functionality or perhaps as an administrative function (credit cards for paying members), the best way to mitigate these risks is through the use of encryption. This can take many forms and it can be complex as utilizing the full-disk encryption of various vendors (PGP), or it can be as simple as creating an encrypted disk image on OS X to store the sensitive information.

If users upload data onto your systems, it is likely not feasible to encrypt all of that information. From that perspective, it’s about managing the risk. Performing regular server and network security audits to verify that the proper steps have been taken to secure your network and, in turn, your customer’s data.