2

Hopefully my question isn't too unique to be asked here, but I didn't find anything similar after some searching.

As a relatively inexperienced developer (only one large project excluding this one under my belt) how can I best secure data at rest in MSSQL and in memory?

The server on which this application would run is itself HIPAA compliant to my knowledge (not my responsibility) but I imagine that a client machine would be highly vulnerable from within, and a severe HIPAA violation could cost my family's business dearly. I am in no hurry to finish this project at the cost of quality, as I am trying to help the business succeed, not get criminal charges pressed against them...

If it is too wide-scoped or vague of a question to answer here, I would be happy to get some security reading recommendations aimed at programmers. There is so much conflicting information and disagreement on best practices that a simple google search for a security layman is overwhelming. (If it helps, I'm working in C++ and MSSQL mostly, and limited to Windows environments, and avoiding non- "commercial-free" licensed tools like the plague.)

Austin
  • 23
  • 6

1 Answers1

0

Any comprehensive solution is going to require depth, i.e. security in layers. Aside from hardening the system, restricting network access, having a substantial logging, auditing, and SIEM approach, you'll want to protect the data within the database as well.

Obviously protect any login information with a strong hashing algorithm like PBKDF2 w/ HMAC/SHA-256 and 100,000+ iterations or bcrypt or scrypt. MD5 or SHA-1 with single iterations is effectively plaintext, even with salting. Bcrypt will take care of the salting problem and the adaptive cost problem as well.

For HIPAA specifically, protecting PII is crucial. For sensitive information that you must be able to recall, strong encryption is a must (AES-128 or 256, using CBC, CTR (with unique nonces), or GCM mode recommended). Proper key management is also critical. Using a DUKPT system or some other transformative key derivation scheme to reduce key overlap or (ideally) an HSM to manage and protect the keys is a strong move in this regard.

For information that is sensitive but not required to be retrievable, but merely searchable, a strong cryptographic hash function (CHF) like SHA-256 (or even better, HMAC/SHA-256) will allow you to do (non-fuzzy) searching against that data in queries while protecting it at rest. This is less common in enterprise environments but for HIPAA concerns it should at least be evaluated against your performance needs.

If you have more specific questions, feel free to comment here. If they're self-contained we can answer inline but larger ones probably merit their own question on the site.

Oh, and never roll your own crypto. There are C# or .NET libraries written by professional cryptographers and cryptography developers to do anything you need. They are audited, updated, and have a high number of eyeballs on them. BouncyCastle is probably the best known.

Andy
  • 209
  • 4
  • 16
  • I'm going to try to reiterate your suggestions, to be sure that I understood them. 1) Authentication and other non-retrievables should be hashed with a known salt using a slow algorithm like SHA-256 w/ many iterations, PBKDF2, bcrypt. I didn't find libraries for the latter two in C++, and as you said, I shouldn't attempt to make my own. 2) PII at rest in the database, should be encrypted with something like AES-256. I'm not sure if MSSQL already does this, or if I need to manually encrypt data when storing it in my code... 3) That leaves memory vulnerable, at least on the server. Inevitable? – Austin Jan 16 '16 at 07:51
  • So much terminology I didn't know! I had to reread your post maybe 20 times with a google window next to it and a notepad! I really appreciate it though. – Austin Jan 16 '16 at 07:57
  • 3) If the data is ever in plaintext on your system, then the "in memory" concern exists. The only way to mitigate this is to use data encrypted with asymmetric or symmetric keys that never exist on the system. – Andy Jan 16 '16 at 08:08
  • 1) look at BouncyCastle's `org.bouncycastle.crypto.providers.BCrypt` class (away from keyboard so trying to remember off the top of my head) as a provider. There should also be a C# provider for OpenSSL PKCS5 PBKDF2. – Andy Jan 16 '16 at 08:12
  • 2) I don't remember if MSSQL has built-in encryption (look for terms like Oracle's TDE or Transparent Data Encryption, etc.) but you could implement this fairly trivially with an AES cipher instance inside your DAO for persistence and retrieval (think AOP). – Andy Jan 16 '16 at 08:15
  • If you are down-voting this answer, do you have any specific critiques or comments? – Andy Mar 01 '16 at 04:31