@accidentalciso I've been on both sides of the comments. When I was a newish SA team lead, I had a person from security operations drop a 50+ page printed report from his newly installed vulnerability scanner on my desk. He said "this is my proof that you don't know how to do your job." Needless to say, he never got much traction with my team.

Thankfully that was lots of years ago. Now that I'm running security for my org, I try to keep that jerk in mind as an example of how not to build a relationship with the ops teams.

@accidentalciso i am huffy after reading that….

I want to be mad but honestly I see their point even if I can spend hours breaking it all down

@accidentalciso in my opinion the problem is often not what these teams (can) do and more how they do it.

Somewhere in the thread someone mentions ‘impositions’ and that’s exactly where things go wrong. I’ve seen teams all over the range from terribly bad to extremely capable. The most successful ones were always the ones that considered themselves to be part of IT. Every team that was located in another building and only communicated via email never got anything done, while the loner responsible for 20 teams and joined standups, lunches, and sat between the IT people actually got help doing their job.

The book ‘promising digital risk management: what no to do in cybersecurity’ is really a recommendation how to handle this better. The basis is ‘promise theory’; if you tell people what to do (ie impose), they will do the least amount to get you of their backs, while if you actively participate and ask people what they want to promise, you’ll get immediate ownership and flip your role from being a cop to becoming a counselor.

But it doesn’t stop there; you also need to become part of the process and not in the way of being that red square on a PowerPoint process flow. Act as a real stakeholder because you are. You represent the hidden desires of the users (things they don’t miss until they’re missing; the KANO model described this perfectly https://www.mindmesh.com/glossary/what-is-kano-model). So integrate your processes in every other business process and make it active and interactive. Combine the BIA with product strategy sessions, embed threat modeling with architecture, make risk management a refinement activity, etc etc and automate wherever you can.

Also accept that perfection is the enemy of good. It’s better to do something with 50% efficacy every week than something with 90% once a year. The most frequently encountered example is using sonarqube as SAST. Security teams often don’t like that because “it’s not that good”. Don’t be like that; if teams want to use that, let them, but also force them to make promises on how they follow up on that.

Citibank decided 40 years ago that infosec should be a separate department with their own budget and C role. That was a bad call imho and everyone is now experiencing the fallout of that decision. We need to reverse that and start being part of the business and IT again.

@accidentalciso something that strikes me as a common issue in those comments is that there is a division of duties but it hasn’t been communicated where that division is.

The security teams being complained about could make a big old RACI matrix for the activities they’re involved in and use it to write role descriptions. It would start a conversation that could explain things and maybe uncover some gaps.