I think that's true but orthogonal. IPMI stacks had huge issues for a decade and no one ever upgrades that or the other lights-out management solutions (idrac, etc.). Buying cycles and planning are such that no one ever does responsive buying in the short term, but customers demonstrate a lack of valuing security-by-design regardless of that.
I'm not pushing our solution, just sharing what I have observed. Management engine in practice will _always_ be unpatched. It is _inherently_ unsafe. Anyone who thinks they will keep their patches up to date, unless they work at Amazon or some other entity where they can institutionalize it, is crazy. I had a CIO directly tell me their mean-time-to-patch CVEs in their exposed servers was two years. The statistics on Linux bug lifetimes show that 5Y is not uncommon.
Security is our underpinning but not how we sell (for the reasons I am explaining); there is a very good reason for that which is that people don't actually buy real security, they buy tools to pass audits. You can see shadows of this in the way that companies continue to deploy vulnerable agents even when they are revealed to degrade host security, or in the resistance to internal secure communications (and the reaction in general to TLS1.3).
Security practices inside large enterprises are bizarre and the result of perverse incentives. Let me give an example. The internal use of Websense proxies, for example, will tend to block encrypted content within TLS connections using entropy detection; a malicious actor will simply use an entropy reduction strategy (bananaphone or whatever trivial solution); a legitimate user who is sending an encrypted document will have that document blocked. People justify these tools as meeting the need to allow inspection of traffic; however your Websense administrator is not actually qualified to see all of the traffic that flows over the proxy (for example, does being able to read the CEO's mail make the admin an insider?) and protocols that carry content that is both safe-to-inspect and unsafe-to-inspect (the CFO's password, for example) do not differentiate the two making inspection inherently dangerous. A decade and a half ago, I knew someone who peeked at the loading dock, invoicing and shipping so that they could predict how the quarter was going to time stock sales.
That's a comical example but it's one we have directly encountered in the secure exchange of cryptographic material; but similar issues crop up all over, from the use of transparent proxies and corporate CAs (to "allow inspection") to all manner of craziness.
The facts lead you to a world view that is even more cynical than the idea of security as theater: instead, security as _ritual_. "I need this server to be secure, I'll install some agent"; "We need this server to be inspectable; I'll disable all forward-secrecy protocols and decrypt and inspect the content." And so on.
So .. I don't think it's high volume or anything else like that which is an outcome of process rather than a choice. It's that many companies long ago adopted a world view where any kind of real security is as far from consideration as possible.
I'm not pushing our solution, just sharing what I have observed. Management engine in practice will _always_ be unpatched. It is _inherently_ unsafe. Anyone who thinks they will keep their patches up to date, unless they work at Amazon or some other entity where they can institutionalize it, is crazy. I had a CIO directly tell me their mean-time-to-patch CVEs in their exposed servers was two years. The statistics on Linux bug lifetimes show that 5Y is not uncommon.
Security is our underpinning but not how we sell (for the reasons I am explaining); there is a very good reason for that which is that people don't actually buy real security, they buy tools to pass audits. You can see shadows of this in the way that companies continue to deploy vulnerable agents even when they are revealed to degrade host security, or in the resistance to internal secure communications (and the reaction in general to TLS1.3).
Security practices inside large enterprises are bizarre and the result of perverse incentives. Let me give an example. The internal use of Websense proxies, for example, will tend to block encrypted content within TLS connections using entropy detection; a malicious actor will simply use an entropy reduction strategy (bananaphone or whatever trivial solution); a legitimate user who is sending an encrypted document will have that document blocked. People justify these tools as meeting the need to allow inspection of traffic; however your Websense administrator is not actually qualified to see all of the traffic that flows over the proxy (for example, does being able to read the CEO's mail make the admin an insider?) and protocols that carry content that is both safe-to-inspect and unsafe-to-inspect (the CFO's password, for example) do not differentiate the two making inspection inherently dangerous. A decade and a half ago, I knew someone who peeked at the loading dock, invoicing and shipping so that they could predict how the quarter was going to time stock sales.
That's a comical example but it's one we have directly encountered in the secure exchange of cryptographic material; but similar issues crop up all over, from the use of transparent proxies and corporate CAs (to "allow inspection") to all manner of craziness.
The facts lead you to a world view that is even more cynical than the idea of security as theater: instead, security as _ritual_. "I need this server to be secure, I'll install some agent"; "We need this server to be inspectable; I'll disable all forward-secrecy protocols and decrypt and inspect the content." And so on.
So .. I don't think it's high volume or anything else like that which is an outcome of process rather than a choice. It's that many companies long ago adopted a world view where any kind of real security is as far from consideration as possible.
(not speaking for skyport, speaking for me)