A new Mindcraft moment?

I think this emphasises some of the points in Jon's original article, namely: what is money spent on, and why? Essentially, you're saying that the bottom line of your employer is driven mainly by the reliability of the system, and to a much lesser extent the security, particularly where security impacts reliability.

The following is all guess work; I'd be keen to know if others have evidence either one way or another on this: The people who learn how to hack into these systems through kernel vulnerabilities know that they skills they've learnt have a market. Thus they don't tend to hack in order to wreak havoc - indeed on the whole where data has been stolen in order to release and embarrass people, it _seems_ as though those hacks are through much simpler vectors. I.e. lesser skilled hackers find there is a whole load of low-hanging fruit which they can get at. They're not being paid ahead of time for the data, so they turn to extortion instead. They don't cover their tracks, and they can often be found and charged with criminal offences.

So if your security meets a certain basic level of proficiency and/or your company isn't doing anything that puts it near the top of "companies we'd like to embarrass" (I suspect the latter is much more effective at keeping systems "safe" than the former), then the hackers that get into your system are likely to be skilled, paid, and probably not going to do much damage - they're stealing data for a competitor / state. So that doesn't bother your bottom line - at least not in a way which your shareholders will be aware of. So why fund security?

Many of my customers has the "breach" experiences and they do agree with that kernel is still a big issue inside the enterprise data centres. In the most common case of an attacking path in the wild-cyber-world may look like: Attacker try to find some vulns from web system( router's mgt UI or a regular website) --> exploit it to get the web shell --> privilege escalation of the linux kernel --> root( pwned). In the real world, more than 60% attacks from inside. Hardened kernel may be your last defensive line. See, kernel( and other core infrastructure including compiler( DDC issues), firmware) is still the matter that you should concern.

On the other hand, some effective mitigation in kernel level would be very helpful to crush cybercriminal/skiddie's try. If one of your customer running a future trading platform exposes some open API to their clients, and if the server has some memory corruption bugs can be exploited remotely. Then you know there are known attack methods( such as offset2lib) can help the attacker make the weaponized exploit so much easier. Will you explain the failosophy "A bug is bug" to your customer and tell them it'd be ok? Btw, offset2lib is useless to PaX/Grsecurity's ASLR imp.

To the most commercial uses, more security mitigation within the software won't cost you more budget. You'll still have to do the regression test for each upgrade.