Authority in Security

I've run into this several times now and I'm trying to formulate my thoughts on the problem. There's a strange dichotomy working in Security: you're tasked to review and ask questions about systems you don't own, and to give requirements or suggest improvements. I want to be a collaborator with owners, working together in the design of a service, hopefully thinking about a problem that they were too close to see - the equivalent of proof-checking an essay. I'm seen though, as someone who enforces rules of their own creation, coming down on owners to exercise authority - the teacher with a birch ruler.

Some of the interactions I've had felt jarring because I got responses that implied I wasn't a positive influence, rather a blocking one, or at worst, a detriment: loading on work where it wasn't needed, asking questions I didn't have the right or seniority to ask, adding requirements where the team was already stretched. The conversation goes something like this:

Me: hey, what do you think about doing X?
PO: no, it works like this and there's no problem here
Me: maybe X would be good, it would prevent Z
PO: we can't do X, it's not <needed|workable|a good solution>
Me: ok, X might not be right then, how about Y instead?
PO: where is this coming from, we didn't do X or Y in <other service|other company>, why should we do it here?

That exchange is my fault. It's difficult to stop yourself taking it personally, to avoid internalising the idea that you're blocking or nagging them. To do so is to forget that the response could be the result of any number of things:

• how Security is seen has a long history: maybe this person worked with a difficult or unsympathetic Security team before and were scarred by the experience
• maybe they're worried that doing X or Y will lead to missed deadlines or wasted time
• they felt that we didn't provide valuable input on a previous problem, and so lost some faith in our ability
• they have external objectives and pressures that don't align with security's right now, and plan to come back to it.
• maybe your idea is genuinely misfounded, and they're just trying to tell you why, but they're swamped and don't really have time to walk through it.

Taken verbatim from a recent conversation I had, after I had dropped into a channel to ask an implementation question:

"Part of the problem is that security has a lot of authority and it's hard to be casual at the same time."

I don't want to exercise any authority, it's assumed and projected as a function of being in this team. I empathise that speaking to someone who can escalate an issue to get their way over yours is threatening or unpleasant - I'd be defensive with that person too.

I need to be more aware of that prejudice, and explain myself better - understanding that I can't just appear and ask questions that imply I might be requiring changes. I've started doing this more but it's fairly hard to sound natural: "Hey, I came across X and was just wondering how it works", then expanding the conversation to the point I'm concerned about. It's leading to more amicable conversations to be fair, and hopefully I'm changing the reputation of the team a little in the process. The desired end state is that product teams see us as a resource to be used to enhance or validate the quality of their own output. That's a difficult state to reach, and doesn't it absolutely doesn't happen accidentally.

It's funny that engineering has lore around feedback loops, observability, abstraction etc that I have to be aware of and understand to take part in the process but engineers aren't aware of any thought work from Security in the last 10 years. We know about giving feedback in automation and not dropping requirements last minute, we made up our own terms for how to work with teams and people have written textbooks about how Security can integrate more tightly and cause less friction while keeping standards up. It's well-understood that being too adversarial and combative leads to employees and engineers taking shortcuts to getting around controls, increasing risk - we absolutely think and care about UX and developer psychology! The golden rule applies: "Don't be an asshole", and maybe that's the area that needs some work.

We have requirements, and targets like any team: we are required to take responsibility for the security of things we have minimal exposure to, and limits to the depth we can explore in a fixed-term engagement. That breeds misunderstandings and issues with communicating, and I guess this has been a visceral topic of experience and growth for me personally. My takeaway is that I need to exude curiosity, not authority.