Hacker News Reader

Comment by tyingq | Hacker News Reader

I can see that happening with a CISO, though, in many scenarios. Like if they presented a stark picture of current state and said that work needed to happen that would put planned revenue generating work on hold. And weren't willing to back down on the opinion that it was that critical.

I imagine they wouldn't want to cite differences of opinion on security posture as the reason for departing.

View on HN

It's hard to imagine anyone being that bad of a CISO. No CISO is going to say "shut down the business while we figure out security", not one who's been a CISO multiple times at least. And then for them to not back down or discuss things? Unlikely.

More likely they just weren't getting things done fast enough. CISOs come and go - they're a very short lived position.

>More likely they just weren't getting things done fast enough

I'd be surprised if that warranted the “nature of this situation” language.

It could mean so many things tbh. It's true though, it's a very odd way to phrase it. It certainly doesn't feel like a typical CISO exit, but idk.

If it's a straight-up termination, that's what you'd expect the company to say (it's extremely unusual for a company to provide backstory for why they're firing senior management, even if the reason is really boring, like "we've lost confidence in the current path the organization is on and feel like we need to take a new direction").

I find it odd the CISO gets two weeks to transition things while the Head of Security (does that get an acronym?) got shown to the door. The latter doesn't seem as much like a straight-up termination for ordinary performance reasons.

Then again, I was at a large company where the CISO managed to get insta-fired in a 1:1 with the CIO. I actually saw the person about two minutes after it happened while they were grabbing their jacket and heading for the door — I don't know what was said, but judging by appearances things got really heated and the CIO had enough. Corporate security appeared shortly to begin boxing things up.

I don't know what the "head of security" role is. I have no inside knowledge here. But if he wasn't on many people's reporting chain, and a big part of his role was talking to external people and selling Twitter's security program --- not an unusual portfolio for a CSO! --- then there might have been no reason to ask him to hang around. You tend not to have your outgoing CSO do high-profile meetings to sell your security programs exsternally.

> No CISO is going to say "shut down the business while we figure out security"

I understand why they wouldn't from a personal perspective, however I can imagine situations where this is the right call. For Twitter perhaps not, but I hope the CISO who works at my bank would make this choice if things got bad enough.

The only situations I could see myself saying that are situations where I'd likely be getting authorities involved anyways. For example if the company is covering up an ongoing breach.

Avg tenure of a CISO is low. I read one figure that put it at 18-24 months. Something will happen. CISO gets the heat. Rinse repeat. This is only a little shorter than usual, assuming it was performance related.

The old yarn of security; when things are great they ask, "What do we pay you for?", when things are bad they ask, "What do we pay you for?"

Security is also something that's pretty hard to "bolt on". The best posture is for every engineer writing code to be aware of potential security problems, and design the system to avoid them. But there aren't enough developers with that skillset to fill the open positions, so instead, they throw it over the wall to another team that improves the security. That makes the security team always one step behind, which is probably annoying to everyone. (People try this with testing and operations as well, with similarly poor results.)

> But there aren't enough developers with that skillset to fill the open positions, so instead, they throw it over the wall to another team that improves the security.

The best- run companies I've seen with respect to this have regular and frequent security audits and assign tickets to the team who wrote the code, sometimes even to the developer who wrote it. Also, security is built into the continuous integration as much as possible.

A good security engineering function as an organization goes a long way. As does security engineering having a good relationship with dev teams. It starts with developers believing in security and knowing how to transform that belief into action with appropriate change agents. There is always a lot more than audits for places with good security practices and developers who deal well with frequent audits.

Somebody told me a few years back that the life time of a CISO in a larger organisation is not larger than 24 months. In my organisation that proved to be true so far. Here the rule applies as well.

Perhaps they should check to see if they ever denied the position to Lord Voldemort.

It really feels like the CISO role has become less about the security posture of an organization and more about being a corporate whipping boy-- Predesignated as the go-to sacrificial lamb for when a public leak or government investigation comes knocking.

Hard to find longevity or stability in a role that exists to fail

Once this is known throughout the industry, it also means that the whipping boys keep getting fired and then taking up their next tenure at the startup next door until they're fired again.

To the extent that's true, it sure doesn't seem to stop high-profile people with lots to lose from taking that role.

$$$, golden parachutes, quick vesting equity...

CISO's get paid a ton of money to be that sacrificial lamb. At the same time, since it's widely known that the post is a sacrificial lamb post, there is really not that much to lose.

A CISO told me that the role was to beg for resources and then to get fired if something goes wrong.

Having seen how some CISOs "beg for resources", I pretty fundamentally believe most of this money is wasted anyway.

The only way you can really get better security at a company is to have an ingrained security culture. I.e. developers are continually educated on secure coding practices and new threats, code reviews include security checklists, corporate security training includes continual social engineering tests and an atmosphere of continual improvement.

And yes, that stuff does cost money, but that's rarely the resources I see CISO's fight for. Instead, they fight for lots of expensive software, things like useless, shitty WAFs or poorly built "network monitoring" software (which can be a huge threat vector in itself, just see the SolarWinds fiasco).

Like many other comments here, I don't believe security is something you can "bolt on" at a company. Yes, there are specialized roles that a dedicated security team needs to fill, but unless everyone at the company has a true understanding of the value and importance of security vigilance, you're screwed.

It's a huge problem in security to know what money is wasted or not. Not hacked yet? Lucky or wise?

It's probably like the old saw about advertising. Half of all it is useless, we just don't know which half!

To your point about security culture vs. buying security appliances, you need both. They address different aspects of security. If you're only doing one of them, you're in trouble. Likewise for checkbox ticking security-by-compliance.

I strongly agree though that you can't really bolt on security, it needs to be designed in and part of the culture as much as possible. You'll never get everyone to understand the value though (I wish!).

> code reviews include security checklists,

Can I have a checklist please?

Full stack web dev

Edit: Here I found one https://www.michaelagreiler.com/security-code-review-checkli...

There are some bits phrased the wrong way around (e.g. are session parameters passed in URLs? Check!). You don't want to do that.

But as list of things to consider, if you already understand what you're doing, its not too bad.

I’ve been told similar for CMO - < 1 year tenure on average. The narrative was that CMO are weirdly in a mix of technical and creative and accounting, meaning they need to come up with answers and execution that satisfy CEOs.

So either the company does well and the CMO stays, or not. And the default for most companies is to fail.

Note that Zatko was the Head of Security and apparently immediately terminated. Sethi (CISO) gets a couple of weeks' transition.

I have no idea if that has to do with their day-to-day roles or the specifics of why they were let go, but it is all a bit interesting.

Reply on news.ycombinator.com