Hacker News new | past | comments | ask | show | jobs | submit login

This is rationalistic.

I guess if my house is burglered because I left the door unlocked, you'd say I'm blameless as long as my "threat model" assumed that any burglers always come in through the window.




A more appropriate house analogy would be getting burgled by someone walking through your not yet existent living room wall of your half constructed house. The security flaw then is not that you're missing a wall, as it's not reasonable to expect walls to be put up instantaneously, but that: a) you left valuables at a construction site or b) you didn't have a fence around the construction site


I mean, yes.

What you're trying to point out is that sometimes the real threat model (i.e. the security concerns list of the stakeholders) is not the same as the explicit modeling they do of threats. And that's actually very common: HTTPS, for example, is based on a model of eavesdropping threats which only applies to a small case of real-world security problems (public WiFi), models a lot of threats which haven't been so important (ISP malfeasance, DNS hijacking) and the resulting certificate system may be worse for some bigger matters of network security (protecting from government eavesdropping, for example) when compared to something like SSH.

But HTTPS is a good security standard for what it does, and we don't claim that HTTPS sucks just because a lot of people have malware on their PCs which can trivially transmit their traffic to untrusted third parties. Rather, it's your responsibility to revise your explicit threat models to accord with your own implicit expectations. Your clients' students are suddenly upset that your client was storing Social Security Numbers on your servers, which could be read by the public via your API? You have hereby discovered that your "explicit" threat model, which left the front door unlocked, was failing to live up to an "implicit" threat model which you had. You now need to either punt the problem off to the client ("we're not storing your sensitive info, our service is not appropriate for that!") or update your explicit model ("we're re-securing our systems and assuming that everything is potentially sensitive, so new permissions systems will guard access").

Running and continuing to run -CURRENT when you know that occasionally the front door's locks can fall off for any or no reason, means that you've accepted this reality.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: