3 ms·

I left security work for a similar reason. In most companies, Security isn't there to collaboratively build more reliable and dependable products that protect c

I left security work for a similar reason. In most companies, Security isn't there to collaboratively build more reliable and dependable products that protect customer privacy, bringing in a useful perspective of how things can go wrong, similar to QA's role. Instead, Security is there to be the internal police, who treat engineers (and other employees) like criminals, and get recognition and rewards for stopping the company from shipping. The way the vast majority of companies treat Security is deeply dysfunctional and soul-killing to anyone who wants to bring a glass-half-full mentality to work. And in an industry where it has become practically an expectation for people to jump ship after ~4 years, that's too much of a career risk to take. (side note: QA has exactly the same problem.)

Mountain_Skies 2y ago
While I'm sure that's also common, my general impression was that security was there to provide legal protection against being found to have been guilty of willful negligence if there were a breach. There wasn't a top down push for actual security but there was one for getting all the proper boxes ticked so the company could get the compliance certifications required for insurance and to make the legal department happy. Essentially it was financial risk management rather than data risk management.
- solatic 2y ago
  That's the same pessimistic perspective. When SOC2 requires that commits be tied to reviews to show that work was visible and approved by management, and not just some cowboy engineer putting who-knows-what into production, but the control is implemented with a simple Jira issue regex so every developer just puts in place ABC-123 or ABC-999 on every commit, and anyway developers are free to open and close Jira issues without management noticing or approving, then the only people guilty of willful negligence are the so-called security engineers for putting in such weak controls and the auditors for approving them regardless, not to mention the security engineering's leadership's outright fraud for essentially lying about effective controls being in place when actually everybody internally considers it a massive joke. The flip side of the joke being, of course, that everyone internally naturally prefers weaker controls (that help them ship faster compared) to stronger controls. So there's a wink and a nod and a smile and everyone moves on while institutionalized corruption is accepted. Nevermind that strong controls over commit messages can also help build automated documentation, notifications, and clear integrations like being able to link a production outage to the Git commit that triggered it, including full business context and knowledge of who to contact. Note that there are two kinds of perspectives to build this kind of control - the glass-half-full perspective that builds Git -> Slack integrations to let people get notified quickly that a review was requested, including signals that this is a hotfix/simple/not-controversial/rubber-stamp to help get simple stuff approved quickly and deployed quickly, along with collaboration with auditors to get them the reports and commit samples they need. The glass-half-empty perspective is to say, well the auditors already have a built-in integration with Jira, so let's throw it in to Jira, along with a complicated and rigid workflow that forces everything to go through sprint planning and approvals by managers 3 levels up, and if it causes a production outage because something can't be fixed quickly, well that's not really Security's or Compliance's fault, the regulations are the regulations and the auditors are the auditors, and why are you trying to work around The Perfect Process That We Worked So Hard To Build, maybe you have malicious reasons hmmm? And maybe it's time we hired separate operators to run everything in production, like A Real Enterprise Company would, like some banks you've heard of?

Mountain_Skies 2y ago

While I'm sure that's also common, my general impression was that security was there to provide legal protection against being found to have been guilty of willful negligence if there were a breach. There wasn't a top down push for actual security but there was one for getting all the proper boxes ticked so the company could get the compliance certifications required for insurance and to make the legal department happy. Essentially it was financial risk management rather than data risk management.

solatic 2y ago
That's the same pessimistic perspective. When SOC2 requires that commits be tied to reviews to show that work was visible and approved by management, and not just some cowboy engineer putting who-knows-what into production, but the control is implemented with a simple Jira issue regex so every developer just puts in place ABC-123 or ABC-999 on every commit, and anyway developers are free to open and close Jira issues without management noticing or approving, then the only people guilty of willful negligence are the so-called security engineers for putting in such weak controls and the auditors for approving them regardless, not to mention the security engineering's leadership's outright fraud for essentially lying about effective controls being in place when actually everybody internally considers it a massive joke. The flip side of the joke being, of course, that everyone internally naturally prefers weaker controls (that help them ship faster compared) to stronger controls. So there's a wink and a nod and a smile and everyone moves on while institutionalized corruption is accepted. Nevermind that strong controls over commit messages can also help build automated documentation, notifications, and clear integrations like being able to link a production outage to the Git commit that triggered it, including full business context and knowledge of who to contact. Note that there are two kinds of perspectives to build this kind of control - the glass-half-full perspective that builds Git -> Slack integrations to let people get notified quickly that a review was requested, including signals that this is a hotfix/simple/not-controversial/rubber-stamp to help get simple stuff approved quickly and deployed quickly, along with collaboration with auditors to get them the reports and commit samples they need. The glass-half-empty perspective is to say, well the auditors already have a built-in integration with Jira, so let's throw it in to Jira, along with a complicated and rigid workflow that forces everything to go through sprint planning and approvals by managers 3 levels up, and if it causes a production outage because something can't be fixed quickly, well that's not really Security's or Compliance's fault, the regulations are the regulations and the auditors are the auditors, and why are you trying to work around The Perfect Process That We Worked So Hard To Build, maybe you have malicious reasons hmmm? And maybe it's time we hired separate operators to run everything in production, like A Real Enterprise Company would, like some banks you've heard of?