Comment by Diggsey | Hacker News Reader

Comment by Diggsey | Hacker News Reader

Parent Full thread

Companies already pay for cyber insurance because they don't want to take on this risk themselves.

In principle the insurance company then dictates security requirements back to the company in order to keep the premiums manageable.

However, in practice the insurance company has no deep understanding of the company and so the security requirements are blunt and ineffective at preventing breaches. They are very effective at covering the asses of the decision makers though... "we tried: look we implemented all these policies and bought this security software and installed it on our machines! Nobody could possibly have prevented such an advanced attack that bypassed all these precautions!"

Another problem is that often the IT at large enterprises is functionally incompetent. Even when the individual people are smart and incentivised (which is no guarantee) the entire department is steeped in legacy ways of doing things and caught between petty power struggles of executives. You can't fix that with financial incentives because most of these companies would go bankrupt before figuring out how to change.

I don't see things improving unless someone spoon-feeds these companies solutions to these problems in a low risk (ie. nobody's going to get fired over implementing them) way.

The typical IT department in a large corporation is way too big to have reasonable visibility into what it manages. There's no way to build reasonable controls that work out when you have 50K programmers on staff. It's purely a matter of size.

Often the end result is having just enough red tape to turn a 2 week project into an 8 month project, and yet not enough as to make sure it's impossible for someone to, say, build a data lake into a new cloud for some reports that just happen to have names, addresses and emails. Too big to manage.

Which gets back to the original point, that the real answer is to minimize how much data is held in the first place. Controls will always be insufficient to prevent breaches. Companies and organizations should keep less data, keep it for less time, and try harder to avoid collecting PII in the first place.

I don't disagree with you but as someone who has thought a moderate amount about data security at a "bigco", I will point out something I haven't seen people really talk about...

Audit trails (of who did/saw what in a system) and PII-reduction (so you don't know who did what) are fundamentally at odds.

Assuming you are already handling "sensitive PII" SSNs/payroll/HIPPA/creditcard# data appropriately, which constitutes security best practice: PII-reduction or audit-reduction?

Let's say the CEO agrees with you and is horrified of any amount of unnecessary data being stored.

How would they then enforce this in a large company with 50k programmers? This was what the previous post was discussing.

Not to mention, a lot of this data is necessary. If you're invoicing, you need to store the names and many other kinds of sensitive data of your customers, you are legally required to do so.

Culture change. The CEO can push for top down culture change to get people to care about this stuff. Make it their job to care. Engage their passion to care.

It’s not easy, but it can move the needle over time.

That is easier said than done. In order to achieve that effectively every employee that has any relation to data needs to be constantly vigilant in keeping PII to a minimum, and properly secured.

It is often much easier to use an email address or a SSN when a randomly generated id, or even a hash of the original data would work fine.

I'm not saying that we shouldn't put more effort into reducing the amount of data kept, but it isn't as simple as just saying "collect less data".

And sometimes you can't avoid keeping PII.

Reply on news.ycombinator.com