That's the logical extreme of the "network segmentation" bullet I listed above. The problem with endpoint security and internal trust is that the endpoints aren't the most valuable goal on the internal network; we attack them because they're pivots to internal applications, which are the most valuable goal. So making it harder to compromise an individual desktop from within an internal network doesn't really do much. Making it harder for an arbitrary desktop to reach the document management server, though, does make a difference.

* No unfiltered attachments in email, for definitions of "filter" that include "stripping out content and re-rendering in simpler formats", like "PDF->RTF" or something equally terrible.

* Fine-grained segmentation of all networks on need-to-know basis, informed by the org chart and detailed role descriptions for virtually all employees.

* No employee access to arbitrary Internet sites

* For employees that require Internet access, air gaps between computers that can hit Google and computers that can access company email

* Formal audits for minor software releases

* Expensive, heavily tested secure coding training for all developers

* Adoption of secure coding/design standards ("this is the XYZcorp way to make an SQL query" and "this is the XYZcorp way to render HTML"). Strict bans on deprecated interfaces.

* Employee access to sensitive internal applications (like document and image management) gated through Citrix-like environments, so you have to remote terminal in to get to the browser that actually talks to the application.

* Extremely minimal access provided to VPN users.

* Total 8021x-style lockdown of network ports and fascist policies against bringing own devices.

And so on.

There is zero chance this is ever going to describe any huge company.

You would also need to ask how much the company is willing to trade off productivity for security. With enough budget, you could have security like that of any three-letter-agency, or even more draconian, but good luck getting work done, or retaining employees.

That's not to say that user data should go unprotected; the majority of people in the company should have zero access to that, such that even if their systems were compromised user data would remain safe.

Check with a Swiss bank. They typically spend 10% of their IT costs on security.

Swiss banks have a tradition of security overkill. Branches in nice areas have bulletproofing rarely seen in the US outside of very bad neighborhoods. It would be un-Swiss not to be prepared.

> infinite monetary and user acceptability/retraining budget

In that case every employee would have one or more security people standing behind them the whole day. No email would be opened without a phone call to the sender to confirm that it's not spear phishing.

But more realistically, loads and loads of 24/7 monitoring and internal auditing and testing. Attackers have to abuse something to get in, and if the company is internally doing the same thing with a large enough team, 99% is probably secure. Hackers will probably look for easier targets then. Still, this is quite unrealistic to happen in present times.

That's a large part of what makes me no longer enthusiastic about working in the space at all.

Which, as it happens, I've rather pointedly not been.

Two big classes of flaws that seem new:

* Exploitable memory corruption (really only began to be recognized in late 1995, and only became mainstream with modern heap exploits, perhaps 10 years later). Really, this trend meaningfully picks up speed with the dawn of the clientside exploit era, in which we no longer obsess about Sendmail vulnerabilities and start obsessing about browser vulnerabilities. In essence: the revelation that memory-unsafe languages are insecure in the presence of virtually any defect, not merely unsafe buffer copies on the stack.

* Side channels, not so much for crypto (crypto attacks are fun but rare, and certainly not the low-hanging fruit used to compromise most networks) but for weaponization of other flaws. Side channels are the other side of the "covert channel" coin, which coin basically describes "surreptitious unintended exfiltration of data from software". So here you're also talking about things like blind SQLI.

In-band signaling and the insecurity of using simple strings to encode program behavior would be a third major class of foundational flaws, but it isn't new; it was well-known in the late 1980s. But industry certainly hasn't adapted to eliminate it; witness, for instance, very widespread Java application frameworks that embed executable server-side scripting code in UI inputs!

Heartbleed and Shellshock come to mind. There have been others, and the "revelations" of NSA et al actively poking or preventing the closing of holes in all kinds of software and hardware.

ROP attacks, or more specifically, that you can build an arbitrarily powerful program given only a buffer overflow to an unexecutable stack and libc.

Too bad we don't have a viable decentralized option, I don't at all relish the idea of Facebook Inc. owning my online identity.

This argument was implied. If they will own your data when you put your HR database on the internet, maybe you shouldn't put your HR database on the internet to begin with. I can't be the only one who feels that computer security is a field that is insufficiently mature, yet people put confidential data on the internet all the time even though the technology isn't ripe yet to do so safely.

Compare this attitude with the extremely conservative approach in rocketry. The technology is positively from the stone age, but everyone agrees that it is well understood. You can't take any other approach when space missions are multi-decade projects and the price tag has nine figures.