> … "and listen to them?"

That's the part I've always had trouble gettin' out of most "management" types. They hire you for your expertise, and then undermine it at every opportunity to "save money" or to exert their "authoritah".

There's significant misalignment of incentives at play here (irrespective of company, generally).

Many "management types" are measured solely and almost entirely by the bottom line - the share price in a traded company, or profits in a private company. Share price is based usually on profits. Usually they're delivering reporting to their boss or the board quarterly. Every dime they save this quarter is "profit" in their eyes.

Obviously there's a line here - you don't want to save the dime that causes the factory to burst into flames and result in 4 months of production downtime. But if that dime can be saved this quarter when times are tough, you'll be seen as a well-performing hero, and next quarter you'll spend a few dimes getting the sprinkler system inspected... Until you need the boost to profits next quarter too(!)

In management and generally in business it's hard to go backwards. Nobody wants to increase their spend on IT unless they are making more money. If they could sign a new deal this quarter, they'll probably give you a decent percentage of that deal as IT budget to get the deal signed (factoring in the risk of the customer not signing).

But in an environment focused almost entirely on pursuit of unrelenting growth of profit or revenue or share price, security simply won't become a priority until you can convince manager-types that the issue is commercial and measurable and that it impacts the bottom line. Even if the issue is unexpected costs of recovery from a breach, the first questions they'll ask are "How likely is it to happen? What will it cost? Can we insure against it? What do our competitors do?" - it's not about preventing the breach, it's about defraying the potential loss of profits without compromising on growth or profits when it isn't a problem.

Hence you'll see people hired to fill roles (new or existing) then being hamstrung by a total and outright refusal to act, because it isn't a commercial problem. Skilled tech leaders are good at turning the problems into language leaders can understand, but there is a limit and a line, and the solution in my view is clear regulation the leaders can "get", involving individual penalties and obligations of competency - even if your core business isn't safety, you have safety obligations as a business to your employees, contractors and the public. It's expected and required that you become suitably competent to do this, or get the expertise to do so, but with you still liable. We need the same for security (in my view).

It's not all bad news - I'm a "management type", but from an almost entirely technical background. Bean counting isn't my style... Maybe we can infiltrate more organisations and bring some basic engineering understanding to decision making? It's frustrating to see most hide behind MBA-waffle though rather than try to actually do real things that make a difference.

> I'm a "management type", but from an almost entirely technical background.

These are the management folks I've historically had the most luck working with. Almost always easy to work out a system of security and backup that actually works (while not wasting massive money to get the job done) with these types of people. I truly wish more "management types" actually had enough technical background to make those wise decisions about the business they're supposed to care about so much. Sadly, it's like "common sense". It's just not all that common.

One of the common complaints I hear from MBA-type CEOs is they don't understand what to look for in a security person. This means they often end up with a similar MBA-style smooth-talker who says they're good at security, and talks the talk.

Assuming you do get some capable security people in, they're part of a "cost centre" - most organisations still see IT as a cost to the business they'd love to eradicate, rather than as a key enabler that allows the organisation to exist. I had hoped covid would cause a shift in mindset as companies realise the enabling effect their IT teams had, but old habits die hard, and it looks good to recharge IT to lower your perceived overheads of doing business by billing other departments internally for IT. That leads to cost cutting and the other issues you pointed out.

Even then, on your final point about listening to them, I share your frustration. Again the common complaint I get is that the security people don't speak the same language, so neither understands the other, and the conversation ends. The security team expect the suits to know why it's bad that the office printer is 15 years old; the suit feels that's prudent cost cutting and assumes it must be fine because it came from a reputable brand.

Ultimately security people need to better communicate to stakeholders that the starting point is for everything to be insecure, and that security is needed to make it secure. And left untouched, it will eventually end up insecure again, through not being patched. Unfortunately this message is just perceived to be self serving, as it's exactly the same message every other department is giving - "our team is really important, give us more money to...."

Some other thoughts in relation to your points:

- the continued insistence on flat network structures with file shares and similar is a huge issue. Same for the security posture of a Windows server in a corporate environment - it's almost entirely based around the idea of a trusted LAN. That's an outdated set of assumptions, but is very often how malware spreads. There's zero reason for workstation to workstation traffic originating from any part of the organisation, irrespective of protocol. Give Devs a separate environment without restrictions, and let IT use a secured jump environment to do their remote connections. Preventing end user devices talking to each other at all would be a good first step.

- Next up would be getting rid of large network shares that half the organisation has read+write access to. Something HTTPS based, with proper logging and 2FA would be a better starting point. Rate limit requests and monitor the logs on the rate limiter. Convince Microsoft somehow to move AD towards a zero trust architecture and run it over HTTPS like a modern service, rather than legacy protocols, or preferably move to something that doesn't require multiple gigabytes of other likely vulnerable services running (DNS, print spooler, file shares, etc) just to give you AAA.

- Security isn't something anyone wants to pay for until it's too late. Businesses often see cyber as another risk on the risk register, and they try to treat the risk through insurance. In the longer term this won't work, because it is becoming a near certainty that the average organisation will be compromised. Insurers don't like to cover for certainties(!) If businesses just see cyber as a financial risk that happens once in a blue moon, expect them to extrapolate the costs per breach and set your budget based on the cost of a breach split across 5 or 10 years. Defenders' dilemma.

- Snake oil security sales pitches very effectively target the MBA suits directly and sell them over hyped claims. You'll then end up pressured to use your finite security budget on their ineffective snake oil, which doesn't actually achieve anything much (and likely slows down systems). This leaves you without budget to develop internal bespoke tools for network monitoring. It's always entertaining to see how many companies can tell if their users iPhones were affected by (for example) NSO Group - can they actually check DNS logs for presence of IOC domain resolution, or do they lack even that level of visibility? But the basics aren't exciting, and the big vendors send well-heeled sales people in with dark backgrounded slide decks to inspire MBA-laden confidence in their snake oil.