It's because security, audit, and ethics teams aren't judged by how much they enable others, they're judged by how many threats they block. I work at a well-known tech company but joined when they were still very small. Our original security "team", a team of 2 engineers, were highly plugged into the product and the concerns of the then-small engineering team. This team was always willing to help and enable builders to stay security conscious.

As we grew into a large company and our security team became an entire organization at the company, the org lost all connection with the product and became a more classic blocker-based team. The org lost empathy with the product and was judged on no product metrics, so naturally the culture in the org began to just be saying "no" to engineers all the time. A few of the earlier hires still try to help, but for the most part they just block.

"Fast" is not the only descriptor that should be applied to work where a financial audit might be involved. "Correct" probably has a few things to say. "Legal," too.

It's not their job to build, it's their job to ensure that what you build isn't crap on any number of fronts (security, compliance with regulations). You know, important things that impact your users (if you have the best software ever, but it leaks user PII in the HTML because you're a dickhead who wanted to build fast without any regard for security, that's not great).

Sure, if they helped you figure out a way to build, that would be fine. Far more often, I am just told to kill feature/bugfix/concept. At a past job, the security people were against the idea of self password reset at all.

The security team at my current company also refuse to allow self password resets. The only way is to call our service desk and give them your DoB and last 4 of your SSN... and they completely ignored me when I pointed out that for at least half the population the US that information is more or less public due to several data leaks.

I haven't worked much with financial teams, but the security teams I've worked with have absolutely helped build our products. They put practices & systems in place that made a golden path to getting software green-lit for production.

Same with QA. Fire those guys!

This, but non-ironically.

Security is a discrete objective with a distinct success / failure metric.

"Responsible innovation" is not discrete.

In simplest terms, one can judge if security is succeeding with a security audit. Either access is avaiable to the right parties, or not.

One cannot say with certainty if one is being a responsible innovator.

If your products are great bc they are are built quickly on top of a swiss cheese security policy, the security team is à blocker (or at worst, a delayer) of the company bankruptcy from fraud/fines/asset loss.

If responsible innovation is blocking product, its not certain what (if any consequences) there will be if the product is unblocked. Therein lies the problem

I used to feel the same when I worked for a bank. And then I worked at a place where security was so unregulated that TBs of data and millions of user’s accounts could be stolen just with a shared password and no one would notice

Ages ago, one of the managers on my team was complaining about how unhelpful the rest of the company was being (with our team's upcoming product release). I explained the job of everyone else in the building was to say "No" and their job was to get those people to say "Yes".

"But, but, but aren't we all on same side?!"

"Oh you sweet innocent child..."

Once this manager understood the rules, they did quite well playing the game.

I'm in a highly regulated industry segment and work in an information security related function. You've made my day.

You're welcome!

> financial audit teams and so-called "IT security"

They do fill a role that actually needs to be filled, though.

Yes. Does the GP think the same thing about security engineering teams? What about QA engineers?

Not really Poe's law. The statement may be exaggerated, but is also true to a degree.

> ...without a clear indicator of the author's intent, every parody of extreme views can be mistaken by some readers for a sincere expression of the views being parodied.

This checks all the boxes on Poe's law:

  [x] Parody
  [x] Reductio ad absurdum intent
  [x] Extreme view
  [x] Mistaken as sincere