That's not true. There are substantially different levels of security required depending on the expected resources an attacker can devote to attacking you, and you can be better or worse at resiliency and recovery (where dollars and hours very much form a continuum).
As an example, you have some fairly non-sensitive private health records. Here are three approaches:
(1) No security at all. You hope nobody is going to bother taking them and using them for anything malicious.
(2) You put in decent security, but a contractor for a new feature left open a vulnerability you didn't know about.
(3) You make sure everything is secure and have security audits over the code that closes the vulnerabilities that a contractor made.
The data for (1) and (2) get hacked and used in a bigger hack on a different service that results in money being stolen.
Now you could say that (1) gets an F, (2) gets a B because at least they tried, and (3) gets an A+ because the data wasn't stolen. This is rubbish - both (1) and (2) resulted in data being stolen and lost customers / lost money / insurance penalties / whatever. The security teams for both (1) and (2) failed utterly and get an F.
If (2) had guessed correctly and nobody had actually devoted those resources then (2) gets a flying colors because the data is safe - but it's just pure gambling. Gambling with security will always be a losing bet in the long run. Rather just make it secure. Going off some strange 'expected resources' is just asking for the time when your data somehow becomes valuable and those resources get brought (or more likely, one of your employees annoys the wrong person with too much free time).
Explaining to your customers that their email addresses weren't valuable enough to do proper security is a great way to lose me as a customer.
What you should realize is that "security teams" are generally not responsible for the level of security at organizations. The information security team will generally present the risk to the business owner of that process, that data, that application, etc and let the business owner decide if they want to accept the risk, mitigate the risk, or avoid the risk. If I went to the CEO of Dropbox and told him the biggest security flaw in Dropbox is that users can share files with each other, he's going to tell me to jump in a lake because that's their entire business.
Nothing is 100% secure, and nothing can be 100% secure. I'm not agreeing or disagreeing with what Prezi is doing, but your notions of all-or-nothing security seem a little out of touch with the reality of business.
You seem to be implying that the fact there are two possible outcomes implies there are only two possible initial states - vulnerable and not vulnerable. If the attacker steals data, the initial state was vulnerable, and if the attacker fails, the initial state was not vulnerable.
This is what poker players call "results-orientated thinking". The initial state is much more like a range of continuous values, where 0 is "having literally no security whatsoever" and 1 is "having security no earthly force can overcome in any scenario".
No private company has perfect security, and perfect security is not desirable, because incremental security has non-zero cost. Does it make sense for a typical firm to spend millions of dollars hardening their office building against the threat of attack by a heavily armed private militia? No, because for most firms the cost of preparing against such an attack outweighs the risk-weighted value of preventing such an attack.
Incrementally improving security narrows the range of successful attacks. Incrementally improving security means fewer attackers will be skilled enough able to successfully infiltrate, and fewer attackers with enough skill will go to the effort to successfully infiltrate. The goal is not to guard against every conceivable attacker, but, in a simplified model, to incrementally improve security until the marginal cost of the last improvement is equal to the marginal value of the reduction of attack scenarios.
> If (2) had guessed correctly and nobody had actually devoted those resources then (2) gets a flying colors because the data is safe - but it's just pure gambling
"Gambling" has no particular meaning in this context, because every decision about security precautions involves weighing known costs against potential risks. The division of security plans is not between "gambling" and "not gambling" but rather between "positive expected value" and "negative expected value".
Either way, the point is, there's a trade off. Kinda like the 80-20 rule. It obviously taken 20% effort to protect against 80% attacks (the casual opportunistic attacks. like preventing sql injections, or locking your front door) and it takes 80% effort to prevent those last 20% attacks (actual Pros). SO "you might as well not have bothered" is somewhat naive in my opinion
Unfortunately, the real world isn't so black and white. The resources someone will put into hacking your site depends on their perceived value of success, and if someone with enough resources values it enough, they will hack your site, no matter what you do.
Anyone who claims to have constructed an unhackable internet service has either constructed a trivial and useless service, or doesn't understand the complexity of software.
"Gambling with security will always be a losing bet in the long run. Rather just make it secure. Going off some strange 'expected resources' is just asking for the time when your data somehow becomes valuable and those resources get brought (or more likely, one of your employees annoys the wrong person with too much free time)."
So, every site you deploy is going to indefinitely withstand armed assault by government forces?
Maybe I can sleep better at night if I didn't go storing them in plain text and I can make up excuses easier, but I still failed. Regardless of how likely any breach was, I failed. My customers have probably jumped ship.
If I store it in plain text and I never get hacked, then I've succeeded. I'm more likely to succeed the more security I add, but if it gets stolen then it doesn't matter anymore. Basically I'm trying to imply that success or failure is a boolean based on real world results and does not depend on the amount of effort placed into the security. The security can influence the result, but once the result occurs the security I used or did not use is irrelevant.
So skimping on security is always a terrible idea. If you know of a way to increase security, then you should increase it. If you offer a bug bounty to improve security, make sure you give a reward for any possible breach that could cause you to get hacked, regardless of whose 'fault' the vulnerability is. If someone can social engineer your developer, then pay out the bounty. Maybe it won't happen next time because now the developer has learned something.
This statement is dead on.
From the Wired article about Max Butler: http://www.wired.com/techbiz/people/magazine/17-01/ff_max_bu...
"Butler spent months plotting to infiltrate and overtake his four competitors, culminating in the two-day hackfest in his overheated safe house high above the Tenderloin. The sites blinked out of existence, their thousands of forum posts later rematerializing on CardersMarket. Iceman now had upwards of 6,000 users on his site, making it by far the biggest carder site on the Internet."
Your security people work 8-5 and go home and leave their work at their office. Most hackers have the ability go days or weeks at a time banging away on your system until they find a crack wide enough to get in and then its game over.
- One copy of your data that is publicly writable is very insecure
- One copy with credentialed access is better
- Redundant copies with credentialed access and PK-signed master-slave synchronization is better still
- Add periodic off-site backups to encrypted media with keys generated using a hash-based one-time password and it's even better
But, oops! Someone left a debug line in the Javascript that runs your restore-from-backup webapp. The auth layer has been silently truncating passwords for the last 10 months to just 3 characters. All that extra security you entered to prevent anyone reading your dataset now means ... absolutely nothing. Anyone could have gotten in, and once they're in the backup app, they've got everything.
Beyond redundant copies to recover after malicious tampering, every single seal must be perfectly tight or you'll leak all your data. I've seen source code for some old Windows 98 malware (analyzed on MSDN, I think) and it's crazy how specific they are. One unchecked array index or untested struct size UINT before a memcpy is all it takes to do a privilege escalation.