Over the course of the past few months, as I’ve been involved with my own startup, I’ve been paying a lot more attention to that industry. With a quick and dirty development model, it’s often easy for devs to overlook security. Although some frameworks address a lot of the usual concerns (SQL Injection, XSS), they are susceptible as well.

Let’s take a look at a couple examples that enterprises such as Microsoft and Google now understand, that small development teams might not.

1. Put an email address on your website.

Yes. I’m serious.

I’ve come across several issues on startup sites recently and being the responsible security researcher that I am, have wanted to report them. Spending a half-hour spidering the site trying to find a single contact email is a lose-lose situation. I’m either going to discard the bug and the site will remain vulnerable, or somebody else will publicly disclose it and the typical ‘hair on fire’ scenario will ensure.

2. Respond to the email.

If you don’t respond, I have no clue if you’re addressing the issue. A timeline for a potential fix might also be nice, but not always necessary.

Additionally, security researchers generally like the cred associated with finding a bug (ego boost and resumé builder, you know?). So if you do make an update and have some release notes, why not thank the researcher for preventing your hair from catching on fire more than it already is?

3. Don’t write off the security guy.

6 years ago, there was a large back-and-forth on a Mozilla bug. This year, it was confirmed as a vulnerability known as clickjacking. That Mozilla thread is a pretty classic example of the security disclosure process. If a security researcher is writing to you to report a vulnerability, engage in conversation to understand the concern. Yes, we do sometimes get a little paranoid. But if we emailed you, we’re really just trying to help.

4. Don’t sue the security guy (aka have a disclosure policy).

One reason that I frequently hold off on reporting bugs I may come across is that I can’t find a disclosure policy on the site. As an example, both eBay and Microsoft allow for easy reporting of security vulnerabilities. Most sites, however, don’t and it has happened in the past where a security report has been misconstrued as “hacking”. Providing some assurance that this sort of action won’t be taken or an easy means to report vulnerabilities will open up the communication channel necessary.

Hopefully these short notes will help small companies become more open and willing to accept security bugs from external researchers. Occasionally, we come across issues in the course of our normal web activity and wish to report them. Having a published and easy means of doing this is important in allowing for this communication.

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.