[jcims]

I've been in infosec since the 90's. A lot of times I think this is on us. As much as I respect the technical acumen and creativity of my colleagues in the industry, I don't think we broadly understand risk that well and as a consequence we do a pretty bad job of communicating it. We tend to peg the panic meter with multiplied likelihoods and catastrophized impacts of possible scenarios while directly causing revenue losses by adding sometimes insane amounts of friction to the product delivery process.

That's not to say there aren't cowboy CxOs recklessly ignoring reality, but accepting risks is part of the job. The real answer generally lies somewhere in the middle of the two extremes.

[culturestate]

> As much as I respect the technical acumen and creativity of my colleagues in the industry...we do a pretty bad job of communicating it.

This is the root of so many problems for technical teams in ostensibly non-technical businesses. More developers and engineers really need to embrace the reality that your work doesn't always speak for itself - sometimes you have to speak convincingly on its behalf.

[sgift]

Or you wait until it explodes and then get the money either way. Plus, you don't have to bother with people who do not want to understand, which is the second problem commonly faced by technical teams. I've seen more than enough technical people doing anything they could to make people understand, but at the end of the day Sinclairs adage about people not understanding something if their income depends on not understanding it holds true.

[culturestate]

It's not always about understanding, sometimes it's just about making them believe you. The relationship between business and tech doesn't have to be adversarial - learning how to get yourself a seat at the table and what to say once you get there can be a quality of life improvement across the board.

[jtdev]

Agreed, It doesn’t seem appropriate for info-sec people to be making decisions about what which risks to mitigate, ignore, etc. They should provide input into that process though. We struggled to even get the CIO and CEO to acknowledge and discuss info-sec risk and make decisions regarding what to do about that risk.

[jcims]

Oh yeah, if they aren’t going to even show up to the conversation then it’s time to yank the ripcord.

[stx]

By yank the ripcord do you mean leave the organization? I see this type of behavior at just about every company I have worked. There is no real priority to fix security holes even when they are discovered.

[jcims]

Depends on the circumstance and what your career goals are. If you want to develop your leadership skills, stay put and try to drive change. If you're developing your IR/SOC/threat hunting skills, maybe stay put b/c you're likely to be needed (assuming org is large enough target to get interesting attention). If you're doing assessment/red team/pen testing I'd stay a short while then move on b/c your reports are going to start to be recyclable. If you're doing security architecture/engineering/etc you're going to be resource starved so maybe move on.

Moral of the story is determine how it impacts your career goals and chose.