# 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.

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.