Ask HN: How do you protect sensitive data? | Hacker News Reader

Ask HN: How do you protect sensitive data?

26 pointsThePhysicist6 comments

In your company, how do you handle sensitive (e.g. personal) data in your IT infrastructure? How do you control access to that data and how do you secure it? Do you use pseudonymization, encryption or anonymization? Which tools do you use?

View on HN

I’m not an expert, but just a few personal guidelines off the top of my head:

1) Only store what you absolutely need, you can’t lose what you don’t have

2) When logging, redact passwords and PII

3) Ensure proper user rights using a whitelist (not a blacklist)

4) Use a proper IDS to detect anomalies early

5) Encrypt data at rest (where possible) and look to take advantage of AMD's[0] or Intel's[1] coming features for runtime.

[0] - https://developer.amd.com/sev/

[1]- https://software.intel.com/en-us/sgx

I would also add "avoid it altogether" where practical. Using stripe or similar, for checkout, for example, and you don't have to ever touch a credit card number, CVV, etc.

PII is radioactive. So:

1. Avoid it.

2. Delete it if you don’t need it anymore.

3. Keep it as coarse as your usage for it.

4. If it’s logs then pseudonomise and randomise.

5. If it’s sensitive content then Encrypt it per client and don’t have access to it.

Basically just think about what a thief would have if they stole your database , and make sure you’re happy with the consequences .

I would try to minimize holding data however there are numerous third party software that help mitigate certain data theft in a variety of cases such as using Stripe and Cloudflare.

The most important step is to remember that data is a "toxic asset"[0], in that as long as you have it its a potential danger. Data deletion is a valid strategy for controlling risks, and as bdibs said in another top-level comment here, you can't have a data breach for data you never had in the first place.

Regarding [pseudo]anonymization, there are plenty of deanonymization attacks against various [pseudo]anonymization techniques, so always look into potential problems specific to the type of data you will be storing and [pseudo]anonymizing.

Something I would recommend to handle the data you do decide to keep; look up a HIPPA electronic compliance guide, and see what engineering practices have been settled on by folks who will get hit with enormous fines if there is a breach. Curiously, when there are consequences for breaches due to non-compliance with data-handling best practices, companies get much better at doing the right thing. Industries where data-mishandling laws have teeth tend to have fewer breaches.

Although I do think there are lessons to be learned for virtually everybody from HIPPA compliance guidelines, the approach you will end up using to protect your data will not be a one-size fits all approach; you will need to consider the architecture of your system, the kinds of data you need to keep, what you'll be using it for, whether you will access it regularly, etc.

A good place to start looking is here[1]. It's got a huge number of short "cheat sheet" like guides that cover a narrow topic relating to security. Some ones you might want to check out: password storage[2], authentication[3], attack surface analysis[4], SQL-injection prevention[5], cryptographic data storage[6]. Find guides related to your data and what you want to do with it, then read up, following some of the recommended other links in each cheat sheet.

[0] https://www.schneier.com/essays/archives/2016/03/data_is_a_t...

[1] https://github.com/OWASP/CheatSheetSeries

[2] https://github.com/OWASP/CheatSheetSeries/blob/master/cheats...

[3] https://github.com/OWASP/CheatSheetSeries/blob/master/cheats...

[4] https://github.com/OWASP/CheatSheetSeries/blob/master/cheats...

[5] https://github.com/OWASP/CheatSheetSeries/blob/master/cheats...

[6] https://github.com/OWASP/CheatSheetSeries/blob/master/cheats...

Disclaimer: I am NOT a security expert, just someone with a hobbyist's interest in security. All opinions expressed in this comment are my own, and are not necessarily reflective of the security community at large. I encourage anyone reading this to do their own review of security best practices, the opinions of security researchers, and the technical literature on security.

Reply on news.ycombinator.com