4

I am building a hosted (SaaS) web application that stores PII like name, email address, and employer of the user. As of right now, I don't intend to ever store credit card numbers or bank account numbers or social security #'s, etc.

I would like to be able to claim that my service follows "industry standard" security practices, but I am a bit unclear what this means today. For example, is a password hashed by SHA-1 or MD5 that is properly salted still considered industry standard and acceptable?

In general, what guidelines do people follow to determine "industry standard" practices from all angles so 1) you are adequately protected from malicious activities and 2) won't get hammered in court if you ever get sued over a data leak.

Also, how does this change if you store more sensitive PII like a social security #?

Gilles 'SO- stop being evil'
  • 51,415
  • 13
  • 121
  • 180
Michael Berkhart
  • 273
  • 1
  • 3
  • 6

5 Answers5

3

If you are not using credit cards, or similar information, you (thankfully) do not need to consider PCI-DSS compliance.

For general 'industry standards' based security for web hosting, look to OWASP:

https://www.owasp.org/

david6
  • 161
  • 6
3

Storing passwords hashed with MD5 or SHA1 is not best practice. Best practice is to hash passwords using bcrypt, scrypt, or PBKDF2 (see also this question) or to use a third-party authentication provider, like OpenID or (shudder) Facebook Connect.

I second @david6's recommendation that OWASP is a good source of information for industry standards for web security.

I also recommend that you read the following two introductions to secure web software development:

They provide information that I think every web developer needs to know. I think it is fair to say that best practice is for your developers to have some familiarity with security issues and how to write secure code. For more reading, see my answer about this.

You might also consider testing the security of your website, either using automated pentesting tools, or by hiring a penetration tester or penetration testing service. This is probably unnecessary if your site does not collect or store any sensitive information. But if it stores sensitive information, then this is probably a good idea.

Community
  • 1
D.W.
  • 98,860
  • 33
  • 271
  • 588
1

I work in government. We follow the FBI's Criminal Justice Information Systems Policy. You can find it here.

Paul Ackerman
  • 466
  • 2
  • 5
1

You need to look at industry and country specific regulations, some important examples are:

etc

Rory Alsop
  • 61,474
  • 12
  • 117
  • 321
0

If all you are storing is name, email, and employer, then things do get much easier for you. But OWASP/SANS/WASC is only one half of the picture. You need to look at the way you store the data, not only how it is accessed. Storage issues look at the database, the server, and the controls internal to your organization that control who has access to that data.

As for SSN, look at: http://www.gao.gov/new.items/d071023t.pdf

On the other hand, what you could do to certify yourself is get 3rd party verification of the security of your site by hiring a professional website tester. That way, instead of saying that you comply to a standard (which don't fully exist yet), you can say that you passed an external security test. Independent testers can be found inexpensively, geared towards small sites on tight budgets.

schroeder
  • 125,553
  • 55
  • 289
  • 326