Comment by dmbaggett | Hacker News Reader

Comment by dmbaggett | Hacker News Reader

I’m sure this article will get some hate from parts of the cybersecurity world, but to me —- who started in cyber in the 80s (when it was called “trusted computing”) and then came back to it decades later — it really resonates.

The binary fallacy is endemic in cybersecurity. At INKY we do active blocking of phishing emails, so people automatically assume that we must take the position, as many of our peer companies do, that “simulated phishing awareness training is worthless”. What we’ve actually found is that phishing awareness training is useful in that it trains users to be rightly suspicious of the identities of email senders. It doesn’t really train users to spot phish, no, but that doesn’t make it worthless!

On the subject of end users I agree with the author as well. What we’ve found is that if you give users useful guidance they truly understand, on a minority of emails, they actually follow it and click on far fewer bad links, pay fewer fake invoices etc. On the other hand, if you slap a static banner on every incoming email that says “external: be super careful!” and nothing else, users quickly learn to ignore this useless information and ultimately become completely blind to it. (And no, making the banner really fugly doesn’t help any.) In our experience with email security over the last 6 years, escaping the tyranny of binary thinking is absolutely critical to getting users properly engaged.

Trusted computing. Oh man, those were heady days. We really thought we could lick that shit with type enforcement and all that jazz. Spending months analyzing covert channels and trying to hard to build safe systems. Now days all you have to do is send one damned email and you own the whole enterprise. So sad, it’s like it was all for naught. But hey, I still have a pristine copy of the rainbow books if you want one :-)

>We really thought we could lick that shit with type enforcement

Why would type enforcement do any good? When do operating systems enforce types?

My money is on capability based security, Genode and Fuchsia and GNU Hurd when it comes out. Give the users a safe way to run a program without exposing everything to danger, and you'll save everyone a ton of grief.

The present scenario is analogous to building more and more layers of security out of crates of explosives. Any little reaction anywhere becomes a reaction everywhere, because all the code in our systems is trusted.

Trusted Solaris did. It was very complicated to use, so only organisations that really needed it were using it.

The product was discontinued in the late 90's and its core features such as RBAC was included in standard Solaris in later versions. However, the more advanced stuff like tagging of connections, etc, was never included and was dropped with the demise of Trusted Solaris. I think it says a lot that I worked at Sun at the time and I actually never used it.

No offense intended, but it would be easier for you to Google “Type Enforcement” than for me to try and explain in a quick reply.

Full disclosure: I was on the Sidewinder team at Secure Computing way back when.

I knew what type enforcement meant, not allowing assignment of the wrong type to a variable in compiled code. I had no idea they (the security community) overloaded the meaning with something completely different.

Thus, you can see why I was mystified.

object-capability security and type enforcement can go together - require programs to use some kind of hardened JVM/CLR-like typed runtime, then use the type system to model capabilities.

A bunch of research operating systems from the 90s and 00s were based on this kind of design. Microsoft had a largeish engineering team working on one for 9 years (with a notion that it might some day supplant Windows; it was even briefly used in production to run some services, before the project was shut down in 2015). If you're curious about how it worked and why, one of the designers wrote some fascinating posts:

http://joeduffyblog.com/2015/11/03/a-tale-of-three-safeties/ (on how type safety worked)

http://joeduffyblog.com/2015/11/10/objects-as-secure-capabil... (on how the type system was used to model capabilities)

What fraction of the phishing you see was just harvesting credentials? Because every such incident becomes irrelevant if you have unphishable credentials, and yet companies are going to spend a bunch of money on phishing prevention/ training and not move to unphishable credentials.

I don’t know the percentage off hand but it’s certainly quite high and we do see huge numbers of fake O365 login sites in particular (often tailored to the intended victim’s company). The problem, though, is that the less frequent fake invoice or malware drive-by phish does a lot more damage, so frequency isn’t a great gauge of overall implied risk. Many of these other kinds of phish originate from third party accounts that have themselves been taken over. So it’s critical to deploy MFA to protect yourself, but that doesn’t help with all your third party contacts who don’t require MFA themselves. There have also been, in the last 6-9 months, more published on attacks that subvert MFA.

You’d also be surprised how many “please buy gift card” kinds of phish we see. And yes people do fall for them if they get through.

The banners can be more intelligent than just ‘this email is external’ - eg. Google Workspace does a red ugly banner when incoming emails match names of people in your organization, while the default external banner is small and orange.

Reply on news.ycombinator.com