4 ms·

I've found that "Do not be Chicken Little" is far and away the most difficult thing to do in startups. This is because the CEO, the Product org, and similar are

by Kalium 5y ago

I've found that "Do not be Chicken Little" is far and away the most difficult thing to do in startups. This is because the CEO, the Product org, and similar are often deeply invested in the idea that they just need a little help and maybe some IR. Helping them understand an accurate assessment, no matter how well-communicated and at the appropriate level of technical detail for the audience, will often come as a rude awakening. In short, Chicken Little-ness is often a matter of the severity of the gap between expectations and findings. Have a clearly communicated, well explained, prioritized, and data-driven plan is valuable. It's especially valuable for the next CISO when the third CISO gets fired for costing too much engineer-time as PMs plead for them to bear in mind the impact on team backlogs of patching. There isn't always a good way to do it right. There's sometimes not any real negotiating space to be more than a figurehead who handles the occasional incident.

mooreds 5y ago
> There's sometimes not any real negotiating space to be more than a figurehead who handles the occasional incident. Should you run from those situations, then? Or is there still valuable experience (or benefit to the company) if you are a figurehead?
- Kalium 5y ago
  If you are someone junior and ambitious and looking to build your career, it's worth asking yourself if the first real incident will lead to leadership learning and adapting or you becoming the Chief Sacrificial/Scapegoat Officer. Do you see clear evidence of them learning painful lessons in other areas, or are they true believers who ignore evidence in favor of convictions? If you are being paid enough to accomplish very little for years, it might be worth considering. In cash, because there's an elevated chance of death-by-incident and you getting nothing for your equity. Much of what you will learn in an environment this unhealthy may prove maladaptive in a healthier one. If you genuinely believe you can win out and make real progress, even after correcting for sunk cost fallacies, it may be worth it. Being able to build an effective security program from scratch in an hostile environment is a huge accomplishment... but also a big if.
datavirtue 5y ago
I watched a CISO come into a startup and take it from a laughing stock (outright fraudulant PCI audits and zero policies by predecessors) to world class compliance. There was a lot of bull-dogging, confrontation, arguing, political back-stabbing, fights with nearly every developer. It was chaos. A lot of it was funny if you were the one sitting back eating popcorn. Most of the big fights involved him trying to get shit done while navigating executive level politics and rediculous antics. This guy is a very rash person and can be abrasive if he "thinks you're dumb" but I don't know if it would have gotten done at the level he was able to do it any other way. It was literally war 24/7 for years.
- mooreds 5y ago
  How did this person not get fired? Did they have board/executive backing? Significant ownership? Was it life or death for the startup to achieve "world class compliance"?
  - nebulous_two 5y ago
    This is the million dollar question. I think there are cases where executives take this kind of aggression like it's tough love and so they argue with the warlike technical folks but ultimately concur, like old habits dying hard
  - PradeetPatel 5y ago
    Possibly due to this person having exceptional stakeholder management skills. Speaking as someone who works in management. Knowing the difference between key stakeholders that you cannot afford to lose, and ones that are disposable are essential.
  - bsder 5y ago
    > Was it life or death for the startup to achieve "world class compliance"? Most likely. Nobody cares about security until they lose actual money because of it. After that, your CISO now has the budget and importance defined by how much money the company got taken for.
  - 5y ago
bitcuration 5y ago
Sure there is a good way to do it right. Yet most IS teams got drawn too much into the polar reaction of either chicken little or boilerplate. From a client standpoint, which came to me as a no surprise but I've learned the hard way for something so obvious, is that they don't understand nor care the whole explanation, articulation of the security issue. All they wanted is you to take care it, don't waste everybody's time by only coming in to find security problem at the worst timing and making impulsive decision as a IS methodology. This calls for build security by design, merge the lifecycle of security management into the modern software engineering, some refer that as DevSecOps, which sounds bolts-on so I doubt that's all there is to it. The software engineering never has given security the weight it deserves. Why now and why this has never been the case since the beginning? Probably because most IS professional are from auditors, operation etc. background. Very few brains are from software engineering background, this is also different from a mere programming background. Script kiddy is not software engineering. Contrary to the article's claim, what it needs is system thinking, STEM brain. People skill will not fix it, only to make it go away.
- Kalium 5y ago
  You're absolutely right. The key idea that's badly needed here is to build secure systems by design, building in security-critical features and design aspects from the start. As you correctly say, this is the best way to do this and addresses what the clients want - just get it done. Having personally experienced several different aspects of this process, I've found that it's almost always much easier said than done. It's been my experience that clients/executives don't just want things done. They want security, but without impacting product roadmaps, development timelines, or design choices. Engineering rarely appreciates someone else trying to tell them how to make design tradeoffs. Product wants security, but this commitment often wavers in the face of increased development time or an ongoing vulnerability management effort. There's a target date to hit, and maybe security isn't viewed as part of the MVP... can't things just be done when they're shipped to prod? How do I, or another security specialist, get leadership of other parts of the organization to enable me to take care of it without wasting everybody's time? Or anybody's time? Generally a lot of people skills, negotiation, and prioritization effort. Security work, no matter how integrated into the overall effort or DevSecOps the implementation, is never completely without cost. Again, you're completely correct. The best way to do what the client wants and just take care of things is to use systems thinking and merge security work into every part of the product lifecycle. Do you think it is perhaps possible that there might be a place for human-wrangling skills in the complex human-computer system that controls how software is developed?

by Kalium 5y ago

mooreds 5y ago

> There's sometimes not any real negotiating space to be more than a figurehead who handles the occasional incident. Should you run from those situations, then? Or is there still valuable experience (or benefit to the company) if you are a figurehead?

Kalium 5y ago
If you are someone junior and ambitious and looking to build your career, it's worth asking yourself if the first real incident will lead to leadership learning and adapting or you becoming the Chief Sacrificial/Scapegoat Officer. Do you see clear evidence of them learning painful lessons in other areas, or are they true believers who ignore evidence in favor of convictions? If you are being paid enough to accomplish very little for years, it might be worth considering. In cash, because there's an elevated chance of death-by-incident and you getting nothing for your equity. Much of what you will learn in an environment this unhealthy may prove maladaptive in a healthier one. If you genuinely believe you can win out and make real progress, even after correcting for sunk cost fallacies, it may be worth it. Being able to build an effective security program from scratch in an hostile environment is a huge accomplishment... but also a big if.

datavirtue 5y ago

I watched a CISO come into a startup and take it from a laughing stock (outright fraudulant PCI audits and zero policies by predecessors) to world class compliance. There was a lot of bull-dogging, confrontation, arguing, political back-stabbing, fights with nearly every developer. It was chaos. A lot of it was funny if you were the one sitting back eating popcorn. Most of the big fights involved him trying to get shit done while navigating executive level politics and rediculous antics. This guy is a very rash person and can be abrasive if he "thinks you're dumb" but I don't know if it would have gotten done at the level he was able to do it any other way. It was literally war 24/7 for years.

mooreds 5y ago
How did this person not get fired? Did they have board/executive backing? Significant ownership? Was it life or death for the startup to achieve "world class compliance"?
- nebulous_two 5y ago
  This is the million dollar question. I think there are cases where executives take this kind of aggression like it's tough love and so they argue with the warlike technical folks but ultimately concur, like old habits dying hard
- PradeetPatel 5y ago
  Possibly due to this person having exceptional stakeholder management skills. Speaking as someone who works in management. Knowing the difference between key stakeholders that you cannot afford to lose, and ones that are disposable are essential.
- bsder 5y ago
  > Was it life or death for the startup to achieve "world class compliance"? Most likely. Nobody cares about security until they lose actual money because of it. After that, your CISO now has the budget and importance defined by how much money the company got taken for.
- 5y ago

bitcuration 5y ago

Sure there is a good way to do it right. Yet most IS teams got drawn too much into the polar reaction of either chicken little or boilerplate. From a client standpoint, which came to me as a no surprise but I've learned the hard way for something so obvious, is that they don't understand nor care the whole explanation, articulation of the security issue. All they wanted is you to take care it, don't waste everybody's time by only coming in to find security problem at the worst timing and making impulsive decision as a IS methodology. This calls for build security by design, merge the lifecycle of security management into the modern software engineering, some refer that as DevSecOps, which sounds bolts-on so I doubt that's all there is to it. The software engineering never has given security the weight it deserves. Why now and why this has never been the case since the beginning? Probably because most IS professional are from auditors, operation etc. background. Very few brains are from software engineering background, this is also different from a mere programming background. Script kiddy is not software engineering. Contrary to the article's claim, what it needs is system thinking, STEM brain. People skill will not fix it, only to make it go away.

Kalium 5y ago
You're absolutely right. The key idea that's badly needed here is to build secure systems by design, building in security-critical features and design aspects from the start. As you correctly say, this is the best way to do this and addresses what the clients want - just get it done. Having personally experienced several different aspects of this process, I've found that it's almost always much easier said than done. It's been my experience that clients/executives don't just want things done. They want security, but without impacting product roadmaps, development timelines, or design choices. Engineering rarely appreciates someone else trying to tell them how to make design tradeoffs. Product wants security, but this commitment often wavers in the face of increased development time or an ongoing vulnerability management effort. There's a target date to hit, and maybe security isn't viewed as part of the MVP... can't things just be done when they're shipped to prod? How do I, or another security specialist, get leadership of other parts of the organization to enable me to take care of it without wasting everybody's time? Or anybody's time? Generally a lot of people skills, negotiation, and prioritization effort. Security work, no matter how integrated into the overall effort or DevSecOps the implementation, is never completely without cost. Again, you're completely correct. The best way to do what the client wants and just take care of things is to use systems thinking and merge security work into every part of the product lifecycle. Do you think it is perhaps possible that there might be a place for human-wrangling skills in the complex human-computer system that controls how software is developed?