Protecting against data breaches in your startup company: Apple + Box

Data security can be the furthest from your mind when doing your startup company.  You have a short runway to get a product out the door and get happy customers.  Security?  Spending scarce resources on it?

I am helping a company now with these very same questions.  The path of least resistance has been to standardize on Box business plan for all data and Apple computers and devices.  Why?   From a cost basis, they are very economical and they have the necessary security bells and whistles you need today.  And most importantly, the users like them and will use them (and you don't need a part time IT person to manage them).

The first thing I do is turn on 2 factor authentication (when you login on a new device, a code is sent to your phone for verification).  Both Box and Google for business support this.  I turn on full disk encryption for Apple computers (put in a password) and passcodes for iPads and iPhones.  And enable the ability to remote wipe any stolen or lost computer or device.  Pretty simple, but you  Wellwould be surprised at the number of people who don't do this.  And it's built in (no additional cost).

On the Box side, make sure you require a passcode to access it from your iPad or iPhone.  Since you have Box business, pin devices / computers to your users and you can restrict what applications your users use with Box.  You can restrict content that can be shared or not.

With Apple and Box, you get a lot of data security built in.   Think of this as a security well.  

You start at the top with the basics and as you grow you increase security measures as you progress down the well and need more protection.   Now that wasn't that hard was it?

Protecting yourself from hacked credit card readers: Google Wallet & Apple Pay

First TJX with 90 million accounts stolen, then Target with 40 million accounts stolen and now Home Depot with 56 million accounts stolen.  I found it interesting that Target was hacked through a flaw in Microsoft Active Directoy.  No news yet on the details of Home Depot.

What's a person to do?   Buy a phone with NFC payment option.  The newer Android phones have Google Wallet and it looks like Apple Pay is coming soon.  When you activate Google Wallet, you link it to a credit card.  I prefer American Express because they have great anti-fraud detection and allow you to dispute un-authorized charges from their website.

When you are shopping, look for the wireless payment option on the card reader.  Most grocery stores have them and big chains like Best Buy.  Walmart is too cheap and does not (use cash if you must shop there).   WirelessWhen you touch your phone to the card reader, Google prompts you for a pin.  And that's it.  What's interesting is that to the card reader, it looks like a single use Master Card regardless of your actual credit card.  And you need a data connection, because Google sends out the authorization code real time.  Pretty cool.  On your credit card statement it will say GOOGNFC*merchant name

If your phone gets misplaced, you can deactivate your wallet from the Google website.  Of course you have 2-factor authentication for your Google account, right?  And you have a lock code on your phone. And a good PIN for Google Wallet.

Bottom line, if that card reader was hacked, the bad guys only get a fictitious credit card number that can't be used.  Not bad.


Designing for Privacy & Security : All your base are belong to us

Last week I had a lively discussion with an education expert talking about privacy and security.  This resulted after interpretations of FERPA resulted in universities selling student directories / email addresses to spammers third party marketing organizations. (just because they can, doesn't mean they should).

Then we moved on to the topic of security.   I always start with the assumption that all systems will be compromised, either externally or internally.   That is reality.  But it can be managed.  Starting with that premise, how do you design or improve your system?

First you need to compartmentalize your system to the smallest discrete pieces.  So if one compartment is compromised, none of the others will be.  Cloud systems tend to be monolithic silos.  Break into one part and everything else is exposed.   At my last company we built a separate virtual instance for each customer.  That way if one customer was compromised, it had zero effect on anyone else.

We also segregated the data (we were dealing with patient health records).  But we needed subsets of that data aggregated to do analytics.  Pulling the data is very bad, because that creates a single point of weakness.  Instead, each instance pushed the summary data to the aggregation database. 

Next you need audit.  Record everything.  And make sure that the system administration role is completely seperate from the auditing role.

Finally you need remediation.  What are the protocols to observe when any part of the system is compromised?  

  • Isolate it
  • Fix it
  • Notify those effected
  • Identify the root cause
  • Change to eliminate the root cause

This goes beyond system design into understanding how your customer / users need to interact with the system.  Do all new users really need to default to administrator role?

It is our job to take security and privacy seriously and engage our users to make sure they have what they need without making their lives more difficult (give me two-factor authentication to my cell phone over complicated passwords any day).

update:  I showed this blog post to a college student and they thought I had typos in my title.  To complete your education on video game nostalgia, read this.

Encyrption is easy: Key management is hard

Encryption basically has two use cases:

1. Moving information from point A to point B and not letting anyone else be able to see it during transit.
2. Making sure that when the information is at rest (data, email, etc.) that unauthorized people cannot use it or read it.

You often hear claims like "AES 256 bit encryption" or "We use military grade encryption".  Doesn't mean much.  All encryption uses keys.  These keys are mathematical constructs, when used properly, Keys provide the amount of security necessary.  Who ever has access to the keys, can see your information.

Key management is a very big deal.  Your first consideration is who generates the keys and how do they do it.   For instance, if you are storing data off site, and the service provider generates and stores the key, you have to ask yourself "Do I trust them"? 

This is the model of Google Drive for instance.  In that case you are at the mercy of rogue Google employees, stolen equipment, or unknown subpoenas from government agencies.

Amazon Web Services also will generate the key for you, but not store it.  That's a little better, but you are vulnerable if a copy is being made surreptitiously.

The best case scenario is you generate your own keys using a proven key generation mechanism (a topic for discussion in itself). 

Now comes the hard part.  Whoever has the key can read the information.  How are you protecting and distributing those keys?  What is your access control and audit?  What happens if an employee leaves and has a key?

The best scenario is to assess the balance of risk and usability.  If it is too difficult it won't be used.  One of the slickest methods I've seen for protecting a user / application communicating to a server works like this:

1) The user / application starts a secure session using a public key (PKI uses a lot of overhead)
2) After the connection is made, a single use symetrical key is created (very fast)
3) The session switches to using the same symmetrical key

This gets more interesting when you're talking about backups and disaster recovery.  To fail over to a cloud warm site, that site needs your key to restore the data.  One way to get around this is to have the service provider hold the key and have that key encrypted.  To release the key, you would simply log into the recovery site, enter your credentials and now the key would be released.  They don't need to store your password, just an encrypted hash of the password to verify (and maybe 2 factor authentication to your cell phone).

This is all doable and well worth the time to think through the process from beginning to end.